Dynamic Host Configuration Working Group                      D. Hankins
Internet-Draft                                                    Google
Updates: 3315 (if approved)                                 T. Mrugalski
Intended status: Standards Track Best Current Practice                      M. Siodelski
Expires: October 11, December 31, 2013                                           ISC
                                                                S. Jiang
                                            Huawei Technologies Co., Ltd
                                                             S. Krishnan
                                                                Ericsson
                                                          April 09,
                                                           June 29, 2013

               Guidelines for Creating New DHCPv6 Options
                  draft-ietf-dhc-option-guidelines-11
                  draft-ietf-dhc-option-guidelines-12

Abstract

   This document provides guidance to prospective DHCPv6 Option
   developers to help them creating option formats that are easily
   adoptable by existing DHCPv6 software.  This document updates
   RFC3315.

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 October 11, December 31, 2013.

Copyright Notice

   Copyright (c) 2013 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 DHCPv6  . . . . . . . . . . . . . . . . . . . . .   3   4
   4.  General Principles  . . . . . . . . . . . . . . . . . . . . .   4
   5.  Reusing Other Options . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Option with IPv6 addresses  . . . . . . . . . . . . . . .   5
     5.2.  Option with a single flag (boolean) . . . . . . . . . . .   6
     5.3.  Option with IPv6 prefix . . . . . . . . . . . . . . . . .   7
     5.4.  Option with 32-bit integer value  . . . . . . . . . . . .   8
     5.5.  Option with 16-bit integer value  . . . . . . . . . . . .   8
     5.6.  Option with 8-bit integer value . . . . . . . . . . . . .   9   8
     5.7.  Option with URI . . . . . . . . . . . . . . . . . . . . .   9
     5.8.  Option with Text String . . . . . . . . . . . . . . . . .  10
     5.9.  Option with variable length data  . . . . . . . . . . . .   9
     5.8.  11
     5.10. Option with DNS Wire Format Domain Name List  . . . . . .  10  12
   6.  Avoid Conditional Formatting  . . . . . . . . . . . . . . . .  10  12
   7.  Avoid Aliasing  . . . . . . . . . . . . . . . . . . . . . . .  11  13
   8.  Choosing between FQDN and address . . . . . . . . . . . . . .  11  13
   9.  Encapsulated options in DHCPv6  . . . . . . . . . . . . . . .  13  15
   10. Additional States Considered Harmful  . . . . . . . . . . . .  14  16
   11. Is DHCPv6 dynamic? Configuration changes occur at fixed times  . . . . . . . . .  16
   12. Multiple provisioning domains . . . . . . . . . . . .  14
   12. Multiple provisioning domains . . . .  17
   13. Chartering Requirements and Advice for Responsible ADs  . . .  17
   14. Considerations for Creating New Formats . . . . . . . . .  15
   13. Considerations for Creating New Formats . .  19
   15. Option Size . . . . . . . . . . .  15
   14. . . . . . . . . . . . . . .  19
   16. Singleton options . . . . . . . . . . . . . . . . . . . . . .  20
   17. Option Size Order  . . . . . . . . . . . . . . . . . . . . . . . .  20
   18. Relay Options . . .  15
   15. . . . . . . . . . . . . . . . . . . . . .  21
   19. Clients Request their Options . . . . . . . . . . . . . . . .  16
   16.  21
   20. Transition Technologies . . . . . . . . . . . . . . . . . . .  17
   17.  22
   21. Recommended sections in the new document  . . . . . . . . . .  17
     17.1.  22
     21.1.  DHCPv6 Client Behavior Text  . . . . . . . . . . . . . . . . .  18
     17.2.  23
     21.2.  DHCPv6 Server Behavior Text  . . . . . . . . . . . . . . . . .  19
     17.3.  24
     21.3.  DHCPv6 Relay Agent Behavior Text . . . . . . . . . . . . . .  19
   18.  24
   22. Should the new document update existing RFCs? . . . . . . . .  19
   19.  24
   23. Security Considerations . . . . . . . . . . . . . . . . . . .  20
   20.  25
   24. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   21.  26
   25. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21
   22. Informative  26
   26. References  . . . . . . . . . . . . . . . . . . .  21 . . . . . .  26
     26.1.  Normative References . . . . . . . . . . . . . . . . . .  26
     26.2.  Informative References . . . . . . . . . . . . . . . . .  26
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23  28

1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   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.

   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 into every stage of the system's process, starting with the
   user interface used to enter the configuration up to the machine
   interfaces where configuration is ultimately consumed.

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

   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; adopted:

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

   o  If it requries new requires 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.

   o  If the option would work well in the particular deployment
      environment the proponents currently envision, but has equally
      valid uses in some other environment where the proposed option
      format would fail or would produce inconsistent results.

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

3.  When to Use DHCPv6

   Principally, 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 DHCPv6.

   The presence of such a knob isn't enough, because 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 the
   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
   administrators.

   Note that the client still reserves the right is not required to ignore configure any of these values
   received via DHCPv6 (for example, due to having a value manually
   configured by its own operator).  Bear in mind that doing so might
   cause the client to be rejected network attachment privileges, and
   this is one of the main reason reasons for the use of DHCPv6 in corporate
   enterprises.

4.  General Principles

   The primary guiding principle to follow in order to enhance an
   option's adoptability is simplification.  More specifically, the reuse.  The option should be created in such
   a way that 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 configuration facilities then it's
   fairly certain that new software can easily formally adopt it.

   There are at least two classes of DHCPv6 options: A bulk class of simple options
   which are provided explicitly to carry data from one side of the
   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 DHCPv6 software or are used during
   special processing (such as the Fully Qualified Domain Name (FQDN)
   option [RFC4704]), and so forth; these options carry data that is the
   result of a routine in some DHCPv6 software.

   The guidelines laid out here should be applied in a relaxed manner
   for the protocol class of options.  Wherever special case code is
   already required to adopt the 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

   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 data elements 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
   variable/indeterminate sized value at the tail end of the option.

   This estimates means that implementations will likely be 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 general, it is usually preferrable preferable to reuse
   previously used option formats.

   However, it isn't very practical to consider the bulk of DHCPv6
   options already allocated, and consider which of those solve a
   similar problem.  So, the following list of common option format
   fragments data
   elements 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.

