Dynamic Host Configuration Working                            D. Hankins
Group                                                             Google
Internet-Draft                                           October 1, 2011                                              T. Mrugalski
Intended status: Informational                              M. Siodelski
Expires: April 3, December 21, 2012                                           ISC
                                                                S. Jiang
                                            Huawei Technologies Co., Ltd
                                                             S. Krishnan
                                                           June 19, 2012

               Guidelines for Creating New DHCP DHCPv6 Options


   This document seeks to provide provides guidance to prospective DHCP DHCPv6 Option
   developers to help them in producing creating option formats that are easily
   adoptable by existing DHCPv6 software.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on April 3, December 21, 2012.

Copyright Notice

   Copyright (c) 2011 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  When to Use DHCP . DHCPv6 . . . . . . . . . . . . . . . . . . . . . .  3
   3.  4
   4.  General Principles . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Reusing Other Options  . . . . . . . . . . . . . . . . . . . .  5
   5.  Avoid Conditional Formatting
     5.1.  Option with IPv6 addresses . . . . . . . . . . . . . . . .  5
     5.2.  Option with 32-bit integer value . .  7
   6.  Avoid Aliasing . . . . . . . . . . .  6
     5.3.  Option with 16-bit integer value . . . . . . . . . . . . .  7
   7.  Considerations for Creating New Formats
     5.4.  Option with 8-bit integer value  . . . . . . . . . . .  8
   8.  The Dangers of Sub Options . .  7
     5.5.  Option with variable length data . . . . . . . . . . . . .  7
     5.6.  Option with DNS Wire Format Domain Name List . . . . . . .  8
   9.  Option Size
   6.  Avoid Conditional Formatting . . . . . . . . . . . . . . . . .  9
   7.  Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Suboptions in DHCPv6 . . . . . . . . . . . . . . . . . . . . . 10
   9.  Additional States Considered Harmful . . . . . . . . . . . . . 11
   10. Clients Request their Options Is DHCPv6 dynamic? . . . . . . . . . . . . . . . . . . . . . . 11
   11. Security Considerations Multiple provisioning domains  . . . . . . . . . . . . . . . . 11
   12. Considerations for Creating New Formats  . . . . . . . . . . . 12
   12. IANA Considerations
   13. Option Size  . . . . . . . . . . . . . . . . . . . . . 13
   13. Informative References . . . . 12
   14. Clients Request their Options  . . . . . . . . . . . . . . . . 13
   Appendix A.  Background on ISC DHCP
   15. Security Considerations  . . . . . . . . . . . . . . . 15
     A.1.  Atomic DHCP . . . . 13
   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . 17
   Author's Address . . 15
   17. References . . . . . . . . . . . . . . . . . . . . . . . 18

1.  Introduction

   Most protocol developers ask themselves if a protocol will work, or
   work efficiently. . . . 15
     17.1. Informative References . . . . . . . . . . . . . . . . . . 15
     17.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Introduction

   Most protocol developers ask themselves if a protocol will work, or
   work efficiently.  These are important questions, but another less
   frequently considered question is whether the proposed protocol
   presents itself needless barriers to adoption by deployed software.

   DHCPv4 [RFC2131] and

   DHCPv6 [RFC3315] software implementors are not merely faced with the
   task of handling a given option's format on the wire.  The option
   must "fit" fit into every stage of the system's process, from starting with the
   user interface where configuration is entered used to enter the configuration upto the machine
   interfaces where configuration is ultimately consumed.  To help understand the
   potential implementation challenges of any new DHCP Option, one
   implementation's approach to tackling DHCP Option formats
   (Appendix A) has been included as an Appendix.

   Another more frequently overlooked aspect of rapid adoption is the
   question: Would whether the
   option would require requires operators to be intimately familiar with the option's
   internal format in order to make use of it?  Most DHCP DHCPv6 software provides a
   facility for "unknown options" handling unknown options at the time of publication publication.
   The handling of such options usually needs to be manually configured
   by hand by an the operator.  But if doing so requires extensive reading (more
   than can be covered in a simple FAQ for example), it inhibits

   So although a given solution would work, and might even be space,
   time, or aesthetically optimal, a given option is presented with a
   series of ever-worsening challenges to be adopted;

   o  If it doesn't fit neatly into existing config files.

   o  If it requries new source code changes to be adopted, and hence
      upgrades of deployed software.

   o  If it does not share its deployment fate in a general manner with
      other options, standing alone in requiring code changes or
      reworking configuration file syntaxes.

   There are many things DHCP DHCPv6 option authors creators can do to form DHCP Options
   to stay off avoid the
   pitfalls in this list entirely, or failing that, to make software
   implementors lives easier and improve its chances for widespread


3.  When to Use DHCP DHCPv6

   Principally, DHCP DHCPv6 carries configuration parameters for its clients.
   Any knob, dial, slider, or checkbox on the client system, such as "my
   domain name servers", "my hostname", or even "my shutdown
   temperature" are candidates for being configured by DHCP. DHCPv6.

   The presence of such a knob isn't enough, because DHCP DHCPv6 also
   presents the extension of an administrative domain - the operator of
   the network to which the client is currently attached.  Someone runs
   not only the local switching network infrastructure that the client
   is directly (or wirelessly) attached to, but the various methods of
   accessing the external Internet via local assist services that
   network must also provide (such as domain name servers, or routers).
   This means that in addition to the existence of a configuration
   parameter, one must also ask themselves if it is reasonable for this
   parameter to be set by the directly attached network's

   Bear in mind

   Note that the client still reserves the right to ignore values
   received via DHCP DHCPv6 (for example, due to having a value manually
   configured by its own operator), and operator).  Bear in mind that at least doing so might
   cause the client to be rejected network attachment privileges, and
   this is one main use case reason for DHCP is the corporate enterprise.  So even if the local Net
   Cafe's operator is not a likely source use of the candidate
   configuration, there may be other DHCP servers DHCPv6 in a client's lifetime
   which are.

