]>
Commit | Line | Data |
---|---|---|
74e55a1e TL |
1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group R. Droms | |
8 | Request for Comments: 2489 Bucknell University | |
9 | BCP: 29 January 1999 | |
10 | Category: Best Current Practice | |
11 | ||
12 | ||
13 | Procedure for Defining New DHCP Options | |
14 | ||
15 | Status of this Memo | |
16 | ||
17 | This document specifies an Internet Best Current Practices for the | |
18 | Internet Community, and requests discussion and suggestions for | |
19 | improvements. Distribution of this memo is unlimited. | |
20 | ||
21 | Copyright Notice | |
22 | ||
23 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
24 | ||
25 | Abstract | |
26 | ||
27 | The Dynamic Host Configuration Protocol (DHCP) provides a framework | |
28 | for passing configuration information to hosts on a TCP/IP network. | |
29 | Configuration parameters and other control information are carried in | |
30 | tagged data items that are stored in the 'options' field of the DHCP | |
31 | message. The data items themselves are also called "options." | |
32 | ||
33 | New DHCP options may be defined after the publication of the DHCP | |
34 | specification to accommodate requirements for conveyance of new | |
35 | configuration parameters. This document describes the procedure for | |
36 | defining new DHCP options. | |
37 | ||
38 | 1. Introduction | |
39 | ||
40 | The Dynamic Host Configuration Protocol (DHCP) [1] provides a | |
41 | framework for passing configuration information to hosts on a TCP/IP | |
42 | network. Configuration parameters and other control information are | |
43 | carried in tagged data items that are stored in the 'options' field | |
44 | of the DHCP message. The data items themselves are also called | |
45 | "options." [2] | |
46 | ||
47 | This document describes the procedure for defining new DHCP options. | |
48 | The procedure will guarantee that: | |
49 | ||
50 | * allocation of new option numbers is coordinated from a single | |
51 | authority, | |
52 | * new options are reviewed for technical correctness and | |
53 | appropriateness, and | |
54 | * documentation for new options is complete and published. | |
55 | ||
56 | ||
57 | ||
58 | Droms Best Current Practice [Page 1] | |
59 | \f | |
60 | RFC 2489 Defining New DCHP Options January 1999 | |
61 | ||
62 | ||
63 | As indicated in "Guidelines for Writing an IANA Considerations | |
64 | Section in RFCs" (see references), IANA acts as a central authority | |
65 | for assignment of numbers such as DHCP option codes. The new | |
66 | procedure outlined in this document will provide guidance to IANA in | |
67 | the assignment of new option codes. | |
68 | ||
69 | 2. Overview and background | |
70 | ||
71 | The procedure described in this document modifies and clarifies the | |
72 | procedure for defining new options in RFC 2131 [2]. The primary | |
73 | modification is to the time at which a new DHCP option is assigned an | |
74 | option number. In the procedure described in this document, the | |
75 | option number is not assigned until specification for the option is | |
76 | about to be published as an RFC. | |
77 | ||
78 | Since the publication of RFC 2132, the option number space for | |
79 | publically defined DHCP options (1-127) has almost been exhausted. | |
80 | Many of the defined option numbers have not been followed up with | |
81 | Internet Drafts submitted to the DHC WG. There has been a lack of | |
82 | specific guidance to IANA from the DHC WG as to the assignment of | |
83 | DHCP option numbers | |
84 | ||
85 | The procedure as specified in RFC 2132 does not clearly state that | |
86 | new options are to be reviewed individually for technical | |
87 | correctness, appropriateness and complete documentation. RFC 2132 | |
88 | also does not require that new options are to be submitted to the | |
89 | IESG for review, and that the author of the option specification is | |
90 | responsible for bringing new options to the attention of the IESG. | |
91 | Finally, RFC 2132 does not make clear that newly defined options are | |
92 | not to be incorporated into products, included in other | |
93 | specifications or otherwise used until the specification for the | |
94 | option is published as an RFC. | |
95 | ||
96 | In the future, new DHCP option codes will be assigned by IETF | |
97 | consensus. New DHCP options will be documented in RFCs approved by | |
98 | the IESG, and the codes for those options will be assigned at the | |
99 | time the relevant RFCs are published. Typically, the IESG will seek | |
100 | input on prospective assignments from appropriate sources (e.g., a | |
101 | relevant Working Group if one exists). Groups of related options may | |
102 | be combined into a single specification and reviewed as a set by the | |
103 | IESG. Prior to assignment of an option code, it is not appropriate | |
104 | to incorporate new options into products, include the specification | |
105 | in other documents or otherwise make use of the new options. | |
106 | ||
107 | The DHCP option number space (1-254) is split into two parts. The | |
108 | site-specific options (128-254) are defined as "Private Use" and | |
109 | require no review by the DHC WG. The public options (1-127) are | |
110 | ||
111 | ||
112 | ||
113 | ||
114 | Droms Best Current Practice [Page 2] | |
115 | \f | |
116 | RFC 2489 Defining New DCHP Options January 1999 | |
117 | ||
118 | ||
119 | defined as "Specification Required" and new options must be reviewed | |
120 | prior to assignment of an option number by IANA. The details of the | |
121 | review process are given in the following section of this document. | |
122 | ||
123 | 3. Procedure | |
124 | ||
125 | The author of a new DHCP option will follow these steps to obtain | |
126 | approval for the option and publication of the specification of the | |
127 | option as an RFC: | |
128 | ||
129 | 1. The author devises the new option. | |
130 | ||
131 | 2. The author documents the new option, leaving the option code as | |
132 | "To Be Determined" (TBD), as an Internet Draft. | |
133 | ||
134 | The requirement that the new option be documented as an Internet | |
135 | Draft is a matter of expediency. In theory, the new option could | |
136 | be documented on the back of an envelope for submission; as a | |
137 | practical matter, the specification will eventually become an | |
138 | Internet Draft as part of the review process. | |
139 | ||
140 | 3. The author submits the Internet Draft for review by the IESG. | |
141 | Preferably, the author will submit the Internet Draft to the DHC | |
142 | Working Group, but the author may choose to submit the Internet | |
143 | Draft directly to the IESG. | |
144 | ||
145 | Note that simply publishing the new option as an Internet Draft | |
146 | does not automatically bring the option to the attention of the | |
147 | IESG. The author of the new option must explicitly forward a | |
148 | request for action on the new option to the DHC WG or the IESG. | |
149 | ||
150 | 4. The specification of the new option is reviewed by the IESG. The | |
151 | specification is reviewed by the DHC WG (if it exists) or by the | |
152 | IETF. If the option is accepted for inclusion in the DHCP | |
153 | specification, the specification of the option is published as an | |
154 | RFC. It may be published as either a standards-track or a non- | |
155 | standards-track RFC. | |
156 | ||
157 | 5. At the time of publication as an RFC, IANA assigns a DHCP option | |
158 | number to the new option. | |
159 | ||
160 | 4. References | |
161 | ||
162 | [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, | |
163 | March 1997. | |
164 | ||
165 | [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor | |
166 | Extensions", RFC 2132, March 1997. | |
167 | ||
168 | ||
169 | ||
170 | Droms Best Current Practice [Page 3] | |
171 | \f | |
172 | RFC 2489 Defining New DCHP Options January 1999 | |
173 | ||
174 | ||
175 | [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information", | |
176 | RFC 2142, November 1997. | |
177 | ||
178 | [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | |
179 | Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. | |
180 | ||
181 | 5. Security Considerations | |
182 | ||
183 | Information that creates or updates an option number assignment needs | |
184 | to be authenticated. | |
185 | ||
186 | An analysis of security issues is required for all newly defined DHCP | |
187 | options. The description of security issues in the specification of | |
188 | new options must be as accurate as possible. The specification for a | |
189 | new option may reference the "Security Considerations" section in the | |
190 | DHCP specification [1]; e.g. (from "NetWare/IP Domain Name and | |
191 | Information" [3]): | |
192 | ||
193 | DHCP currently provides no authentication or security mechanisms. | |
194 | Potential exposures to attack are discussed in section 7 of the | |
195 | DHCP protocol specification [RFC 2131]. | |
196 | ||
197 | 6. IANA Considerations | |
198 | ||
199 | RFC 2132 provided guidance to the IANA on the procedure it should | |
200 | follow when assigning option numbers for new DHCP options. This | |
201 | document updates and replaces those instructions. In particular, | |
202 | IANA is requested to assign DHCP option numbers only for options that | |
203 | have been approved for publication as RFCs; i.e., documents that have | |
204 | been approved through "IETF consensus" as defined in RFC 2434 [4]. | |
205 | ||
206 | 7. Author's Address | |
207 | ||
208 | Ralph Droms | |
209 | Computer Science Department | |
210 | 323 Dana Engineering | |
211 | Bucknell University | |
212 | Lewisburg, PA 17837 | |
213 | ||
214 | Phone: (717) 524-1145 | |
215 | EMail: droms@bucknell.edu | |
216 | ||
217 | ||
218 | ||
219 | ||
220 | ||
221 | ||
222 | ||
223 | ||
224 | ||
225 | ||
226 | Droms Best Current Practice [Page 4] | |
227 | \f | |
228 | RFC 2489 Defining New DCHP Options January 1999 | |
229 | ||
230 | ||
231 | 8. Full Copyright Statement | |
232 | ||
233 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
234 | ||
235 | This document and translations of it may be copied and furnished to | |
236 | others, and derivative works that comment on or otherwise explain it | |
237 | or assist in its implementation may be prepared, copied, published | |
238 | and distributed, in whole or in part, without restriction of any | |
239 | kind, provided that the above copyright notice and this paragraph are | |
240 | included on all such copies and derivative works. However, this | |
241 | document itself may not be modified in any way, such as by removing | |
242 | the copyright notice or references to the Internet Society or other | |
243 | Internet organizations, except as needed for the purpose of | |
244 | developing Internet standards in which case the procedures for | |
245 | copyrights defined in the Internet Standards process must be | |
246 | followed, or as required to translate it into languages other than | |
247 | English. | |
248 | ||
249 | The limited permissions granted above are perpetual and will not be | |
250 | revoked by the Internet Society or its successors or assigns. | |
251 | ||
252 | This document and the information contained herein is provided on an | |
253 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
254 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
255 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
256 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
257 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
258 | ||
259 | ||
260 | ||
261 | ||
262 | ||
263 | ||
264 | ||
265 | ||
266 | ||
267 | ||
268 | ||
269 | ||
270 | ||
271 | ||
272 | ||
273 | ||
274 | ||
275 | ||
276 | ||
277 | ||
278 | ||
279 | ||
280 | ||
281 | ||
282 | Droms Best Current Practice [Page 5] | |
283 | \f |