idnits 2.17.1 draft-ietf-dhc-extended-optioncodes-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 126: '... The client MAY list the options in ...' RFC 2119 keyword, line 128: '... but MUST try to insert the requeste...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 114 has weird spacing: '...e Len optio...' == Line 134 has weird spacing: '...e Len optio...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2003) is 7649 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2131' is defined on line 321, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1497 (Obsoleted by RFC 1533) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force B. Volz 2 INTERNET DRAFT Ericsson 3 Expires: August 2003 R. Droms 4 Cisco 5 T. Lemon 6 Nominum 7 May 2003 9 Extending DHCP Options Codes 10 draft-ietf-dhc-extended-optioncodes-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 7, 2003. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 RFC 2132 defines the DHCP for IPv4 options 1 to 127 as the DHCP 42 public option space which is managed by IANA as documented in RFC 43 2939. As this public option space has few unassigned options at this 44 time, it is prudent to define a mechanism to extend this option space 45 before it is too late. This Internet-Draft proposes several means to 46 extend this option space. 48 1. Introduction 50 RFC 2132 defines the DHCP public option space as options 1 to 127 51 (decimal). This option space has a limited number of unassigned 52 option numbers at the present time. Work is in progress 53 [unused-optioncodes] to recover options that were assigned before 54 RFC 2489 (since updated by 2939) was published and never formally 55 documented. Approximately 20 unused option codes should be available 56 after the recovery initiative is completed and currently pending 57 options are assigned codes. 59 However, even with this effort, the current public space is likely to 60 be exhausted over the expected lifetime of DHCPv4 and so some actions 61 are needed to plan for this before it is too late. 63 This document proposes four means to extend this option space: 65 1. Use already allocated options 126 and 127 as previously proposed 66 by Ralph Droms. 68 2. Use option numbers from the site-specific option space as defined 69 by RFC 2132 (options 128 to 254). 71 3. Reclaim publicly assigned DHCP option numbers that are not in 72 active use. 74 4. Use 16-bit options and a new magic cookie to identify use of the 75 16-bit option format. 77 2. Requirements 79 The requirements for any proposal to extend the public options space 80 should include: 82 o The mechanism must interoperate with existing clients and servers. 83 Existing clients should be able to continue operating with servers 84 that implement the mechanism, and vice versa. 86 o The mechanism must interoperate with existing relay agents. Relay 87 agents must not need to be updated in order for clients and 88 servers to use the mechanism. 90 o The mechanism must not create an undue burden to DHCP client and 91 server implementations for the first few options that need to make 92 use of this option space. 94 o The mechanism must not negatively impact existing DHCP uses. 96 o The mechanism must not negatively impact existing 97 standards-compliant uses of DHCP. 99 3. Use of 16-bit Options 101 The first proposal, originally submitted in late 1996 by Ralph Droms 102 proposed the use of two "extension options" and requested IANA to 103 reserve options 126 and 127 for this purpose. As this pre-dated 104 RFC 2489 procedures, these option codes were assigned without formal 105 review and are now being considered to be returned to the available 106 list [unused-optioncodes]. 108 3.1 Definition of option 127 110 Option code 127 indicates that the DHCP option has a two-octet 111 extended option code. The format of these options is: 113 Extended 114 Code Len option code Data... 115 +-----+-----+-----+-----+-----+-----+---- 116 | 127 | XXX | oh | ol | d1 | d2 | ... 117 +-----+-----+-----+-----+-----+-----+---- 119 3.2 Definition of option 126 121 This option is used by a DHCP client to request values for specified 122 configuration parameters that are identified by extended option codes 123 as defined above. The list of n requested parameters is specified as 124 2n octets, where each pair of octets is a valid extended option code. 126 The client MAY list the options in order of preference. The DHCP 127 server is not required to return the options in the requested order, 128 but MUST try to insert the requested options in the order requested 129 by the client. 131 The code for this option is 126. Its minimum length is 2. 133 Extended 134 Code Len option codes 135 +-----+-----+-----+-----+-----+-----+---- 136 | 126 | XXX | c1h | c1l | c2h | c2l | ... 137 +-----+-----+-----+-----+-----+-----+---- 139 4. Using Site-Specific Options 141 The site-specific option range is rather large (127 options in all) 142 and has, in general, been little used. Ideally, DHCP options in wide 143 use should be in the public option space rather than in the 144 site-specific space (since these options are not site specific). 146 The use of option codes in the site-specific option code range (128 - 147 254 decimal) for other purposes such as vendor defined options that 148 have not been part of the IETF standards process is not compliant 149 with the DHCP Internet Standard as described in RFC2132. 151 This proposal is to reclassify site specific options 128 to 223 as 152 public options, leaving options 224 to 254 as site specific options. 154 As proper use of site-specific options likely requires very few 155 actual options, this proposal leaves 31 site-specific options. 157 4.1 Impact To Existing Site-Specific Options 159 There are known to be uses of option codes that are not 160 standards-compliant and there are likely sites legitimately using 161 option codes in the range being proposed for reclassification. These 162 sites and users will be impacted by this action when IANA begins to 163 assign the options numbers to new uses. 165 Users would be encouraged to move to alternative site-specific option 166 numbers (224 to 254), switch to using the vendor-specific option, or 167 document the existing usage and request a public option number using 168 the process described in RFC 2939 (IANA should be requested to 169 allocate the existing site-specific option number if in the 170 reclassified public option space and still available). 172 IANA would be requested to assign the reclassified options only after 173 the original public option space (1 to 127) has been exhausted. And, 174 further IANA should assign options from this reclassified range 175 starting at the lowest value (128). 177 This should give a reasonable amount of time for corrective action to 178 be taken. 180 If there are existing uses of these options and some of the systems 181 can not be updated, there is a potential for confusion at some point. 183 4.2. Resultant IANA Recommendations 185 IANA is requested to increase the DHCP public option space from 1 to 186 127 to 1 to 223. IANA is requested not to assign any options from the 187 new space (128 to 223) until such time as all options from 1 to 127 188 have been assigned. At such time, IANA is further requested to assign 189 options starting at 128 on up. 191 IANA should allow an exception to the above when an existing usage of 192 a site-specific option in the 128 to 223 range is approved (per RFC 193 2939) and the approved usage is consistent with the existing usage, 194 IANA should assign the existing site-specific option number if 195 available. 197 5. Reclaiming Unused Options 199 There are some DHCP options specified in [RFC2132] or since assigned 200 by IANA that are believed not to be in use today and these could be 201 reclaimed and made available for reassignment to future options. 203 Research would be needed to create a list of these options and 204 solicit feedback from the IETF community to confirm if these options 205 are not in active use. 207 This is already being done for options assigned by IANA but never 208 officially documented [unused-optioncodes]. 210 6. New Magic Cookie with 16-bit Options 212 This proposal would use a new magic cookie (the current is defined 213 in [RFC1497]) for DHCP messages and messages using this new cookie 214 would use 16-bit options (16-bit option code and length fields). 215 The existing 8-bit options would use the first 256 codes in the new 216 16-bit option space. 218 This proposal would require clients, servers, and relays agents to 219 support both 8-bit and 16-bit option formats for a time. The first 220 option to use the 16-bit options would require significant 221 implementation work in client, server, and relay agent code to add 222 the required support. 224 This proposal would require a client to send the new magic cookie 225 formatted message and if no server responded, try the old magic 226 cookie formatted messages. A client might send both simultaneously to 227 speed up the process, at the expends of increased broadcast traffic. 229 7. Analysis of the Proposals 231 7.1 Use of 16-bit Options 233 This proposal allows for a very large number of DHCP options and with 234 the definition of the procedure for encoding large options [RFC3396], 235 the data in Option 127 would not be restricted to 255 octets. 237 The proposal meets all of the requirements listed in section 2 with 238 one exception, "the mechanism must not create an undue burden to DHCP 239 client and server implements for the first few options that need to 240 make use of this option space." The first option using this proposal 241 will require implementing two other options (in addition to the 242 desired option) - option 127 and 126 as defined by the proposal - and 243 also the encoding large options [RFC3396] if not already implemented. 244 The encoding of large options is needed to allow option 127 to carry 245 multiple 16-bit options and allow these options (either singly or in 246 aggregate) to exceed 255 bytes. 248 7.2 Using Site-Specific Options 250 This proposal adds 96 additional DHCP options to the public options 251 space, which is about 75% of the original space. The original space 252 has lasted 10+ years (based on the publication of RFC 1531) and is 253 not yet exhausted. This original space also included many options 254 inherited from BOOTP and to support the basic DHCP protocol. Thus, 96 255 additional option codes should last for a long time. 257 The proposal meets all of the requirements listed in section 2 with 258 one exception, "The mechanism must not negatively impact existing 259 DHCP uses." As stated in section 4.1, existing uses of site-specific 260 options in the reclassified range are impacted and these uses must 261 be moved to the newly proposed site-specific option range, to a 262 vendor specific option, or documented and to a public option. 264 However, there are believed to be few sites that make heavy use of 265 site-specific options and they would have many years to redeploy. 267 7.3 Reclaiming Options 269 This proposal would likely result in few options being reclaimed. 270 Therefore, while nothing precludes doing this in parallel with one of 271 the other proposals, the benefit is believed to be fairly minor. And, 272 there is a risk that a reused option might conflict with an earlier 273 use of the option in some client, server, relay agent, or other 274 implementations and result in unexpected problems or at best 275 confusion. 277 Note that this is somewhat different than the work being done to 278 reclaim undocumented options ([unused-optioncodes]), as these options 279 were not officially adopted and documented by the IETF. 281 7.4 New Magic Cookie with 16-bit Options 283 This proposal requires client, servers, and relay agents to likely 284 support both the current DHCP message format with 8-bit options as 285 well as the new 16-bit options. It would require clients to send 286 both types of messages, perhaps favoring the new format and if no 287 response is received causing the client to send the old format. 289 It is not known how existing clients, servers, and relay agents 290 would behave if they received messages with the new magic cookie 291 values. Presumably, the messages would be dropped. In the worst 292 case, it could cause significant failures (though in these cases 293 it could be argued that these devices should be promptly corrected 294 as this presents an easy denial of service attack). 296 This proposal fails to interoperate with existing clients, servers, 297 and relays. It also impacts other devices that monitor DHCP traffic 298 (such as packet sniffers). 300 This proposal creates an undue burden for the first few options that 301 need to make use of the 16-bit option space. 303 This proposal also impacts networks for a long time as clients and 304 servers may need to send messages with both the new and old magic 305 cookie values. 307 7.5 Recommendations 309 TBD 311 8. Security Considerations 313 This document in and by itself provides no security, nor does it 314 impact existing security. 316 References 318 [RFC1497] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 319 1497, USC/Information Sciences Institute, August 1993. 321 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 322 March 1997. 324 [RFC2132] Alexander, S. and R. Droms, "DHCP options and BOOTP Vendor 325 Extensions", RFC 2132, March 1997. 327 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", 328 RFC 3396, November 2002. 330 [unused-optioncodes] Droms, "Unused DHCP Option Codes", Work in 331 Progress. 333 Author's Address 335 Ralph Droms 336 Cisco Systems 337 300 Apollo Drive 338 Chelmsford, MA 01824 339 Phone: +1 978.497.4733 340 EMail: rdroms@cisco.com 342 Ted Lemon 343 Nominum, Inc. 344 950 Charter Street 345 Redwood City, CA 94043 346 USA 347 E-mail: Ted.Lemon@nominum.com 348 Bernie Volz 349 Ericsson 350 959 Concord Street 351 Framingham, MA 01701 352 Phone: +1 508 875 3162 353 EMail: bernie.volz@ericsson.com 355 Full Copyright Statement 357 Copyright (C) The Internet Society (2003). All Rights Reserved. 359 This document and translations of it may be copied and furnished to 360 others, and derivative works that comment on or otherwise explain it 361 or assist in its implementation may be prepared, copied, published 362 and distributed, in whole or in part, without restriction of any 363 kind, provided that the above copyright notice and this paragraph are 364 included on all such copies and derivative works. However, this 365 document itself may not be modified in any way, such as by removing 366 the copyright notice or references to the Internet Society or other 367 Internet organizations, except as needed for the purpose of 368 developing Internet standards in which case the procedures for 369 copyrights defined in the Internet Standards process must be 370 followed, or as required to translate it into languages other than 371 English. 373 The limited permissions granted above are perpetual and will not be 374 revoked by the Internet Society or its successors or assigns. 376 This document and the information contained herein is provided on an 377 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 378 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 379 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 380 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 381 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 383 Acknowledgement 385 Funding for the RFC Editor function is currently provided by the 386 Internet Society.