3. corporate

4.  General Principles

   The primary guiding principle to follow in order to enhance an
   option's adoptability is certainly simplification.  But more  More specifically, to
   create the
   option should be created in such a way that it should does not require any new
   or special case software to support.  If old software currently
   deployed and in the field can adopt the option through supplied
   conveniences facilities then it's fairly well assured certain that new software
   can easily formally adopt it.

   There are at least two classes of DHCP DHCPv6 options: A bulk class of
   options which are provided explicitly to carry data from one side of
   the DHCP DHCPv6 exchange to the other (such as nameservers, domain names,
   or time servers), and a protocol class of options which require
   special processing on the part of the DHCP DHCPv6 software or are used
   during special processing (such as the FQDN options ([RFC4702], [RFC4704]),
   DHCPv4 message type Fully Qualified Domain Name
   (FQDN) option [RFC2132], link selection options
   ([RFC3011], [RFC3527]), [RFC4704]), and so forth; these options carry data that
   is the result of a routine in some DHCP software). DHCPv6 software.

   The guidelines laid out here should be understood to be applied in a relaxed manner
   for the protocol class of options.  Wherever special-case-code special case code is
   already required to adopt the DHCP DHCPv6 option, it is substantially more
   reasonable to format the option in a less generic fashion, if there
   are measurable benefits to doing so.


5.  Reusing Other Options

   In DHCPv4, there are now nearly one hundred

   The easiest approach to manufacturing trivially deployable DHCPv6
   Options is to assemble the option out of whatever common fragments
   fit - possibly allowing a group of fragments to repeat to fill the
   remaining space (if present) and thirty options, so provide multiple values.  Place
   all fixed size values at
   least as IETF standards, which might the start of the option, and any variable/
   indeterminate sized value at the tail end of the option.

   This estimates that implementations will be used as an example.  There is
   also one handy document [RFC2132] containing many option definitions. able to reuse code paths
   designed to support the other options.

   There is a tradeoff between the adoptability of previously defined
   option formats, and the advantages that new or specialized formats
   can provide.  In the balance, general, it is usually preferrable to reuse
   previously used option formats.

   However, it isn't very practical to consider the bulk of DHCP DHCPv6
   options already allocated, and consider which of those solve a
   similar problem.  So, the following list of common option format
   fragments is provided as a shorthand.  Please note that it is not
   complete in terms of exampling every option format ever devised...it
   is only a list of option format fragments which are used in two or
   more options.

   |      Fragment |  Size | Types of Uses                             |
   |  ipv4-address |

5.1.  Option with IPv6 addresses

   This option format is used to carry one or many IPv6 addresses:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     | Default gateway, requested address,          option-code          |           option-len          |
     |                                                               | subnet mask [RFC2132], addresses of
     |                         ipv6-address                          |
     |                                                               | servers ([RFC2132], [RFC2241], [RFC2242],
     |                                                               |
     |                                                               | [RFC3495], [RFC3634], [RFC4174]), as a
     |                         ipv6-address                          |
     |                                                               | component in a list of routes [RFC3442].
     |                                                               |  ipv6-address
     |    16                              ...                              |

                    Figure 1: Option with IPv6 address

   Examples of use:

   o  DHCPv6 server unicast address [RFC3315],  |
   |               |       | addresses of servers ([RFC3319],          |
   |               |       | [RFC3646], [RFC3898], [RFC4075],          |
   |               |       | [RFC4280]).                               |
   | [RFC3315]

   o  SIP Servers IPv6 Address List [RFC3319]

   o  DNS Recursive Name Server [RFC3646]

   o  NIS Servers [RFC3898]

   o  SNTP Servers [RFC4075]

   o  Broadcast and Multicast Service Controller IPv6 Address Option for
      DHCPv6 [RFC4280]

5.2.  Option with 32-bit |     4 | Signed integer value

   This option format can be used to carry 32 bit-signed or unsigned varieties. Used for    |
   integer value:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |          option-code          | timezone time offset [RFC2132]            |
   |               |       | (deprecated by [RFC4833]). Other uses for |
   |               |       | host configuration values such as path    |
   |               |       | MTU aging timeouts, ARP cache timeouts,   |
   |               |       | TCP keepalive intervals [RFC2132]. Also   |           option-len          |
     |                         32-bit-integer                        |

                Figure 2: Option with 32-bit-integer value

   Examples of use:

   o  Information Refresh Time [RFC4242]

5.3.  Option with 16-bit integer value

   This option format can be used by the DHCPv4 protocol for relative  |
   |               |       | times, and times since epoch.             |
   | to carry 16-bit |     2 | Client configuration parameters, such as  |
   | signed or unsigned
   integer values:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |          option-code          | MTU, maximum datagram reassembly limits,  |
   |               |       | the DHCPv4 maximum message size           |
   |               |       | [RFC2132], or the elapsed time option     |           option-len          |
     |         16-bit-integer        |

                Figure 3: Option with 16-bit integer value

   Examples of use:

   o  Elapsed Time [RFC3315] in DHCPv6.                      |

