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


. 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).


. 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.


. 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 | ...
   +-----+-----+-----+-----+-----+-----+----


. 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


. 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


. 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]