summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3942.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3942.txt')
-rw-r--r--doc/rfc/rfc3942.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc3942.txt b/doc/rfc/rfc3942.txt
new file mode 100644
index 0000000..0676a49
--- /dev/null
+++ b/doc/rfc/rfc3942.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group B. Volz
+Request for Comments: 3942 Cisco Systems, Inc.
+Updates: 2132 November 2004
+Category: Standards Track
+
+
+ Reclassifying Dynamic Host Configuration Protocol
+ version 4 (DHCPv4) Options
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This document updates RFC 2132 to reclassify Dynamic Host
+ Configuration Protocol version 4 (DHCPv4) option codes 128 to 223
+ (decimal) as publicly defined options to be managed by IANA in
+ accordance with RFC 2939. This document directs IANA to make these
+ option codes available for assignment as publicly defined DHCP
+ options for future options.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
+ 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 3.1. Publicly Defined Options Range . . . . . . . . . . . . . 2
+ 3.2. Site-Specific Options Range . . . . . . . . . . . . . . 3
+ 4. Reclassifying Options . . . . . . . . . . . . . . . . . . . . 3
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
+ 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 5
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 6
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 7
+
+
+
+
+
+Volz Standards Track [Page 1]
+
+RFC 3942 Reclassifying DHCPv4 Options November 2004
+
+
+1. Introduction
+
+ The DHCPv4 [RFC2131] publicly defined options range, options 1 - 127,
+ is nearly used up. Efforts such as [RFC3679] help extend the life of
+ this space, but ultimately the space will be exhausted.
+
+ This document reclassifies much of the site-specific option range,
+ which has not been widely used for its original intended purpose, to
+ extend the publicly defined options space.
+
+2. Requirements Notation
+
+ 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 [RFC2119].
+
+3. Background
+
+ The DHCP option space (0 - 255) is divided into two ranges [RFC2132]:
+
+ 1. 1 - 127 are publicly defined options, now allocated in accordance
+ with [RFC2939].
+
+ 2. 128 - 254 are site-specific options.
+
+ Options 0 (pad) and 255 (end) are special and defined in [RFC2131].
+
+3.1. Publicly Defined Options Range
+
+ The publicly defined options space (1 - 127) is nearly exhausted.
+ Recent work [RFC3679] will buy more time, as several allocated but
+ unused option codes have been reclaimed. A review could be made from
+ time to time to determine whether there are other option codes that
+ can be reclaimed.
+
+ A longer-term solution to the eventual exhaustion of the publicly
+ defined options space is desired. The DHC WG evaluated several
+ solutions:
+
+ 1. Using options 126 and 127 to carry 16-bit options as originally
+ proposed by Ralph Droms in late 1996. However, this significantly
+ penalizes the first option assigned to this new space, as it
+ requires implementing the 16-bit option support. Because of this,
+ options 126 and 127 have been reclaimed [RFC3679].
+
+ 2. Using a new magic cookie and 16-bit option code format. However,
+ this proposal
+
+
+
+
+Volz Standards Track [Page 2]
+
+RFC 3942 Reclassifying DHCPv4 Options November 2004
+
+
+ * penalizes the first option assigned to this new space, as it
+ requires significant changes to clients, servers, and relay
+ agents,
+
+ * could adversely impact existing clients, servers, and relay
+ agents that fail to properly check the magic cookie value,
+
+ * requires support of both message formats for the foreseeable
+ future, and
+
+ * requires clients to send multiple DHCPDISCOVER messages -- one
+ for each magic cookie.
+
+ 3. Reclassifying a portion of the site-specific option codes as
+ publicly defined. The impact is minimal, as only those sites
+ presently using options in the reclassified range need to renumber
+ their options.
+
+3.2. Site-Specific Options Range
+
+ The site-specific option range is rather large (127 options in all)
+ and little used. The original intent of the site-specific option
+ range was to support local (to a site) configuration options, and it
+ is difficult to believe a site would need 127 options for this
+ purpose. Further, many DHCP client implementations do not provide a
+ well documented means to request site-specific options from a server
+ or to allow applications to extract the returned option values.
+
+ Some vendors have made use of site-specific option codes that violate
+ the intent of the site-specific options, as the options are used to
+ configure features of their products and thus are specific to many
+ sites. This usage could potentially cause problems if a site that
+ has been using the same site-specific option codes for other purposes
+ deploys products from one of the vendors, or if two vendors pick the
+ same site-specific options.
+
+4. Reclassifying Options
+
+ The site-specific option codes 128 to 223 are hereby reclassified as
+ publicly defined options. This leaves 31 site-specific options, 224
+ to 254.
+
+ To allow vendors that have made use of site-specific options within
+ the reclassified range to publish their option usage and to request
+ an official assignment of the option number to that usage, the
+ following procedure will be used to reclassify these options:
+
+
+
+
+
+Volz Standards Track [Page 3]
+
+RFC 3942 Reclassifying DHCPv4 Options November 2004
+
+
+ 1. The reclassified options (128 to 223) will be placed in the
+ "Unavailable" state by IANA. These options are not yet available
+ for assignment to publicly defined options.
+
+ 2. Vendors that currently use one or more of the reclassified options
+ have 6 months following this RFC's publication date to notify the
+ DHC WG and IANA that they are using particular options numbers and
+ agree to document that usage in an RFC. IANA will move these
+ options from the "Unavailable" to "Tentatively Assigned" state.
+
+ Vendors have 18 months from this RFC's publication date to start
+ the documentation process by submitting an Internet-Draft.
+
+ NOTE: If multiple vendors of an option number come forward and can
+ demonstrate that their usage is in reasonably wide use, none of
+ the vendors will be allowed to keep the current option number, and
+ they MUST go through the normal process of getting a publicly
+ assigned option [RFC2939].
+
+ 3. Any options still classified as "Unavailable" 6 months after the
+ RFC publication date will be moved to the "Unassigned" state by
+ IANA. These options may then be assigned to any new publicly
+ defined options in accordance with [RFC2939].
+
+ 4. For those options in the "Tentatively Assigned" state, vendors
+ have 18 months following this RFC's publication date to submit an
+ Internet-Draft documenting the option. The documented usage MUST
+ be consistent with the existing usage. When the option usage is
+ published as an RFC, IANA will move the option to the "Assigned"
+ state.
+
+ If no Internet-Draft is published within the 18 months or should
+ one of these Internet-Drafts expire after the 18 months, IANA will
+ move the option to the "Unassigned" state, and the option may then
+ be assigned to any new publicly defined options in accordance with
+ [RFC2939].
+
+ Sites presently using site-specific option codes within the
+ reclassified range SHOULD take steps to renumber these options to
+ values within the remaining range. If a site needs more than 31
+ site-specific options, the site must switch to using suboptions, as
+ has been done for other options, such as the Relay Agent Information
+ Option [RFC3046].
+
+5. Security Considerations
+
+ This document in and by itself provides no security, nor does it
+ impact existing DCHP security as described in [RFC2131].
+
+
+
+Volz Standards Track [Page 4]
+
+RFC 3942 Reclassifying DHCPv4 Options November 2004
+
+
+6. IANA Considerations
+
+ IANA is requested to
+
+ 1. expand the publicly defined DHCPv4 options space from 1 - 127 to 1
+ - 223. The new options (128 - 223) are to be listed as
+ "Unavailable" and MUST NOT be assigned to any publicly defined
+ options.
+
+ 2. receive notices from vendors that have been using one or more of
+ the options in the 128-223 range that they are using the option
+ and are willing to document that usage. IANA will list these
+ options as "Tentatively Assigned".
+
+ 3. change the listing of any options listed as "Unavailable" to
+ "Available" 6 months from this RFC's publication date. These
+ options may now be assigned in accordance with [RFC2939].
+
+ 4. change the listing of any options listed as "Tentatively-Assigned"
+ to "Unavailable" 18 months from this RFC's publication date and
+ periodically thereafter as long as there is an option listed as
+ "Tentatively-Assigned", if no un-expired Internet-Draft exists
+ documenting the usage.
+
+7. Acknowledgements
+
+ Many thanks to Ralph Droms and Ted Lemon for their valuable input and
+ earlier work on the various alternatives.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
+ 2131, March 1997.
+
+ [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+ Extensions", RFC 2132, March 1997.
+
+ [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
+ of New DHCP Options and Message Types", BCP 43, RFC 2939,
+ September 2000.
+
+
+
+
+
+
+Volz Standards Track [Page 5]
+
+RFC 3942 Reclassifying DHCPv4 Options November 2004
+
+
+8.2. Informative References
+
+ [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
+ 3046, January 2001.
+
+ [RFC3679] Droms, R., "Unused Dynamic Host Configuration Protocol
+ (DHCP) Option Codes", RFC 3679, January 2004.
+
+Author's Address
+
+ Bernard Volz
+ Cisco Systems, Inc.
+ 1414 Massachusetts Ave.
+ Boxborough, MA 01719
+ USA
+
+ Phone: +1 978 936 0382
+ EMail: volz@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Volz Standards Track [Page 6]
+
+RFC 3942 Reclassifying DHCPv4 Options November 2004
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the IETF's procedures with respect to rights in IETF Documents can
+ be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Volz Standards Track [Page 7]
+