Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types
RFC 2939
Document | Type |
RFC - Best Current Practice
(September 2000; Errata)
Obsoletes RFC 2489
Also known as BCP 43
|
|
---|---|---|---|
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2939 (Best Current Practice) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group R. Droms Request for Comments: 2939 Bucknell University BCP: 43 September 2000 Obsoletes: 2489 Category: Best Current Practice Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types 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 (2000). All Rights Reserved. Abstract The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a Transmission Control Protocol/Internet Protocol (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 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 Best Current Practice [Page 1] RFC 2939 Procedures for New DHCP Options September 2000 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. This document updates and replaces RFC 2489. 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 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 Droms Best Current Practice [Page 2] RFC 2939 Procedures for New DHCP Options September 2000 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 byShow full document text