2000-07-14 13:33 New Option Review Carney Page 1 Network Working Group Michael Carney Dynamic Host Configuration Working Group Sun Microsystems, Inc Category: Standards Track July 2000 INTERNET-DRAFT Expires: January 2001 New Option Review Guidelines for DHCP 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. Comments regarding this draft should be sent to dhcp-v4@bucknell.edu Abstract This document outlines deficiencies that have become evident since RFC 2131 and RFC 2132 were published regarding the allocation of new option codes, the review of drafts covering these new option codes, and the availability of option codes for new parameters. The document then presents proposals for correcting these deficiencies. 1. Introduction The rapid and wide-spread adoption of DHCP for IPv4 has lead to an increasing number of new DHCP option and message type drafts under DHC WG review. Experience with the current IANA option code allocation process and the DHC WG draft review process has identified a number of deficiencies, namely: * We're rapidly going through the remaining option codes, and face the possibility of exhausting the remaining codes before the wide-spread adoption of IPv6 is achieved. 2000-07-14 13:33 New Option Review Carney Page 2 * There are no guidelines to help the DHC WG and the DHCP community at large gauge the impact of the addition of new message types and options. Some message types and options that have been proposed require changes to the DHCP protocol itself and/or current implementations. Because the adoption of such message types or options has a greater impact on the DHCP community, these message types and options require more scrutiny by the DHC WG and IESG. * Because some options or message types could change the DHCP protocol itself, we need a method of explicitly communicating the change of DHCP versions among implementations. Today, we have no such method. * There is no provision to preserve compatibility with earlier versions of the protocol. Inter-operability testing at Connectathon (1997-2000) has shown a reduction in the level of interoperability between implementations. These interoperability problems were found to be due to confusion among implementors about how certain features of the protocol should be implemented. Improvement (tightening) of the general RFC 2131 and RFC 2132 drafts as well as the tightening of new option drafts (using the guidelines defined in this document) will help prevent these interoperability problems from occurring as new implementations appear. The specification of a RFC 2132-form option to carry the DHCP protocol version and a proposal for a new, larger option namespace is discussed in a companion document, "A New Option Namespace for DHCP" [8]. 1.1 Conventions Used in the Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5]. 2. Review Guidelines We tackle the message type and option code review problem by defining a set of categories based upon the impact the adoption of an option or new message type will have on the DHCP community. Option or new message drafts appropriately categorized aid reviewers by helping them evaluate the draft. Once the DHC WG and the draft author(s) agree on the category of the proposed option or message type, that category will be listed explicitly in the abstract of the option or message draft. 2000-07-14 13:33 New Option Review Carney Page 3 2.1. Hints for selecting the correct review category Read the following hints and select the one which best describes your option or message type, then proceed to Table 1 at the end of this section for the suggested option review category. If, after reading the following hints, you cannot find one that fits your option or message type, read each of the category sections (2.2-2.5) carefully. If you still are not sure which category your option or message type belongs in, you can ask the DHC WG (if it still exists) or the IESG for help in selecting the right category. A) This option has no relationship to other existing or proposed options. It would not require change of existing DHCP client, server, or BOOTP relay agent implementations. It would not change the version of the DHCP protocol. Its introduction would not invalidate previous version(s) of the DHCP protocol. The proposed option provides data which is non-implementation specific and unrelated to network configuration. B) This message type has no relationship to other existing or proposed message types. It would not require change of existing DHCP client, server, or BOOTP relay agent implementations. It would not change the version of the DHCP protocol. The message type is useful to the DHCP community at large. C) This option has no relationship to other existing or proposed options or message types. It would not require change of existing DHCP client, server, or BOOTP relay agent implementations. It would not change the version of the DHCP protocol. Its introduction would not invalidate previous version(s) of the DHCP protocol [8]. The information it carries is network or system configuration related, but only for a particular implementation or set of implementations from the same vendor. D) This option has no relationship to other existing or proposed options or message types. It would not require change of existing DHCP client, server, or BOOTP relay agent implementations. It would not change the version of the DHCP protocol. Its introduction would not invalidate previous version(s) of the DHCP protocol [8]. It carries network or system configuration data with is of general usefulness. E) This option would have a implicit or explicit relationship between it and other existing options or other proposed options. It MAY change the behavior of existing DHCP client, server, and/or BOOTP relay agent implementations. It would not change the DHCP protocol version. Its introduction would not invalidate previous version(s) of the DHCP protocol [8]. 2000-07-14 13:33 New Option Review Carney Page 4 Examples of implicit/explicit option relationships: Option Related Options ------ --------------- Vendor Class Identifier Encapsulated vendor option(s) User Class Identifier Standard option's scope F) This message type would have a implicit or explicit relationship between it and other existing message types or options. Its adoption MAY change the behavior of existing DHCP client, server, and/or BOOTP relay agent implementations. It would not change the DHCP protocol version. Its introduction would not invalidate previous version(s) of the DHCP protocol [8]. G) The addition of this option would change Table 3, "Fields and options used by DHCP servers" and/or Table 5, "Fields and options used by DHCP clients" in RFC 2131 [1], and thus change the DHCP protocol. Pre-existing versions / implementations would continue to interoperate. H) The addition of this option or message type would invalidate previous versions of the DHCP protocol [8], preventing client, server, and/or BOOTP relay agents implementing the earlier version(s) from functioning. Table 1: Linking Hints to Review Category Guidelines Review Category ---------- --------------- A None. Use SLP or an other alternative to to register and deliver your information. B Category One C None. Use your Vendor-specific option space for your option. D Category One E Category Two F Category Two G Category Three H Category Four 2000-07-14 13:33 New Option Review Carney Page 5 2.2. Category One Options in this category MUST NOT require changes to the DHCP protocol, server, client, or BOOTP relay agent implementations. They MUST NOT be dependent on other options being present or absent. Earlier versions/implementations of the protocol continue to interoperate in the presence of these options. Administrative tools and DHCP protocol debugging tools which generically support the default option types MAY need to be reconfigured in order to permit management of the new option. Options of this type are "payload" options, and MUST be of one of the default option types for the option block form (RFC 2132 or RFC TBD_NS [8]). Acceptance criteria: Working group/IETF community review: Yes. IANA option number registration: Yes. Inter-operability testing (2 or more implementations) No. DHCP protocol version change [8]: No. 2.3. Category Two Options in this category MUST NOT require changes to the DHCP protocol. They MAY require changes to server, client, relay agent implementations, administrative tools, and DHCP protocol debugging tools. They MAY depend on the presence or absence of other options, as long as those other options are NOT in Table 3 or Table 5 of RFC 2131 [1]. Any dependence on other options MUST be made explicit in the new options draft. Existing versions / implementations of the protocol continue to interoperate in the presence of messages containing category two options. Options of this type are "affect implementation" options. An option MUST be designed in such a way as a reply/response from non-compliant implementations can be easily distinguished from those of compliant implementations. An option MUST NEVER change the interpretation of existing options. The option draft author MUST specify a compliant implementation's behavior if that implement- ation receives a reply/response from a non-compliant implementation. Acceptance criteria: Working group/IETF community review: Yes. IANA option number registration: Yes. Inter-operability testing (2 or more implementations) Yes. DHCP protocol version change [8]: No. 2000-07-14 13:33 New Option Review Carney Page 6 2.4. Category Three Options in this category EXPLICITLY change the DHCP protocol. They WILL require changes to server, client, and/or relay agent implementations. They MAY depend on the presence or absence of other options. Any dependence on other options MUST be made explicit in the new option draft. The addition of such options result in changes to Table 3, "Fields and options used by DHCP servers" and/or Table 5, "Fields and options used by DHCP clients" in RFC 2131 [1]. Existing versions / implementations of the protocol continue to interoperate in the presence of traffic containing category three options. Administrative tools MUST be changed to support options of this type. DHCP protocol debugging tools would need to be updated to recognize these options. Options of this type are known as "affect protocol" options. The acceptance of a Category Three option results in incrementing the DHCP version option value (see a companion document, "A New Option Namespace for DHCP" for details on the DHCP version option [8]. An option MUST be designed in such a way as a reply/response from non-compliant implementations can be easily distinguished from those of compliant implementations. The option draft author MUST specify a compliant implementation's behavior if that implement- ation receives a reply/response from a non-compliant implementation. An option MUST NEVER change the interpretation of existing options. Category Three option implementations can easily detect a non-compliant implementation due to the absence of the DHCP version option or a lower than expected version number [8]. Acceptance criteria: Working group/IETF community review: Yes. IANA option number registration: Yes. Inter-operability testing (2 or more implementations) Yes. DHCP protocol version change [8]: Yes. 2.5. Category Four Options in this category would EXPLICITLY change the DHCP protocol in a non-backward compatible manner. They would require changes to ALL DHCP client, server, and/or BOOTP relay agent implementations. They INVALIDATE one or more of the previous versions of the BOOTP/DHCP protocol. Because category four options invalidate previous versions of the protocol, they are NOT candidates for acceptance. Changes to the the DHCP protocol MUST BE backward compatible. Acceptance criteria: Working group/IETF community review: N/A. IANA option number registration: N/A. Inter-operability testing (2 or more implementations) N/A. DHCP protocol version change [8]: N/A. 2000-07-14 13:33 New Option Review Carney Page 7 3. Security Considerations Not Applicable. 4. Acknowledgements The author would like to gratefully acknowledge the active participation of the following DHCP future panel members: Ralph Droms, Kester Fong, Pratik Gupta, Barr Hibbs, Kim Kinnear, Ted Lemon, Nathan Lane, and Glenn Waters. The author would also like to thank Thomas Narten and Bernie Volz for their review comments. 5. Copyright Copyright (C) The Internet Society (2000). 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. 6. References [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997. [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extension", RFC 2132, March 1997. 2000-07-14 13:33 New Option Review Carney Page 8 [3] Prindeville, P. "BOOTP Vendor Information Extensions", RFC 1048, McGill University, February 1988. [4] Droms, R. "Procedure for Defining New DHCP Options", INTERNET-DRAFT, August 1998 [5] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [6] Hinden R. and Deering, S., "IP Version 6 Addressing Architecture", RFC 2373, Nokia and Cisco Systems, July 1998. [7] Guttman E., Perkins C., Veizades J., and Day M., "Service Location Protocol, Version 2", April 1999. [8] Carney, M., "A New Option Namespace for DHCP", RFC TBD_NS, July 2000. 7. Author's Address Michael Carney Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303-4900 Phone: (650) 786-4171 Fax: (650) 786-5896 Email: Michael.Carney@sun.com 8. Expiration This document will expire on January 31, 2001.