datatracker.ietf.org
Sign in
Version 5.7.1.p2, 2014-10-29
Report a bug

Procedure for Defining New DHCP Options
RFC 2489

Document type: RFC - Best Current Practice (January 1999; Errata)
Obsoleted by RFC 2939
Also Known As BCP 29
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Document shepherd: No shepherd assigned

IESG State: RFC 2489 (Best Current Practice)
Responsible AD: (None)
Send notices to: No addresses provided

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.

Droms                    Best Current Practice                  [Page 1]
RFC 2489               Defining New DCHP Options            January 1999

   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

Droms                    Best Current Practice                  [Page 2]

[include full document text]