[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]
Versions: 00
2000-07-14 13:33 New Option Review Carney Page 1
Network Working Group Michael Carney
Dynamic Host Configuration Working Group Sun Microsystems, Inc
Category: Standards Track July 2000
INTERNET-DRAFT Expires: January 2001
New Option Review Guidelines for DHCP
<draft-ietf-dhc-new-opt-review-00.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Comments regarding this draft should be sent to dhcp-v4@bucknell.edu
Abstract
This document outlines deficiencies that have become evident since
RFC 2131 and RFC 2132 were published regarding the allocation of
new option codes, the review of drafts covering these new option
codes, and the availability of option codes for new parameters. The
document then presents proposals for correcting these deficiencies.
1. Introduction
The rapid and wide-spread adoption of DHCP for IPv4 has lead to an
increasing number of new DHCP option and message type drafts under
DHC WG review. Experience with the current IANA option code
allocation process and the DHC WG draft review process has
identified a number of deficiencies, namely:
* We're rapidly going through the remaining option codes, and face
the possibility of exhausting the remaining codes before the
wide-spread adoption of IPv6 is achieved.
2000-07-14 13:33 New Option Review Carney Page 2
* There are no guidelines to help the DHC WG and the DHCP
community at large gauge the impact of the addition of new
message types and options. Some message types and options that
have been proposed require changes to the DHCP protocol itself
and/or current implementations. Because the adoption of such
message types or options has a greater impact on the DHCP
community, these message types and options require more
scrutiny by the DHC WG and IESG.
* Because some options or message types could change the DHCP
protocol itself, we need a method of explicitly communicating
the change of DHCP versions among implementations. Today, we
have no such method.
* There is no provision to preserve compatibility with earlier
versions of the protocol.
Inter-operability testing at Connectathon (1997-2000) has shown a
reduction in the level of interoperability between
implementations. These interoperability problems were found to
be due to confusion among implementors about how certain features
of the protocol should be implemented. Improvement (tightening)
of the general RFC 2131 and RFC 2132 drafts as well as the
tightening of new option drafts (using the guidelines defined in
this document) will help prevent these interoperability problems
from occurring as new implementations appear.
The specification of a RFC 2132-form option to carry the DHCP
protocol version and a proposal for a new, larger option namespace
is discussed in a companion document, "A New Option Namespace for
DHCP" [8].
1.1 Conventions Used in the Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5].
2. Review Guidelines
We tackle the message type and option code review problem by
defining a set of categories based upon the impact the adoption
of an option or new message type will have on the DHCP community.
Option or new message drafts appropriately categorized aid
reviewers by helping them evaluate the draft. Once the DHC WG
and the draft author(s) agree on the category of the proposed
option or message type, that category will be listed explicitly
in the abstract of the option or message draft.
2000-07-14 13:33 New Option Review Carney Page 3
2.1. Hints for selecting the correct review category
Read the following hints and select the one which best describes
your option or message type, then proceed to Table 1 at the end of
this section for the suggested option review category. If, after
reading the following hints, you cannot find one that fits your
option or message type, read each of the category sections (2.2-2.5)
carefully. If you still are not sure which category your option
or message type belongs in, you can ask the DHC WG (if it still
exists) or the IESG for help in selecting the right category.
A) This option has no relationship to other existing or proposed
options. 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. The proposed option provides data which is
non-implementation specific and unrelated to network
configuration.
B) This message type has no relationship to other existing or
proposed 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. The message type is useful to the DHCP community at
large.
C) 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 [8]. The information it carries
is network or system configuration related, but only for a
particular implementation or set of implementations from the
same vendor.
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 [8]. It carries network or
system configuration data with is of general usefulness.
E) This option would have a implicit or explicit relationship
between it and other existing options or other proposed
options. It 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 [8].
2000-07-14 13:33 New Option Review Carney Page 4
Examples of implicit/explicit option relationships:
Option Related Options
------ ---------------
Vendor Class Identifier Encapsulated vendor option(s)
User Class Identifier Standard option's scope
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 [8].
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 clients" in RFC 2131 [1], and thus
change the DHCP protocol. Pre-existing versions /
implementations would continue to interoperate.
H) The addition of this option or message type would invalidate
previous versions of the DHCP protocol [8], preventing client,
server, and/or BOOTP relay agents implementing the earlier
version(s) from functioning.
Table 1: Linking Hints to Review Category
Guidelines Review Category
---------- ---------------
A None. Use SLP or an other alternative to
to register and deliver your information.
B Category One
C None. Use your Vendor-specific
option space for your option.
D Category One
E Category Two
F Category Two
G Category Three
H Category Four
2000-07-14 13:33 New Option Review Carney Page 5
2.2. Category One
Options in this category MUST NOT require changes to the DHCP
protocol, server, client, or BOOTP relay agent implementations.
They MUST NOT be dependent on other options being present or
absent. Earlier versions/implementations of the protocol continue
to interoperate in the presence of these options. Administrative
tools and DHCP protocol debugging tools which generically support
the default option types MAY need to be reconfigured in order to
permit management of the new option. Options of this type are
"payload" options, and MUST be of one of the default option types
for the option block form (RFC 2132 or RFC TBD_NS [8]).
Acceptance criteria:
Working group/IETF community review: Yes.
IANA option number registration: Yes.
Inter-operability testing (2 or more implementations) No.
DHCP protocol version change [8]: No.
2.3. Category Two
Options in this category MUST NOT require changes to the DHCP
protocol. They MAY require changes to server, client, relay agent
implementations, administrative tools, and DHCP protocol debugging
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
RFC 2131 [1]. Any dependence on other options MUST be made
explicit in the new options draft. Existing versions /
implementations of the protocol continue to interoperate in the
presence of messages containing category two options. Options of
this type are "affect implementation" options.
An option MUST be designed in such a way as a reply/response from
non-compliant implementations can be easily distinguished from
those of compliant implementations. An option MUST NEVER change the
interpretation of existing options. The option draft author MUST
specify a compliant implementation's behavior if that implement-
ation receives a reply/response from a non-compliant implementation.
Acceptance criteria:
Working group/IETF community review: Yes.
IANA option number registration: Yes.
Inter-operability testing (2 or more implementations) Yes.
DHCP protocol version change [8]: No.
2000-07-14 13:33 New Option Review Carney Page 6
2.4. Category Three
Options in this category EXPLICITLY change the DHCP protocol. They
WILL require changes to server, client, and/or relay agent
implementations. They MAY depend on the presence or absence of
other options. Any dependence on other options MUST be made
explicit in the new option draft. The addition of such options
result in changes to Table 3, "Fields and options used by DHCP
servers" and/or Table 5, "Fields and options used by DHCP clients"
in RFC 2131 [1]. Existing versions / implementations of the
protocol continue to interoperate in the presence of traffic
containing category three options. Administrative tools MUST be
changed to support options of this type. DHCP protocol debugging
tools would need to be updated to recognize these options. Options
of this type are known as "affect protocol" options. The acceptance
of a Category Three option results in incrementing the DHCP version
option value (see a companion document, "A New Option Namespace
for DHCP" for details on the DHCP version option [8].
An option MUST be designed in such a way as a reply/response from
non-compliant implementations can be easily distinguished from
those of compliant implementations. The option draft author MUST
specify a compliant implementation's behavior if that implement-
ation receives a reply/response from a non-compliant
implementation. An option MUST NEVER change the interpretation of
existing options. Category Three option implementations can easily
detect a non-compliant implementation due to the absence of the
DHCP version option or a lower than expected version number [8].
Acceptance criteria:
Working group/IETF community review: Yes.
IANA option number registration: Yes.
Inter-operability testing (2 or more implementations) Yes.
DHCP protocol version change [8]: Yes.
2.5. Category Four
Options in this category would EXPLICITLY change the DHCP
protocol in a non-backward compatible manner. They would require
changes to ALL DHCP client, server, and/or BOOTP relay agent
implementations. They INVALIDATE one or more of the previous
versions of the BOOTP/DHCP protocol.
Because category four options invalidate previous versions of the
protocol, they are NOT candidates for acceptance. Changes to the
the DHCP protocol MUST BE backward compatible.
Acceptance criteria:
Working group/IETF community review: N/A.
IANA option number registration: N/A.
Inter-operability testing (2 or more implementations) N/A.
DHCP protocol version change [8]: N/A.
2000-07-14 13:33 New Option Review Carney Page 7
3. Security Considerations
Not Applicable.
4. Acknowledgements
The author would like to gratefully acknowledge the active
participation of the following DHCP future panel members:
Ralph Droms, Kester Fong, Pratik Gupta, Barr Hibbs, Kim Kinnear,
Ted Lemon, Nathan Lane, and Glenn Waters. The author would also
like to thank Thomas Narten and Bernie Volz for their review
comments.
5. Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
6. References
[1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131,
Bucknell University, March 1997.
<ftp://ds.internic.net/rfc/rfc2131.txt>
[2] Alexander, S. and Droms, R., "DHCP Options and BOOTP
Vendor Extension", RFC 2132, March 1997.
<ftp://ds.internic.net/rfc/rfc2132.txt>
2000-07-14 13:33 New Option Review Carney Page 8
[3] Prindeville, P. "BOOTP Vendor Information Extensions", RFC 1048,
McGill University, February 1988.
<ftp://ds.internic.net/rfc/rfc1048.txt>
[4] Droms, R. "Procedure for Defining New DHCP Options",
INTERNET-DRAFT, August 1998
<ftp://www.ietf.org/internet-drafts/draft-ietf-dhc-new-options-02.txt>
[5] Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, Harvard University, March 1997.
<ftp://ds.internic.net/rfc/rfc2119.txt>
[6] Hinden R. and Deering, S., "IP Version 6 Addressing
Architecture", RFC 2373, Nokia and Cisco Systems, July 1998.
<ftp://ds.internic.net/rfc/rfc2373.txt>
[7] Guttman E., Perkins C., Veizades J., and Day M., "Service
Location Protocol, Version 2", April 1999.
<ftp://www.ietf.org/internet-drafts/draft-ietf-svrloc-protocol-v2-16.txt>
[8] Carney, M., "A New Option Namespace for DHCP", RFC TBD_NS,
July 2000. <ftp://ds.internic.net/rfc/rfcTBD_NS>
7. Author's Address
Michael Carney
Sun Microsystems, Inc.
901 San Antonio Road
Palo Alto, CA 94303-4900
Phone: (650) 786-4171
Fax: (650) 786-5896
Email: Michael.Carney@sun.com
8. Expiration
This document will expire on January 31, 2001.
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/