5.1.  Option with IPv6 addresses

   This option format is used to carry one or many IPv6 addresses.  In
   some cases the number of allowed address is limited (e.g. to one):

      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-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         ipv6-address                          |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         ipv6-address                          |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: Option with IPv6 address

   Examples of use:

   o  DHCPv6 server unicast address (a single address only) [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]

   o  MIPv6 Home Agent Address [RFC6610] (a single address only)

   o  NTP server [RFC5908] (a single address only)

   o  NTP Multicast address [RFC5908] (a single address only)

5.2.  Option with a single flag (boolean)

   Sometimes it is useful to convey a single flag that can either take
   on or off values.  Instead of specifying an option with one bit of
   usable data and 7 bits of padding, it is better to define an option
   without any content.  It is the presence or absence of the option
   that conveys the value.  This approach has the additional benefit of
   absent option designating the default, i.e. administrator has to take
   explicit actions to deploy the oposite opposite of the default 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          |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Option for conveying boolean

   Examples of use:

   o  DHCPv6 rapid-commit [RFC3315]

5.3.  Option with IPv6 prefix

   Sometimes there is a need to convey an IPv6 prefix.  The information
   to be carried by such an option includes the 128-bit IPv6 prefix
   together with a length of this prefix taking values from 0 to 128.
   Using the simplest approach, the option could convey this data in two
   fixed length fields: one carrying prefix length, another carrying the
   prefix.  However, in many cases /64 or shorter prefixes are used.
   This implies that the large part of the prefix data carried by the
   option would have its bits set to zero and would be unused.  In order
   to avoid carrying unused data, it is recommended to store prefix in
   the variable length data field.  The appropriate option format is
   defined as follows:

      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         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  prefix6-len  |              ipv6-prefix                      |
     +-+-+-+-+-+-+-+-+           (variable length)                   |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 3: Option with IPv6 Prefix

   option-length is set to 1 + length of the IPv6 prefix.

   prefix6-len is one octet long and specifies the length in bits of the
   IPv6 prefix.  Typically allowed values are 0 to 128.

   ipv6-prefix field is a variable length field that specifies the IPv6
   prefix.  The length is (prefix6-len + 7) / 8.  This field is padded
   with zeros zero bits up to the nearest octet boundary when prefix6-len is
   not divisible by 8.  This can be
   expressed using the following equation: >prefix6-len<+7/8

   Examples of use:

   o  Default Mapping Rule [I-D.ietf-softwire-map-dhcp]

   For example, the prefix 2001:db8::/60 would be encoded with an
   option-length of 9, prefix-len prefix6-len would be set to 60, the ipv6-prefix
   would be 8 octets and would contains contain octets 20 01 0d b8 00 00 00 00.

   It should be noted that Prefix Delegation mechanism used in the IAPREFIX option defined by [RFC3633] uses constant
   a full length prefixes. 16-octet prefix field.  The concern about option length
   was not well understood at the time of its publication.

5.4.  Option with 32-bit integer value

   This option format can be used to carry 32 bit-signed or unsigned
   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          |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         32-bit-integer                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 4: Option with 32-bit-integer value

   Examples of use:

   o  Information Refresh Time [RFC4242]

5.5.  Option with 16-bit integer value

   This option format can be used to carry 16-bit 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          |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         16-bit-integer        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 5: Option with 16-bit integer value

   Examples of use:

   o  Elapsed Time [RFC3315]

5.6.  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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          option-code          |          option-len           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 8-bit-integer |
     +-+-+-+-+-+-+-+-+

                 Figure 6: Option with 8-bit integer value

   Examples of use:

   o  DHCPv6 Preference [RFC3315]

5.7.  Option with variable length data

   This option can be used to carry variable length data of any kind.
   Internal representation of carried data URI

   A Uniform Resource Identifier (URI) [RFC3986] is option specific.  Some a compact sequence
   of characters that identifies an abstract or physical resource.  The
   term "Uniform Resource Locator" (URL) refers to the existing DHCPv6 options use NVT-ASCII strings subset of URIs
   that, in addition to encode:
   filenames, host or domain names, protocol features or textual
   messages such as verbose error indicators. identifying a resource, provide a means of
   locating the resource by describing its primary access mechanism
   (e.g., its network "location").  This option format provides a lot of flexibility to pass data of
   almost any kind.  Though, whenever possible it is highly recommended can be used to use more specialized options, with field types better matching
   carried data types.
   carry a single URI:

      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-len           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                        URI (variable length)                  .
     .                      variable length data                     .
     .                                                               .
     |                           ...                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 7: Option with variale length data URI

   Examples of use:

   o  Client Identifier [RFC3315]

   o  Server Identifier [RFC3315]

   o  Boot File URL [RFC5970]

5.8.  Option with DNS Wire Format Domain Name List

   This option is used

   An alternate encoding to carry 'domain search' lists support multiple URIs is available.  An
   option must be defined to use either the single URI format above or any host
   the multiple URL format below depending on whether a single is always
   sufficient or
   domain name: if multiple URLs are possible.

      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          option-len           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               DNS Wire Format Domain Name List                |
     |                              ...                              |
     .                                                               .
     .                            uri-data                           .
     .                             . . .                             .

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 8: Option with DNS Wire Format Domain Name List

   Examples of use:

   o  SIP Servers Domain Name List [RFC3319] (many domains)

   o  NIS Domain Name (many domains) [RFC3898] (many domains)

   o  DS-Lite AFTR location [RFC6334] (a single FQDN)

   o  Home Network Identifier [RFC6610] (a single FQDN)

   o  Home Agent FQDN [RFC6610] (a single FQDN)

6.  Avoid Conditional Formatting

   Placing an octet at the start multiple URIs

   Each instance of the option which informs the
   software how to process the remaining uri-data is formatted as follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
   |       uri-len                 |          URI                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

   The uri-len is two octets of the option may appear
   simple to long and specifies the casual observer.  But length of the only conditional formatting
   methods uri
   data.

5.8.  Option with Text String

   A text string is a sequence of characters that are in widespread use today are 'protocol' class
   options.  Therefore have no semantics.
   The encoding (such as 7-bit ASCII, NVT-ASCII, UTF-8) of the conditional formatting requires new code to text
   string MUST be written, as well as introduces an implementation problem; as specified.  If a data format has semantics other than
   just being text, it
   requires that all speakers implement all current and future
   conditional formats.

   Conditional formatting is not recommended, except in cases where the
   DHCPv6 option has already been deployed experimentally, a string.  E.g., a FQDN is not a string,
   and all but
   one conditional format a URI is deprecated.

