Network Working Group                                           R. Droms
INTERNET-DRAFT                                       Bucknell University
Obsoletes: draft-ietf-dhc-new-options-01.txt                 August 1998
                                                   Expires February 1999


                Procedure for Defining New DHCP Options
                  <draft-ietf-dhc-new-options-02.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 in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
   ftp.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) [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]



Droms                                                           [Page 1]


DRAFT           Procedure for Defining New DHCP Options      August 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.

   As indicated in "Guidelines for Writing an IANA Considerations
   Section in RFCs" [3], IANA acts as a central authority for assignment
   of numbers for new DHCP options.  The new procedure outlined in this
   document will provide guidance to IANA in the assignment of new
   option numbers.

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 after the option has been
   accepted as an Internet Standard and the specification is about to be
   published as an RFC.

   DISCUSSION:

      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 acceptance as
      Internet Standards 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



Droms                                                           [Page 2]


DRAFT           Procedure for Defining New DHCP Options      August 1998


   reviewed individually by the DHC WG and the IETF 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 is
      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, leaving the option code as
      "To Be Determined" (TBD), as an Internet Draft.

      DISCUSSION:
         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 through the IETF
      standards process as defined in "Internet Official Protocol
      Standards" (STD 1) [4] and "Internet Standards Process" (BCP 9)
      [6].

      DISCUSSION:
         Note that simply publishing the new option as an Internet Draft
         does not automatically enter the option into the Standards
         Track.  The author of the new option must explicitly forward a



Droms                                                           [Page 3]


DRAFT           Procedure for Defining New DHCP Options      August 1998


         request for action on the new option to the DHC WG or the IESG.

   4. The new option progresses through the IETF standards process.  The
      specification of the new option is 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 specification for the option is published as a separate RFC.

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

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] Narten, T. and H. T. Alvestrand, "Guidelines for Writing an IANA
    Considerations Section in RFCs", (work in progress), May 1998.

[4] Postel, J. (Ed.), "Internet Official Protocol Standards", STD 1, May
    1998.

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

[6] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
    October, 1996.

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" [5]):

      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 4]


DRAFT           Procedure for Defining New DHCP Options      August 1998


Author's Address

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

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

Expiration

   This document will expire on February 2, 1999.





































Droms                                                           [Page 5]


DRAFT           Procedure for Defining New DHCP Options      August 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.

























Droms                                                           [Page 6]