This is a purely informative rendering of an RFC that includes verified errata. This rendering may not be used as a reference.

The following 'Verified' errata have been incorporated in this document: EID 855
Network Working Group                                           R. Droms
Request for Comments: 2489                           Bucknell University
BCP: 29                                                     January 1999
Category: Best Current Practice


                Procedure for Defining New DHCP Options

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

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.

1. Introduction

   The Dynamic Host Configuration Protocol (DHCP) [1] 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." [2]

   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.

   As indicated in "Guidelines for Writing an IANA Considerations
   Section in RFCs" (see references), IANA acts as a central authority
   for assignment of numbers such as DHCP option codes.  The new
   procedure outlined in this document will provide guidance to IANA in
   the assignment of new option codes.

2. Overview and background

   The procedure described in this document modifies and clarifies the
   procedure for defining new options in RFC 2131 [2].  The primary
   modification is to the time at which a new DHCP option is assigned an
   option number.  In the procedure described in this document, the
   option number is not assigned until specification for the option is
   about to be published as an RFC.

   Since the publication of RFC 2132, the option number space for
   publically defined DHCP options (1-127) has almost been exhausted.
   Many of the defined 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 options are to be reviewed individually for technical
   correctness, appropriateness and complete documentation.  RFC 2132
   also does not require that new options are to be submitted to the
   IESG for review, and that the author of the option specification is
   responsible for bringing new options to the attention of the IESG.
   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 the specification for the
   option is published as an RFC.

   In the future, new DHCP option codes will be assigned by IETF
   consensus.  New DHCP options will be documented in RFCs approved by
   the IESG, and the codes for those options will be assigned at the
   time the relevant RFCs are published.  Typically, the IESG will seek
   input on prospective assignments from appropriate sources (e.g., a
   relevant Working Group if one exists).  Groups of related options may
   be combined  into a single specification and reviewed as a set by the
   IESG.  Prior to assignment of an option code, it is not appropriate
   to incorporate new options into products, include the specification
   in other documents or otherwise make use of the new options.

   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.

3. Procedure

   The author of a new DHCP option will follow these steps to obtain
   approval for the option and publication of the specification of the
   option as an RFC:

   1. The author devises the new option.

   2. The author documents the new option, leaving the option code as
      "To Be Determined" (TBD), as an Internet Draft.

      The requirement that the new option be documented as an Internet
      Draft is a matter of expediency.  In theory, the new option could
      be documented on the back of an envelope for submission; as a
      practical matter, the specification will eventually become an
      Internet Draft as part of the review process.

   3. The author submits the Internet Draft for review by the IESG.
      Preferably, the author will submit the Internet Draft to the DHC
      Working Group, but the author may choose to submit the Internet
      Draft directly to the IESG.

      Note that simply publishing the new option as an Internet Draft
      does not automatically bring the option to the attention of the
      IESG.  The author of the new option must explicitly forward a
      request for action on the new option to the DHC WG or the IESG.

   4. The specification of the new option is reviewed by the IESG.  The
      specification is reviewed by the DHC WG (if it exists) or by the
      IETF.  If the option is accepted for inclusion in the DHCP
      specification, the specification of the option is published as an
      RFC.  It may be published as either a standards-track or a non-
      standards-track RFC.

   5. At the time of publication as an RFC, IANA assigns a DHCP option
      number to the new option.

4. References

   [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
       March 1997.

   [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
       Extensions", RFC 2132, March 1997.

      [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information", 
       RFC 2242, November 1997.
EID 855 (Verified) is as follows:

Section: 4

Original Text:

   [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
       RFC 2142, November 1997.

Corrected Text:

   [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
       RFC 2242, November 1997.
Notes:
References to RFC 2142 should be to 2242.

from pending
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 5. Security Considerations Information that creates or updates an option number assignment needs to be authenticated. An analysis of security issues is required for all newly defined DHCP options. The description of security issues in the specification of new options must be as accurate as possible. The specification for a new option may reference the "Security Considerations" section in the DHCP specification [1]; e.g. (from "NetWare/IP Domain Name and Information" [3]): DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [RFC 2131]. 6. IANA Considerations RFC 2132 provided guidance to the IANA on the procedure it should follow when assigning option numbers for new DHCP options. This document updates and replaces those instructions. In particular, IANA is requested to assign DHCP option numbers only for options that have been approved for publication as RFCs; i.e., documents that have been approved through "IETF consensus" as defined in RFC 2434 [4]. 7. Author's Address Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837 Phone: (717) 524-1145 EMail: droms@bucknell.edu 8. Full Copyright Statement Copyright (C) The Internet Society (1999). 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.