7.  Avoid Aliasing

   Options are said to be aliases of each other if also not a string, because they provide input to
   the same configuration parameter. have different
   semantics.  A commonly proposed example string must not enclude any terminator (such as a null
   byte).  This option format can be used to carry a text string:

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

                     Figure 9: Option with text string

   Examples of use:

   o  Timezone Options for DHCPv6 [RFC4833]

   An alternate encoding to support multiple text strings is available.
   An option must be defined to
   configure use either the location of some new service ("my foo server") using a
   binary IP address, single text string format
   above or the multiple text string format below depending on whether a domain name field, and an URL.  This kind
   single is always sufficient or if multiple text strings are possible.

      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-len           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                           text-data                           .
     .                             . . .                             .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 10: Option with multiple text strings

   Each instance of
   aliasing the text-data is undesirable, and formatted as follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
   |       text-len                |        String                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

   The text-len is not recommended.

   In this case, where three different formats are supposed, it more
   than triples two octets long and specifies the work length of the software involved, requiring support for
   not merely one format, but support
   string.

5.9.  Option with variable length data

   This option can be used to carry variable length data of any kind.
   Internal representation of carried data is option specific.  Whenever
   this format is used by the new option being defined, the data
   encoding should be documented.

   This option format provides a lot of flexibility to pass data of
   almost any 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          option-code          |         option-len            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                      variable length data                     .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 11: Option with variable length data

   Examples of use:

   o  Client Identifier [RFC3315]

   o  Server Identifier [RFC3315]

5.10.  Option with DNS Wire Format Domain Name List

   This option is used to carry 'domain search' lists or any host or
   domain name.  It uses the same format as described in Section 5.9,
   but with the special data encoding, described in section 8 of
   [RFC3315].  This data encoding supports carrying multiple instances
   of hosts or domain names in a single option, by terminating each
   instance with the byte value of 0.

      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         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               DNS Wire Format Domain Name List                |
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 12: Option with DNS Wire Format Domain Name List

   Examples of use:

   o  SIP Servers Domain Name List [RFC3319] (many domains)

   o  NIS Domain Name (many domains) [RFC3898] (many domains)

   o  DS-Lite AFTR location [RFC6334] (a single FQDN)

   o  Home Network Identifier [RFC6610] (a single FQDN)

   o  Home Agent FQDN [RFC6610] (a single FQDN)

6.  Avoid Conditional Formatting

   Placing an 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.  Therefore conditional formatting requires new code to be
   written and complicates future interoperability should new
   conditional formats be added; and existing code has to ignore
   conditional format that it does not support.

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 an URL.  This kind of
   aliasing is undesirable, and is 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 in
   the case where the server is configured with all formats, DHCPv6
   message bandwidth is wasted on option contents that are redundant.
   Also, the DHCPv6 option space is wasted, as three new option codes
   are required, rather than one.

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

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

8.  Choosing between FQDN and address

   Some parameters may be specified as FQDN or an address.  It is not
   allowed to define both option types at the same time (see section
   Section 7), so one of them must be chosen.  This section is intended
   to help make an informed decision in that regard.

   On the specific subject of desiring to configure a value using a FQDN
   instead of a binary IP address, note that most DHCPv6 server
   implementations will happily accept a Domain Name entered by the
   administrator, and use DNS resolution to render binary IP addresses
   in 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 produce consider in making a decision on format.

   Unless there are specific reasons to do otherwise, address should be
   used.  It is simpler to use, its validation is trivial (length of 16
   constitutes a valid option), is explicit and digest all three.
   Furthermore, code development does not allow any
   ambiguity.  It is faster (does not require extra resolution efforts),
   so it is more efficient, which can be especially important for energy
   restricted devices.

   FQDN options are discouraged for options intended to configure hosts,
   because hosts may have multiple provisioning domains (see
   Section 12), and may get a different answer from the DNS depending on
   the provisioning domain.  This is particularly a problem when the
   normal expected use of the option makes sense with private DNS
   zone(s), as might be the case with a corporate VPN.

   FQDN does require a resolution into an actual address.  This implies
   the question when the FQDN resolution should be taken.  There are a
   couple of possible answers: a) by the server, when it is started, b)
   by the server, when it is about to send an option, c) by the client,
   immediately after receiving an option, d) by the client, when the
   content of the option is actually consumed.  For a), b) and possibly
   c), the option should really convey an address, not FQDN.  The only
   real incentive to use FQDN is case d).  It is the only case that
   allows possible changes in the DNS to be picked up by clients.

   FQDN imposes a number of additional failure modes and testing issues that
   should be dealt with:

   1.  The client must cover all have a knowledge about available DNS servers.
       That typically means that option DNS_SERVERS is mandatory.  This
       should be mentioned in the draft that defines new option.  It is
       possible
   combinations of defined formats.  Since clients cannot predict what
   values that the server will provide, they return FQDN option, but not the DNS
       Servers option.  There should be a brief discussion about it;

   2.  The DNS may not be reachable;

   3.  DNS may be available, but may not have appropriate information
       (e.g. no AAAA records for specified FQDN);

   4.  Address family must request all formats.  So in be specified (A, AAAA or any);

   5.  What should the case where client do if there are multiple records available
       (use only the server first one, use all, use one and switch to the
       second if the first fails for whatever reason, etc.);

   6.  Multi-homed devices may be connected to different administrative
       domains with each domain providing different information in DNS
       (e.g. an enterprise network exposing private domains).  Client
       may send DNS queries to a different DNS server;

   7.  It should be mentioned if Internationalized Domain Names are
       allowed.  If they are, what kind of DNS option encoding should be
       specified.

9.  Encapsulated options in DHCPv6

   Most options are conveyed in a DHCPv6 message directly.  Although
   there is no codified normative language for such options, they are
   often referred to as top-level options.  Many options may include
   other options.  Such inner options are often referred to as
   encapsulated or nested options.  Those options are sometimes called
   sub-options, but this term actually means something else, and
   therefore should never be used to describe encapsulated options.  It
   is configured with all formats, DHCPv6
   message bandwidth recommended to use term "encapsulated" as this terminology is wasted on option contents that used
   in [RFC3315].  The difference between encapsulated and sub-options
   are redundant.
   Also, that the former uses normal DHCPv6 option space is wasted, as three new codes, while the
   latter uses option codes
   are required, rather than one. space specific to a given parent option.  It also becomes unclear which types of values are mandatory, and how
   configuring some
   should be noted that, contrary to DHCPv4, there is no shortage of the
   option numbers.  Therefore almost all options may influence the others. share a common option
   space.  For
   example, example option type 1 meant different things in DHCPv4,
   depending 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) it was located in a single field top-level or
   channel.  If that channel has a natural format, then any alternative
   formats merely make more work for intervening software in providing
   conversions.

   So the best advice inside of Relay Agent
   Information option.  There 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).