5.4.  Option with 8-bit integer | value

   This option format can be used to carry 8-bit integer values:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     | Used for host configuration parameters,   |
   |               |       | such as the default IP TTL, default TCP   |
   |               |       | TTL, NetBIOS node type [RFC2132]. Also    |
   |               |       | used for protocol features, such as the          option-code          |          option-len           |
     | 8-bit-integer | DHCPv4

                 Figure 4: Option Overload (as flags), DHCP   |
   |               |       | Message Type (as an enumeration) or       |
   |               |       | with 8-bit integer value

   Examples of use:

   o  DHCPv6 Preference [RFC3315].              |
   |     NVT-ASCII | unlim | This [RFC3315]

5.5.  Option with variable length data

   This option can be used to carry variable length data of any kind.
   Internal representation of carried data is the kitchen sink option specific.  Some of common        |
   |          Text |       | fragments. Common uses are for filenames  |
   |               |       | (such as TFTP paths),
   the existing DHCPv6 options use NVT-ASCII strings to encode:
   filenames, host or domain      |
   |               |       | names (but this should be discouraged),   |
   |               |       | or names, protocol features such as or textual      |
   |               |       |
   messages such as verbose error            |
   |               |       | indicators. Since the size of this

   This option format |
   |               |       | cannot be determined (it is not NULL      |
   |               |       | terminated), it consumes provides a lot of flexibility to pass data of
   almost any remaining    |
   |               | kind.  Though, whenever possible it is highly recommended
   to use more specialized options, with field types better matching
   carried data types.
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     | space in the option.          option-code          |         option-len            |
     .                                                               .
     .                      variable length data                     .
     .                                                               .

                 Figure 5: Option with variale length data

   Examples of use:

   o  Client Identifier [RFC3315]

   o  Server Identifier [RFC3315]

   o  Boot File URL [RFC5970]

5.6.  Option with DNS Wire | unlim | Presently used for 'domain search' lists  |
   | Format Domain |       | in both DHCPv4 [RFC3397] and DHCPv6       |
   | Name List |       | [RFC3646], but also

   This option is used in DHCPv6 for    |
   |     [RFC1035] |       | to carry 'domain search' lists or any host or
   domain name. A field          |
   |               |       | formatted this way may have a determinate name:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |          option-code          |         option-length         |
     | length if the number of root labels is    |               DNS Wire Format Domain Name List                |
     |                              ...                              | limited, but use

          Figure 6: Option with DNS Wire Format Domain Name List

   Examples of this format as being  |
   |               |       | use:

   o  SIP Servers Domain Name List [RFC3319]

   o  NIS Domain Name [RFC3898]

6.  Avoid Conditional Formatting

   Placing a determinate length should be            |
   |               |       | discouraged in DHCPv4, less so in DHCPv6. |
   |   'suboption' | unlim | The Relay Agent Information Option        |
   | encapsulation |       | [RFC3046], vendor options [RFC2132],      |
   |               |       | Vendor Identified Vendor SubOptions       |
   |               |       | ([RFC3925], [RFC3315]). Commonly used for |
   |               |       | situations where octet at the full format cannot   |
   |               |       | be known initially, such as where there   |
   |               |       | seems to be some room for later protocol  |
   |               |       | work start of the option which informs the software
   how to expand process the amount remaining octets of information  |
   |               |       | carried, or where the full extent of data |
   |               |       | carried is defined option may appear simple
   to the casual observer.  But the only conditional formatting methods
   that are in a private           |
   |               |       | specification (such as with vendor        |
   |               |       | options). Encapsulations do not widespread use 'PAD' |
   |               |       | today are 'protocol' class options.  So
   conditional formatting requires new code to be written, as well as
   introduces an implementation problem; as it requires that all
   speakers implement all current and 'END' options future conditional formats.

   Conditional formatting is not recommended, except in DHCPv4, cases where the
   DHCPv6 option has already been deployed experimentally, and there    |
   |               |       | are no such options in DHCPv6, so this    |
   |               |       | format also is of indeterminate length.   |

                     Table 1: Common Option Fragments

   The easiest approach to manufacturing trivially deployable DHCP
   Options is to assemble the option out of whatever common fragments
   fit - possibly allowing a group of fragments to repeat to fill the
   remaining space (if present) and so provide multiple values.  Place
   all fixed size values at the start of the option, and any variable/
   indeterminate sized value at the tail end of the option.

   This estimates that implementations will be able to reuse code paths
   designed to support the other options.

5.  Avoid Conditional Formatting

   Placing a octet at the start of the option which informs the software
   how to process the remaining octets of the option may appear simple
   to the casual observer.  But the only conditional formatting methods
   that are in widespread use today are 'protocol' class options.  So
   conditional formatting requires new code to be written, as well as
   introduces an implementation problem; as it requires that all
   speakers implement all current and future conditional formats.

   Conditional formatting is absolutely not recommended, except in cases
   where the DHCP option has already been deployed experimentally, and
   all but one conditional all but
   one conditional format is deprecated.


