draft-ietf-dhc-new-options-04.txt   rfc2489.txt 
Network Working Group R. Droms Network Working Group R. Droms
INTERNET-DRAFT Bucknell University Request for Comments: 2489 Bucknell University
Obsoletes: draft-ietf-dhc-new-options-03.txt October 1998 BCP: 29 January 1999
Expires April 1999 Category: Best Current Practice
Procedure for Defining New DHCP Options Procedure for Defining New DHCP Options
<draft-ietf-dhc-new-options-04.txt>
Status of this memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document specifies an Internet Best Current Practices for the
documents of the Internet Engineering Task Force (IETF), its areas, Internet Community, and requests discussion and suggestions for
and its working groups. Note that other groups may also distribute improvements. Distribution of this memo is unlimited.
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
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 Copyright (C) The Internet Society (1999). All Rights Reserved.
"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 Abstract
The Dynamic Host Configuration Protocol (DHCP) provides a framework The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a TCP/IP network. for passing configuration information to hosts on a TCP/IP network.
Configuration parameters and other control information are carried in Configuration parameters and other control information are carried in
tagged data items that are stored in the 'options' field of the DHCP tagged data items that are stored in the 'options' field of the DHCP
message. The data items themselves are also called "options." message. The data items themselves are also called "options."
New DHCP options may be defined after the publication of the DHCP New DHCP options may be defined after the publication of the DHCP
specification to accommodate requirements for conveyance of new specification to accommodate requirements for conveyance of new
configuration parameters. This document describes the procedure for configuration parameters. This document describes the procedure for
defining new DHCP options. defining new DHCP options.
Introduction 1. Introduction
The Dynamic Host Configuration Protocol (DHCP) [1] provides a The Dynamic Host Configuration Protocol (DHCP) [1] provides a
framework for passing configuration information to hosts on a TCP/IP framework for passing configuration information to hosts on a TCP/IP
network. Configuration parameters and other control information are network. Configuration parameters and other control information are
carried in tagged data items that are stored in the 'options' field carried in tagged data items that are stored in the 'options' field
of the DHCP message. The data items themselves are also called of the DHCP message. The data items themselves are also called
"options." [2] "options." [2]
DRAFT Procedure for Defining New DHCP Options October 1998
This document describes the procedure for defining new DHCP options. This document describes the procedure for defining new DHCP options.
The procedure will guarantee that: The procedure will guarantee that:
* allocation of new option numbers is coordinated from a single * allocation of new option numbers is coordinated from a single
authority, authority,
* new options are reviewed for technical correctness and * new options are reviewed for technical correctness and
appropriateness, and appropriateness, and
* documentation for new options is complete and published. * documentation for new options is complete and published.
As indicated in "Guidelines for Writing an IANA Considerations As indicated in "Guidelines for Writing an IANA Considerations
Section in RFCs" (see references), IANA acts as a central authority Section in RFCs" (see references), IANA acts as a central authority
for assignment of numbers such as DHCP option codes. The new for assignment of numbers such as DHCP option codes. The new
procedure outlined in this document will provide guidance to IANA in procedure outlined in this document will provide guidance to IANA in
the assignment of new option codes. the assignment of new option codes.
Overview and background 2. Overview and background
The procedure described in this document modifies and clarifies the The procedure described in this document modifies and clarifies the
procedure for defining new options in RFC 2131 [2]. The primary 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 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. In the procedure described in this document, the
option number is not assigned until specification for the option is option number is not assigned until specification for the option is
about to be published as an RFC. about to be published as an RFC.
Since the publication of RFC 2132, the option number space for Since the publication of RFC 2132, the option number space for
publically defined DHCP options (1-127) has almost been exhausted. publically defined DHCP options (1-127) has almost been exhausted.
skipping to change at page 3, line 4 skipping to change at page 2, line 44
not to be incorporated into products, included in other not to be incorporated into products, included in other
specifications or otherwise used until the specification for the specifications or otherwise used until the specification for the
option is published as an RFC. option is published as an RFC.
In the future, new DHCP option codes will be assigned by IETF In the future, new DHCP option codes will be assigned by IETF
consensus. New DHCP options will be documented in RFCs approved by consensus. New DHCP options will be documented in RFCs approved by
the IESG, and the codes for those options will be assigned at the the IESG, and the codes for those options will be assigned at the
time the relevant RFCs are published. Typically, the IESG will seek time the relevant RFCs are published. Typically, the IESG will seek
input on prospective assignments from appropriate sources (e.g., a input on prospective assignments from appropriate sources (e.g., a
relevant Working Group if one exists). Groups of related options may relevant Working Group if one exists). Groups of related options may
DRAFT Procedure for Defining New DHCP Options October 1998
be combined into a single specification and reviewed as a set by the 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 IESG. Prior to assignment of an option code, it is not appropriate
to incorporate new options into products, include the specification to incorporate new options into products, include the specification
in other documents or otherwise make use of the new options. in other documents or otherwise make use of the new options.
The DHCP option number space (1-254) is split into two parts. The The DHCP option number space (1-254) is split into two parts. The
site-specific options (128-254) are defined as "Private Use" and site-specific options (128-254) are defined as "Private Use" and
require no review by the DHC WG. The public options (1-127) are require no review by the DHC WG. The public options (1-127) are
defined as "Specification Required" and new options must be reviewed defined as "Specification Required" and new options must be reviewed
prior to assignment of an option number by IANA. The details of the prior to assignment of an option number by IANA. The details of the
review process are given in the following section of this document. review process are given in the following section of this document.
Procedure 3. Procedure
The author of a new DHCP option will follow these steps to obtain The author of a new DHCP option will follow these steps to obtain
approval for the option and publication of the specification of the approval for the option and publication of the specification of the
option as an RFC: option as an RFC:
1. The author devises the new option. 1. The author devises the new option.
2. The author documents the new option, leaving the option code as 2. The author documents the new option, leaving the option code as
"To Be Determined" (TBD), as an Internet Draft. "To Be Determined" (TBD), as an Internet Draft.
The requirement that the new option be documented as an Internet The requirement that the new option be documented as an Internet
Draft is a matter of expediency. In theory, the new option could Draft is a matter of expediency. In theory, the new option could
be documented on the back of an envelope for submission; as a be documented on the back of an envelope for submission; as a
practical matter, the specification will eventually become an practical matter, the specification will eventually become an
Internet Draft as part of the review process. Internet Draft as part of the review process.
3. The author submits the Internet Draft for review by the IESG. 3. The author submits the Internet Draft for review by the IESG.
skipping to change at page 4, line 5 skipping to change at page 3, line 45
4. The specification of the new option is reviewed by the IESG. The 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 specification is reviewed by the DHC WG (if it exists) or by the
IETF. If the option is accepted for inclusion in the DHCP IETF. If the option is accepted for inclusion in the DHCP
specification, the specification of the option is published as an specification, the specification of the option is published as an
RFC. It may be published as either a standards-track or a non- RFC. It may be published as either a standards-track or a non-
standards-track RFC. standards-track RFC.
5. At the time of publication as an RFC, IANA assigns a DHCP option 5. At the time of publication as an RFC, IANA assigns a DHCP option
number to the new option. number to the new option.
DRAFT Procedure for Defining New DHCP Options October 1998 4. References
References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
University, March 1997. March 1997.
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, Lachman Associates, March 1997. Extensions", RFC 2132, March 1997.
[3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information", RFC [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
2142, November 1997. RFC 2142, November 1997.
Note: This document was written after consideration of information [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
found in "Guidelines for Writing an IANA Considerations Section in Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
RFCs" <draft-iesg-iana-considerations-06.txt>, by T. Narten and H.
T. Alvestrand, which is a work in progress.
Security Considerations 5. Security Considerations
Information that creates or updates an option number assignment needs Information that creates or updates an option number assignment needs
to be authenticated. to be authenticated.
An analysis of security issues is required for all newly defined DHCP An analysis of security issues is required for all newly defined DHCP
options. The description of security issues in the specification of options. The description of security issues in the specification of
new options must be as accurate as possible. The specification for a new options must be as accurate as possible. The specification for a
new option may reference the "Security Considerations" section in the new option may reference the "Security Considerations" section in the
DHCP specification [1]; e.g. (from "NetWare/IP Domain Name and DHCP specification [1]; e.g. (from "NetWare/IP Domain Name and
Information" [3]): Information" [3]):
DHCP currently provides no authentication or security mechanisms. DHCP currently provides no authentication or security mechanisms.
Potential exposures to attack are discussed in section 7 of the Potential exposures to attack are discussed in section 7 of the
DHCP protocol specification [RFC 2131]. DHCP protocol specification [RFC 2131].
Author's Address 6. 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 [4].
7. Author's Address
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
323 Dana Engineering 323 Dana Engineering
Bucknell University Bucknell University
Lewisburg, PA 17837 Lewisburg, PA 17837
Phone: (717) 524-1145 Phone: (717) 524-1145
EMail: droms@bucknell.edu EMail: droms@bucknell.edu
Expiration 8. Full Copyright Statement
This document will expire on March 31, 1999.
DRAFT Procedure for Defining New DHCP Options October 1998
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published
distributed, in whole or in part, without restriction of any kind, and distributed, in whole or in part, without restriction of any
provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing Internet organizations, except as needed for the purpose of
Internet standards in which case the procedures for copyrights defined developing Internet standards in which case the procedures for
in the Internet Standards process must be followed, or as required to copyrights defined in the Internet Standards process must be
translate it into languages other than English. followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 24 change blocks. 
59 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/