8.  Choosing between FQDN no such ambiguity in DHCPv6 (with the
   unfortunate exception of [RFC5908], which never got proper review
   from the DHC working group and address

   Some parameters may contains many errors, and should not
   under any circumstances be specified used as FQDN or an address.  It a template for future DHCP option
   definitions).

   From the implementation perspective, it is easier to implement
   encapsulated options rather than sub-options, as the implementers do
   not
   allowed have to define both deal with separate option types at spaces and can use the same time (see section
   Section 7), so one of them must be chosen.  This section is intended
   as a help to make an informed decision
   buffer parser in that regard.

   On several places throughout the specific subject of desiring code.

   Such encapsulation is not limited to configure a value using a FQDN
   instead of a binary IP address, note one level.  There is at least
   one defined option that most DHCPv6 server
   implementations will happily accept a Domain Name entered 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 an excluded prefix range that is
   represented by the
   administrator, and use DNS resolution to render binary IP addresses PD_EXCLUDE option that is conveyed as encapsulated
   inside IAPREFIX (PD_EXCLUDE, defined in DHCPv6 replies [RFC6603]).  It seems awkward
   to clients.  Consequently, consider the extra
   packet overhead incurred on the client's end refer to perform DNS
   resolution itself.  The client may be operating on a battery and
   packet transmission such options as sub-sub-option or doubly encapsulated
   option, therefore "encapsulated option" term is a non-trivial typically used,
   regardless of the nesting level.

   When defining configuration means for more complex mechanisms, it may
   be tempting to simply use sub-options.  That should be avoided, as it
   increases complexity of power, and the extra RTT
   delays the client must endure before the service parser.  It is configured are at
   least two factors much easier, faster and
   less error prone to consider in making parse a decision larger number of options on format.

   Unless there are specific reasons to do otherwise, address a single
   (top-level) scope, than parse options on several scopes.  The use of
   sub-options should be
   used.  It avoided as much as possible, but it is simpler better
   to use, its validation is trivial (length of 16
   constitutes a valid option), use sub-options rather than conditional formatting.

   It should be noted that currently there is explicit no clear way defined for
   requesting sub-options.  Most known implementations are simply using
   top-level ORO for requesting both top-level options and does not allow any
   ambiguity.  It encapsulated
   options.

10.  Additional States Considered Harmful

   DHCP is faster (does not require extra resolution efforts),
   so a protocol designed for provisioning clients.  Less
   experienced protocol designers often assume that it is more efficient, which can be especially important easy to define
   an option that will convey a different parameter for energy
   restricted devices.

   FQDN does require each client in a resolution into an actual address.  This implies
   network.  Such problems arose during designs of MAP
   [I-D.ietf-softwire-map-dhcp] and 4rd [I-D.ietf-softwire-4rd].  While
   it would be easier for provisioned clients to get ready to use per
   client option values, such requirement puts exceedingly large loads
   on the question when server side.  The new extensions may introduce new
   implementation complexity and additional database state on the FQDN resolution
   server.  Alternatives should be taken.  There are a
   couple of possible answers: a) by the server, when it is started, b)
   by the server, when it is about to send an option, c) by the client,
   immediately after receiving considered, if possible.  As an option, d) by the client, when
   example, [I-D.ietf-softwire-map-dhcp] was designed in a way that all
   clients are provisioned with the
   content same set of the option is actually consumed.  For a), b) MAP options and possibly
   c), each
   provisioned client uses its unique address and delegated prefix to
   generate client-specific information.  Such a solution does not
   introduce any additional state for the option server and therefore scales
   better.

   It also should really convey an address, not FQDN.  The be noted that 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 client will
   initiate renewal.  Those timers apply only
   real incentive to use FQDN is case d).  It is its own IA containers.
   Refreshing other parameters should be initiated after a time
   specified in the only case that
   allows possible changes Information Refresh Time Option (defined in
   [RFC4242]), carried in the DNS Reply message and returned in response to be picked up by clients.

   FQDN imposes number of
   Information-Request message.  Introducing additional failure modes timers make
   deployment unnecessarily complex and issues that
   should SHOULD be dealt with:

   1.  The client must have avoided.

11.  Configuration changes occur at fixed times
   In general, DHCPv6 clients only refresh configuration data from the
   DHCP server when the T1 timer expires.  Although there is a knowledge about available DNS servers.
       That typically means
   RECONFIGURE mechanism that allows a DHCP server to request that option DNS_SERVERS
   clients initiate reconfiguration, support for this mechanism is mandatory.  This
       should
   optional and cannot be mentioned in the draft that defines new option.  It is
       possible that the relied upon.

   Even when DHCP clients refresh their configuration information, not
   all consumers of DHCP-sourced configuration data notice these
   changes.  For instance, if a server will return FQDN option, is started using parameters
   received in an early DHCP transaction, but does not check for updates
   from DHCP, it may well continue to use the DNS
       Servers option.  There should be same parameter
   indefinitely.  Modern notification systems take care of reconfiguring
   services when the client moves to a brief discussion about it;

   2.  The DNS may not be reachable;

   3.  DNS may be available, new network, but it's worth
   bearing in mind that a renew may not have appropriate information
       (e.g.  no AAAA records for specified FQDN);

   4.  Address family must be specified (A, AAAA or any);

   5.  What should actually result in the client do if there are multiple records available
       (use only the first one, use all, use one and switch to
   taking up new configuration information that it receives.

   In light of the
       second if above, when designing an option you should take into
   consideration the first fails for whatever reason, etc.);

   6.  Multi-homed devices fact that your option may hold stale data that will
   only be connected to different administrative updated at an arbitrary time in the future.

12.  Multiple provisioning domains

   In some cases there could be more than one DHCPv6 server on a link,
   with each domain providing provisioning a different information in DNS
       (e.g.  an enterprise set of parameters.  One notable
   example of such a case is a home network exposing private domains).  Client 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 than one
   ADVERTISE message, may send DNS queries respond to one or more of them, such
   capability was never observed in any known implementations.  Existing
   clients will pick one server and will continue configuration process
   with that server, ignoring all other servers.

   This is a different DNS server;

   7.  It generic DHCP protocol issue and should not be mentioned if Internationalized Domain Names are
       allowed.  If they are, what kind of DNS dealt within
   each option encoding separately.  This issue is better dealt with using a
   protocol-level solution and fixing this problem should not be
       specified.

