[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00
Internet Engineering Task Force B. Volz
INTERNET DRAFT Ericsson
Expires: August 2003 R. Droms
Cisco
T. Lemon
Nominum
February 2003
Extending DHCP Options Codes
draft-volz-dhc-extended-optioncodes-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.
This Internet-Draft will expire on August 1, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
RFC 2132 defines the DHCP for IPv4 options 1 to 127 as the DHCP
public option space which is managed by IANA as documented in RFC
2939. As this public option space has few unassigned options at this
time, it is prudent to define a mechanism to extend this option space
before it is too late. This Internet-Draft proposes two means to
extend this option space.
Volz, et al. Expires 1 Aug 2003 [Page 1]
Internet Draft Extending DHCP Options Codes 23 February, 2003
1. Introduction
RFC 2132 defines the DHCP public option space as options 1 to 127
(decimal). This option space has a limited number of unassigned
option numbers at the present time. Work is in progress
[unused-optioncodes] to recover options that were assigned before
RFC 2489 (since updated by 2939) was published and never formally
documented. Approximately 20 unused option codes should be available
after the recovery initiative is completed.
However, even with this effort, the current public space is likely
to be exhausted over the expected lifetime of DHCPv4 and so some
actions are needed to plan for this before it is too late.
This document proposes two means to extend this option space:
1. Use already allocated options 126 and 127 as previously proposed
by Ralph Droms.
2. Use option numbers from the site-specific option space as defined
by RFC 2132 (options 128 to 254).
2. Requirements
The requirements for any proposal to extend the public options space
should include:
o The mechanism must interoperate with existing clients and servers.
Existing clients should be able to continue operating with servers
that implement the mechanism, and vice versa.
o The mechanism must interoperate with existing relay agents. Relay
agents must not need to be updated in order for clients and servers
to use the mechanism.
o The mechanism must not create an undue burden to DHCP client and
server implementations for the first few options that need to make
use of this option space.
o The mechanism must not negatively impact existing DHCP uses.
o The mechanism must not negatively impact existing
standards-compliant uses of DHCP.
3. Use of 16-bit Options
The first proposal, originally submitted in late 1996 by Ralph
Droms proposed the use of two "extension options" and requested
IANA to reserve options 126 and 127 for this purpose. As this
Volz, et al. Expires 1 Aug 2003 [Page 2]
Internet Draft Extending DHCP Options Codes 23 February, 2003
pre-dated RFC 2489 procedures, these option codes were assigned
without formal review and are now being considered to be returned
to the available list [unused-optioncodes].
3.1 Definition of option 127
Option code 127 indicates that the DHCP option has a two-octet
extended option code. The format of these options is:
Extended
Code Len option code Data...
+-----+-----+-----+-----+-----+-----+----
| 127 | XXX | oh | ol | d1 | d2 | ...
+-----+-----+-----+-----+-----+-----+----
3.2 Definition of option 126
This option is used by a DHCP client to request values for specified
configuration paramaters that are identified by extended option codes
as defined above. The list of n requested parameters is specified as
2n octets, where each pair of octets is a valid extended option code.
The client MAY list the options in order of preference. The DHCP
server is not required to return the options in the requested order,
but MUST try to insert the requested options in the order requested
by the client.
The code for this option is 126. Its minimum length is 2.
Extended
Code Len option codes
+-----+-----+-----+-----+-----+-----+----
| 126 | XXX | c1h | c1l | c2h | c2l | ...
+-----+-----+-----+-----+-----+-----+----
4. Using Site-Specific Options
The site-specific option range is rather large (127 options in all)
and has, in general, been little used. Ideally, DHCP options in wide
use should be in the public option space rather than in the
site-specific space (since these options are not site specific).
The use of option codes in the site-specific option code range
(128-254 decimal) for other purposes such as vendor defined
options that have not been part of the IETF standards
process is not compliant with the DHCP Internet Standard as
described in RFC2132.
Volz, et al. Expires 1 Aug 2003 [Page 3]
Internet Draft Extending DHCP Options Codes 23 February, 2003
This proposal is to reclassify site specific options 128 to 223
as public options, leaving options 224 to 254 as site specific
options.
As proper use of site-specific options likely requires very few
actual options, this proposal provides 31 site-specific options.
4.1 Impact To Existing Site-Specific Options
There are known to be uses of option codes that are not
standards-compliant and there are likely sites legitimately using
option codes in the range being proposed for reclassification. These
sites and users will be impacted by this action when IANA begins to
assign the options numbers to new uses.
Users would be encouraged to move to alternative site-specific option
numbers (224 to 254), switch to using the vendor-specific option, or
document the existing usage and request a public option number using
the process described in RFC 2939 (IANA should be requested to
allocate the existing site-specific option number if in the
reclassified public option space and still available).
IANA would be requested to assign the reclassified options only after
the original public option space (1 to 127) has been exhausted. And,
further IANA should assign options from this reclassified range
starting at the lowest value (128).
This should give a reasonable amount of time for corrective action to
be taken.
If there are existing uses of these options and some of the systems
can not be updated, there is a potential for confusion at some point.
4.2. Resultant IANA Recommendations
IANA is requested to increase the DHCP public option space from 1 to
127 to 1 to 223. IANA is requested not to assign any options from the
new space (128 to 223) until such time as all options from 1 to 127
have been assigned. At such time, IANA is further requested to assign
options starting at 128 on up.
IANA should allow an exception to the above when an existing usage of
a site-specific option in the 128 to 223 range is approved (per RFC
2939) and the approved usage is consistent with the existing usage,
IANA should assign the existing site-specific option number if
available.
Volz, et al. Expires 1 Aug 2003 [Page 4]
Internet Draft Extending DHCP Options Codes 23 February, 2003
5. Analysis of the Two Proposals
5.1 Use of 16-bit Options
This proposal allows for a very large number of DHCP options and with
the definition of the procedure for encoding large options [RFC3396],
the data in Option 127 would not be restricted to 255 octets.
The proposal meets all of the requirements listed in section 2 with
one exception, "the mechanism must not create an undue burden to DHCP
client and server implements for the first few options that need to
make use of this option space." The first option using this proposal
will require implementing two other options (in addition to the
desired option) - option 127 and 126 as defined by the proposal - and
also the encoding large options [RFC3396] if not already implemented.
The encoding of large options is needed to allow option 127 to carry
multiple 16-bit options and allow these options (either singly or in
aggregate) to exceed 255 bytes.
5.2 Using Site-Specific Options
This proposal adds 96 additional DHCP options to the public options
space, which is about 75% of the original space. The original space
has lasted 10+ years (based on the publication of RFC 1531) and is
not yet exhausted. This original space also included many options
inherited from BOOTP and to support the basic DHCP protocol. Thus,
96 additional option codes should last for a long time.
The proposal meets all of the requirements listed in section 2 with
one exception, "The mechanism must not negatively impact existing
DHCP uses." As stated in section 4.1, existing uses of site-specific
options in the reclassified range are impacted and these uses must
be moved to the newly proposed site-specific option range, to a
vendor specific option, or documented and to a public option.
However, there are believed to be few sites that make heavy use of
site-specific options and they would have many years to redeploy.
5.3 Recommendations
TBD
6. Security Considerations
This document in and by itself provides no security, nor does it
impact existing security.
Volz, et al. Expires 1 Aug 2003 [Page 5]
Internet Draft Extending DHCP Options Codes 23 February, 2003
References
[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.
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options",
RFC 3396, November 2002.
[unused-optioncodes] Droms, "Unused DHCP Option Codes", Work in
Progress.
Author's Address
Ralph Droms
Cisco Systems
300 Apollo Drive
Chelmsford, MA 01824
Phone: +1 978.497.4733
EMail: rdroms@cisco.com
Ted Lemon
Nominum, Inc.
950 Charter Street
Redwood City, CA 94043
USA
E-mail: Ted.Lemon@nominum.com
Bernie Volz
Ericsson
959 Concord Street
Framingham, MA 01701
Phone: +1 508 875 3162
EMail: bernie.volz@ericsson.com
Volz, et al. Expires 1 Aug 2003 [Page 6]
Internet Draft Extending DHCP Options Codes 23 February, 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Volz, et al. Expires 1 Aug 2003 [Page 7]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/