idnits 2.17.1 draft-volz-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 6 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 119: '... The client MAY list the options in ...' RFC 2119 keyword, line 121: '... 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 107 has weird spacing: '...e Len optio...' == Line 127 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 (February 2003) is 7738 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 240, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 243, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 7 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 February 2003 9 Extending DHCP Options Codes 10 draft-volz-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 August 1, 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 two 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. 58 However, even with this effort, the current public space is likely 59 to be exhausted over the expected lifetime of DHCPv4 and so some 60 actions are needed to plan for this before it is too late. 62 This document proposes two means to extend this option space: 64 1. Use already allocated options 126 and 127 as previously proposed 65 by Ralph Droms. 67 2. Use option numbers from the site-specific option space as defined 68 by RFC 2132 (options 128 to 254). 70 2. Requirements 72 The requirements for any proposal to extend the public options space 73 should include: 75 o The mechanism must interoperate with existing clients and servers. 76 Existing clients should be able to continue operating with servers 77 that implement the mechanism, and vice versa. 79 o The mechanism must interoperate with existing relay agents. Relay 80 agents must not need to be updated in order for clients and servers 81 to use the mechanism. 83 o The mechanism must not create an undue burden to DHCP client and 84 server implementations for the first few options that need to make 85 use of this option space. 87 o The mechanism must not negatively impact existing DHCP uses. 89 o The mechanism must not negatively impact existing 90 standards-compliant uses of DHCP. 92 3. Use of 16-bit Options 94 The first proposal, originally submitted in late 1996 by Ralph 95 Droms proposed the use of two "extension options" and requested 96 IANA to reserve options 126 and 127 for this purpose. As this 97 pre-dated RFC 2489 procedures, these option codes were assigned 98 without formal review and are now being considered to be returned 99 to the available list [unused-optioncodes]. 101 3.1 Definition of option 127 103 Option code 127 indicates that the DHCP option has a two-octet 104 extended option code. The format of these options is: 106 Extended 107 Code Len option code Data... 108 +-----+-----+-----+-----+-----+-----+---- 109 | 127 | XXX | oh | ol | d1 | d2 | ... 110 +-----+-----+-----+-----+-----+-----+---- 112 3.2 Definition of option 126 114 This option is used by a DHCP client to request values for specified 115 configuration paramaters that are identified by extended option codes 116 as defined above. The list of n requested parameters is specified as 117 2n octets, where each pair of octets is a valid extended option code. 119 The client MAY list the options in order of preference. The DHCP 120 server is not required to return the options in the requested order, 121 but MUST try to insert the requested options in the order requested 122 by the client. 124 The code for this option is 126. Its minimum length is 2. 126 Extended 127 Code Len option codes 128 +-----+-----+-----+-----+-----+-----+---- 129 | 126 | XXX | c1h | c1l | c2h | c2l | ... 130 +-----+-----+-----+-----+-----+-----+---- 132 4. Using Site-Specific Options 134 The site-specific option range is rather large (127 options in all) 135 and has, in general, been little used. Ideally, DHCP options in wide 136 use should be in the public option space rather than in the 137 site-specific space (since these options are not site specific). 139 The use of option codes in the site-specific option code range 140 (128-254 decimal) for other purposes such as vendor defined 141 options that have not been part of the IETF standards 142 process is not compliant with the DHCP Internet Standard as 143 described in RFC2132. 145 This proposal is to reclassify site specific options 128 to 223 146 as public options, leaving options 224 to 254 as site specific 147 options. 148 As proper use of site-specific options likely requires very few 149 actual options, this proposal provides 31 site-specific options. 151 4.1 Impact To Existing Site-Specific Options 153 There are known to be uses of option codes that are not 154 standards-compliant and there are likely sites legitimately using 155 option codes in the range being proposed for reclassification. These 156 sites and users will be impacted by this action when IANA begins to 157 assign the options numbers to new uses. 159 Users would be encouraged to move to alternative site-specific option 160 numbers (224 to 254), switch to using the vendor-specific option, or 161 document the existing usage and request a public option number using 162 the process described in RFC 2939 (IANA should be requested to 163 allocate the existing site-specific option number if in the 164 reclassified public option space and still available). 166 IANA would be requested to assign the reclassified options only after 167 the original public option space (1 to 127) has been exhausted. And, 168 further IANA should assign options from this reclassified range 169 starting at the lowest value (128). 171 This should give a reasonable amount of time for corrective action to 172 be taken. 174 If there are existing uses of these options and some of the systems 175 can not be updated, there is a potential for confusion at some point. 177 4.2. Resultant IANA Recommendations 179 IANA is requested to increase the DHCP public option space from 1 to 180 127 to 1 to 223. IANA is requested not to assign any options from the 181 new space (128 to 223) until such time as all options from 1 to 127 182 have been assigned. At such time, IANA is further requested to assign 183 options starting at 128 on up. 185 IANA should allow an exception to the above when an existing usage of 186 a site-specific option in the 128 to 223 range is approved (per RFC 187 2939) and the approved usage is consistent with the existing usage, 188 IANA should assign the existing site-specific option number if 189 available. 191 5. Analysis of the Two Proposals 193 5.1 Use of 16-bit Options 195 This proposal allows for a very large number of DHCP options and with 196 the definition of the procedure for encoding large options [RFC3396], 197 the data in Option 127 would not be restricted to 255 octets. 199 The proposal meets all of the requirements listed in section 2 with 200 one exception, "the mechanism must not create an undue burden to DHCP 201 client and server implements for the first few options that need to 202 make use of this option space." The first option using this proposal 203 will require implementing two other options (in addition to the 204 desired option) - option 127 and 126 as defined by the proposal - and 205 also the encoding large options [RFC3396] if not already implemented. 206 The encoding of large options is needed to allow option 127 to carry 207 multiple 16-bit options and allow these options (either singly or in 208 aggregate) to exceed 255 bytes. 210 5.2 Using Site-Specific Options 212 This proposal adds 96 additional DHCP options to the public options 213 space, which is about 75% of the original space. The original space 214 has lasted 10+ years (based on the publication of RFC 1531) and is 215 not yet exhausted. This original space also included many options 216 inherited from BOOTP and to support the basic DHCP protocol. Thus, 217 96 additional option codes should last for a long time. 219 The proposal meets all of the requirements listed in section 2 with 220 one exception, "The mechanism must not negatively impact existing 221 DHCP uses." As stated in section 4.1, existing uses of site-specific 222 options in the reclassified range are impacted and these uses must 223 be moved to the newly proposed site-specific option range, to a 224 vendor specific option, or documented and to a public option. 226 However, there are believed to be few sites that make heavy use of 227 site-specific options and they would have many years to redeploy. 229 5.3 Recommendations 231 TBD 233 6. Security Considerations 235 This document in and by itself provides no security, nor does it 236 impact existing security. 238 References 240 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 241 March 1997. 243 [RFC2132] Alexander, S. and R. Droms, "DHCP options and BOOTP Vendor 244 Extensions", RFC 2132, March 1997. 246 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", 247 RFC 3396, November 2002. 249 [unused-optioncodes] Droms, "Unused DHCP Option Codes", Work in 250 Progress. 252 Author's Address 254 Ralph Droms 255 Cisco Systems 256 300 Apollo Drive 257 Chelmsford, MA 01824 258 Phone: +1 978.497.4733 259 EMail: rdroms@cisco.com 261 Ted Lemon 262 Nominum, Inc. 263 950 Charter Street 264 Redwood City, CA 94043 265 USA 266 E-mail: Ted.Lemon@nominum.com 268 Bernie Volz 269 Ericsson 270 959 Concord Street 271 Framingham, MA 01701 272 Phone: +1 508 875 3162 273 EMail: bernie.volz@ericsson.com 275 Full Copyright Statement 277 Copyright (C) The Internet Society (2003). All Rights Reserved. 279 This document and translations of it may be copied and furnished to 280 others, and derivative works that comment on or otherwise explain it 281 or assist in its implementation may be prepared, copied, published 282 and distributed, in whole or in part, without restriction of any 283 kind, provided that the above copyright notice and this paragraph are 284 included on all such copies and derivative works. However, this 285 document itself may not be modified in any way, such as by removing 286 the copyright notice or references to the Internet Society or other 287 Internet organizations, except as needed for the purpose of 288 developing Internet standards in which case the procedures for 289 copyrights defined in the Internet Standards process must be 290 followed, or as required to translate it into languages other than 291 English. 293 The limited permissions granted above are perpetual and will not be 294 revoked by the Internet Society or its successors or assigns. 296 This document and the information contained herein is provided on an 297 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 298 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 299 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 300 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 301 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 303 Acknowledgement 305 Funding for the RFC Editor function is currently provided by the 306 Internet Society.