9.  Encapsulated options in DHCPv6

   Most options are conveyed in
   attempted on a DHCPv6 message directly.  Although
   there is no codified normative language per option basis.

13.  Chartering Requirements and Advice for such options, they are
   often referred to as top-level options.  Many options may include
   other options.  Such inner options are often referred to as
   encapsulated or nested options.  Those options are sometimes called
   sub-options, but this term Responsible ADs
   Adding a simple DHCP option is not precise straightforward, and thus discouraged.  It
   is recommened generally
   something that any working group can do, perhaps with some help from
   designated DHCP experts.  However, when new fragment types need to use term "encapsulated" as be
   devised, this terminology is used
   in [RFC3315].  The difference between encapsulated requires the attention of DHCP experts, and sub-options
   are should not
   be done in a working group that doesn't have a quorum of such
   experts.  This is true whether the former uses normal DHCPv6 option space codes, while new fragment type has the
   latter uses option space specific same
   structure as an existing fragment type, but has different semantics.
   It is equally true when the new format has a new structure.

   Responsible Area Directors for working groups that wish to add a given parent option.  It work
   item to a working group charter to define a new DHCP option should be noted that, contrary
   get clarity from the working group as to DHCPv4, there is no shortage of whether the new option numbers.  Therefore almost all options share is a common option
   space.  For example
   simple DHCP option with no new fragment type 1 meant different things in DHCPv4,
   depending if or new fragment
   semantics, or whether it was located in top-level or inside fact will require new fragment types.  A
   working group charter item should explicitly state which of Relay Agent
   Information option.  There these two
   types is no such ambiguity in DHCPv6 (with the
   unfortunate exception of [RFC5908]).

   From the implementation perspective, required; if it is easier to implement
   encapsulated option rather than sub-option, as the implementor do not
   have to deal with separate option spaces and can use known at the same buffer
   parser in several places throughout time of chartering, the code.

   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 an excluded prefix range that
   is represented by PD_EXCLUDE option
   charter should state that is conveyed as sub-option
   inside IAPREFIX (PD_EXCLUDE, defined in [RFC6603]).  It seems awkward
   to refer to such options as sub-sub-option or doubly encapsulated
   option, therefore "encapsulated option" term is typically used,
   regardless of the nesting level.

   When defining configuration means for more complex mechanisms, it may
   be tempting working group will study the question
   and recharter or seek help elsewhere if a new fragment type is to simply use sub-options.  That should usually be
   avoided, as
   defined.

   If a working group needs a new fragment type, it increases complexity of the parser.  It is much
   easier, faster preferable to
   seek out a working group whose members already have sufficient
   expertise to evaluate the new work and less error prone try to parse larger number of options
   on come up with a single (top-level) scope, new
   format that generalizes well and can be reused, rather than parse options on several scopes.
   The a single-
   use of sub-options fragment type.  If such a working group is available, the work
   should be avoided chartered in that working group as much a separate draft that
   documents the new fragment type.  The working group that needs the
   new fragment type can then define their new option referencing the
   new fragment type document.  This work can generally be done in
   parallel so as possible but it
   is better not to use sub-options rather than conditional formatting.

   It should be noted delay the process significantly.

   In the event that 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.

10.  Additional States Considered Harmful working group with DHCP is a protocol designed for provisioning nodes.  Less experienced
   protocol designers often assume expertise that it is easy to
   can define an option
   that will convey a different parameter for each node in a network.
   Such problems arose during designs of MAP
   [I-D.ietf-softwire-map-dhcp] and 4rd [I-D.ietf-softwire-4rd].  While
   it would be easier for provisioned nodes to get ready the new fragment type, the responsible AD should seek out
   help from known DHCP experts within the IETF to use per node
   option values, such requirement puts exceedingly large loads on provide advice and
   frequent early review as the
   server side.  Alternatives working group defines the new fragment
   type.  The new fragment type should still be considered, if possible.  As an
   example, [I-D.ietf-softwire-map-dhcp] was designed done in a way that all
   nodes are provisioned with separate
   document, even if it's done in the same set working group, so as to
   foster reuse of MAP options and each
   provisioned node uses its unique address the new fragment type.  The responsible AD should
   work with the working group chairs and delegated prefix designated DHCP experts to
   generate node-specific information.  Such solution does not introduce
   any additional state for
   ensure that new fragment type document has in fact been carefully
   reviewed by the server experts and therefore scales better.

   It also appears satisfactory.

   Responsible area directors for working groups that are considering
   defining options that actually update the DHCP protocol, as opposed
   to simple options, should go through a process similar to that
   described above when trying to determine where to do the work.  Under
   no circumstances should a working group be noted given a charter
   deliverable to define a new DHCP option, and then on the basis of
   that contrary charter item actually make updates to DHCPv4, DHCPv6 keeps several
   timers the DHCP protocol.

14.  Considerations for renewals.  Each IA_NA (addresses) and IA_PD (prefixes)
   contains T1 Creating New Formats

   When defining new options, one specific consideration to evaluate is
   whether or not options of a similar format would need to have
   multiple or single values encoded (whatever differs from the current
   option), and T2 timers how that designate time after which client will
   initiate renewal.  Those timers apply only might be accomplished in a similar format.

   When defining a new option, it is best to its own IA containers.
   For renewing other parameters, please use Information Refresh Time
   Option (defined synthesize the option
   format using fragment types already in use.  However, in some cases
   there may be no fragment type that accomplishes the intended purpose.

   The matter of size considerations and option order are further
   discussed in [RFC4242]).  Introducing additional timers make
   deployment unnecessarily complex Section 15 and should be avoided.

11.  Is DHCPv6 dynamic? Section 17.

