RFC 
 2489 
 TOC 
Network Working GroupR. Droms
Request for Comments: 2489Bucknell University, Computer
BCP: 29Science Department
Category: Best Current PracticeJanuary 1999


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


 RFC 
 2489 
 TOC 

Table of Contents

1.  Introduction
2.  Overview and background
3.  Procedure
4.  References (BOILERPLATE)
5.  Security Considerations
6.  Security Considerations
7.  IANA Considerations
8.  Author's Address (BOILERPLATE)
9.  Full Copyright Statement (BOILERPLATE)
10.  References
§  Author's Address
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

The Dynamic Host Configuration Protocol (DHCP) [RFC2131] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) 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." [RFC2132] (Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions,” March 1997.)

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.



 TOC 

2.  Overview and background

The procedure described in this document modifies and clarifies the procedure for defining new options in RFC 2131 [RFC2132] (Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions,” March 1997.). 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.



 TOC 

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.



 TOC 

4.  References (BOILERPLATE)

This RFC contained boilerplate in this section which has been moved to the RFC2223-compliant unnumbered section "References."



 TOC 

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 [RFC2131] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.); e.g. (from "NetWare/IP Domain Name and Information" [RFC2142] (Crocker, D., “MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS,” May 1997.)):

DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [RFC 2131].



 TOC 

6.  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 [RFC2131] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.); e.g. (from "NetWare/IP Domain Name and Information" [RFC2142] (Crocker, D., “MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS,” May 1997.)):

DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [RFC 2131].



 TOC 

7.  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 [RFC2434] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” October 1998.).



 TOC 

8.  Author's Address (BOILERPLATE)

This RFC contained boilerplate in this section which has been moved to the RFC2223-compliant unnumbered section "Author's Address."



 TOC 

9.  Full Copyright Statement (BOILERPLATE)

This RFC contained boilerplate in this section which has been moved to the RFC2223-compliant unnumbered section "Full Copyright Statement."



 TOC 

10. References

[RFC2131] Droms, R., “Dynamic Host Configuration Protocol,” RFC 2131, March 1997 (TXT, HTML, XML).
[RFC2132] Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions,” RFC 2132, March 1997 (TXT, HTML, XML).
[RFC2142] Crocker, D., “MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS,” RFC 2142, May 1997 (TXT, HTML, XML).
[RFC2434] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 2434, October 1998 (TXT, HTML, XML).


 TOC 

Author's Address

  Ralph Droms
  Bucknell University, Computer Science Department
  323 Dana Engineering
  Lewisburg, PA 17837
  USA
Phone:  +1 717 524 1145
Email:  droms@bucknell.edu


 TOC 

Full Copyright Statement

Intellectual Property