7.  Avoid Aliasing

   Options are said to be aliases of each other if they provide input to
   the same configuration parameter.  A commonly proposed example is to
   configure the location of some new service ("my foo server") using a
   binary IP address, a domain name field, and a URL.  This kind of
   aliasing is undesirable, and is best avoided. not recommended.

   In this case, where three different formats are supposed, it more
   than triples the work of the software involved, requiring support for
   not merely one format, but support to produce and digest all three.
   Furthermore, code development and testing must cover all possible
   combinations of defined formats.  Since clients cannot predict what
   values the server will provide, they must request all formats...so formats... so
   in the case where the server is configured with all formats, DHCP DHCPv6
   option space is wasted on option contents that are redundant.

   It also becomes unclear which types of values are mandatory, and how
   configuring some of the options may influence the others.  For
   example, if an operator configures the URL only, should the server
   synthesize a domain name and IP address?

   A single configuration value on a host is probably presented to the
   operator (or other software on the machine) in a single field or
   channel.  If that channel has a natural format, then any alternative
   formats merely make more work for intervening software in providing

   So the best advice is to choose the one method that best fulfills the
   requirements, be that for simplicity (such as with an IP address and
   port pair), late binding (such as with DNS), or completeness (such as
   with a URL).

   On the specific subject of desiring to configure a value using a
   Fully Qualified Domain Name FQDN
   instead of a binary IP address, note that most DHCP DHCPv6 server
   implementations will happily accept a Domain Name entered by the
   administrator, and use DNS resolution to render binary IP addresses
   in DHCP DHCPv6 replies to clients.  Consequently, consider the extra
   packet overhead incurred on the client's end to perform DNS
   resolution itself.  The client may be operating on a battery and
   packet transmission is a non-trivial use of power, and the extra RTT
   delays the client must endure before the service is configured are at
   least two factors to consider in making a decision on format.

7.  Considerations for Creating New Formats

   If the option simply will not fit into any existing work by using
   fragments, the last recourse is to create

8.  Suboptions in DHCPv6

   Most options are conveyed in a new format to fit.

   When doing so, it is not enough to gauge whether or not the option
   format will work in the context of the option presently being
   considered.  It DHCPv6 message directly.  Although
   there is equally important no codified normative language for such options, they are
   often referred to consider if the new format's
   fragments might reasonably have any as top-level options.  Many options may include
   other uses, and if so, options.  Such inner options are often referred to create
   the option with the foreknowledge that its parts may later become a
   common fragment.

   One specific consideration as sub-
   options.  It should be noted that, contrary to evaluate DHCPv4, there is whether or not options no
   shortage of option numbers.  Therefore all options share a
   similar format would need to have multiple or single values encoded
   (whatever differs from the current option), and how that might be
   accomplished common
   option space.  For example option type 1 meant different things in a similar format.

8.  The Dangers
   DHCPv4, depending if it was located in top-level or inside of Sub Options

   Some DHCP options, such as the DHCPv4 Relay
   Agent Information Option
   [RFC3046] are defined option.  There is no such ambiguity in DHCPv6.

   Such encapsulation mechanism is not limited to one level.  There is
   at least one defined option that is encapsulated twice: Identity
   Association for Prefix Delegation (IA_PD, defined in [RFC3633],
   section 9) conveys IA Prefix (IAPREFIX, defined in [RFC3633], section
   10).  Such delegated prefix may contain a series of DHCP options, possibly
   using code tags specific to an excluded prefix range that
   is represented by PD_EXCLUDE option (but not in some limited
   "protocol feature" cases that is conveyed as sub-option
   inside IAPREFIX (PD_EXCLUDE, defined in DHCPv6 [RFC3315]).  These are commonly
   referred [RFC6603]).  It seems awkward
   to as Encapsulated Option Spaces or more simply, Sub

   Sub refer to such options seem very attractive, because they allow the encoding as sub-sub-option, therefore "sub-option"
   term is typically used, regardless of
   multiple variable length fields within the single "parent" option.

   However, DHCP software will only include these options on an "all or
   nothing" basis, there is no well deployed mechanism nesting level.

   When defining configuration means for "Sub Option
   Parameter Request Lists" (although some defined sub-option spaces,
   such as for DOCSIS, do describe sub-option scoped PRL analogues), and
   the software will not include the entire option if there is not
   sufficient space.

   Consequently, more complex mechanisms, it is not advisable to group options that may not be
   requested at the same time by the same client under an encapsulated

   Another attraction sub options present is ease of extending the
   configuration value for later, related configuration.  This must
   weighed against the cost associated with asking IANA to maintain the
   space's internally assigned option codes.  Generally, the cost tempting to
   IANA is greater, simply use sub-options.  That should usually be
   avoided, as it increases complexity of the parser.  It is unlikely that much
   easier, faster and less error prone to parse larger number of options will be later
   on a single (top-level) scope, than parse options on several scopes.
   The use of sub-options should be avoided as much as possible but it
   is not a solution better to aliasing problems.  Sub-
   options that contain multiple configuration values use sub-options rather than conditional formatting.

   It should be noted that alias the
   same configuration element actually makes matters worse.  The only
   solution to aliasing problems currently there is no clear way defined for
   requesting sub-options.  Most known implementations are simply using
   top-level ORO for requesting both top-level options and sub-options.

9.  Additional States Considered Harmful

   DHCP is to select a single option format, or
   where protocol designed for provisioning nodes.  Less experienced
   protocol designers often assume that it is literally impossible, easy to use multiple DHCP options.  In
   this way, clients may place only the options they support on their define an option
   that will convey a different parameter request list, for each node in the order they support them.  Later
   protocol maintenance may incorporate a means network.
   Such problems arose during designs of MAP
   [I-D.mdt-softwire-map-dhcp-option] and 4rd [I-D.ietf-softwire-4rd].
   While it would be easier for provisioned nodes to select a single DHCP get ready to use
   per node option code out of values, such requirement puts exceedingly large loads
   on the server side.  Alternatives should be considered, if possible.
   As an example, [I-D.mdt-softwire-map-dhcp-option] was designed in a list of aliased options, so do not concern
   yourself with packet space issues arising from receiving
   way that all the

   Additionally, DHCPv4 option concatenation (Section 9) has not been
   defined in any DHCPv4 sub-options space.  Currently there is some
   DHCP software which does concatenate multiple DHCP options present in
   a sub-option space.  There is also software that treats multiple DHCP
   option codes present in a sub-option as individual single options.
   So there is no reliably predictable default behaviour.

   Because no sub-options space has yet been defined that includes the
   possibility of having more than one instance of an option of nodes are provisioned with the same
   code, any attempt to do so is discouraged.