15.  Option Size

   DHCPv6 stands for Dynamic Host Configuration Protocol [RFC3315] allows for IPv6.
   Contrary packet sizes up to 64KB.  First, through
   its name, in many contexts it is not dynamic.  While
   designing DHCPv6 options, use of link-local addresses, it is worth noting avoids many of the deployment
   problems that there plague DHCPv4, and is no
   reliable way actually an UDP over IPv6 based
   protocol (compared to instantly notify clients that something has happened,
   e.g.  parameter value has changed.  There DHCPv4, which is a RECONFIGURE mechanism, mostly UDP over IPv4 protocol,
   but it has several serious drawbacks with layer 2 hacks).  Second, RFC 3315 explicitly refers readers
   to RFC 2460 Section 5, which describes an MTU of 1280 octets and a
   minimum fragment reassembly of 1500 octets.  It's feasible to suggest
   that makes its use difficult.
   First, its support DHCPv6 is optional capable of having larger options deployed over it, and many client implementations do not
   support it.  To use reconfigure mechanism, server must use
   at least no common upper limit is yet known to have been encoded by
   its secret
   nonce.  That means implementors.  It is impossible to describe any fixed limit that provisioning server
   cleanly divides those too big from the workable.

   It is advantageous to prefer option formats which contain the only one desired
   information in the smallest form factor that satisfies the
   requirements.  Common sense still applies here.  It is better to
   split distinct values into separate octets rather than propose overly
   complex bit shifting operations to save several bits (or even an
   octet or two) that can
   initiate reconfiguration.  Other servers do not know it and cannot
   trigger reconfiguration.  Therefore would be padded to the only reliable way next octet boundary anyway.

   DHCPv6 does allow for clients
   to refresh their configuration multiple instances of a given option, and they
   are treated as distinct values following the defined format, however
   this feature is generally preferred to wait until T1 expires.

12.  Multiple provisioning domains

   In some cases there could be more than one DHCPv6 server on a link,
   with each provisioning a different set of parameters.  One notable
   example restricted to protocol
   class features (such as the IA_* series of options).  In such case cases,
   it is a home network with a connection better to two
   independent ISPs.

   DHCPv6 was not initially designed with multiple provisioning domains.
   Although [RFC3315] states that define an option as an array if it is possible.  It
   is recommended to clarify (with normative language) whether a client that receives more than one
   ADVERTISE message, given
   DHCPv6 option may respond to one appear once or more of them, such
   capability was never observed in any known implementations.  Existing
   clients will pick one server multiple times.  The default
   assumption is only once.

   Relay agents have to do fragment reassembly and will continue configuration process
   with that server, ignoring all other servers.

   This fragmentation on
   transmission.  So while fragmentation is allowed, if a generic DHCP protocol issue and should not be dealt within
   each new option separately.  This issue is better dealt with using
   results in significant fragmentation, it probably isn't a
   protocol-level solution and fixing this problem good choice
   for DHCP configuration; instead DHCP should not be
   attempted on simply point to a per option basis.

13.  Considerations for Creating New Formats

   If URI
   where the configuration information can be obtained.

16.  Singleton options

   Although [RFC3315] states that each option simply will not fit into any existing work by using
   fragments, type MAY appear more than
   once, the last recourse original idea was that multiple instances are reserved for
   stateful options, like IA_NA or IA_PD.  For most other options it is to create a new format to fit.

   When doing so,
   usually expected that they will appear at most once.  Such options
   are called singleton options.  Sadly, it is often not enough clearly
   specified in RFCs that were published up to gauge this date whether only
   one or not the option
   format will work in the context of the option presently being
   considered.  It is equally important to consider if the new format's
   fragments might reasonably have any other uses, and if so, to create
   the more option with the foreknowledge instances are allowed.  Documents that its parts may later become a
   common fragment.

   One specific consideration to evaluate is define new
   defined options SHOULD state whether new options are singletons or not
   not.  Unless otherwise specified, new defined options of are singletons.

   When deciding whether a
   similar format would need to have multiple or single values encoded
   (whatever differs from the current option), and how that might be
   accomplished or multiple option instances are
   allowed in a similar format.

   The matter of size considerations is further discussed in Section 14.

14.  Option Size

   DHCPv6 [RFC3315] allows for packet sizes up to 64KB.  First, through
   its use of link-local addresses, it steps aside many of message, take into consideration how the
   deployment problems that plague DHCPv4, and is actually an UDP over
   IPv6 based protocol (compared to DHCPv4, which is mostly UDP over
   IPv4 protocol, but with layer 2 hacks).  Second, RFC 3315 explicitly
   refers readers to RFC 2460 Section 5, which describes an MTU of 1280
   octets and a minimum fragment reassembly content of 1500 octets.  It's
   feasible the
   option will be used.  Depending on the service being configured it
   may or may not make sense to suggest that DHCPv6 is capable of having larger options
   deployed over it, and at least no common upper limit have multiple values configured.  If
   multiple values make sense, it is yet known better to
   have been encoded explicitly allow that by its implementors.  It is impossible
   using option format that allows multiple values within one option
   instance.

   Allowing multiple option instances often leads to describe
   any fixed limit confusion.
   Consider the following example.  Basic DS-Lite architecture assumes
   that cleanly divides those too big from the workable.

   It is advantageous B4 element (DHCPv6 client) will receive AFTR option and
   establish a single tunnel to prefer configured tunnel termination point
   (AFTR).  During standardization process of [RFC6334] there was a
   discussion whether multiple instances of DS-Lite tunnel option formats which contain should
   be allowed.  This created an unfounded expectation that the desired
   information clients
   receiving multiple instances of the option will somehow know when one
   tunnel endpoint goes off-line and do some sort of failover between
   other values provided in other instances of the smallest form factor AFTR option.  Others
   assumed that satisfies if there are multiple options, the
   requirements.  A common sense still applies here. client will somehow
   do a load balancing between provided tunnel endpoints.  Neither
   failover nor load balancing was defined for DS-Lite architecture, so
   it caused confusion.  It is better to
   split distinct values into separate octects rather than propose
   overly complex bit shifting operations was eventually decided to save up several bits (or
   even an octet allow only one
   instance of the AFTR option.

17.  Option Order
   Option order, either the order among many DHCPv6 options or two) that would the order
   of multiple instances of the same option, SHOULD NOT be padded to significant
   and MUST NOT be assumed.  An exception may be security relevant
   options, which are often created last and put at the next octet boundary
   anyway.

   DHCPv6 does allow last position,
   or whose location indicates the protected range.

   As there is no explicit order for multiple instances instance of a given the same
   option, and they
   are treated as distinct values following an option definition SHOULD instead restrict the defined format, however
   this feature is generally preferred to be restricted to protocol
   class features (such as order within
   the IA_* series option by using a list of options). items rather than a single item.

