Network Working Group R. Droms
INTERNET DRAFTINTERNET-DRAFT Bucknell University Obsoletes: February 1996 Expires August 1996draft-ietf-dhc-new-options-00.txt July 1998 Procedure for Defining New DHCP Options <draft-ietf-dhc-new-options-00.txt><draft-ietf-dhc-new-options-01.txt> Status of this memo This document is an Internet-Draft. 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"work in progress.''progress." To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt''"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.netftp.nordu.net (Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ds.internic.netftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called "options." New DHCP options may be defined after the publication of the DHCP specification to accommodate requirements for conveyance of new configuration parameters. This document describes the procedure for defining new DHCP options. Introduction The Dynamic Host Configuration Protocol (DHCP)  provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called "options."  DRAFT Procedure for Defining New DHCP Options July 1998 This document describes the procedure for defining new DHCP options. The procedure will guarantee that: * allocation of new option numbers is coordinated from a single authority, * new options are reviewed for technical correctness and appropriateness, and * documentation for new options is complete and published. DRAFT ProcedureAs indicated in "Guidelines for Defining New DHCP Options February 1996 Procedure The author ofWriting an IANA Considerations Section in RFCs" , IANA acts as a central authority for assignment of numbers for new DHCP optionoptions. The new procedure outlined in this document will follow these stepsprovide guidance to obtain acceptance ofIANA in the option as a partassignment of the DHCP Internet Standard: 1.new option numbers. Overview and background The author devisesprocedure described in this document modifies and clarifies the procedure for defining new option. 2.options in RFC 2131 . The author requests a number forprimary modification is to the time at which a new DHCP option from IANA. 3. The author documentsis assigned an option number. In the new option, usingprocedure described in this document, the newly obtainedoption number,number is not assigned until after the option has been accepted as an Internet Draft. 4. The author submitsStandard and the Internet Draftspecification is about to be published as an RFC. DISCUSSION: Since the publication of RFC 2132, the option number space for review throughpublically defined DHCP options (1-127) has almost been exhausted. Many of the IETF standards process asdefined in "Internet Official Protocol Standards" (STD 1).option numbers have not been followed up with Internet Drafts submitted to the DHC WG. There has been a lack of specific guidance to IANA from the DHC WG as to the assignment of DHCP option numbers The procedure as specified in RFC 2132 does not clearly state that new option willoptions are to be submittedreviewed individually for eventualacceptance as anInternet Standard. 5. The new option progressesStandards and that the specifications for newly accepted Standard options are to be published as separate RFCs. RFC 2132 also does not require that new options are to be submitted to the DHC WG through the WG chair, and that the author of the option specification is responsible for bringing new options to the attention of the WG chair for WG review. Finally, RFC 2132 does not make clear that newly defined options are not to be incorporated into products, included in other specifications or otherwise used until accepted as Internet Standards. The Internet Standard DHCP options assigned as of March 1997 are defined in RFC 2132. In the future, new DHCP options will be DRAFT Procedure for Defining New DHCP Options July 1998 reviewed individually by the DHC WG and the IETF standards process;for acceptance as Internet Standards and the specifications will be published as separate RFCs. Groups of related options may be combined into a single specification and reviewed as a set by the DHC WG. Prior to acceptance as an Internet Standard, it is not appropriate to incorporate new options into products, include the specification in other documents or otherwise make use of the new options. DISCUSSION: While the last statement is strong, if it is not included the IETF may be presented with a "fait accompli" in which a new option willis defined and shipped prior to review by the WG. The DHCP option number space (1-254) is split into two parts. The site-specific options (128-254) are defined as "Private Use" and require no review by the DHC WG. The public options (1-127) are defined as "Specification Required" and new options must be reviewed prior to assignment of an option number by IANA. The details of the review process are given in the following section of this document. Procedure The author of a new DHCP option will follow these steps to obtain acceptance of the option as a part of the DHCP Internet Standard: 1. The author devises the new option. 2. The author documents the new option, using the newly obtained option number, as an Internet Draft. 3. The author submits the Internet Draft for review through the IETF standards process as defined in "Internet Official Protocol Standards" (STD 1) . If the Dynamic Host Configuration Working Group (if thatworking group (DHC WG) still exists), orexists, the author MUST submit the specification to the DHC WG through the working group chair. If the DHC WG has concluded, the author MUST submit the specification as an Internet Draft not submitted by an IETF working group. 6. If4. The new option progresses through the IETF standards process. The specification of the new option fails to gainis reviewed by the DHC WG (if it exists) or by the IETF. The option is considered for acceptance as an Internet Standard. If the option is accepted as a Standard, the assignedspecification for the option is published as a separate RFC. 5. At the time of publication as an RFC, IANA assigns a DHCP option number will be returnedto IANAthe new option. DRAFT Procedure for Defining New DHCP Options July 1998 References  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997.  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, Lachman Associates, March 1997.  Narten, T. and H. T. Alvestrand, "Guidelines for reassignment. AcceptanceWriting an IANA Considerations Section in RFCs", (work in progress), May 1998.  Postel, J. (Ed.), "Internet Official Protocol Standards", STD 1, May 1998.  Droms, R. and publication If this procedureK. Fong, "NetWare/IP Domain Name and Information", RFC 2142, November 1997. Security Considerations Information that creates or updates an option number assignment needs to be authenticated. An analysis of security issues is accepted, it willrequired for all newly defined DHCP options. The description of security issues in the specification of new options must be added toas accurate as possible. The specification for a new option may reference the "Security Considerations" section in the DHCP optionsspecification as an Appendix. Security Considerations Security issues; e.g. (from "NetWare/IP Domain Name and Information" ): DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are notdiscussed in this memo.section 7 of the DHCP protocol specification [RFC 2131]. Author's Address Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837 Phone: (717) 524-1145 EMail: email@example.com DRAFT Procedure for Defining New DHCP Options July 1998 Expiration This document will expire on January 2, 1999. DRAFT Procedure for Defining New DHCP Options July 1998 Full Copyright Statement Copyright (C) The Internet Society (1998). 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.