9.  Option Size

   DHCPv4 [RFC2131] options payload space is limited, as there are a
   number set of unaddressed deployment problems with DHCPv4 packet sizes.
   The end result is that you should build your option MAP options
   and each provisioned node uses its unique address and delegated
   prefix to generate node-specific information.  Such solution does not
   introduce any additional state for the assumption
   that the packet will server and therefore scales

   It also should be no larger than 576 octets.  This means noted that
   the options payload space will be 312 octets, contrary to DHCPv4, DHCPv6 keeps several
   timers for renewals.  Each IA_NA (addresses) and IA_PD (prefixes)
   contains T1 and T2 timers that designate time after which you client will have
   initiate renewal.  Those timers apply only to
   share with its own IA containers.
   For renewing other options.  This space can be extended by making parameters, please use
   of Information Refresh Time
   Option Overloading [RFC2132], which allows the use of the BOOTP
   FILE and SNAME header fields (defined in [RFC4242]).  Introducing additional timers make
   deployment unnecessarily complex.  Please try to avoid it.

10.  Is DHCPv6 dynamic?

   DHCPv6 stands for carrying DHCPv4 options (adding 192
   octets), but these header fields will not be available Dynamic Host Configuration Protocol for
   overloading if they have been configured IPv6.
   Contrary to carry a value. its name, is many contexts it is not dynamic.  While
   designing DHCPv6 [RFC3315] options, it is much better off.  First, through worth noting that there is no
   reliable way to instantly notify clients that something has happened,
   e.g. parameter value has changed.  There is a RECONFIGURE mechanism,
   but it has several serious drawbacks that makes its use of link-
   local addresses, it steps aside difficult.
   First, its support is optional and many of client implementations do not
   support it.  To use reconfigure mechanism, server must use its secret
   nonce.  That means that provisioning server is the deployment problems only one that
   plague DHCPv4, can
   initiate reconfiguration.  Other servers do not know it and looks a great deal more like any other UDP based
   application; oblivious to packet sizes up cannot
   trigger reconfiguration.  Therefore the only reliable way for clients
   to 64KB.  Second, RFC 3315
   explicitly refers readers refresh their configuration is to RFC 2460 Section 5, which describes an
   MTU of 1280 octets and wait till T1 expires.

11.  Multiple provisioning domains

   In some cases there could be more than one DHCPv6 server on a minimum fragment reassembly link,
   with each provisioning a different set of 1500 octets.
   It's much parameters.  One notable
   example of such case is a home network with a connection to two
   independent ISPs.

   DHCPv6 was not initially designed with multiple provisioning domains.
   Although [RFC3315] states that a client that receives more feasible than one
   ADVERTISE message, may respond to suggest one or more, such capability was
   never observed in any known implementations.  Existing clients will
   pick one server and will continue configuration process with that DHCPv6
   server, ignoring all other servers.

   This is capable of having
   larger options deployed over it, a generic DHCP protocol issue and at least no common upper limit should not be dealt within
   each option separately.  This issue is yet known to have been encoded better dealt with using a
   protocol-level solution and fixing this problem should not be
   attempted on a per option basis.

12.  Considerations for Creating New Formats

   If the option simply will not fit into any existing work by its implementors.  It using
   fragments, the last recourse is
   impossible to describe any fixed limit that cleanly divides those too
   big from the workable.

   So in either protocol, create a new format to fit.

   When doing so, it is advantageous not enough to prefer option formats
   which contain gauge whether or not the desired information option
   format will work in the smallest form factor
   that solves context of the requirements.  One example option presently being
   considered.  It is equally important to use a 4-octet IPv4
   address rather than a fully qualified domain name, because many DHCP
   servers will perform DNS resolution on configured FQDN's (so the DNS
   recursive lookup is performed anyway).  There may be motivations to
   use the fully qualified domain name anyway, such as consider if the intended
   RRSET is not an address, or new format's
   fragments might reasonably have any other uses, and if the client must refresh the name more
   frequently than common lease renewal periods.

   When it is not possible so, to compress the configuration contents either
   because of create
   the simple size of option with the parameters, or because it is
   expected foreknowledge that very large configurations are valid, it its parts may be
   preferable to use later become a second stage configuration.  Some examples of
   this are
   common fragment.

   One specific consideration to provide TFTP server and pathnames, evaluate is whether or not options of a URL, which the
   client will load and process externally
   similar format would need to the DHCP protocol.

   The DHCPv4 code and length tags are each a have multiple or single octet.  As the
   length field describes the length of the DHCP option's contents (not
   including values encoded
   (whatever differs from the code current option), and length octets), any option whose contents'
   length exceeds 255 octets can not how that might be contained
   accomplished in a single option.
   These 'long options' will simply be fragmented into multiple options
   within the packet.  DHCP software processing these fragments will
   concatenate them, in the order they appear as defined by [RFC2131],
   prior similar format.