18.  Relay Options

   In such cases,
   it is better to define an option DHCPv4, all relay options are organized as sub-options within DHCP
   Relay Agent Information Option[RFC3046].  And an array if it is possible.  It independent number
   space called "DHCP Relay Agent Sub-options" is recommended to clarify (with normative language) whether a given maintained by IANA.
   Different from DHCPv4, in DHCPv6, Relay options are defined in the
   same way as client/server options, and they too use the same number
   space as client/server options.  Future DHCPv6 option Relay options MUST be
   allocated from this single DHCPv6 Option code space.

   However, the Relay-Supplied Options Option [RFC6422] may appear once or multiple times.

15. also contain
   some DHCPv6 options as permitted, such as the EAP Re-authentication
   Protocol (ERP) Local Domain Name DHCPv6 Option [RFC6440].

19.  Clients Request their Options

   The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315], is an option
   that serves two purposes - to inform the server what options the
   client supports and to inform what options the client is willing to
   consume.

   It doesn't make sense for some options to be requested using Option
   Request Option, such as those formed by elements of the protocol's
   internal workings, or are formed on either end by DHCPv6-level
   software engaged in some exchange of information.  When in 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 tempting to put a add text that requires the client to include a new
   option in Option Request Option list, similar to this text: "Clients
   MUST place the foo option code on the Option Request Option list,
   clients MAY include option foo in their packets as hints for the
   server as values the desire, and servers MUST include option foo when
   the client requested it (and the server has been so configured)".
   Such a text is discouraged as there are several issues with it.  First,
   it assumes that client implementation that supports a given option
   will always want to use it.  This is not true.  The second and more
   important reason is that such a text essentially duplicates mechanism
   already defined in [RFC3315].  It is better to simply refer to the
   existing mechanism rather than define it again.  See Section 17 21 for
   proposed examples on how to do that.

   Creators of DHCPv6 options MUST NOT should not require special ordering of
   options either in the relevant request option, or in the order of
   options within the packet.  Although it is reasonable to expect that
   options will be processed in the order they appear in ORO, server
   software is not required to sort DHCPv6 options into the same order
   in reply messages.

   It should also be noted that any requirement regarding
   option ordering will break down most existing implementations, as
   "order is not important" was one 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 values are never aligned within
   the DHCP packet, even the option code and option encapsulation should be considered.

16. length may appear on
   odd byte boundaries.

20.  Transition Technologies

   Transition from IPv4 to IPv6 is progressing, albeit at somewhat
   disappointing pace. progressing.  Many transition
   technologies are proposed to speed it up.  As a natural consequence
   there are also DHCP options proposed to provision those proposals.
   The inevitable question is
   that whether the required parameters should be
   delivered over DHCPv4 or DHCPv6.  Authors often don't give much
   thought about it and simply pick DHCPv6 without realizing the
   consequences.  IPv6 is expected to stay with us for many decades, and
   so is DHCPv6.  There is no mechanism available to deprecate an option
   in DHCPv6, so any options defined will stay with us as long as DHCPv6
   protocol itself.  It seems likely that such options defined to
   transition from IPv4 will outlive IPv4 by many decades.  From that
   perspective it is better to implement provisioning of the transition
   technologies in DHCPv4, which will be obsoleted together with IPv4.

17.

   When the network infrastructure becomes IPv6-only, the support for
   IPv4-only nodes may still be needed.  In this scenario, provisioning
   IPv4 configuration over IPv6-only networks
   [I-D.ietf-dhc-v4configuration] may be needed.

21.  Recommended sections in the new document

   There are three major entities in DHCPv6 protocol: server, relay
   agent, and client.  There is also a separate entity called requestor,
   which is a special client-like type that participates in leasequery
   protocol [RFC5007] and [RFC5460].  It is very helpful for
   implementors implementers to include
   separate sections that describe operation for those three major components.
   entities.  Even when a given entity does not participate, it is
   useful to have a very short section stating that it must not send a
   given option and must ignore it when received.

   Similar

   There is also a separate entity called requestor, which is a special
   client-like type that participates in leasequery protocol [RFC5007]
   and [RFC5460].  A similar section for the requestor is not required,
   unless the new option has anything to do with requestor (or it is
   likely that the reader may think that is has).  It should be noted
   that while in the majority of deployments, requestor is colocated co-located
   with relay agent, those are two separate entities from the protocol
   perspective and they may be used separately.  There are stand-alone
   requestor implementations available.

   The following sections include proposed text for such sections.  That
   text is not required to appear, but it is appropriate in most cases.
   Additional or modified text specific to a given option is often
   required.

   Although requestor is somewhat uncommon functionality, its existence
   should be noted, especially when allowing or disallowing options to
   appear in certain message or being sent be by certain entities.
   Additional message types may appear in the future, besides types
   defined in [RFC3315].  Therefore authors are encouraged to
   familiarize themselves with a list of currently defined DHCPv6
   messages available on IANA website [iana].

   Typically new options are requested by clients and assigned by the
   server, so there is no specific relay behavior.  Nevertheless it is
   good to include a section for relay agent behaviour behavior and simply state
   that there are no additional requirements for relays.  The same
   applies for client behavior if the options are to be exchanged
   between relay and server.

   Section

   Sections that contain option definition definitions MUST include formal
   verification procedure.  Often it is very simple, e.g. option that
   conveys IPv6 address must be exactly 16 bytes long, but sometimes the
   rules are more complex.  It is recommeded to refer to existing
   documents (e.g. section 8 of RFC3315 for domain name enconding) encoding) rather
   than trying to repeat such rules.

17.1.

21.1.  DHCPv6 Client Behavior

   Client Text

   Clients MAY request option foo, as defined in [RFC3315], sections
   17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5 and 22.7.  As a convenience to
   the reader, we mention here that the client includes requested option
   codes in Option Request Option.

   Optional text (if client's hints make sense): Client also MAY include
   option foo in its SOLICIT, REQUEST, RENEW, REBIND and INFORMATION-
   REQUEST messages as a hint for the server regarding preferred option
   values.

   Optional text (if the option contains FQDN): If the client request requests
   an option that conveys an FQDN, it is expected that content the contents of
   that option will be resolved using DNS.  Hence the following text may
   be useful:
   Client Clients that requests request option foo SHOULD also request option
   OPTION_DNS_SERVERS specified in [RFC3646].

   Client

   Clients MUST discard option foo if it is invalid (i.e. did not pass
   validation steps defined in Section X.Y).

   Optional text (if option foo in expected to be exchanged between
   relays or request and server): servers): Option foo is exchanged between relays and
   servers only.  Clients are not aware of the usage of option foo.
   Clients MUST ignore received option foo.

