Internet Engineering Task Force B. Volz INTERNET DRAFT Ericsson Expires: August 2003 R. Droms Cisco T. Lemon Nominum May 2003 Extending DHCP Options Codes draft-ietf-dhc-extended-optioncodes-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 7, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract RFC 2132 defines the DHCP for IPv4 options 1 to 127 as the DHCP public option space which is managed by IANA as documented in RFC 2939. As this public option space has few unassigned options at this time, it is prudent to define a mechanism to extend this option space before it is too late. This Internet-Draft proposes several means to extend this option space. Volz, et al. Expires 7 Nov 2003 [Page 1] Internet Draft Extending DHCP Options Codes May 7, 2003 1. Introduction RFC 2132 defines the DHCP public option space as options 1 to 127 (decimal). This option space has a limited number of unassigned option numbers at the present time. Work is in progress [unused-optioncodes] to recover options that were assigned before RFC 2489 (since updated by 2939) was published and never formally documented. Approximately 20 unused option codes should be available after the recovery initiative is completed and currently pending options are assigned codes. However, even with this effort, the current public space is likely to be exhausted over the expected lifetime of DHCPv4 and so some actions are needed to plan for this before it is too late. This document proposes four means to extend this option space: 1. Use already allocated options 126 and 127 as previously proposed by Ralph Droms. 2. Use option numbers from the site-specific option space as defined by RFC 2132 (options 128 to 254). 3. Reclaim publicly assigned DHCP option numbers that are not in active use. 4. Use 16-bit options and a new magic cookie to identify use of the 16-bit option format. 2. Requirements The requirements for any proposal to extend the public options space should include: o The mechanism must interoperate with existing clients and servers. Existing clients should be able to continue operating with servers that implement the mechanism, and vice versa. o The mechanism must interoperate with existing relay agents. Relay agents must not need to be updated in order for clients and servers to use the mechanism. o The mechanism must not create an undue burden to DHCP client and server implementations for the first few options that need to make use of this option space. o The mechanism must not negatively impact existing DHCP uses. o The mechanism must not negatively impact existing standards-compliant uses of DHCP. Volz, et al. Expires 7 Nov 2003 [Page 2] Internet Draft Extending DHCP Options Codes May 7, 2003 3. Use of 16-bit Options The first proposal, originally submitted in late 1996 by Ralph Droms proposed the use of two "extension options" and requested IANA to reserve options 126 and 127 for this purpose. As this pre-dated RFC 2489 procedures, these option codes were assigned without formal review and are now being considered to be returned to the available list [unused-optioncodes]. 3.1 Definition of option 127 Option code 127 indicates that the DHCP option has a two-octet extended option code. The format of these options is: Extended Code Len option code Data... +-----+-----+-----+-----+-----+-----+---- | 127 | XXX | oh | ol | d1 | d2 | ... +-----+-----+-----+-----+-----+-----+---- 3.2 Definition of option 126 This option is used by a DHCP client to request values for specified configuration parameters that are identified by extended option codes as defined above. The list of n requested parameters is specified as 2n octets, where each pair of octets is a valid extended option code. The client MAY list the options in order of preference. The DHCP server is not required to return the options in the requested order, but MUST try to insert the requested options in the order requested by the client. The code for this option is 126. Its minimum length is 2. Extended Code Len option codes +-----+-----+-----+-----+-----+-----+---- | 126 | XXX | c1h | c1l | c2h | c2l | ... +-----+-----+-----+-----+-----+-----+---- 4. Using Site-Specific Options The site-specific option range is rather large (127 options in all) and has, in general, been little used. Ideally, DHCP options in wide use should be in the public option space rather than in the site-specific space (since these options are not site specific). The use of option codes in the site-specific option code range (128 - 254 decimal) for other purposes such as vendor defined options that have not been part of the IETF standards process is not compliant with the DHCP Internet Standard as described in RFC2132. Volz, et al. Expires 7 Nov 2003 [Page 3] Internet Draft Extending DHCP Options Codes May 7, 2003 This proposal is to reclassify site specific options 128 to 223 as public options, leaving options 224 to 254 as site specific options. As proper use of site-specific options likely requires very few actual options, this proposal leaves 31 site-specific options. 4.1 Impact To Existing Site-Specific Options There are known to be uses of option codes that are not standards-compliant and there are likely sites legitimately using option codes in the range being proposed for reclassification. These sites and users will be impacted by this action when IANA begins to assign the options numbers to new uses. Users would be encouraged to move to alternative site-specific option numbers (224 to 254), switch to using the vendor-specific option, or document the existing usage and request a public option number using the process described in RFC 2939 (IANA should be requested to allocate the existing site-specific option number if in the reclassified public option space and still available). IANA would be requested to assign the reclassified options only after the original public option space (1 to 127) has been exhausted. And, further IANA should assign options from this reclassified range starting at the lowest value (128). This should give a reasonable amount of time for corrective action to be taken. If there are existing uses of these options and some of the systems can not be updated, there is a potential for confusion at some point. 4.2. Resultant IANA Recommendations IANA is requested to increase the DHCP public option space from 1 to 127 to 1 to 223. IANA is requested not to assign any options from the new space (128 to 223) until such time as all options from 1 to 127 have been assigned. At such time, IANA is further requested to assign options starting at 128 on up. IANA should allow an exception to the above when an existing usage of a site-specific option in the 128 to 223 range is approved (per RFC 2939) and the approved usage is consistent with the existing usage, IANA should assign the existing site-specific option number if available. 5. Reclaiming Unused Options There are some DHCP options specified in [RFC2132] or since assigned by IANA that are believed not to be in use today and these could be reclaimed and made available for reassignment to future options. Volz, et al. Expires 7 Nov 2003 [Page 4] Internet Draft Extending DHCP Options Codes May 7, 2003 Research would be needed to create a list of these options and solicit feedback from the IETF community to confirm if these options are not in active use. This is already being done for options assigned by IANA but never officially documented [unused-optioncodes]. 6. New Magic Cookie with 16-bit Options This proposal would use a new magic cookie (the current is defined in [RFC1497]) for DHCP messages and messages using this new cookie would use 16-bit options (16-bit option code and length fields). The existing 8-bit options would use the first 256 codes in the new 16-bit option space. This proposal would require clients, servers, and relays agents to support both 8-bit and 16-bit option formats for a time. The first option to use the 16-bit options would require significant implementation work in client, server, and relay agent code to add the required support. This proposal would require a client to send the new magic cookie formatted message and if no server responded, try the old magic cookie formatted messages. A client might send both simultaneously to speed up the process, at the expends of increased broadcast traffic. 7. Analysis of the Proposals 7.1 Use of 16-bit Options This proposal allows for a very large number of DHCP options and with the definition of the procedure for encoding large options [RFC3396], the data in Option 127 would not be restricted to 255 octets. The proposal meets all of the requirements listed in section 2 with one exception, "the mechanism must not create an undue burden to DHCP client and server implements for the first few options that need to make use of this option space." The first option using this proposal will require implementing two other options (in addition to the desired option) - option 127 and 126 as defined by the proposal - and also the encoding large options [RFC3396] if not already implemented. The encoding of large options is needed to allow option 127 to carry multiple 16-bit options and allow these options (either singly or in aggregate) to exceed 255 bytes. 7.2 Using Site-Specific Options This proposal adds 96 additional DHCP options to the public options space, which is about 75% of the original space. The original space Volz, et al. Expires 7 Nov 2003 [Page 5] Internet Draft Extending DHCP Options Codes May 7, 2003 has lasted 10+ years (based on the publication of RFC 1531) and is not yet exhausted. This original space also included many options inherited from BOOTP and to support the basic DHCP protocol. Thus, 96 additional option codes should last for a long time. The proposal meets all of the requirements listed in section 2 with one exception, "The mechanism must not negatively impact existing DHCP uses." As stated in section 4.1, existing uses of site-specific options in the reclassified range are impacted and these uses must be moved to the newly proposed site-specific option range, to a vendor specific option, or documented and to a public option. However, there are believed to be few sites that make heavy use of site-specific options and they would have many years to redeploy. 7.3 Reclaiming Options This proposal would likely result in few options being reclaimed. Therefore, while nothing precludes doing this in parallel with one of the other proposals, the benefit is believed to be fairly minor. And, there is a risk that a reused option might conflict with an earlier use of the option in some client, server, relay agent, or other implementations and result in unexpected problems or at best confusion. Note that this is somewhat different than the work being done to reclaim undocumented options ([unused-optioncodes]), as these options were not officially adopted and documented by the IETF. 7.4 New Magic Cookie with 16-bit Options This proposal requires client, servers, and relay agents to likely support both the current DHCP message format with 8-bit options as well as the new 16-bit options. It would require clients to send both types of messages, perhaps favoring the new format and if no response is received causing the client to send the old format. It is not known how existing clients, servers, and relay agents would behave if they received messages with the new magic cookie values. Presumably, the messages would be dropped. In the worst case, it could cause significant failures (though in these cases it could be argued that these devices should be promptly corrected as this presents an easy denial of service attack). This proposal fails to interoperate with existing clients, servers, and relays. It also impacts other devices that monitor DHCP traffic (such as packet sniffers). This proposal creates an undue burden for the first few options that need to make use of the 16-bit option space. Volz, et al. Expires 7 Nov 2003 [Page 6] Internet Draft Extending DHCP Options Codes May 7, 2003 This proposal also impacts networks for a long time as clients and servers may need to send messages with both the new and old magic cookie values. 7.5 Recommendations TBD 8. Security Considerations This document in and by itself provides no security, nor does it impact existing security. References [RFC1497] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, USC/Information Sciences Institute, August 1993. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", RFC 3396, November 2002. [unused-optioncodes] Droms, "Unused DHCP Option Codes", Work in Progress. Author's Address Ralph Droms Cisco Systems 300 Apollo Drive Chelmsford, MA 01824 Phone: +1 978.497.4733 EMail: rdroms@cisco.com Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 USA E-mail: Ted.Lemon@nominum.com Volz, et al. Expires 7 Nov 2003 [Page 7] Internet Draft Extending DHCP Options Codes May 7, 2003 Bernie Volz Ericsson 959 Concord Street Framingham, MA 01701 Phone: +1 508 875 3162 EMail: bernie.volz@ericsson.com Volz, et al. Expires 7 Nov 2003 [Page 8] Internet Draft Extending DHCP Options Codes May 7, 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Volz, et al. Expires 7 Nov 2003 [Page 9]