[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-volz-dhc-extended-optioncodes) 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/