13.  Option Size

   DHCPv6 [RFC3315] allows for packet sizes up to evaluating their contents.  This 64KB.  First, through
   its use of link-local addresses, it steps aside many of the
   deployment problems that plague DHCPv4, and is actually an important distinction
   that UDP over
   IPv6 based protocol (compared to DHCPv4, which is sometimes overlooked by authors - these multiple options are
   not individually formatted mostly UDP over
   IPv4 protocol, but with layer 2 hacks).  Second, RFC 3315 explicitly
   refers readers to convey one unit RFC 2460 Section 5, which describes an MTU of information
   precisely as you have defined, but rather one option that has been
   split along any arbitrary octet boundary into multiple containers.

   When documenting an example, then, try to make sure that the division
   point you select as an example does not lie on 1280
   octets and a clean division minimum fragment reassembly of
   your option contents - place it at an offset so as 1500 octets.  It's
   feasible to reinforce suggest that
   these values must be concatenated rather than processed individually.

   DHCPv4 option fragments are a basic protocol feature, so there
   usually DHCPv6 is no reason to mention this feature in new option
   definitions, capable of having larger options
   deployed over it, and at least no requirement for every option definition common upper limit is yet known to be
   presented as a series of fragments.
   have been encoded by its implementors.  It is only recommended impossible to
   reinforce the existence of DHCP option fragmentation when describe
   any fixed limit that cleanly divides those too big from the
   potential for large options workable.

   It is likely.  In this case, try advantageous to choose a
   large example data value.

   Note that prefer option fragmentation is also a very common side-effect of
   running out of options space, and moving to overloaded FILE or SNAME
   fields.  Although formats which contain the option may be considerably shorter than 255
   octets, if it does not fit desired
   information in the remaining space then software may
   consume all remaining options space with one option fragment, and
   place the remainder in an overloaded field.

   Primarily it is important to remember smallest form factor that DHCPv4 differs from DHCPv6
   on this point: DHCPv4 can only convey one option of a given option
   code at any time - additional options (or possibly sub options, which
   do not have concisely defined semantics) of satisfies the same code will be
   concatenated together and processed at once.

   DHCPv6 does allow for multiple instances of a given option, and they
   are treated as distinct values following the defined format, however
   this feature is generally preferred to be restricted to protocol
   class features (such as the IA_* series of options); options).  In such cases,
   it is better to define your an option as an array if it is possible.

   So remember that it  It
   is out of the question recommended to define clarify (with normative language) whether a case for
   multiple instances of your option in DHCPv4, and it is recommended to
   clarify (with normative language) if any given
   DHCPv6 option may appear once or multiple times.


14.  Clients Request their Options

   The DHCPv4 Parameter Request List [RFC2132], and the DHCPv6 Option Request Option (OPTION_ORO) [RFC3315], are both options is an option
   that serve serves two purposes - to inform the server what options the
   client supports and is willing to digest, and in what order of priority the client
   places those option contents (in the event that they will not fit in
   the packet, later options are to be dropped). consume.

   It doesn't make sense for some options to appear on this Parameter Option
   Request List, Option, such as those formed by elements of the protocol's
   internal workings, or are formed on either end by DHCP-level DHCPv6-level
   software engaged in some exchange of information.  When in any form of doubt, it
   is prudent to assume that any new option must be present on the
   relevant option request list if the client desires to receive it.

   It is a frequent mistake of option draft authors, then, to create
   text that implies that a server will simply provide the new option,
   and clients will digest it.  Generally, it's best to also specify
   that clients MUST place the new option code on the relevant list
   option, clients MAY include the new option in their packets to
   servers with hints as to values they desire, and servers MAY respond
   with the option contents (if they have been so configured).

   Under only the most dire

   Creators of circumstances should a new option
   definition DHCPv6 options MUST NOT require special ordering of
   options either in the relevant request option, or in the order of
   options within the packet.  Although the request option does imply a priority, which might it is reasonable to expect that
   options will be processed in order, a server may shuffle options around in a DHCPv4
   packet in the order to make them fit, and they appear in ORO, server
   software may is not required to sort DHCPv6 options into strange orders.  There the same order
   in reply messages.  It should be noted that any requirement regarding
   option ordering will break down most existing implementations, as
   "order is not important" was one universal approach.

11. of the design priciples of DHCPv6
   and many implementations follow it.  For example, there are existing
   implementations that use hash maps for storing options, so forcing
   any particular order is not feasible without great deal of work.  If
   options must be processed in any specific order (e.g. due to inter-
   dependency), use of option encapsulation should be considered.

15.  Security Considerations


   DHCPv6 does have an Authentication mechanism ([RFC3118], [RFC3315],
   [RFC4030]), where ([RFC3315]) that makes
   it is possible for DHCP DHCPv6 software to discriminate between authentic
   endpoints and men in the middle.  Other authentication mechanisms may
   optionally be deployed.  For example, the Secure DHCPv6
   [I-D.ietf-dhc-secure-dhcpv6], based on Cryptographically Generated
   Addresses (CGA) [RFC3972], can provide source address ownership
   validation, message origin authentication and message integrity
   without requiring symmetric key pairs or supporting from any key
   management system.  However, at this date as of now, the mechanism is poorly not widely
   deployed.  It also does not provide end-to-end encryption.

   So, while creating a new option, bear in mind it is prudent to assume that DHCP the
   DHCPv6 packet contents are always transmitted in the clear, and
   actual production use of the software will probably be vulnerable at
   least to man-in-
   the-middle man-in-the-middle attacks from within the network, even
   where the network itself is protected from external attacks by
   firewalls.  In particular, some DHCP DHCPv6 message exchanges are
   transmitted to broadcast
   or multicast addresses that are likely broadcast anyway.

   If an option is of a specific fixed length, it is useful to remind
   the implementer of the option data's full length.  This is easily
   done by declaring the specific value of the 'length' tag of the
   option.  This helps to gently remind implementers to validate option
   length before digesting them into likewise fixed length regions of
   memory or stack.

   If an option may be of variable size (such as having indeterminate
   length fields, such as domain names or text strings), it is advisable
   to explicitly remind the implementor to be aware of the potential for
   long options.  Either define a reasonable upper limit (and suggest
   validating it), or explicitly remind the implementor that an option
   may be exceptionally long (to be prepared to handle errors rather
   than truncate values).

   For some option contents, "insane values" out of bound values may be used to breach
   security.  An IP address field might be made to carry a loopback
   address, or local broadcast address, and depending on the protocol
   this may lead to undesirable results.  A domain name field may be
   filled with contrived contents that exceed the limitations placed
   upon domain name formatting...as formatting... as this value is possibly delivered to
   "internal configuration" records of the system, it may be trusted,
   rather than implicitly
   trusted without being validated.

   So it behooves an option's definition to contain any validation
   measures as can reasonably be made.


