draft-ietf-dhc-option-review-and-namespace-00.txt   draft-ietf-dhc-option-review-and-namespace-01.txt 
Network Working Group Michael Carney Network Working Group Michael Carney
Dynamic Host Configuration Working Group Sun Microsystems, Inc Dynamic Host Configuration Working Group Sun Microsystems, Inc
Category: Standards Track June 1999 Category: Standards Track October 1999
New Option Review Guidelines and Additional Option Namespace New Option Review Guidelines and Additional Option Namespace
<draft-ietf-dhc-option-review-and-namespace-00.txt> <draft-ietf-dhc-option-review-and-namespace-01.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at line 54 skipping to change at line 55
the DHC WG option draft review process has identified a number of the DHC WG option draft review process has identified a number of
deficiencies, namely: deficiencies, namely:
* We're rapidly going through the remaining option codes, and face * We're rapidly going through the remaining option codes, and face
the possibility of exhausting the remaining codes before the the possibility of exhausting the remaining codes before the
wide-spread adoption of IPv6 is achieved. wide-spread adoption of IPv6 is achieved.
* There are no guidelines to help the DHC WG and the DHCP * There are no guidelines to help the DHC WG and the DHCP
community at large gauge the impact of the addition of new community at large gauge the impact of the addition of new
options. Some options that have been proposed require changes to options. Some options that have been proposed require changes to
the DHCP protocol itself and/or current implementations. Because the DHCP protocol itself and/or current implementations. Because
the adoption of such options has a greater impact on the DHCP the adoption of such options has a greater impact on the DHCP
community than other, simple "payload" options, these options community than other, simple "payload" options, these options
require more scrutiny by the DHC WG and IESG. require more scrutiny by the DHC WG and IESG.
* Since some options could change the DHCP protocol itself, we * Because some options could change the DHCP protocol itself, we
need a method of explicitly communicating the change of DHCP need a method of explicitly communicating the change of DHCP
versions among implementations. Today, we have no such method. versions among implementations. Today, we have no such method.
* There is no provision to preserve compatibility with earlier * There is no provision to preserve compatibility with earlier
versions of the protocol. versions of the protocol.
Interoperability testing at Connectathon (1997, 1998, and 1999) Interoperability testing at Connectathon (1997, 1998, and 1999)
has shown a reduction in the level of interoperability between has shown a reduction in the level of interoperability between
implementations. These interoperability problems were found to implementations. These interoperability problems were found to
be due to confusion among implementors about how certain features be due to confusion among implementors about how certain features
skipping to change at line 107 skipping to change at line 107
2. Option Review Guidelines 2. Option Review Guidelines
We tackle the option code review problem by defining a set of We tackle the option code review problem by defining a set of
option categories based upon upon the impact the adoption of an option categories based upon upon the impact the adoption of an
option will have on the DHCP community. Option drafts appropriately option will have on the DHCP community. Option drafts appropriately
categorized aid reviewers by helping them evaluate the draft. Once categorized aid reviewers by helping them evaluate the draft. Once
the DHC WG and the draft author(s) agree on the category of the the DHC WG and the draft author(s) agree on the category of the
proposed option, that category will be listed explicitly in the proposed option, that category will be listed explicitly in the
abstract of the option draft. abstract of the option draft.
2.1. General Option Draft Review Guidelines 2.1. Hints for selecting the correct option category
A) This option has no relationship to other existing or proposed A) This option has no relationship to other existing or proposed
options. It would not require change of existing DHCP client, options. It would not require change of existing DHCP client,
server, or BOOTP relay agent implementations. It would not server, or BOOTP relay agent implementations. It would not
change the version of the DHCP protocol. Its introduction change the version of the DHCP protocol. Its introduction
would not invalidate previous version(s) of the DHCP protocol. would not invalidate previous version(s) of the DHCP protocol.
Is this option better handled by the Service Location Is this option better handled by the Service Location
Protocol (SLP) [7]? If it provides data which is unrelated Protocol (SLP) [7]? If it provides data which is unrelated
to network interface configuration, then the option proposer to network interface configuration, then the option proposer
SHOULD consider the use of SLP for the delivery of this data, SHOULD consider the use of SLP for the delivery of this data,
if SLP is deployed widely enough to meet her needs. if SLP is deployed widely enough to meet her needs.
B) This option has no relationship to other existing or proposed B) This option has no relationship to other existing or proposed
skipping to change at line 160 skipping to change at line 158
default option type (Section 3.5 below). It MAY change the default option type (Section 3.5 below). It MAY change the
behavior of existing DHCP client, server, and/or BOOTP relay behavior of existing DHCP client, server, and/or BOOTP relay
agent implementations. It would not change the DHCP protocol agent implementations. It would not change the DHCP protocol
version. Its introduction would not invalidate previous version. Its introduction would not invalidate previous
version(s) of the DHCP protocol. version(s) of the DHCP protocol.
Examples of implicit/explicit option relationships: Examples of implicit/explicit option relationships:
Option Related Options Option Related Options
------ --------------- ------ ---------------
Client Class Encapsulated vendor option(s) Vendor Class Identifier Encapsulated vendor option(s)
User Class Standard option's scope User Class Identifier Standard option's scope
E) The addition of this option would change Table 3, "Fields and E) The addition of this option would change Table 3, "Fields and
options used by DHCP servers" and/or Table 5, "Fields and options used by DHCP servers" and/or Table 5, "Fields and
options used by DHCP clients" in RFC 2131 [1], and thus options used by DHCP clients" in RFC 2131 [1], and thus
change the DHCP protocol. Pre-existing versions / change the DHCP protocol. Pre-existing versions /
implementations would continue to interoperate. implementations would continue to interoperate.
F) The addition of this option would invalidate previous F) The addition of this option would invalidate previous
versions of the DHCP protocol, preventing client, server, versions of the DHCP protocol, preventing client, server,
and/or BOOTP relay agents implementing the earlier version(s) and/or BOOTP relay agents implementing the earlier version(s)
skipping to change at line 204 skipping to change at line 202
They MAY be either RFC 2132-form or RFC TBD-form options. They MUST They MAY be either RFC 2132-form or RFC TBD-form options. They MUST
NOT be dependent on other options being present or absent. Earlier NOT be dependent on other options being present or absent. Earlier
versions/implementations of the protocol continue to interoperate versions/implementations of the protocol continue to interoperate
in the presence of these options. Administrative tools and DHCP in the presence of these options. Administrative tools and DHCP
protocol debugging tools which generically support the default protocol debugging tools which generically support the default
option types MAY need to be reconfigured in order to permit option types MAY need to be reconfigured in order to permit
management of the new option. Options of this type are "payload" management of the new option. Options of this type are "payload"
options, and MUST be of one of the default option types for the options, and MUST be of one of the default option types for the
option block form (RFC 2132 or RFC TBD). option block form (RFC 2132 or RFC TBD).
Although category one options do not require DHCP protocol / DHCP
implementation interoperability testing, they do require
interoperability testing between the programs(s) which ultimately
will consume the information contained within the option value.
Acceptance criteria: Acceptance criteria:
Working group/IETF community review: Yes. Working group/IETF community review: Yes.
IANA option number registration: Yes. IANA option number registration: Yes.
Interoperability testing (2 or more implementations) No. Interoperability testing (2 or more implementations) No.
DHCP protocol version change: No. DHCP protocol version change: No.
2.3. Category Two Options 2.3. Category Two Options
Options in this category MUST NOT require changes to the DHCP Options in this category MUST NOT require changes to the DHCP
skipping to change at line 354 skipping to change at line 344
interoperability testing could occur at the next Connectathon interoperability testing could occur at the next Connectathon
event (held late February/early March every year). event (held late February/early March every year).
The selection of which name space from which to allocate an option The selection of which name space from which to allocate an option
is left to the DHC WG and IESG, following the process outlined in is left to the DHC WG and IESG, following the process outlined in
Ralph Drom's "Procedure for Defining New DHCP Options" [4]. Ralph Drom's "Procedure for Defining New DHCP Options" [4].
3.4. RFC 2132 Option Block Form 3.4. RFC 2132 Option Block Form
For convenience, I have extracted the description of RFC 2132-form For convenience, I have extracted the description of RFC 2132-form
options from [2]. options from RFC 2132 [2].
code len value code len value
+---+---+------- +---+---+-------
| | | ... | | | ...
+---+---+------- +---+---+-------
Options of this form consist of three single octet fields: code, Options of this form consist of three single octet fields: code,
len, and value. len, and value.
The code value is a single octet (0-255). 0 (pad) and 255 (end) The code value is a single octet (0-255). 0 (pad) and 255 (end)
skipping to change at line 601 skipping to change at line 590
include a policy mechanism which turns on pure RFC TBD-form and include a policy mechanism which turns on pure RFC TBD-form and
thus disables the RFC 2132-form request method. Such behavior thus disables the RFC 2132-form request method. Such behavior
might be controlled by a RFC 2132-form option, for example. might be controlled by a RFC 2132-form option, for example.
* RFC TBD-form requests look like BOOTP requests with an * RFC TBD-form requests look like BOOTP requests with an
unrecognized magic cookie. Disabling BOOTP compatibility in unrecognized magic cookie. Disabling BOOTP compatibility in
RFC 2132 servers and turning it on in RFC TBD servers (which RFC 2132 servers and turning it on in RFC TBD servers (which
can appropriately recognize the clients) seems like a reasonable can appropriately recognize the clients) seems like a reasonable
approach. approach.
* Relationship between DHCP protocol version and option block
format. Section 4.1.1 states that a client will prefer RFC TBD-
form replies over RFC 2132-form replies first, then within the
selected option block form, DHCP protocol version. Do people
believe that this is the correct ordering? Should clients
prefer version over option block form instead?
* This document doesn't currently address the addition of new
message types. The addition of new message types will change
Table 3 and Table 5 of RFC 2131 [1]. Usually, the addition of a
new message type doesn't require changes to existing
implementations. DHCPINFORM is an example of such a message
type. Such message types fall into category 3. The addition of
message types which require changes to existing implementations
fall into category 4.
The addition of new message types does not require a change in
the DHCP protocol version, since each additional message
implicitly represents a backward compatible DHCP protocol
change in most cases.
6. Security Considerations 6. Security Considerations
Not Applicable. Not Applicable.
7. Acknowledgements 7. Acknowledgements
The author would like to gratefully acknowledge the active The author would like to gratefully acknowledge the active
participation of the following DHCP future panel members: participation of the following DHCP future panel members:
Ralph Droms, Kester Fong, Pratik Gupta, Barr Hibbs, Kim Kinnear, Ralph Droms, Kester Fong, Pratik Gupta, Barr Hibbs, Kim Kinnear,
Ted Lemon, Nathan Lane, and Glenn Waters. The author would also Ted Lemon, Nathan Lane, and Glenn Waters. The author would also
skipping to change at line 683 skipping to change at line 694
Sun Microsystems, Inc. Sun Microsystems, Inc.
One Network Drive One Network Drive
Burlington, MA 01803 Burlington, MA 01803
Phone: (781) 442-0469 Phone: (781) 442-0469
Fax: (781) 442-1677 Fax: (781) 442-1677
Email: Michael.Carney@sun.com Email: Michael.Carney@sun.com
11. Expiration 11. Expiration
This document will expire on December 31, 1999. This document will expire on March 31, 2000.
 End of changes. 

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