draft-ietf-dhc-new-opt-msg-00.txt   draft-ietf-dhc-new-opt-msg-01.txt 
Network Working Group R. Droms Network Working Group R. Droms
INTERNET-DRAFT Bucknell University INTERNET-DRAFT Bucknell University
May 2000 Obsoletes: draft-ietf-dhc-new-opt-msg-00.txt June 2000
Expires November 2000 Expires December 2000
Procedure for Defining New DHCP Options and Message Types Procedure for Defining New DHCP Options and Message Types
<draft-ietf-dhc-new-opt-msg-00.txt> <draft-ietf-dhc-new-opt-msg-01.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 2, line 29 skipping to change at page 2, line 29
* allocation of new option numbers and message type numbers is * allocation of new option numbers and message type numbers is
coordinated from a single authority, coordinated from a single authority,
* new options and message types are reviewed for technical * new options and message types are reviewed for technical
correctness and appropriateness, and correctness and appropriateness, and
* documentation for new options and message types is complete and * documentation for new options and message types is complete and
published. 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 and message type codes.
procedure outlined in this document will provide guidance to IANA in The new procedure outlined in this document will provide guidance to
the assignment of new option and message type codes. IANA in the assignment of new option and message type codes.
2. Overview and background 2. Overview and background
This document specifies procedures for defining new option codes and This document specifies procedures for defining new option codes and
message types. message types.
2.1 New DHCP option codes 2.1 New DHCP option codes
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. publicly defined DHCP options (1-127) has almost been exhausted.
Many of the defined option numbers have not been followed up with 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 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 specific guidance to IANA from the DHC WG as to the assignment of
DHCP option numbers DHCP option numbers
The procedure as specified in RFC 2132 does not clearly state that The procedure as specified in RFC 2132 does not clearly state that
DRAFT Defining New DHCP Options and Message Types June, 2000 DRAFT Defining New DHCP Options and Message Types June, 2000
new options are to be reviewed individually for technical new options are to be reviewed individually for technical
skipping to change at page 3, line 29 skipping to change at page 3, line 29
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
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 option codes [2] (128-254) are defined as "Private Use"
require no review by the DHC WG. The public options (1-127) are and require no review by the DHC WG. Site-specific options codes
defined as "Specification Required" and new options must be reviewed (128-254) MUST NOT be defined for use by any publicly distributed
prior to assignment of an option number by IANA. The details of the DHCP server or client implementations. These option codes are
review process are given in the following section of this document. explicitly reserved for private definition and use within a site or
an organization.
The public option codes (0-127, 255) 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.
2.2 New DHCP message types 2.2 New DHCP message types
RFC2131 does not specify any mechanism for defining new DHCP message RFC2131 does not specify any mechanism for defining new DHCP message
types. In the future, new DHCP message types will be document in RFCs types. In the future, new DHCP message types will be documented in
approved by the IESG, and the codes for these new message types will RFCs approved by the IESG, and the codes for these new message types
be assigned at the time the relevant RFCs are published. will be assigned at the time the relevant RFCs are published.
Typically, the IESG will seek input on new message types from Typically, the IESG will seek input on new message types from
appropriate sources (e.g., a relevant Working Group if one exists). appropriate sources (e.g., a relevant Working Group if one exists).
Prior to assignment of a message type code, it is not appropriate to Prior to assignment of a message type code, it is not appropriate to
incorporate new message types into products, include the incorporate new message types into products, include the
specification in other documents or otherwise make use of the new specification in other documents or otherwise make use of the new
message types. message types.
DRAFT Defining New DHCP Options and Message Types June, 2000
When the DHC WG has defined a procedure for the consideration and When the DHC WG has defined a procedure for the consideration and
review of changes to the DHCP specification that include the review of changes to the DHCP specification that include the
definition of new message types, that procedure will be followed definition of new message types, that procedure will be followed
prior to the accepatance of any new message types and the publication prior to the acceptance of any new message types and the publication
of the specification of those message types in RFCs. of the specification of those message types in RFCs.
DRAFT Defining New DHCP Options and Message Types June, 2000
3. Procedure 3. Procedure
The author of a new DHCP option or message type will follow these The author of a new DHCP option or message type will follow these
steps to obtain approval for the option and publication of the steps to obtain approval for the option and publication of the
specification of the option as an RFC: specification of the option as an RFC:
1. The author devises the new option or message type. 1. The author devises the new option or message type.
2. The author documents the new option or message type, leaving the 2. The author documents the new option or message type, leaving the
option code or message type code as "To Be Determined" (TBD), as option code or message type code as "To Be Determined" (TBD), as
skipping to change at page 4, line 48 skipping to change at page 5, line 5
the IESG. The specification is reviewed by the DHC WG (if it the IESG. The specification is reviewed by the DHC WG (if it
exists) or by the IETF. If the option or message type is accepted exists) or by the IETF. If the option or message type is accepted
for inclusion in the DHCP specification, the specification of the for inclusion in the DHCP specification, the specification of the
option or message type is published as an RFC. It may be option or message type is published as an RFC. It may be
published as either a standards-track or a non-standards-track published as either a standards-track or a non-standards-track
RFC. 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
code or message type code to the new option or message type. code or message type code to the new option or message type.
DRAFT Defining New DHCP Options and Message Types June, 2000
4. References 4. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell
University, March 1997. University, 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, Lachman Associates, March 1997.
DRAFT Defining New DHCP Options and Message Types June, 2000
[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", RFC
2142, November 1997. 2142, November 1997.
[4] Narten, T. and H. T. Alvestrand, "Guidelines for Writing an IANA [4] Narten, T. and H. T. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998. Considerations Section in RFCs", RFC 2434, October 1998.
5. Security Considerations [5] Droms, R., "Procedure for Defining New DHCP Options", RFC 2489,
January 1999.
5. Changes from RFC2489
This document extends the procedures for defining new DHCP options
specified in RFC 2489 [5] to include the definition of new DHCP
message types. The language reserving site-specific option codes
has been strengthened to emphasize the requirement that site-
specific option codes must not be encoded in publicly distributed
DHCP implementations.
6. Security Considerations
Information that creates or updates an option code or message type Information that creates or updates an option code or message type
code assignment needs to be authenticated. code assignment needs 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 or message types. The description of security issues in the options or message types. The description of security issues in the
specification of new options or message types must be as accurate as specification of new options or message types must be as accurate as
possible. The specification for a new option or message typemay possible. The specification for a new option or message typemay
reference the "Security Considerations" section in the DHCP reference the "Security Considerations" section in the DHCP
specification [1]; e.g. (from "NetWare/IP Domain Name and 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].
6. IANA Considerations DRAFT Defining New DHCP Options and Message Types June, 2000
7. IANA Considerations
RFC 2132 provided guidance to the IANA on the procedure it should RFC 2132 provided guidance to the IANA on the procedure it should
follow when assigning option numbers for new DHCP options or message follow when assigning option numbers for new DHCP options or message
types. This document updates and replaces those instructions. In types. This document updates and replaces those instructions. In
particular, IANA is requested to assign DHCP option codes or message particular, IANA is requested to assign DHCP option codes or message
type codes only for options or message types that have been approved type codes only for options or message types that have been approved
for publication as RFCs; i.e., documents that have been approved for publication as RFCs; i.e., documents that have been approved
through "IETF consensus" as defined in RFC 2434 [4]. through "IETF consensus" as defined in RFC 2434 [4].
7. Author's Address 8. 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: 570) 524-1145 Phone: 570) 524-1145
EMail: droms@bucknell.edu EMail: droms@bucknell.edu
8. Expiration 9. Expiration
This document will expire on November 30, 2000. This document will expire on December 31, 2000.
DRAFT Defining New DHCP Options and Message Types June, 2000 DRAFT Defining New DHCP Options and Message Types June, 2000
9. Full Copyright Statement 10. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). 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 and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are 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
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/