16.  IANA Considerations

   This document has no actions for IANA.


17.  References

17.1.  Informative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2131, 2119, March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC2241]  Provan, D., "DHCP Options for Novell Directory Services",
              RFC 2241, November 1997.

   [RFC2242]  Droms, R. and K. Fong, "NetWare/IP Domain Name and
              Information", RFC 2242, November 1997.

   [RFC3011]  Waters, G., "The IPv4 Subnet Selection Option for DHCP",
              RFC 3011, November 2000.

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.


   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3319]  Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
              Protocol (DHCPv6) Options for Session Initiation Protocol
              (SIP) Servers", RFC 3319, July 2003.

   [RFC3397]  Aboba, B. and S. Cheshire, "Dynamic Host Configuration
              Protocol (DHCP) Domain Search Option", RFC 3397,
              November 2002.

   [RFC3442]  Lemon, T., Cheshire, S.,

   [RFC3633]  Troan, O. and B. Volz, "The Classless
              Static Route Option R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 4", RFC 3442, December 2002.

   [RFC3495]  Beser, B. and P. Duffy, "Dynamic Host Configuration
              Protocol (DHCP) Option for CableLabs Client
              Configuration", RFC 3495, March 2003.

   [RFC3527]  Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
              "Link Selection sub-option for the Relay Agent Information
              Option for DHCPv4", RFC 3527, April 2003.

   [RFC3634]  Luehrs, K., Woundy, R., Bevilacqua, J., and N. Davoust,
              "Key Distribution Center (KDC) Server Address Sub-option
              for the Dynamic Host Configuration Protocol (DHCP)
              CableLabs Client Configuration (CCC) Option", 6", RFC 3634, 3633,
              December 2003.

   [RFC3646]  Droms, R., "DNS Configuration options for Dynamic Host
              Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
              December 2003.

   [RFC3898]  Kalusivalingam, V., "Network Information Service (NIS)
              Configuration Options for Dynamic Host Configuration
              Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.

   [RFC3925]  Littlefield, J., "Vendor-Identifying Vendor Options for
              Dynamic Host Configuration Protocol version 4 (DHCPv4)",
              RFC 3925, October 2004.

   [RFC3942]  Volz, B., "Reclassifying Dynamic Host Configuration
              Protocol version 4 (DHCPv4) Options", RFC 3942,
              November 2004.

   [RFC4030]  Stapp, M. and T. Lemon, "The Authentication Suboption for
              the Dynamic Host Configuration Protocol (DHCP) Relay Agent

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 4030, 3972, March 2005.

   [RFC4075]  Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
              Configuration Option for DHCPv6", RFC 4075, May 2005.

   [RFC4174]  Monia, C., Tseng, J.,

   [RFC4242]  Venaas, S., Chown, T., and K. Gibbons, "The IPv4 B. Volz, "Information Refresh
              Time Option for Dynamic Host Configuration Protocol (DHCP) Option for the Internet
              Storage Name Service",
              IPv6 (DHCPv6)", RFC 4174, September 4242, November 2005.

   [RFC4280]  Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host
              Configuration Protocol (DHCP) Options for Broadcast and
              Multicast Control Servers", RFC 4280, November 2005.

   [RFC4702]  Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
              Configuration Protocol (DHCP) Client Fully Qualified
              Domain Name (FQDN) Option", RFC 4702, October 2006.

   [RFC4704]  Volz, B., "The Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
              Option", RFC 4704, October 2006.

   [RFC4833]  Lear, E. and P. Eggert, "Timezone Options for DHCP",
              RFC 4833, April 2007.

