Internet Engineering Task Force B. Volz
INTERNET DRAFT Ericsson
Expires: August 2003 R. Droms
Cisco
T. Lemon
Nominum
May 2003
Extending DHCP Options Codes
draft-ietf-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 November 7, 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 several means to
extend this option space.
Volz, et al. Expires 7 Nov 2003 [Page 1]
Internet Draft Extending DHCP Options Codes May 7, 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 and currently pending
options are assigned codes.
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 four 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).
3. Reclaim publicly assigned DHCP option numbers that are not in
active use.
4. Use 16-bit options and a new magic cookie to identify use of the
16-bit option format.
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.
Volz, et al. Expires 7 Nov 2003 [Page 2]
Internet Draft Extending DHCP Options Codes May 7, 2003
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 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 parameters 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 7 Nov 2003 [Page 3]
Internet Draft Extending DHCP Options Codes May 7, 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 leaves 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.
5. Reclaiming Unused Options
There are some DHCP options specified in [RFC2132] or since assigned
by IANA that are believed not to be in use today and these could be
reclaimed and made available for reassignment to future options.
Volz, et al. Expires 7 Nov 2003 [Page 4]
Internet Draft Extending DHCP Options Codes May 7, 2003
Research would be needed to create a list of these options and
solicit feedback from the IETF community to confirm if these options
are not in active use.
This is already being done for options assigned by IANA but never
officially documented [unused-optioncodes].
6. New Magic Cookie with 16-bit Options
This proposal would use a new magic cookie (the current is defined
in [RFC1497]) for DHCP messages and messages using this new cookie
would use 16-bit options (16-bit option code and length fields).
The existing 8-bit options would use the first 256 codes in the new
16-bit option space.
This proposal would require clients, servers, and relays agents to
support both 8-bit and 16-bit option formats for a time. The first
option to use the 16-bit options would require significant
implementation work in client, server, and relay agent code to add
the required support.
This proposal would require a client to send the new magic cookie
formatted message and if no server responded, try the old magic
cookie formatted messages. A client might send both simultaneously to
speed up the process, at the expends of increased broadcast traffic.
7. Analysis of the Proposals
7.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.
7.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
Volz, et al. Expires 7 Nov 2003 [Page 5]
Internet Draft Extending DHCP Options Codes May 7, 2003
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.
7.3 Reclaiming Options
This proposal would likely result in few options being reclaimed.
Therefore, while nothing precludes doing this in parallel with one of
the other proposals, the benefit is believed to be fairly minor. And,
there is a risk that a reused option might conflict with an earlier
use of the option in some client, server, relay agent, or other
implementations and result in unexpected problems or at best
confusion.
Note that this is somewhat different than the work being done to
reclaim undocumented options ([unused-optioncodes]), as these options
were not officially adopted and documented by the IETF.
7.4 New Magic Cookie with 16-bit Options
This proposal requires client, servers, and relay agents to likely
support both the current DHCP message format with 8-bit options as
well as the new 16-bit options. It would require clients to send
both types of messages, perhaps favoring the new format and if no
response is received causing the client to send the old format.
It is not known how existing clients, servers, and relay agents
would behave if they received messages with the new magic cookie
values. Presumably, the messages would be dropped. In the worst
case, it could cause significant failures (though in these cases
it could be argued that these devices should be promptly corrected
as this presents an easy denial of service attack).
This proposal fails to interoperate with existing clients, servers,
and relays. It also impacts other devices that monitor DHCP traffic
(such as packet sniffers).
This proposal creates an undue burden for the first few options that
need to make use of the 16-bit option space.
Volz, et al. Expires 7 Nov 2003 [Page 6]
Internet Draft Extending DHCP Options Codes May 7, 2003
This proposal also impacts networks for a long time as clients and
servers may need to send messages with both the new and old magic
cookie values.
7.5 Recommendations
TBD
8. Security Considerations
This document in and by itself provides no security, nor does it
impact existing security.
References
[RFC1497] Reynolds, J., "BOOTP Vendor Information Extensions", RFC
1497, USC/Information Sciences Institute, August 1993.
[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
Volz, et al. Expires 7 Nov 2003 [Page 7]
Internet Draft Extending DHCP Options Codes May 7, 2003
Bernie Volz
Ericsson
959 Concord Street
Framingham, MA 01701
Phone: +1 508 875 3162
EMail: bernie.volz@ericsson.com
Volz, et al. Expires 7 Nov 2003 [Page 8]
Internet Draft Extending DHCP Options Codes May 7, 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 7 Nov 2003 [Page 9]