17.2.

21.2.  DHCPv6 Server Behavior Text

   Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in
   regards of to option assignment.  As a convenience to the reader, we
   mention here that the server will send option foo only if configured
   with specific values for foo and the client requested it.

   Optional text: Server Option foo is a singleton.  Servers MUST NOT send more
   than one instance of foo option.

   Optional text (if server is never supposed to receive option foo):
   Server
   Servers MUST ignore incoming foo option.

17.3.

21.3.  DHCPv6 Relay Agent Behavior Text

   It's never appropriate for a relay agent to add options to a message
   heading toward the client, and relay agents don't actually construct
   Relay-Reply messages anyway.

   Optional text (if foo option is exchanged between clients and server
   or between requestors and servers): There are no additional
   requirements for relays.

   Optional text (if relays are expected to insert or consume option
   foo): Relay agents MAY include option foo in a Relay-Forw when
   forwarding packets from clients to the server.

18. servers.

22.  Should the new document update existing RFCs?

   Authors often ask themselves a question whether their proposal
   updates exist RFCs, especially 3315.  During time of writing this
   document  In April 2013 there were 79 about
   80 options defined.  Had all documents that defined them also updated
   RFC3315, its comprehension of such a document set would be extremely
   difficult.  It should be noted that "extends" and "updates" are two
   very different verbs.  If a new draft defines a new option that
   clients request and servers provide, it merely extends current
   standards, so "updates 3315" is not required in the new document
   header.  On the other hand, if the a new draft
   changes something in already defined behavior, e.g.  servers must
   discard incoming messages if option foo is invalid document replaces or missing, then
   the "updates" phrase is warranted.

19.  Security Considerations

   DHCPv6 does have an Authentication mechanism ([RFC3315]) modifies
   existing behavior, it should be noted that makes it possible for DHCPv6 software to discriminate between authentic
   endpoints and men in updates the middle.  Other authentication mechanisms may
   optionally be deployed. other
   document.  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, [RFC6644] clearly updates [RFC3315] as of now, the it
   replaces existing with new text.

23.  Security Considerations

   DHCPv6 does have an Authentication mechanism is not widely ([RFC3315]) that makes
   it possible for DHCPv6 software to discriminate between authentic
   endpoints and man-in-the-middle.  Other authentication mechanisms may
   optionally be deployed.  It also does not provide end-to-end encryption.

   So, while creating a new option, it is prudent to assume that 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 attacks from within the network, even
   where the network itself is protected from external attacks by
   firewalls.  In particular, some DHCPv6 message exchanges are
   transmitted to 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, 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 multicast 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 this value is possibly delivered to
   "internal configuration" records of the system, it may be implicitly
   trusted without being validated.

   So it behooves an option's definition

   Authors of drafts defining new DHCP options are therefore strongly
   advised to contain any explicitly define validation measures as that recipients of
   such options are required to do before processing such options.

   However, validation measures already defined by RFC3315 or other
   specifications referenced by the new option document are redundant,
   and can reasonably be made.

20. introduce errors, so authors are equally strongly advised to
   refer to the base specification for any such validation language
   rather than copying it into the new specification.

24.  IANA Considerations

   This document has no actions for IANA.

21.

25.  Acknowledgements

   Authors would like to thank Simon Perreault, Bernie Volz and Ted
   Lemon for their comments.

22.

26.  References

26.1.  Normative References

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

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

26.2.  Informative References

   [I-D.ietf-dhc-secure-dhcpv6]
              Jiang, S.

   [I-D.ietf-dhc-v4configuration]
              Rajtar, B. and S. Shen, "Secure DHCPv6 Using CGAs", draft-
              ietf-dhc-secure-dhcpv6-07 I. Farrer, "Provisioning IPv4 Configuration
              Over IPv6 Only Networks", draft-ietf-dhc-
              v4configuration-01 (work in progress), September
              2012. May 2013.

   [I-D.ietf-softwire-4rd]
              Jiang, S.,
              Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and
              M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless
              Solution (4rd)", draft-ietf-softwire-4rd-04 draft-ietf-softwire-4rd-05 (work in
              progress), October 2012. April 2013.

   [I-D.ietf-softwire-map-dhcp]
              Mrugalski, T., Troan, O., Dec, W., Bao, C.,
              leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options
              for Mapping of Address and Port", draft-ietf-softwire-map-
              dhcp-03 (work in progress), February 2013.

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

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

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

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

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 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.

   [RFC3972]  Aura,

   [RFC3986]  Berners-Lee, T., "Cryptographically Generated Addresses (CGA)", Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC 3972, March
              3986, January 2005.

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

   [RFC4242]  Venaas, S., Chown, T., and B. Volz, "Information Refresh
              Time Option for Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 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.

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

   [RFC5007]  Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
              "DHCPv6 Leasequery", RFC 5007, September 2007.

   [RFC5460]  Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February
              2009.

   [RFC5908]  Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP)
              Server Option for DHCPv6", RFC 5908, June 2010.

   [RFC5970]  Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
              Options for Network Boot", RFC 5970, September 2010.

   [RFC6334]  Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
              Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
              RFC 6334, August 2011.

   [RFC6422]  Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC
              6422, December 2011.

   [RFC6440]  Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication
              Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440,
              December 2011.

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

   [RFC6610]  Jang, H., Yegin, A., Chowdhury, K., Choi, J., and T.
              Lemon, "DHCP Options for Home Information Discovery in
              Mobile IPv6 (MIPv6)", RFC 6610, May 2012.

   [RFC6644]  Evans, D., Droms, R., and S. Jiang, "Rebind Capability in
              DHCPv6 Reconfigure Messages", RFC 6644, July 2012.

   [iana]     IANA, , ., "DHCPv6 parameters (IANA webpage)", November
              2003,
              <http://www.iana.org/assignments/dhcpv6-parameters/>.

Authors' Addresses

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

   Email: dhankins@google.com

   Tomek Mrugalski
   Internet Systems Consortium, Inc.
   950 Charter Street
   Redwood City, CA  94063
   USA

   Phone: +1 650 423 1345
   Email: tomasz.mrugalski@gmail.com
   Marcin Siodelski
   950 Charter Street
   Redwood City, CA  94063
   USA

   Phone: +1 650 423 1431
   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
   Ericsson
   8400 Blvd Decarie
   Town of Mount Royal, Quebec
   Canada

   Email: suresh.krishnan@ericsson.com