Appendix A.  Background on ISC DHCP

   The ISC DHCP software package was mostly written by Ted Lemon in
   cooperation with Nominum, Inc. Since then, it has been given to
   Internet Systems Consortium, Inc. ("ISC") where it has been
   maintained in the public interest by contributors and ISC employees.

   It includes a DHCP Server, Relay, and Client implementation, with a
   common library of DHCP protocol handling procedures.

   The DHCP Client may be found on some Linux distributions, and FreeBSD
   5 and earlier.  Variations ("Forks") of older versions of the client
   may be found on several BSDs, including FreeBSD 6 and later.

   The DHCP Server implementation is known to be in wide use by many
   Unix-based servers, and comes pre-installed on most Linux

   The ISC DHCP Software Suite has to allow:

   o  Administrators to configure arbitrary DHCP Option Wire Formats for
      options that either were not published at the time the software
      released, or are of the System Administrator's invention (such as
      'Site-Local' [RFC3942] options), or finally were of Vendor design
      (Vendor Encapsulated Options [RFC2132] or similar).

   o  Pre-defined names and formats of options allocated by IANA and
      defined by the IETF Standards body.

   o  Applications deriving their configuration parameters from values
      provided by these options to receive and understand their content.
      Often, the binary format on the wire is not helpful or digestable
      by, for example, 'ifconfig' or '/etc/resolv.conf'.

   So, one can imagine that this would require a number of software

   1.  To read operator-written configuration value into memory.

   2.  To write the in-memory representation into protocol wire format.

   3.  To read the protocol wire format into memory.

   4.  To write the in-memory format to persistent storage (to cache
       across reboots for example).

   5.  To write the in-memory format to a format that can be consumed by

   If every option were formatted differently and uniquely, then we
   would have to write 5 functions for every option.  As there is the
   potential for as many as 254 DHCPv4 options, or 65536 DHCPv6 options,
   not to mention the various encapsulated spaces ("suboptions"), this
   is not scalable.

   One simple trick is to make the in-memory format the same as the wire
   format.  This reduces the number of functions required from 5 to 3.
   This is not always workable - sometimes an intermediate format is
   required, but it is a good general case.

   Another simple trick is to use the same (or very nearly the same)
   format for persistent storage as is used to convey parameters to
   applications.  This reduces the number of functions again from 3 to

   This is still an intractable number of functions per each DHCP
   option, even without the entire DHCP option space populated.  So, we
   need a way to reduce this to small orders.

A.1.  Atomic DHCP

   To accomplish these goals, a common "Format String" is used to
   describe, in abstract, all of the above.  Each octet in this format
   string represents a "DHCP Atom".  We chain these 'atoms' together,
   forming a sort of molecular structure for a particular DHCP option's
   defined format.

   The Configuration Syntax allows the user to construct such a format
   string without having to understand how the Atom is encoded on the
   wire, and how it is configured or presented.

   You can reasonably imagine that the various common formats of DHCP
   options described above (Table 1) each have an Atom associated with
   it.  There are special use Atoms, such as one to repeat the previous
   Atoms indefinitely (for example, November 2005.

   [RFC4704]  Volz, B., "The Dynamic Host Configuration Protocol for options with multiple IPv4
   addresses one after the other),
              IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
              Option", RFC 4704, October 2006.

   [RFC5970]  Huth, T., Freimann, J., Zimmer, V., and one which makes the previous Atom

   As the software encounters a format string, it processes each Atom
   individually to read from configuration into wire format, D. Thaler, "DHCPv6
              Options for Network Boot", RFC 5970, September 2010.

   [RFC6603]  Korhonen, J., Savolainen, T., Krishnan, S., and also to
   validate O. Troan,
              "Prefix Exclude Option for DHCPv6-based Prefix
              Delegation", RFC 6603, May 2012.

17.2.  Informative References

              Jiang, S. and convert wire format into output format (which with some
   small exclusions is identical to the configuration format).

   The format strings themselves are either hard coded by the software
   in a table of option definitions, or are compiled at runtime through
   configuration syntax generated by the operator.

           option <space>.<option> code <number> = <definition>;

   The <space> refers to the option space, which may be the DHCPv4
   option space, the S. Shen, "Secure DHCPv6 option space, or any suboption space such as
   the DHCPv4 Relay Agent Information suboptions or similar.

   The <option> refers to the option's symbolic name within that space.

   The code <number> refers to the binary code assigned to this option.

   The <definition> is a complex statement that brings together DHCP
   Atoms, many of which are the aforementioned common formats, that
   compose this option.

   Below is a sample configuration for two options, whose wire formats
   are defined Using CGAs",
              draft-ietf-dhc-secure-dhcpv6-06 (work in [RFC2132].  The Path MTU Plateau Table option, progress),
              March 2012.

              Despres, R., Penno, R., Lee, Y., Chen, G., and the
   Static Routes option.

        option dhcp.path-mtu-plateau-table code 25 =
                                           array of unsigned integer 16;
        option dhcp.static-routes code 33 = array of { ip-address,
                                                       ip-address };

   Once the options' syntax configuration is out of the way, values to
   be carried in the options may be configured.  These acts are
   distinct; the previous configuration only prepares the parser system
   to accept the configuration below.  The below configuration actually
   supplies S. Jiang,
              "IPv4 Residual Deployment via IPv6 - a value to be transmitted on the wire, relying on the above
   format definition.

        option dhcp.path-mtu-plataeu-table 4352, 1500, 576;
        option dhcp.static-routes,

Author's unified Stateless
              Solution (4rd)", draft-ietf-softwire-4rd-00 (work in
              progress), May 2012.

              Mrugalski, T., Boucadair, M., Deng, X., Troan, O., and C.
              Bao, "DHCPv6 Options for Mapping of Address and Port",
              draft-mdt-softwire-map-dhcp-option-02 (work in progress),
              January 2012.

Authors' Addresses

   David W. Hankins
   Google, Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA  94043

   Email: dhankins@google.com
   Tomasz Mrugalski
   Internet Systems Consortium, Inc.
   950 Charter Street
   Redwood City, CA  94063

   Phone: +1 650 423 1345
   Email: tomasz.mrugalski@gmail.com

   Marcin Siodelski

   Email: msiodelski@gmail.com

   Sheng Jiang
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: jiangsheng@huawei.com

   Suresh Krishnan
   8400 Blvd Decarie
   Town of Mount Royal, Quebec

   Email: suresh.krishnan@ericsson.com