draft-ietf-dhc-option-guidelines-07.txt   draft-ietf-dhc-option-guidelines-08.txt 
Dynamic Host Configuration Working D. Hankins Dynamic Host Configuration Working D. Hankins
Group Google Group Google
Internet-Draft October 1, 2011 Internet-Draft T. Mrugalski
Intended status: Informational Intended status: Informational M. Siodelski
Expires: April 3, 2012 Expires: December 21, 2012 ISC
S. Jiang
Huawei Technologies Co., Ltd
S. Krishnan
Ericsson
June 19, 2012
Guidelines for Creating New DHCP Options Guidelines for Creating New DHCPv6 Options
draft-ietf-dhc-option-guidelines-07 draft-ietf-dhc-option-guidelines-08
Abstract Abstract
This document seeks to provide guidance to prospective DHCP Option This document provides guidance to prospective DHCPv6 Option
authors, to help them in producing option formats that are easily developers to help them creating option formats that are easily
adoptable. adoptable by existing DHCPv6 software.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 3, 2012. This Internet-Draft will expire on December 21, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
2. When to Use DHCP . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. General Principles . . . . . . . . . . . . . . . . . . . . . . 4 3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . . 4
4. Reusing Other Options . . . . . . . . . . . . . . . . . . . . 5 4. General Principles . . . . . . . . . . . . . . . . . . . . . . 4
5. Avoid Conditional Formatting . . . . . . . . . . . . . . . . . 7 5. Reusing Other Options . . . . . . . . . . . . . . . . . . . . 5
6. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Option with IPv6 addresses . . . . . . . . . . . . . . . . 5
7. Considerations for Creating New Formats . . . . . . . . . . . 8 5.2. Option with 32-bit integer value . . . . . . . . . . . . . 6
8. The Dangers of Sub Options . . . . . . . . . . . . . . . . . . 8 5.3. Option with 16-bit integer value . . . . . . . . . . . . . 7
9. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Option with 8-bit integer value . . . . . . . . . . . . . 7
10. Clients Request their Options . . . . . . . . . . . . . . . . 11 5.5. Option with variable length data . . . . . . . . . . . . . 7
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5.6. Option with DNS Wire Format Domain Name List . . . . . . . 8
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . . 9
13. Informative References . . . . . . . . . . . . . . . . . . . . 13 7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Background on ISC DHCP . . . . . . . . . . . . . . . 15 8. Suboptions in DHCPv6 . . . . . . . . . . . . . . . . . . . . . 10
A.1. Atomic DHCP . . . . . . . . . . . . . . . . . . . . . . . 17 9. Additional States Considered Harmful . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Is DHCPv6 dynamic? . . . . . . . . . . . . . . . . . . . . . . 11
11. Multiple provisioning domains . . . . . . . . . . . . . . . . 11
12. Considerations for Creating New Formats . . . . . . . . . . . 12
13. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 12
14. Clients Request their Options . . . . . . . . . . . . . . . . 13
15. Security Considerations . . . . . . . . . . . . . . . . . . . 13
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
17.1. Informative References . . . . . . . . . . . . . . . . . . 15
17.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 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 Most protocol developers ask themselves if a protocol will work, or
work efficiently. These are important questions, but another less work efficiently. These are important questions, but another less
frequently considered question is whether the proposed protocol frequently considered question is whether the proposed protocol
presents itself needless barriers to adoption by deployed software. presents itself needless barriers to adoption by deployed software.
DHCPv4 [RFC2131] and DHCPv6 [RFC3315] software implementors are not DHCPv6 [RFC3315] software implementors are not merely faced with the
merely faced with the task of a given option's format on the wire. task of handling a given option's format on the wire. The option
The option must "fit" into every stage of the system's process, from must fit into every stage of the system's process, starting with the
the user interface where configuration is entered to the machine user interface used to enter the configuration upto the machine
interfaces where configuration is consumed. To help understand the interfaces where configuration is ultimately consumed.
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 Another frequently overlooked aspect of rapid adoption is whether the
question: Would the option would require operators to be intimately option requires operators to be intimately familiar with the option's
familiar with the option's internal format in order to make use of internal format in order to use it? Most DHCPv6 software provides a
it? Most DHCP software provides a facility for "unknown options" at facility for handling unknown options at the time of publication.
the time of publication to be configured by hand by an operator. But The handling of such options usually needs to be manually configured
if doing so requires extensive reading (more than can be covered in a by the operator. But if doing so requires extensive reading (more
simple FAQ for example), it inhibits adoption. 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, So although a given solution would work, and might even be space,
time, or aesthetically optimal, a given option is presented with a time, or aesthetically optimal, a given option is presented with a
series of ever-worsening challenges to be adopted; series of ever-worsening challenges to be adopted;
o If it doesn't fit neatly into existing config files. o If it doesn't fit neatly into existing config files.
o If it requries new source code changes to be adopted, and hence o If it requries new source code changes to be adopted, and hence
upgrades of deployed software. upgrades of deployed software.
o If it does not share its deployment fate in a general manner with o If it does not share its deployment fate in a general manner with
other options, standing alone in requiring code changes or other options, standing alone in requiring code changes or
reworking configuration file syntaxes. reworking configuration file syntaxes.
There are many things DHCP option authors can do to form DHCP Options There are many things DHCPv6 option creators can do to avoid the
to stay off this list entirely, or failing that, to make software pitfalls in this list entirely, or failing that, to make software
implementors lives easier and improve its chances for widespread implementors lives easier and improve its chances for widespread
adoption. adoption.
2. When to Use DHCP 3. When to Use DHCPv6
Principally, DHCP carries configuration parameters for its clients. Principally, DHCPv6 carries configuration parameters for its clients.
Any knob, dial, slider, or checkbox on the client system, such as "my Any knob, dial, slider, or checkbox on the client system, such as "my
domain name servers", "my hostname", or even "my shutdown domain name servers", "my hostname", or even "my shutdown
temperature" are candidates for being configured by DHCP. temperature" are candidates for being configured by DHCPv6.
The presence of such a knob isn't enough, because DHCP also presents The presence of such a knob isn't enough, because DHCPv6 also
the extension of an administrative domain - the operator of the presents the extension of an administrative domain - the operator of
network to which the client is currently attached. Someone runs not the network to which the client is currently attached. Someone runs
only the local switching network infrastructure that the client is not only the local switching network infrastructure that the client
directly (or wirelessly) attached to, but the various methods of is directly (or wirelessly) attached to, but the various methods of
accessing the external Internet via local assist services that accessing the external Internet via local assist services that
network must also provide (such as domain name servers, or routers). network must also provide (such as domain name servers, or routers).
This means that in addition to the existence of a configuration This means that in addition to the existence of a configuration
parameter, one must also ask themselves if it is reasonable for this parameter, one must also ask themselves if it is reasonable for this
parameter to be set by the directly attached network's parameter to be set by the directly attached network's
administrators. administrators.
Bear in mind that the client still reserves the right to ignore Note that the client still reserves the right to ignore values
values received via DHCP (for example, due to having a value manually received via DHCPv6 (for example, due to having a value manually
configured by its own operator), and that at least one main use case configured by its own operator). Bear in mind that doing so might
for DHCP is the corporate enterprise. So even if the local Net cause the client to be rejected network attachment privileges, and
Cafe's operator is not a likely source of the candidate this is one main reason for the use of DHCPv6 in corporate
configuration, there may be other DHCP servers in a client's lifetime enterprises.
which are.
3. General Principles 4. General Principles
The primary principle to follow in order to enhance an option's The primary guiding principle to follow in order to enhance an
adoptability is certainly simplification. But more specifically, to option's adoptability is simplification. More specifically, the
create the option in such a way that it should not require any new or option should be created in such a way that does not require any new
special case software to support. If old software currently deployed or special case software to support. If old software currently
and in the field can adopt the option through supplied configuration deployed and in the field can adopt the option through supplied
conveniences then it's fairly well assured that new software can configuration facilities then it's fairly certain that new software
easily formally adopt it. can easily formally adopt it.
There are at least two classes of DHCP options: A bulk class of There are at least two classes of DHCPv6 options: A bulk class of
options which are provided explicitly to carry data from one side of options which are provided explicitly to carry data from one side of
the DHCP exchange to the other (such as nameservers, domain names, or the DHCPv6 exchange to the other (such as nameservers, domain names,
time servers), and a protocol class of options which require special or time servers), and a protocol class of options which require
processing on the part of the DHCP software or are used during special processing on the part of the DHCPv6 software or are used
special processing (such as the FQDN options ([RFC4702], [RFC4704]), during special processing (such as the Fully Qualified Domain Name
DHCPv4 message type option [RFC2132], link selection options (FQDN) option [RFC4704]), and so forth; these options carry data that
([RFC3011], [RFC3527]), and so forth; these options carry data that is the result of a routine in some DHCPv6 software.
is the result of a routine in some DHCP software).
The guidelines laid out here should be understood to be relaxed for The guidelines laid out here should be applied in a relaxed manner
the protocol class of options. Wherever special-case-code is already for the protocol class of options. Wherever special case code is
required to adopt the DHCP option, it is substantially more already required to adopt the DHCPv6 option, it is substantially more
reasonable to format the option in a less generic fashion, if there reasonable to format the option in a less generic fashion, if there
are measurable benefits to doing so. are measurable benefits to doing so.
4. Reusing Other Options 5. Reusing Other Options
In DHCPv4, there are now nearly one hundred and thirty options, at
least as IETF standards, which might be used as an example. There is
also one handy document [RFC2132] containing many option definitions.
There is a tradeoff between the adoptability of previously defined
option formats, and the advantages new or specialized formats can
provide. In the balance, it is usually preferrable to reuse
previously used option formats.
However, it isn't very practical to consider the bulk of DHCP 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 | 4 | Default gateway, requested address, |
| | | subnet mask [RFC2132], addresses of |
| | | servers ([RFC2132], [RFC2241], [RFC2242], |
| | | [RFC3495], [RFC3634], [RFC4174]), as a |
| | | component in a list of routes [RFC3442]. |
| ipv6-address | 16 | DHCPv6 server unicast address [RFC3315], |
| | | addresses of servers ([RFC3319], |
| | | [RFC3646], [RFC3898], [RFC4075], |
| | | [RFC4280]). |
| 32-bit | 4 | Signed or unsigned varieties. Used for |
| integer | | 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 |
| | | used by the DHCPv4 protocol for relative |
| | | times, and times since epoch. |
| 16-bit | 2 | Client configuration parameters, such as |
| integer | | MTU, maximum datagram reassembly limits, |
| | | the DHCPv4 maximum message size |
| | | [RFC2132], or the elapsed time option |
| | | [RFC3315] in DHCPv6. |
| 8-bit integer | 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 |
| | | DHCPv4 Option Overload (as flags), DHCP |
| | | Message Type (as an enumeration) or |
| | | DHCPv6 Preference [RFC3315]. |
| NVT-ASCII | unlim | This is the kitchen sink of common |
| Text | | fragments. Common uses are for filenames |
| | | (such as TFTP paths), host or domain |
| | | names (but this should be discouraged), |
| | | or protocol features such as textual |
| | | messages such as verbose error |
| | | indicators. Since the size of this format |
| | | cannot be determined (it is not NULL |
| | | terminated), it consumes any remaining |
| | | space in the option. |
| DNS Wire | unlim | Presently used for 'domain search' lists |
| Format Domain | | in both DHCPv4 [RFC3397] and DHCPv6 |
| Name List | | [RFC3646], but also used in DHCPv6 for |
| [RFC1035] | | any host or domain name. A field |
| | | formatted this way may have a determinate |
| | | length if the number of root labels is |
| | | limited, but use of this format as being |
| | | 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 the full format cannot |
| | | be known initially, such as where there |
| | | seems to be some room for later protocol |
| | | work to expand the amount of information |
| | | carried, or where the full extent of data |
| | | carried is defined in a private |
| | | specification (such as with vendor |
| | | options). Encapsulations do not use 'PAD' |
| | | and 'END' options in DHCPv4, 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 The easiest approach to manufacturing trivially deployable DHCPv6
Options is to assemble the option out of whatever common fragments Options is to assemble the option out of whatever common fragments
fit - possibly allowing a group of fragments to repeat to fill the fit - possibly allowing a group of fragments to repeat to fill the
remaining space (if present) and so provide multiple values. Place remaining space (if present) and so provide multiple values. Place
all fixed size values at the start of the option, and any variable/ all fixed size values at the start of the option, and any variable/
indeterminate sized value at the tail end of the option. indeterminate sized value at the tail end of the option.
This estimates that implementations will be able to reuse code paths This estimates that implementations will be able to reuse code paths
designed to support the other options. designed to support the other options.
5. Avoid Conditional Formatting 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 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 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:
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 [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 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 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 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 3: Option with 16-bit integer value
Examples of use:
o Elapsed Time [RFC3315]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8-bit-integer |
+-+-+-+-+-+-+-+-+
Figure 4: Option with 8-bit integer value
Examples of use:
o DHCPv6 Preference [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 option specific. Some of
the existing DHCPv6 options use NVT-ASCII strings to encode:
filenames, host or domain names, protocol features or textual
messages such as verbose error indicators.
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 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 Format Domain Name List
This option is used to carry 'domain search' lists or any host or
domain 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DNS Wire Format Domain Name List |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Option with DNS Wire Format Domain Name List
Examples of use:
o SIP Servers Domain Name List [RFC3319]
o NIS Domain Name [RFC3898]
6. Avoid Conditional Formatting
Placing a octet at the start of the option which informs the software 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 how to process the remaining octets of the option may appear simple
to the casual observer. But the only conditional formatting methods to the casual observer. But the only conditional formatting methods
that are in widespread use today are 'protocol' class options. So that are in widespread use today are 'protocol' class options. So
conditional formatting requires new code to be written, as well as conditional formatting requires new code to be written, as well as
introduces an implementation problem; as it requires that all introduces an implementation problem; as it requires that all
speakers implement all current and future conditional formats. speakers implement all current and future conditional formats.
Conditional formatting is absolutely not recommended, except in cases Conditional formatting is not recommended, except in cases where the
where the DHCP option has already been deployed experimentally, and DHCPv6 option has already been deployed experimentally, and all but
all but one conditional format is deprecated. one conditional format is deprecated.
6. Avoid Aliasing 7. Avoid Aliasing
Options are said to be aliases of each other if they provide input to Options are said to be aliases of each other if they provide input to
the same configuration parameter. A commonly proposed example is to the same configuration parameter. A commonly proposed example is to
configure the location of some new service ("my foo server") using a 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 binary IP address, a domain name field, and a URL. This kind of
aliasing is undesirable, and is best avoided. aliasing is undesirable, and is not recommended.
In this case, where three different formats are supposed, it triples In this case, where three different formats are supposed, it more
the work of the software involved, requiring support for not merely than triples the work of the software involved, requiring support for
one format, but support to produce and digest all three. Since not merely one format, but support to produce and digest all three.
clients cannot predict what values the server will provide, they must Furthermore, code development and testing must cover all possible
request all formats...so in the case where the server is configured combinations of defined formats. Since clients cannot predict what
with all formats, DHCP option space is wasted on option contents that values the server will provide, they must request all formats... so
are redundant. in the case where the server is configured with all formats, DHCPv6
option space is wasted on option contents that are redundant.
It also becomes unclear which types of values are mandatory, and how It also becomes unclear which types of values are mandatory, and how
configuring some of the options may influence the others. For configuring some of the options may influence the others. For
example, if an operator configures the URL only, should the server example, if an operator configures the URL only, should the server
synthesize a domain name and IP address? synthesize a domain name and IP address?
A single configuration value on a host is probably presented to the A single configuration value on a host is probably presented to the
operator (or other software on the machine) in a single field or operator (or other software on the machine) in a single field or
channel. If that channel has a natural format, then any alternative channel. If that channel has a natural format, then any alternative
formats merely make more work for intervening software in providing formats merely make more work for intervening software in providing
conversions. conversions.
So the best advice is to choose the one method that best fulfills the 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 requirements, be that for simplicity (such as with an IP address and
port pair), late binding (such as with DNS), or completeness (such as port pair), late binding (such as with DNS), or completeness (such as
with a URL). with a URL).
On the specific subject of desiring to configure a value using a On the specific subject of desiring to configure a value using a FQDN
Fully Qualified Domain Name instead of a binary IP address, note that instead of a binary IP address, note that most DHCPv6 server
most DHCP server implementations will happily accept a Domain Name implementations will happily accept a Domain Name entered by the
entered by the administrator, and use DNS resolution to render binary administrator, and use DNS resolution to render binary IP addresses
IP addresses in DHCP replies to clients. Consequently, consider the in DHCPv6 replies to clients. Consequently, consider the extra
extra packet overhead incurred on the client's end to perform DNS packet overhead incurred on the client's end to perform DNS
resolution itself. The client may be operating on a battery and resolution itself. The client may be operating on a battery and
packet transmission is a non-trivial use of power, and the extra RTT 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 delays the client must endure before the service is configured are at
least two factors to consider in making a decision on format. least two factors to consider in making a decision on format.
7. Considerations for Creating New Formats 8. Suboptions in DHCPv6
If the option simply will not fit into any existing work by using
fragments, the last recourse is to create 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 is equally important to consider if the new format's
fragments might reasonably have any other uses, and if so, to create
the option with the foreknowledge that its parts may later become a
common fragment.
One specific consideration to evaluate is whether or not options of a Most options are conveyed in a DHCPv6 message directly. Although
similar format would need to have multiple or single values encoded there is no codified normative language for such options, they are
(whatever differs from the current option), and how that might be often referred to as top-level options. Many options may include
accomplished in a similar format. other options. Such inner options are often referred to as sub-
options. It should be noted that, contrary to DHCPv4, there is no
shortage of option numbers. Therefore all options share a common
option space. For example option type 1 meant different things in
DHCPv4, depending if it was located in top-level or inside of Relay
Agent Information option. There is no such ambiguity in DHCPv6.
8. The Dangers of Sub Options 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 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, therefore "sub-option"
term is typically used, regardless of the nesting level.
Some DHCP options, such as the DHCPv4 Relay Agent Information Option When defining configuration means for more complex mechanisms, it may
[RFC3046] are defined to contain a series of DHCP options, possibly be tempting to simply use sub-options. That should usually be
using code tags specific to that option (but not in some limited avoided, as it increases complexity of the parser. It is much
"protocol feature" cases in DHCPv6 [RFC3315]). These are commonly easier, faster and less error prone to parse larger number of options
referred to as Encapsulated Option Spaces or more simply, Sub on a single (top-level) scope, than parse options on several scopes.
Options. The use of sub-options should be avoided as much as possible but it
is better to use sub-options rather than conditional formatting.
Sub options seem very attractive, because they allow the encoding of It should be noted that currently there is no clear way defined for
multiple variable length fields within the single "parent" option. requesting sub-options. Most known implementations are simply using
top-level ORO for requesting both top-level options and sub-options.
However, DHCP software will only include these options on an "all or 9. Additional States Considered Harmful
nothing" basis, there is no well deployed mechanism 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, it is not advisable to group options that may not be DHCP is a protocol designed for provisioning nodes. Less experienced
requested at the same time by the same client under an encapsulated protocol designers often assume that it is easy to define an option
space. that will convey a different parameter for each node in a 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 get ready to use
per node option 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
way that all nodes are provisioned with the same set of 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 server and therefore scales
better.
Another attraction sub options present is ease of extending the It also should be noted that contrary to DHCPv4, DHCPv6 keeps several
configuration value for later, related configuration. This must be timers for renewals. Each IA_NA (addresses) and IA_PD (prefixes)
weighed against the cost associated with asking IANA to maintain the contains T1 and T2 timers that designate time after which client will
space's internally assigned option codes. Generally, the cost to initiate renewal. Those timers apply only to its own IA containers.
IANA is greater, as it is unlikely that options will be later For renewing other parameters, please use Information Refresh Time
extended. Option (defined in [RFC4242]). Introducing additional timers make
deployment unnecessarily complex. Please try to avoid it.
The use of sub-options is not a solution to aliasing problems. Sub- 10. Is DHCPv6 dynamic?
options that contain multiple configuration values that alias the
same configuration element actually makes matters worse. The only
solution to aliasing problems is to select a single option format, or
where that is literally impossible, to use multiple DHCP options. In
this way, clients may place only the options they support on their
parameter request list, in the order they support them. Later
protocol maintenance may incorporate a means to select a single DHCP
option code out of a list of aliased options, so do not concern
yourself with packet space issues arising from receiving all the
aliases.
Additionally, DHCPv4 option concatenation (Section 9) has not been DHCPv6 stands for Dynamic Host Configuration Protocol for IPv6.
defined in any DHCPv4 sub-options space. Currently there is some Contrary to its name, is many contexts it is not dynamic. While
DHCP software which does concatenate multiple DHCP options present in designing DHCPv6 options, it is worth noting that there is no
a sub-option space. There is also software that treats multiple DHCP reliable way to instantly notify clients that something has happened,
option codes present in a sub-option as individual single options. e.g. parameter value has changed. There is a RECONFIGURE mechanism,
So there is no reliably predictable default behaviour. but it has several serious drawbacks that makes its use difficult.
First, its support is optional and many client implementations do not
support it. To use reconfigure mechanism, server must use its secret
nonce. That means that provisioning server is the only one that can
initiate reconfiguration. Other servers do not know it and cannot
trigger reconfiguration. Therefore the only reliable way for clients
to refresh their configuration is to wait till T1 expires.
Because no sub-options space has yet been defined that includes the 11. Multiple provisioning domains
possibility of having more than one instance of an option of the same
code, any attempt to do so is discouraged.
9. Option Size 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 of such case is a home network with a connection to two
independent ISPs.
DHCPv4 [RFC2131] options payload space is limited, as there are a DHCPv6 was not initially designed with multiple provisioning domains.
number of unaddressed deployment problems with DHCPv4 packet sizes. Although [RFC3315] states that a client that receives more than one
The end result is that you should build your option to the assumption ADVERTISE message, may respond to one or more, such capability was
that the packet will be no larger than 576 octets. This means that never observed in any known implementations. Existing clients will
the options payload space will be 312 octets, which you will have to pick one server and will continue configuration process with that
share with other options. This space can be extended by making use server, ignoring all other servers.
of Option Overloading [RFC2132], which allows the use of the BOOTP
FILE and SNAME header fields for carrying DHCPv4 options (adding 192
octets), but these header fields will not be available for
overloading if they have been configured to carry a value.
DHCPv6 [RFC3315] is much better off. First, through its use of link- This is a generic DHCP protocol issue and should not be dealt within
local addresses, it steps aside many of the deployment problems that each option separately. This issue is better dealt with using a
plague DHCPv4, and looks a great deal more like any other UDP based protocol-level solution and fixing this problem should not be
application; oblivious to packet sizes up to 64KB. Second, RFC 3315 attempted on a per option basis.
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 much more feasible to suggest that DHCPv6 is capable of having
larger options deployed over it, and at least no common upper limit
is yet known to have been encoded by its implementors. It is
impossible to describe any fixed limit that cleanly divides those too
big from the workable.
So in either protocol, it is advantageous to prefer option formats 12. Considerations for Creating New Formats
which contain the desired information in the smallest form factor
that solves the requirements. One example is 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 if the intended
RRSET is not an address, or if the client must refresh the name more
frequently than common lease renewal periods.
When it is not possible to compress the configuration contents either If the option simply will not fit into any existing work by using
because of the simple size of the parameters, or because it is fragments, the last recourse is to create a new format to fit.
expected that very large configurations are valid, it may be
preferable to use a second stage configuration. Some examples of
this are to provide TFTP server and pathnames, or a URL, which the
client will load and process externally to the DHCP protocol.
The DHCPv4 code and length tags are each a single octet. As the When doing so, it is not enough to gauge whether or not the option
length field describes the length of the DHCP option's contents (not format will work in the context of the option presently being
including the code and length octets), any option whose contents' considered. It is equally important to consider if the new format's
length exceeds 255 octets can not be contained in a single option. fragments might reasonably have any other uses, and if so, to create
These 'long options' will simply be fragmented into multiple options the option with the foreknowledge that its parts may later become a
within the packet. DHCP software processing these fragments will common fragment.
concatenate them, in the order they appear as defined by [RFC2131],
prior to evaluating their contents. This is an important distinction
that is sometimes overlooked by authors - these multiple options are
not individually formatted to convey one unit 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 One specific consideration to evaluate is whether or not options of a
point you select as an example does not lie on a clean division of similar format would need to have multiple or single values encoded
your option contents - place it at an offset so as to reinforce that (whatever differs from the current option), and how that might be
these values must be concatenated rather than processed individually. accomplished in a similar format.
DHCPv4 option fragments are a basic protocol feature, so there 13. Option Size
usually is no reason to mention this feature in new option
definitions, and no requirement for every option definition to be
presented as a series of fragments. It is only recommended to
reinforce the existence of DHCP option fragmentation when the
potential for large options is likely. In this case, try to choose a
large example data value.
Note that option fragmentation is also a very common side-effect of DHCPv6 [RFC3315] allows for packet sizes up to 64KB. First, through
running out of options space, and moving to overloaded FILE or SNAME its use of link-local addresses, it steps aside many of the
fields. Although the option may be considerably shorter than 255 deployment problems that plague DHCPv4, and is actually an UDP over
octets, if it does not fit in the remaining space then software may IPv6 based protocol (compared to DHCPv4, which is mostly UDP over
consume all remaining options space with one option fragment, and IPv4 protocol, but with layer 2 hacks). Second, RFC 3315 explicitly
place the remainder in an overloaded field. 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 DHCPv6 is capable of having larger options
deployed over it, and at least no common upper limit is yet known to
have been encoded by its implementors. It is impossible to describe
any fixed limit that cleanly divides those too big from the workable.
Primarily it is important to remember that DHCPv4 differs from DHCPv6 It is advantageous to prefer option formats which contain the desired
on this point: DHCPv4 can only convey one option of a given option information in the smallest form factor that satisfies the
code at any time - additional options (or possibly sub options, which requirements.
do not have concisely defined semantics) of the same code will be
concatenated together and processed at once. DHCPv6 does allow
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); it is better to define your option as
an array if it is possible.
So remember that it is out of the question to define a case for DHCPv6 does allow for multiple instances of a given option, and they
multiple instances of your option in DHCPv4, and it is recommended to are treated as distinct values following the defined format, however
clarify (with normative language) if any DHCPv6 option may appear this feature is generally preferred to be restricted to protocol
once or multiple times. class features (such as the IA_* series of options). In such cases,
it is better to define an option as an array if it is possible. It
is recommended to clarify (with normative language) whether a given
DHCPv6 option may appear once or multiple times.
10. Clients Request their Options 14. Clients Request their Options
The DHCPv4 Parameter Request List [RFC2132], and the DHCPv6 Option The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315], is an option
Request Option (OPTION_ORO) [RFC3315], are both options that serve that serves two purposes - to inform the server what options the
two purposes - to inform the server what options the client supports client supports and is willing to consume.
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).
It doesn't make sense for some options to appear on this Parameter It doesn't make sense for some options to appear on this Option
Request List, such as those formed by elements of the protocol's Request Option, such as those formed by elements of the protocol's
internal workings, or are formed on either end by DHCP-level software internal workings, or are formed on either end by DHCPv6-level
engaged in some exchange of information. When in any form of doubt, software engaged in some exchange of information. When in doubt, it
assume that any new option must be present on the relevant option is prudent to assume that any new option must be present on the
request list if the client desires it. relevant option request list if the client desires to receive it.
It is a frequent mistake of option draft authors, then, to create It is a frequent mistake of option draft authors, then, to create
text that implies that a server will simply provide the new option, text that implies that a server will simply provide the new option,
and clients will digest it. Generally, it's best to also specify and clients will digest it. Generally, it's best to also specify
that clients MUST place the new option code on the relevant list that clients MUST place the new option code on the relevant list
option, clients MAY include the new option in their packets to option, clients MAY include the new option in their packets to
servers with hints as to values they desire, and servers MAY respond servers with hints as to values they desire, and servers MAY respond
with the option contents (if they have been so configured). with the option contents (if they have been so configured).
Under only the most dire of circumstances should a new option Creators of DHCPv6 options MUST NOT require special ordering of
definition require special ordering of options either in the relevant options either in the relevant request option, or in the order of
request option, or in the order of options within the packet. options within the packet. Although it is reasonable to expect that
Although the request option does imply a priority, which might be options will be processed in the order they appear in ORO, server
processed in order, a server may shuffle options around in a DHCPv4 software is not required to sort DHCPv6 options into the same order
packet in order to make them fit, and server software may sort DHCPv6 in reply messages. It should be noted that any requirement regarding
options into strange orders. There is not one universal approach. option ordering will break down most existing implementations, as
"order is not important" was one of the design priciples of DHCPv6
11. Security Considerations 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.
DHCP does have an Authentication mechanism ([RFC3118], [RFC3315], 15. Security Considerations
[RFC4030]), where it is possible for DHCP software to discriminate
between authentic endpoints and men in the middle.
However, at this date the mechanism is poorly deployed. It also does DHCPv6 does have an Authentication mechanism ([RFC3315]) that makes
not provide end-to-end encryption. it possible for 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, as of now, the mechanism is not widely
deployed. It also does not provide end-to-end encryption.
So, while creating a new option, bear in mind that DHCP packet So, while creating a new option, it is prudent to assume that the
contents are always transmitted in the clear, and actual production DHCPv6 packet contents are always transmitted in the clear, and
use of the software will probably be vulnerable at least to man-in- actual production use of the software will probably be vulnerable at
the-middle attacks from within the network, even where the network least to man-in-the-middle attacks from within the network, even
itself is protected from external attacks by firewalls. In where the network itself is protected from external attacks by
particular, some DHCP message exchanges are transmitted to broadcast firewalls. In particular, some DHCPv6 message exchanges are
or multicast addresses that are likely broadcast anyway. transmitted to multicast addresses that are likely broadcast anyway.
If an option is of a specific fixed length, it is useful to remind 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 the implementer of the option data's full length. This is easily
done by declaring the specific value of the 'length' tag of the done by declaring the specific value of the 'length' tag of the
option. This helps to gently remind implementers to validate option option. This helps to gently remind implementers to validate option
length before digesting them into likewise fixed length regions of length before digesting them into likewise fixed length regions of
memory or stack. memory or stack.
If an option may be of variable size (such as having indeterminate If an option may be of variable size (such as having indeterminate
length fields, such as domain names or text strings), it is advisable length fields, such as domain names or text strings), it is advisable
to explicitly remind the implementor to be aware of the potential for to explicitly remind the implementor to be aware of the potential for
long options. Either define a reasonable upper limit (and suggest long options. Either define a reasonable upper limit (and suggest
validating it), or explicitly remind the implementor that an option validating it), or explicitly remind the implementor that an option
may be exceptionally long (to be prepared to handle errors rather may be exceptionally long (to be prepared to handle errors rather
than truncate values). than truncate values).
For some option contents, "insane values" may be used to breach 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 security. An IP address field might be made to carry a loopback
address, or local broadcast address, and depending on the protocol address, or local broadcast address, and depending on the protocol
this may lead to undesirable results. A domain name field may be this may lead to undesirable results. A domain name field may be
filled with contrived contents that exceed the limitations placed filled with contrived contents that exceed the limitations placed
upon domain name formatting...as this value is possibly delivered to upon domain name formatting... as this value is possibly delivered to
"internal configuration" records of the system, it may be trusted, "internal configuration" records of the system, it may be implicitly
rather than validated. trusted without being validated.
So it behooves an option's definition to contain any validation So it behooves an option's definition to contain any validation
measures as can reasonably be made. measures as can reasonably be made.
12. IANA Considerations 16. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
13. Informative References 17. References
17.1. Informative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. 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
RFC 2131, March 1997. Requirement Levels", BCP 14, RFC 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., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol Protocol (DHCPv6) Options for Session Initiation Protocol
(SIP) Servers", RFC 3319, July 2003. (SIP) Servers", RFC 3319, July 2003.
[RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Protocol (DHCP) Domain Search Option", RFC 3397, Host Configuration Protocol (DHCP) version 6", RFC 3633,
November 2002.
[RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless
Static Route Option 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", RFC 3634,
December 2003. December 2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003. December 2003.
[RFC3898] Kalusivalingam, V., "Network Information Service (NIS) [RFC3898] Kalusivalingam, V., "Network Information Service (NIS)
Configuration Options for Dynamic Host Configuration Configuration Options for Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004. Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
[RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC 3972, March 2005.
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
Option", RFC 4030, March 2005.
[RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
Configuration Option for DHCPv6", RFC 4075, May 2005. Configuration Option for DHCPv6", RFC 4075, May 2005.
[RFC4174] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Host Configuration Protocol (DHCP) Option for the Internet Time Option for Dynamic Host Configuration Protocol for
Storage Name Service", RFC 4174, September 2005. IPv6 (DHCPv6)", RFC 4242, November 2005.
[RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host [RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host
Configuration Protocol (DHCP) Options for Broadcast and Configuration Protocol (DHCP) Options for Broadcast and
Multicast Control Servers", RFC 4280, November 2005. 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 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, October 2006. Option", RFC 4704, October 2006.
[RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP", [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
RFC 4833, April 2007. Options for Network Boot", RFC 5970, September 2010.
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
distributions.
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
functions:
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
applications.
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
2.
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 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
options described above (Table 1) each have an Atom associated with "Prefix Exclude Option for DHCPv6-based Prefix
it. There are special use Atoms, such as one to repeat the previous Delegation", RFC 6603, May 2012.
Atoms indefinitely (for example, for options with multiple IPv4
addresses one after the other), and one which makes the previous Atom
optional.
As the software encounters a format string, it processes each Atom 17.2. Informative References
individually to read from configuration into wire format, and also to
validate 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 [I-D.ietf-dhc-secure-dhcpv6]
in a table of option definitions, or are compiled at runtime through Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs",
configuration syntax generated by the operator. draft-ietf-dhc-secure-dhcpv6-06 (work in progress),
March 2012.
option <space>.<option> code <number> = <definition>; [I-D.ietf-softwire-4rd]
Despres, R., Penno, R., Lee, Y., Chen, G., and S. Jiang,
"IPv4 Residual Deployment via IPv6 - a unified Stateless
Solution (4rd)", draft-ietf-softwire-4rd-00 (work in
progress), May 2012.
The <space> refers to the option space, which may be the DHCPv4 [I-D.mdt-softwire-map-dhcp-option]
option space, the DHCPv6 option space, or any suboption space such as Mrugalski, T., Boucadair, M., Deng, X., Troan, O., and C.
the DHCPv4 Relay Agent Information suboptions or similar. Bao, "DHCPv6 Options for Mapping of Address and Port",
draft-mdt-softwire-map-dhcp-option-02 (work in progress),
January 2012.
The <option> refers to the option's symbolic name within that space. Authors' Addresses
The code <number> refers to the binary code assigned to this option. David W. Hankins
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
USA
The <definition> is a complex statement that brings together DHCP Email: dhankins@google.com
Atoms, many of which are the aforementioned common formats, that Tomasz Mrugalski
compose this option. Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
USA
Below is a sample configuration for two options, whose wire formats Phone: +1 650 423 1345
are defined in [RFC2132]. The Path MTU Plateau Table option, and the Email: tomasz.mrugalski@gmail.com
Static Routes option.
option dhcp.path-mtu-plateau-table code 25 = Marcin Siodelski
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 Phone:
be carried in the options may be configured. These acts are Email: msiodelski@gmail.com
distinct; the previous configuration only prepares the parser system
to accept the configuration below. The below configuration actually
supplies a value to be transmitted on the wire, relying on the above
format definition.
option dhcp.path-mtu-plataeu-table 4352, 1500, 576; Sheng Jiang
option dhcp.static-routes 10.10.10.10 10.10.10.9, Huawei Technologies Co., Ltd
10.10.10.11 10.10.10.9; Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
P.R. China
Author's Address Email: jiangsheng@huawei.com
David W. Hankins Suresh Krishnan
Google, Inc. Ericsson
1600 Amphitheatre Parkway 8400 Blvd Decarie
Mountain View, CA 94043 Town of Mount Royal, Quebec
USA Canada
Email: dhankins@google.com Email: suresh.krishnan@ericsson.com
 End of changes. 82 change blocks. 
550 lines changed or deleted 495 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/