[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 RFC 2939

Network Working Group                                           R. Droms
INTERNET-DRAFT                                       Bucknell University
Obsoletes: draft-ietf-dhc-new-opt-msg-00.txt                   June 2000
                                                   Expires December 2000


       Procedure for Defining New DHCP Options and Message Types
                  <draft-ietf-dhc-new-opt-msg-01.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, and the list of
   Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

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."

   DHCP protocol messages are identified by the 'DHCP Message Type'
   option (option code 51).  Each message type is defined by the data
   value carried in the 'DHCP Message Type' option.

   New DHCP options and message types may be defined after the
   publication of the DHCP specification to accommodate requirements for
   conveyance of new configuration parameters or to accommodate new
   protocol semantics. This document describes the procedure for
   defining new DHCP options and message types.

1. Introduction

   The Dynamic Host Configuration Protocol (DHCP) [1] provides a



Droms                                                           [Page 1]

DRAFT         Defining New DHCP Options and Message Types     June, 2000


   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]

   DHCP protocol messages are identified by the 'DHCP Message Type'
   option (option code 51).  Each message type is defined by the data
   value carried in the 'DHCP Message Type' option.

   This document describes the procedure for defining new DHCP options
   and message types. The procedure will guarantee that:

   * allocation of new option numbers and message type numbers is
     coordinated from a single authority,
   * new options and message types are reviewed for technical
     correctness and appropriateness, and
   * documentation for new options and message types 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 and message type codes.
   The new procedure outlined in this document will provide guidance to
   IANA in the assignment of new option and message type codes.

2. Overview and background

   This document specifies procedures for defining new option codes and
   message types.

2.1 New DHCP option codes

   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
   publicly 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



Droms                                                           [Page 2]

DRAFT         Defining New DHCP Options and Message Types     June, 2000


   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 option codes [2] (128-254) are defined as "Private Use"
   and require no review by the DHC WG.  Site-specific options codes
   (128-254) MUST NOT be defined for use by any publicly distributed
   DHCP server or client implementations. These option codes are
   explicitly reserved for private definition and use within a site or
   an organization.

   The public option codes (0-127, 255) 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.

2.2 New DHCP message types

   RFC2131 does not specify any mechanism for defining new DHCP message
   types. In the future, new DHCP message types will be documented in
   RFCs approved by the IESG, and the codes for these new message types
   will be assigned at the time the relevant RFCs are published.

   Typically, the IESG will seek input on new message types from
   appropriate sources (e.g., a relevant Working Group if one exists).
   Prior to assignment of a message type code, it is not appropriate to
   incorporate new message types into products, include the
   specification in other documents or otherwise make use of the new
   message types.




Droms                                                           [Page 3]

DRAFT         Defining New DHCP Options and Message Types     June, 2000


   When the DHC WG has defined a procedure for the consideration and
   review of changes to the DHCP specification that include the
   definition of new message types, that procedure will be followed
   prior to the acceptance of any new message types and the publication
   of the specification of those message types in RFCs.

3. Procedure

   The author of a new DHCP option or message type 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 or message type.

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

      The requirement that the new option or message type be documented
      as an Internet Draft is a matter of expediency.  In theory, the
      new option or message type 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 or message type as an
      Internet Draft does not automatically bring the option to the
      attention of the IESG.  The author of the new option or message
      type 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 or message type is reviewed by
      the IESG.  The specification is reviewed by the DHC WG (if it
      exists) or by the IETF.  If the option or message type is accepted
      for inclusion in the DHCP specification, the specification of the
      option or message type 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
      code or message type code to the new option or message type.





Droms                                                           [Page 4]

DRAFT         Defining New DHCP Options and Message Types     June, 2000


4. References

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

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

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

[4] Narten, T. and  H. T. Alvestrand, "Guidelines for Writing an IANA
    Considerations Section in RFCs", RFC 2434, October 1998.

[5] Droms, R., "Procedure for Defining New DHCP Options", RFC 2489,
    January 1999.

5. Changes from RFC2489

    This document extends the procedures for defining new DHCP options
    specified in RFC 2489 [5] to include the definition of new DHCP
    message types.  The language reserving site-specific option codes
    has been strengthened to emphasize the requirement that site-
    specific option codes must not be encoded in publicly distributed
    DHCP implementations.

6. Security Considerations

   Information that creates or updates an option code or message type
   code assignment needs to be authenticated.

   An analysis of security issues is required for all newly defined DHCP
   options or message types.  The description of security issues in the
   specification of new options or message types must be as accurate as
   possible.  The specification for a new option or message type 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].









Droms                                                           [Page 5]

DRAFT         Defining New DHCP Options and Message Types     June, 2000


7. IANA Considerations

   RFC 2132 provided guidance to the IANA on the procedure it should
   follow when assigning option numbers for new DHCP options or message
   types.  This document updates and replaces those instructions.  In
   particular, IANA is requested to assign DHCP option codes or message
   type codes only for options or message types that have been approved
   for publication as RFCs; i.e., documents that have been approved
   through "IETF consensus" as defined in RFC 2434 [4].

8. Author's Address

   Ralph Droms
   Computer Science Department
   323 Dana Engineering
   Bucknell University
   Lewisburg, PA 17837

   Phone: 570) 524-1145
   EMail: droms@bucknell.edu

9. Expiration

   This document will expire on December 31, 2000.



























Droms                                                           [Page 6]

DRAFT         Defining New DHCP Options and Message Types     June, 2000


10. Full Copyright Statement

   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.

























Droms                                                           [Page 7]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/