draft-ietf-dhc-option-review-and-namespace-01.txt   draft-ietf-dhc-option-review-and-namespace-02.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 October 1999 Category: Standards Track March 2000
New Option Review Guidelines and Additional Option Namespace New Option Review Guidelines and Additional Option Namespace
<draft-ietf-dhc-option-review-and-namespace-01.txt> <draft-ietf-dhc-option-review-and-namespace-02.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 43 skipping to change at line 43
This document outlines deficiencies that have become evident since This document outlines deficiencies that have become evident since
RFC 2131 and RFC 2132 were published regarding the allocation of RFC 2131 and RFC 2132 were published regarding the allocation of
new option codes, the review of drafts covering these new option new option codes, the review of drafts covering these new option
codes, and the availability of option codes for new parameters. The codes, and the availability of option codes for new parameters. The
document then presents proposals for correcting these deficiencies. document then presents proposals for correcting these deficiencies.
1. Introduction 1. Introduction
The rapid and wide-spread adoption of DHCPv4 has lead to an The rapid and wide-spread adoption of DHCPv4 has lead to an
increasing number of new DHCP option drafts under DHC WG review. increasing number of new DHCP option and message type drafts under
Experience with the current IANA option code allocation process and DHC WG review. Experience with the current IANA option code
the DHC WG option draft review process has identified a number of allocation process and the DHC WG draft review process has
deficiencies, namely: identified a number of 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 message types and options. Some message types and options that
the DHCP protocol itself and/or current implementations. Because have been proposed require changes to the DHCP protocol itself
the adoption of such options has a greater impact on the DHCP and/or current implementations. Because the adoption of such
community than other, simple "payload" options, these options message types or options has a greater impact on the DHCP
require more scrutiny by the DHC WG and IESG. community, these message types and options require more
scrutiny by the DHC WG and IESG.
* Because some options could change the DHCP protocol itself, we * Because some options or message types could change the DHCP
need a method of explicitly communicating the change of DHCP protocol itself, we need a method of explicitly communicating
versions among implementations. Today, we have no such method. the change of DHCP 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
of the protocol should be implemented. Improvement (tightening) of the protocol should be implemented. Improvement (tightening)
of the general RFC 2131 and RFC 2132 drafts as well as the of the general RFC 2131 and RFC 2132 drafts as well as the
skipping to change at line 97 skipping to change at line 99
documented in RFC 2131 [1]. This option documented in RFC 2131 [1]. This option
form is identified by the BOOTP magic form is identified by the BOOTP magic
cookie {99, 130, 83, 99}. cookie {99, 130, 83, 99}.
RFC TBD-form options A new option block form recommendation RFC TBD-form options A new option block form recommendation
to alleviate option code exhaustion to alleviate option code exhaustion
(described in section 3.6 below). This (described in section 3.6 below). This
option form will be identified by a TBD option form will be identified by a TBD
BOOTP magic cookie issued by IANA. BOOTP magic cookie issued by IANA.
2. Option Review Guidelines 2. Review Guidelines
We tackle the option code review problem by defining a set of We tackle the message type and option code review problem by
option categories based upon upon the impact the adoption of an defining a set of categories based upon upon the impact the
option will have on the DHCP community. Option drafts appropriately adoption of an option or new message type will have on the DHCP
categorized aid reviewers by helping them evaluate the draft. Once community. Option or new message drafts appropriately categorized
the DHC WG and the draft author(s) agree on the category of the aid reviewers by helping them evaluate the draft. Once the DHC WG
proposed option, that category will be listed explicitly in the and the draft author(s) agree on the category of the proposed
abstract of the option draft. option or message type, that category will be listed explicitly
in the abstract of the option or message draft.
2.1. Hints for selecting the correct review category
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
Is this option better handled by the Service Location protocol. 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 message type has no relationship to other existing or
options. It would not require change of existing DHCP proposed message types. It would not require change of
client, server, or BOOTP relay agent implementations. It existing DHCP client, server, or BOOTP relay agent
would not change the version of the DHCP protocol. Its implementations. It would not change the version of the DHCP
introduction would not invalidate previous version(s) of the protocol. The message type is useful to the DHCP community at
DHCP protocol. It isn't a candidate for SLP. Is this option large.
useful to the DHCP community at large (e.g. implementors) or
is it specific to a particular implementation? If it is the
latter, then the proposer of the option should consider using
the encapsulated vendor space available to your
implementation to encode this information. Note that most
DHCP implementations only support default option types for
encapsulated options. (see Section 3.5 below).
C) This option has no relationship to other existing or proposed C) This option has no relationship to other existing or
options. It would not require change of existing DHCP proposed options or message types. It would not require
client, server, or BOOTP relay agent implementations. It change of existing DHCP client, server, or BOOTP relay
would not change the version of the DHCP protocol. Its agent implementations. It would not change the version of the
introduction would not invalidate previous version(s) of the DHCP protocol. Its introduction would not invalidate previous
DHCP protocol. It is not a candidate for SLP or the vendor's version(s) of the DHCP protocol. It isn't a candidate for SLP.
option space. Can this option be effectively encoded in the Is this option useful to the DHCP community at large (e.g.
default option type (Section 3.5 below)? For example, can it implementors) or is it specific to a particular
be communicated as a single ASCII string? A list of IP implementation? If it is the latter, then the proposer of
addresses? If so, then one of the default formats should be the option should consider using the encapsulated vendor space
used. available to your implementation to encode this information.
Note that most DHCP implementations only support default
option types for encapsulated options. (see Section 3.6 below).
D) This option would have a implicit or explicit relationship D) This option has no relationship to other existing or
proposed options or message types. It would not require change
of existing DHCP client, server, or BOOTP relay agent
implementations. It would not change the version of the DHCP
protocol. Its introduction would not invalidate previous
version(s) of the DHCP protocol. It is not a candidate for
SLP or the vendor's option space. Can this option be
effectively encoded in the default option type (Section 3.6
below)? For example, can it be communicated as a single
ASCII string? A list of IP addresses? If so, then one of the
default formats should be used.
E) This option would have a implicit or explicit relationship
between it and other existing options or other proposed between it and other existing options or other proposed
options, or the data it represents cannot be carried in a options, or the data it represents cannot be carried in a
default option type (Section 3.5 below). It MAY change the default option type (Section 3.6 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
------ --------------- ------ ---------------
Vendor Class Identifier Encapsulated vendor option(s) Vendor Class Identifier Encapsulated vendor option(s)
User Class Identifier Standard option's scope User Class Identifier Standard option's scope
E) The addition of this option would change Table 3, "Fields and F) This message type would have a implicit or explicit
relationship between it and other existing message types or
options Its adoption MAY change the behavior of existing DHCP
client, server, and/or BOOTP relay agent implementations. It
would not change the DHCP protocol version. Its introduction
would not invalidate previous version(s) of the DHCP protocol.
G) 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 H) The addition of this option or message type would invalidate
versions of the DHCP protocol, preventing client, server, previous versions of the DHCP protocol, preventing client,
and/or BOOTP relay agents implementing the earlier version(s) server, and/or BOOTP relay agents implementing the earlier
from functioning. version(s) from functioning.
Guidelines Option Category Guidelines Review Category
---------- --------------- ---------- ---------------
A None. Use SLP to register and A None. Use SLP to register and
deliver your information. deliver your information.
B None. Use your Vendor-specific B Category One
C None. Use your Vendor-specific
option space for your option. option space for your option.
C Category One D Category One
D Category Two E Category Two
E Category Three F Category Two
F Category Four G Category Three
2.2. Category One Options H Category Four
2.2. Category One
Options in this category MUST NOT require changes to the DHCP Options in this category MUST NOT require changes to the DHCP
protocol, server, client, or BOOTP relay agent implementations. protocol, server, client, or BOOTP relay agent implementations.
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).
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 in this category MUST NOT require changes to the DHCP Options in this category MUST NOT require changes to the DHCP
protocol. They MAY require changes to server, client, relay agent protocol. They MAY require changes to server, client, relay agent
implementations, administrative tools, and DHCP protocol debugging implementations, administrative tools, and DHCP protocol debugging
tools. They MAY depend on the presence or absence of other options, tools. They MAY depend on the presence or absence of other options,
as long as those other options are NOT in Table 3 or Table 5 of as long as those other options are NOT in Table 3 or Table 5 of
RFC 2131 [1]. Any dependence on other options MUST be made RFC 2131 [1]. Any dependence on other options MUST be made
explicit in the new options draft. Existing versions / explicit in the new options draft. Existing versions /
implementations of the protocol continue to interoperate in the implementations of the protocol continue to interoperate in the
presence of messages containing category two options. Options of presence of messages containing category two options. Options of
skipping to change at line 236 skipping to change at line 258
specify a compliant implementation's behavior if that implement- specify a compliant implementation's behavior if that implement-
ation receives a reply/response from a non-compliant implementation. ation receives a reply/response from a non-compliant implementation.
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) Yes. Interoperability testing (2 or more implementations) Yes.
DHCP protocol version change: No. DHCP protocol version change: No.
2.4. Category Three Options 2.4. Category Three
Options in this category EXPLICITLY change the DHCP protocol. They Options in this category EXPLICITLY change the DHCP protocol. They
WILL require changes to server, client, and/or relay agent WILL require changes to server, client, and/or relay agent
implementations. They MAY depend on the presence or absence of implementations. They MAY depend on the presence or absence of
other options. Any dependence on other options MUST be made other options. Any dependence on other options MUST be made
explicit in the new option draft. The addition of such options explicit in the new option draft. The addition of such options
result in changes to Table 3, "Fields and options used by DHCP result in changes to Table 3, "Fields and options used by DHCP
servers" and/or Table 5, "Fields and options used by DHCP clients" servers" and/or Table 5, "Fields and options used by DHCP clients"
in RFC 2131 [1]. Existing versions / implementations of the in RFC 2131 [1]. Existing versions / implementations of the
protocol continue to interoperate in the presence of traffic protocol continue to interoperate in the presence of traffic
skipping to change at line 271 skipping to change at line 293
detect a non-compliant implementation due to the absence of the detect a non-compliant implementation due to the absence of the
DHCP version option or a lower than expected version number. DHCP version option or a lower than expected version number.
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) Yes. Interoperability testing (2 or more implementations) Yes.
DHCP protocol version change: Yes. DHCP protocol version change: Yes.
2.5. Category Four Options 2.5. Category Four
Options in this category would EXPLICITLY change the DHCP Options in this category would EXPLICITLY change the DHCP
protocol in a non-backward compatible manner. They would require protocol in a non-backward compatible manner. They would require
changes to ALL DHCP client, server, and/or BOOTP relay agent changes to ALL DHCP client, server, and/or BOOTP relay agent
implementations. They INVALIDATE one or more of the previous implementations. They INVALIDATE one or more of the previous
versions of the BOOTP/DHCP protocol. versions of the BOOTP/DHCP protocol.
Because category four options invalidate previous versions of the Because category four options invalidate previous versions of the
protocol, they are NOT candidates for acceptance. Changes to the protocol, they are NOT candidates for acceptance. Changes to the
the DHCP protocol MUST BE backward compatible. the DHCP protocol MUST BE backward compatible.
3. Specification of DHCP protocol version and DHCP option block form. 3. New RFC 2132-form options for version, block-type, and parameter
request list.
We define two RFC 2132-form options. The first is used by a DHCP We define three new RFC 2132-form options. The first is used by
client to request a response in a certain option block form. The a DHCP client to request a response in a certain option block form.
second option is used by both DHCP clients and servers to The second option is used by both DHCP clients and servers to
identify the version of protocol used in the messages generated. explicitly identify the version of protocol used in the messages
generated. The final option is used by RFC TBD client
implementations to request RFC TBD options from RFC TBD servers.
3.1. DHCP Option Block Request Option 3.1. DHCP Option Block Request Option
This option is used by RFC TBD client implementations to request This option is used by RFC TBD client implementations to request
RFC TBD-form replies from RFC TBD server implementations. This RFC TBD-form replies from RFC TBD server implementations. This
option is included in RFC 2132-form DHCPDISCOVERs, INIT-REBOOT option is included in RFC 2132-form DHCPDISCOVERs, INIT-REBOOT
DHCPREQUESTs, and DHCPINFORMs to request RFC TBD-form replies. DHCPREQUESTs, and DHCPINFORMs to request RFC TBD-form replies.
This option MUST NEVER be used by DHCP servers in their responses This option MUST NOT be used by DHCP servers in their responses
to DHCP clients. to DHCP clients.
The DHCP Option Block Request Option is of the RFC 2132-form, and The DHCP Option Block Request Option is of the RFC 2132-form, and
consists of a single 4 octet string holding the magic cookie of consists of a single 4 octet string holding the magic cookie of
the desired option block form. the desired option block form.
code len magic cookie Code Len Magic cookie
+---+---+----------------+ +-----+-----+----------------+
| X | 4 | ... | | X | 4 | ... |
+---+---+----------------+ +-----+-----+----------------+
3.2. DHCP Version Option 3.2. DHCP Version Option
This option represents the DHCP version. DHCP messages without This option represents the DHCP version. DHCP messages without
this option are RFC 2131 [1]. The addition of Category Three this option are RFC 2131 [1]. The addition of Category Three
option(s) (perhaps grouped together) result in a DHCP version option(s) (perhaps grouped together) result in a DHCP version
change. All implementations supporting versions greater than RFC change. All implementations supporting versions greater than RFC
2131 MUST include the DHCP version option in all messages, 2131 MUST include the DHCP version option in all messages,
generated by both client or server. generated by both client or server.
The DHCP Protocol Version Option is of the RFC 2132-form, and The DHCP Protocol Version Option is of the RFC 2132-form, and
consists of an single unsigned 16bit integer. The first Category consists of an single unsigned 16bit integer. The first Category
Three option accepted by the DHC WG will be assigned version zero Three option accepted by the DHC WG will be assigned version zero
(0). (0).
code len value Code Len Value
+---+---+---------+ +-----+-----+---------+
| Y | 2 |(0-65535)| | Y | 2 |(0-65535)|
+---+---+---------+ +-----+-----+---------+
DHCP protocol versions MUST be backward compatible with earlier DHCP protocol versions MUST be backward compatible with earlier
versions. versions.
3.3 Allocation of options from RFC 2132 or RFC TBD option name spaces 3.3. RFC TBD Parameter Request List Option
This option is used by a RFC TBD DHCP client to request values for
the specified configuration parameters. The list of requested
parameters is specified as a power of 2n octets, where each 16 bit
field carries an unsigned 16bit number from 1-65534 representing
valid DHCP option codes defined in RFC 2132 [2] and in separate
option specification drafts. Note that at most 128 options can be
requested.
The client MAY list the options in order of preference. The DHCP
server is not required to return the options in the requested
order.
The RFC TBD parameter request list option is intended for use by
RFC TBD DHCP clients and servers ONLY. While a RFC TBD client
could include use either (or both) parameter request list options
(RFC 2132 code 55 or this option), such a client SHOULD make
request its parameters using only the RFC TBD parameter request
list option.
Code Len Option Codes
+-----+-----+-----+-----+-----+-----+---
| Z | 2n | s1 | s2 | ...
+-----+-----+-----+-----+-----+-----+---
3.4 Allocation of options from RFC 2132 or RFC TBD option name spaces
Allocation of new options from the RFC TBD name space can only Allocation of new options from the RFC TBD name space can only
occur if we have two (2) or more RFC TBD option name space occur if we have two (2) or more RFC TBD option name space
implementations which have demonstrated interoperability. Such implementations which have demonstrated interoperability. Such
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.5. 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 RFC 2132 [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)
are the only codes that do not follow the code, len, value form. are the only codes that do not follow the code, len, value form.
Len is a single octet (0-255) describing the length of the value Len is a single octet (0-255) describing the length of the value
field. Value contains the data payload. field. Value contains the data payload.
3.5. RFC 2132-form Default Option Types 3.6. RFC 2132-form Default Option Types
1) Single variable-length ASCII string. 1) Single variable-length ASCII string.
2) Single variable-length OCTET string. 2) Single variable-length OCTET string.
3) 1-X Multiple of NUMBERs (1, 2, 4, 8 octets each). May consist of 3) 1-X Multiple of NUMBERs (1, 2, 4, 8 octets each). May consist of
a LIST where the list entries are defined as multiple NUMBERs. a LIST where the list entries are defined as multiple NUMBERs.
Example: "A variable-length list of 2 32bit NUMBERs Example: "A variable-length list of 2 32bit NUMBERs
representing the offset and length of a representing the offset and length of a
skipping to change at line 384 skipping to change at line 438
Example: "A list of static routes (destination, router), ..." Example: "A list of static routes (destination, router), ..."
If an implementation encounters RFC 2132-form options which it does If an implementation encounters RFC 2132-form options which it does
not understand, it will simply skip over the option (using that not understand, it will simply skip over the option (using that
option's len field) and continue option processing. This behavior option's len field) and continue option processing. This behavior
ensures that RFC 2131 compliant implementations safely ignore new ensures that RFC 2131 compliant implementations safely ignore new
options (e.g. the DHCP version option). Current DHCP options (e.g. the DHCP version option). Current DHCP
implementations SHOULD ignore any non-RFC 2132-form option block. implementations SHOULD ignore any non-RFC 2132-form option block.
3.6. Proposed RFC TBD Option Block Form 3.7. Proposed RFC TBD Option Block Form
We propose the creation of the following option block form We propose the creation of the following option block form
described below, which greatly increases the option space and size described below, which greatly increases the option space and size
of individual options. We feel that the adoption of this option of individual options. We feel that the adoption of this option
block form will resolve the approaching RFC 2132 standard option block form will resolve the approaching RFC 2132 standard option
code availability problem. code availability problem.
Code Len Data Code Len Data
+---------+---------+------------------ +---------+---------+------------------
| uint16_t| uint16_t| ... | uint16_t| uint16_t| ...
+---------+---------+------------------ +---------+---------+------------------
Code value is a network-order double-octet unsigned value (0- Code value is a network-order double-octet unsigned value (0-
65535). 0 (pad) and 65535 (end) are the only codes that do not 65535). 0 (pad) and 65535 (end) are the only codes that do not
follow the code, len, value form. Len is a network-order follow the code, len, value form. Len is a network-order
double-octet unsigned value (0-65535). Data contains Len octets. double-octet unsigned value (0-65535). Data contains Len octets.
The first 255 RFC TBD option codes are preassigned for mapping The first 255 RFC TBD option codes are preassigned for mapping
RFC 2132 options into RFC TBD option space. Because the size limit RFC 2132 options into the RFC TBD option space. Because the size
of options within the RFC TBD option space is much higher than limit of options within the RFC TBD option space is much higher
that of options within the RFC 2132 option space, RFC TBD than that of options within the RFC 2132 option space, RFC TBD
implementations MUST use care in responding to RFC 2132 clients. If server implementations MUST use care in responding to RFC 2132
the data for a mapped RFC 2132 option would exceed the 253 length clients. If the data for a mapped RFC 2132 option would exceed the
restriction of RFC 2132 clients, the RFC TBD implementation MUST 253 length restriction of RFC 2132 clients, the RFC TBD
drop the option from the reply, and SHOULD increment an error count implementation MUST drop the option from the reply, and SHOULD
or log a message regarding this event. Note that the creation of increment an error count or log a message regarding this event.
multiple instances of RFC 2132 options in order to provide all of Note that the creation of multiple instances of RFC 2132 options
the data within the configured RFC TBD option is not workable, since in order to provide all of the data within the configured RFC TBD
by definition options within the RFC 2132 (and RFC TBD) option space option is not workable, since by definition options within the
are position-independent, and thus deterministic ordering of data RFC 2132 (and RFC TBD) option space are position-independent, and
is not possible. thus deterministic ordering of data is not possible.
3.7. RFC TBD Default Option Types 3.8. RFC TBD Default Option Types
All option types as listed in Section 3.5, and: All option types as listed in Section 3.6, and:
1) UNICODE string. 1) UNICODE string.
2) IPv6 addresses(s). Multiple of 16 octets. Encoded within an 2) IPv6 addresses(s). Multiple of 16 octets. Encoded within an
implementation's configuration table using the text implementation's configuration table using the text
representation as defined by Section 2.2 of RFC 2373 [6]. representation as defined by Section 2.2 of RFC 2373 [6].
3) Encapsulated RFC TBD options. For example, New User class, 3) Encapsulated RFC TBD options. For example, New User class,
Vendor class-style options. Encapsulated options follow same Vendor class-style options. Encapsulated options follow same
code, len, value form of RFC TBD options. Overall length code, len, value form of RFC TBD options. Overall length
specifies limit of encapsulation. specifies limit of encapsulation.
4) Mixed-type options. These options are made up of combinations 4) Mixed-type options. These options are made up of combinations
of 3.5/3.7 typed fields. Variable-length typed fields are of 3.6/3.8 typed fields. Variable-length typed fields are
preceded by a two octet unsigned integer length field. Mixed preceded by a two octet unsigned integer length field. Mixed
type options are useful for encoding combinations of data type options are useful for encoding combinations of data
(structures). (structures).
Example: The following option contains an NVT ASCII string Example: The following option contains an NVT ASCII string
followed by a boolean, followed by a 32bit unsigned integer. followed by a boolean, followed by a 32bit unsigned integer.
Code Len Data Code Len Data
+-------+-------+-------+-------------+---+---------------+ +-------+-------+-------+-------------+---+---------------+
| 771 | 17 | 13 |Hello, World!| 1 | 4123782 | | 771 | 17 | 13 |Hello, World!| 1 | 4123782 |
+-------+-------+-------+-------------+---+---------------+ +-------+-------+-------+-------------+---+---------------+
skipping to change at line 488 skipping to change at line 542
A RFC TBD-form client in one of these states forms the appropriate A RFC TBD-form client in one of these states forms the appropriate
RFC 2132-form message (DHCPDISCOVER, DHCPINFORM) and includes the RFC 2132-form message (DHCPDISCOVER, DHCPINFORM) and includes the
DHCP Option Block Request Option (set to the RFC TBD magic cookie) DHCP Option Block Request Option (set to the RFC TBD magic cookie)
and the DHCP version option if it supports a version greater than and the DHCP version option if it supports a version greater than
that specified in RFC 2131, and sends this message in the manner that specified in RFC 2131, and sends this message in the manner
appropriate for the message type. A RFC TBD-form client appropriate for the message type. A RFC TBD-form client
prefers RFC TBD-form responses over RFC 2132-form responses. Within prefers RFC TBD-form responses over RFC 2132-form responses. Within
responses of a certain option form, responses which match the responses of a certain option form, responses which match the
client's DHCP protocol version are preferred over those responses client's DHCP protocol version are preferred over those responses
that are down-rev. If no DHCP responses are received, the client that are down-rev. If no DHCP responses are received, the client
MAY choose a BOOTP response if such a response is available. MAY choose a BOOTP response if such a response is available. A RFC
TBD-form client MAY use the RFC TBD parameter request option to
request options in the RFC TBD option space (section 3.3).
In the case of an INIT state client, the DHCPREQUEST used to accept In the case of an INIT state client, the DHCPREQUEST used to accept
the DHCPOFFER is formed using the option block form and DHCP the DHCPOFFER is formed using the option block form and DHCP
protocol version of the selected DHCPOFFER. protocol version of the selected DHCPOFFER.
For the duration of the lease, the client MUST form request messages For the duration of the lease, the client MUST form request messages
using the option block form and DHCP protocol version of the using the option block form and DHCP protocol version of the
original DHCPACK (INIT/INFORM) states when verifying existing original DHCPACK (INIT/INFORM) states when verifying existing
configuration (INIT-REBOOT DHCPREQUEST), requesting lease configuration (INIT-REBOOT DHCPREQUEST), requesting lease
extensions (DHCPREQUEST), declining an IP address (DHCPDECLINE), extensions (DHCPREQUEST), declining an IP address (DHCPDECLINE),
skipping to change at line 552 skipping to change at line 608
4.2.2 RFC TBD-form Server Behavior 4.2.2 RFC TBD-form Server Behavior
A RFC TBD-form server can identify a RFC TBD-form client by the A RFC TBD-form server can identify a RFC TBD-form client by the
presence of the DHCP Option Block Request Option with the RFC TBD presence of the DHCP Option Block Request Option with the RFC TBD
magic cookie in the option value field in RFC 2132-form requests magic cookie in the option value field in RFC 2132-form requests
or RFC TBD-form requests identified by the RFC TBD-form magic or RFC TBD-form requests identified by the RFC TBD-form magic
cookie. For the following scenarios, assume a RFC TBD-form server cookie. For the following scenarios, assume a RFC TBD-form server
has free resources available for allocation. has free resources available for allocation.
a) If a RFC TBD-form response is requested, it MUST respond with a) If a RFC TBD-form response is requested, it MUST respond with
a RFC TBD-form response if it chooses to respond at all. a RFC TBD-form response if it chooses to respond at all. The
server SHOULD endeavor to provide the information requested
in any present RFC 2132 code 55 (parameter request list
option) and/or RFC TBD parameter request list option (Section
3.3).
b) If a RFC 2132-form response is requested (no DHCP Option Block b) If a RFC 2132-form response is requested (no DHCP Option Block
Request Option is present) and the RFC TBD-form server is Request Option is present) and the RFC TBD-form server is
explicitly configured to respond to RFC 2132-form clients, it explicitly configured to respond to RFC 2132-form clients, it
MUST respond with a RFC 2132-form response if it chooses to MUST respond with a RFC 2132-form response if it chooses to
respond at all. respond at all.
c) If a request is received which contains a DHCP Option Block c) If a request is received which contains a DHCP Option Block
Request Option with a value it does not recognize, the server Request Option with a value it does not recognize, the server
MUST either drop the request or respond with a RFC 2132-form MUST either drop the request or respond with a RFC 2132-form
response. Its behavior in this situation SHOULD be an response. Its behavior in this situation SHOULD be an
administrator-configured option. administrator-configured option.
A DHCP server MUST NOT use the DHCP Option Block Request Option in A DHCP server MUST NOT use the DHCP Option Block Request Option in
the messages it generates for DHCP clients. the messages it generates for DHCP clients.
5. Open Issues 5. Security Considerations
The author would appreciate comments/feedback regarding these issues.
* Parameter request option in RFC 2132-form requests.
A RFC 2132-form DISCOVER/REQUEST can only request options from
the RFC 2132 name space. One possible solution is for a
RFC TBD-form implementation to generate a RFC TBD-form DISCOVER
or REQUEST containing the full parameter request list if it
receives RFC TBD-form replies. The downside of this approach is
the extra DHCP traffic. I propose that RFC TBD-form implementors
include a policy mechanism which turns on pure RFC TBD-form and
thus disables the RFC 2132-form request method. Such behavior
might be controlled by a RFC 2132-form option, for example.
* RFC TBD-form requests look like BOOTP requests with an
unrecognized magic cookie. Disabling BOOTP compatibility in
RFC 2132 servers and turning it on in RFC TBD servers (which
can appropriately recognize the clients) seems like a reasonable
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
Not Applicable. Not Applicable.
7. Acknowledgements 6. 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
like to thank Thomas Narten for his review comments. like to thank Thomas Narten for his review comments.
8. Copyright 7. Copyright
Copyright (C) The Internet Society (1999). 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 or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, 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
skipping to change at line 651 skipping to change at line 669
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 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN 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.
9. References 8. References
[1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131,
Bucknell University, March 1997. Bucknell University, March 1997.
<ftp://ds.internic.net/rfc/rfc2131.txt> <ftp://ds.internic.net/rfc/rfc2131.txt>
[2] Alexander, S. and Droms, R., "DHCP Options and BOOTP [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP
Vendor Extension", RFC 2132, March 1997. Vendor Extension", RFC 2132, March 1997.
<ftp://ds.internic.net/rfc/rfc2132.txt> <ftp://ds.internic.net/rfc/rfc2132.txt>
[3] Prindeville, P. "BOOTP Vendor Information Extensions", RFC 1048, [3] Prindeville, P. "BOOTP Vendor Information Extensions", RFC 1048,
McGill University, February 1988. McGill University, February 1988.
<ftp://ds.internic.net/rfc/rfc1048.txt> <ftp://ds.internic.net/rfc/rfc1048.txt>
skipping to change at line 681 skipping to change at line 698
<ftp://ds.internic.net/rfc/rfc2119.txt> <ftp://ds.internic.net/rfc/rfc2119.txt>
[6] Hinden R. and Deering, S., "IP Version 6 Addressing [6] Hinden R. and Deering, S., "IP Version 6 Addressing
Architecture", RFC 2373, Nokia and Cisco Systems, July 1998. Architecture", RFC 2373, Nokia and Cisco Systems, July 1998.
<ftp://ds.internic.net/rfc/rfc2373.txt> <ftp://ds.internic.net/rfc/rfc2373.txt>
[7] Guttman E., Perkins C., Veizades J., and Day M., "Service [7] Guttman E., Perkins C., Veizades J., and Day M., "Service
Location Protocol, Version 2", April 1999. Location Protocol, Version 2", April 1999.
<ftp://www.ietf.org/internet-drafts/draft-ietf-svrloc-protocol-v2-16.txt> <ftp://www.ietf.org/internet-drafts/draft-ietf-svrloc-protocol-v2-16.txt>
10. Author's Address 9. Author's Address
Michael Carney Michael Carney
Sun Microsystems, Inc. Sun Microsystems, Inc.
One Network Drive 901 San Antonio Road
Burlington, MA 01803 Palo Alto, CA 94303-4900
Phone: (781) 442-0469 Phone: (650) 786-4171
Fax: (781) 442-1677 Fax: (650) 786-5896
Email: Michael.Carney@sun.com Email: Michael.Carney@sun.com
11. Expiration 10. Expiration
This document will expire on September 30, 2000.
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/