draft-ietf-dhc-option-guidelines-08.txt   draft-ietf-dhc-option-guidelines-09.txt 
Dynamic Host Configuration Working D. Hankins Dynamic Host Configuration Working D. Hankins
Group Google Group Google
Internet-Draft T. Mrugalski Internet-Draft T. Mrugalski
Intended status: Informational M. Siodelski Updates: 3315 (if approved) M. Siodelski
Expires: December 21, 2012 ISC Intended status: Standards Track ISC
S. Jiang Expires: June 23, 2013 S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
S. Krishnan S. Krishnan
Ericsson Ericsson
June 19, 2012 December 20, 2012
Guidelines for Creating New DHCPv6 Options Guidelines for Creating New DHCPv6 Options
draft-ietf-dhc-option-guidelines-08 draft-ietf-dhc-option-guidelines-09
Abstract Abstract
This document provides guidance to prospective DHCPv6 Option This document provides guidance to prospective DHCPv6 Option
developers to help them creating option formats that are easily developers to help them creating option formats that are easily
adoptable by existing DHCPv6 software. adoptable by existing DHCPv6 software. This document updates
RFC3315.
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 December 21, 2012. This Internet-Draft will expire on June 23, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 2, line 17 skipping to change at page 2, line 18
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . . 4 3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . . 4
4. General Principles . . . . . . . . . . . . . . . . . . . . . . 4 4. General Principles . . . . . . . . . . . . . . . . . . . . . . 4
5. Reusing Other Options . . . . . . . . . . . . . . . . . . . . 5 5. Reusing Other Options . . . . . . . . . . . . . . . . . . . . 5
5.1. Option with IPv6 addresses . . . . . . . . . . . . . . . . 5 5.1. Option with IPv6 addresses . . . . . . . . . . . . . . . . 5
5.2. Option with 32-bit integer value . . . . . . . . . . . . . 6 5.2. Option with a single flag (boolean) . . . . . . . . . . . 6
5.3. Option with 16-bit integer value . . . . . . . . . . . . . 7 5.3. Option with IPv6 prefix . . . . . . . . . . . . . . . . . 7
5.4. Option with 8-bit integer value . . . . . . . . . . . . . 7 5.4. Option with 32-bit integer value . . . . . . . . . . . . . 8
5.5. Option with variable length data . . . . . . . . . . . . . 7 5.5. Option with 16-bit integer value . . . . . . . . . . . . . 8
5.6. Option with DNS Wire Format Domain Name List . . . . . . . 8 5.6. Option with 8-bit integer value . . . . . . . . . . . . . 8
6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . . 9 5.7. Option with variable length data . . . . . . . . . . . . . 9
7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 9 5.8. Option with DNS Wire Format Domain Name List . . . . . . . 10
8. Suboptions in DHCPv6 . . . . . . . . . . . . . . . . . . . . . 10 5.9. Option with IPv6 Prefix . . . . . . . . . . . . . . . . . 10
9. Additional States Considered Harmful . . . . . . . . . . . . . 11 6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . . 11
10. Is DHCPv6 dynamic? . . . . . . . . . . . . . . . . . . . . . . 11 7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 11
11. Multiple provisioning domains . . . . . . . . . . . . . . . . 11 8. Choosing between FQDN and address . . . . . . . . . . . . . . 12
12. Considerations for Creating New Formats . . . . . . . . . . . 12 9. Suboptions in DHCPv6 . . . . . . . . . . . . . . . . . . . . . 14
13. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Additional States Considered Harmful . . . . . . . . . . . . . 14
14. Clients Request their Options . . . . . . . . . . . . . . . . 13 11. Is DHCPv6 dynamic? . . . . . . . . . . . . . . . . . . . . . . 15
15. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12. Multiple provisioning domains . . . . . . . . . . . . . . . . 15
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 13. Considerations for Creating New Formats . . . . . . . . . . . 16
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 14. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 16
17.1. Informative References . . . . . . . . . . . . . . . . . . 15 15. Clients Request their Options . . . . . . . . . . . . . . . . 16
17.2. Informative References . . . . . . . . . . . . . . . . . . 16 16. Transition Technologies . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 17. Security Considerations . . . . . . . . . . . . . . . . . . . 18
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
20. Informative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Requirements Language 1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction 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.
DHCPv6 [RFC3315] software implementors are not merely faced with the DHCPv6 [RFC3315] software implementors are not merely faced with the
task of handling a given option's format on the wire. The option 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 must fit into every stage of the system's process, starting with the
user interface used to enter the configuration upto the machine user interface used to enter the configuration up to the machine
interfaces where configuration is ultimately consumed. interfaces where configuration is ultimately consumed.
Another frequently overlooked aspect of rapid adoption is whether the Another frequently overlooked aspect of rapid adoption is whether the
option requires operators to be intimately familiar with the option's option requires operators to be intimately familiar with the option's
internal format in order to use it? Most DHCPv6 software provides a internal format in order to use it? Most DHCPv6 software provides a
facility for handling unknown options at the time of publication. facility for handling unknown options at the time of publication.
The handling of such options usually needs to be manually configured The handling of such options usually needs to be manually configured
by the operator. But if doing so requires extensive reading (more by the operator. But if doing so requires extensive reading (more
than can be covered in a simple FAQ for example), it inhibits than can be covered in a simple FAQ for example), it inhibits
adoption. adoption.
skipping to change at page 5, line 35 skipping to change at page 5, line 35
However, it isn't very practical to consider the bulk of DHCPv6 However, it isn't very practical to consider the bulk of DHCPv6
options already allocated, and consider which of those solve a options already allocated, and consider which of those solve a
similar problem. So, the following list of common option format similar problem. So, the following list of common option format
fragments is provided as a shorthand. Please note that it is not fragments is provided as a shorthand. Please note that it is not
complete in terms of exampling every option format ever devised...it 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 is only a list of option format fragments which are used in two or
more options. more options.
5.1. Option with IPv6 addresses 5.1. Option with IPv6 addresses
This option format is used to carry one or many 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
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 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 | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| ipv6-address | | ipv6-address |
| | | |
| | | |
skipping to change at page 6, line 40 skipping to change at page 6, line 40
o DNS Recursive Name Server [RFC3646] o DNS Recursive Name Server [RFC3646]
o NIS Servers [RFC3898] o NIS Servers [RFC3898]
o SNTP Servers [RFC4075] o SNTP Servers [RFC4075]
o Broadcast and Multicast Service Controller IPv6 Address Option for o Broadcast and Multicast Service Controller IPv6 Address Option for
DHCPv6 [RFC4280] DHCPv6 [RFC4280]
5.2. Option with 32-bit integer value 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 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 IPv6 prefix. The information
that should be delivered to the user is a 128-bit IPv6 prefix
together with a prefix length that takes values from 0 to 128. Using
the simplest approach, the option would convey that information as
is. However, in many cases /64 or shorter prefixes are used. That
means that remaining 128 - prefix length bits are zeros. That means
that in typical case case of /64 prefixes the option would contains
at least 8 bytes of useless zeros. That should be avoided. For that
reason the recommended format for storing prefixes is 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_MAP_DMR | 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
it one octet long and specifies prefix length of the IPv6 prefix
expressed in bits. Typically allowed values are 0 to 128.
ipv6-prefix field is a variable length field that specifies the IPv6
prefix. This field is padded with zeros up to the nearest octet
boundary when prefix6-len is not divisible by 8.
Examples of use:
o Default Mapping Rule [I-D.ietf-softwire-map-dhcp]
It should be noted that Prefix Delegation mechanism used in [RFC3633]
uses constant length prefixes. 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 This option format can be used to carry 32 bit-signed or unsigned
integer value: integer value:
0 1 2 3 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 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 | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit-integer | | 32-bit-integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Option with 32-bit-integer value Figure 4: Option with 32-bit-integer value
Examples of use: Examples of use:
o Information Refresh Time [RFC4242] o Information Refresh Time [RFC4242]
5.3. Option with 16-bit integer value 5.5. Option with 16-bit integer value
This option format can be used to carry 16-bit signed or unsigned This option format can be used to carry 16-bit signed or unsigned
integer values: integer values:
0 1 2 3 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 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 | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-bit-integer | | 16-bit-integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Option with 16-bit integer value Figure 5: Option with 16-bit integer value
Examples of use: Examples of use:
o Elapsed Time [RFC3315] o Elapsed Time [RFC3315]
5.4. Option with 8-bit integer value 5.6. Option with 8-bit integer value
This option format can be used to carry 8-bit integer values: This option format can be used to carry 8-bit integer values:
0 1 2 3 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 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 | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8-bit-integer | | 8-bit-integer |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 4: Option with 8-bit integer value Figure 6: Option with 8-bit integer value
Examples of use: Examples of use:
o DHCPv6 Preference [RFC3315] o DHCPv6 Preference [RFC3315]
5.5. Option with variable length data 5.7. Option with variable length data
This option can be used to carry variable length data of any kind. This option can be used to carry variable length data of any kind.
Internal representation of carried data is option specific. Some of Internal representation of carried data is option specific. Some of
the existing DHCPv6 options use NVT-ASCII strings to encode: the existing DHCPv6 options use NVT-ASCII strings to encode:
filenames, host or domain names, protocol features or textual filenames, host or domain names, protocol features or textual
messages such as verbose error indicators. messages such as verbose error indicators.
This option format provides a lot of flexibility to pass data of This option format provides a lot of flexibility to pass data of
almost any kind. Though, whenever possible it is highly recommended almost any kind. Though, whenever possible it is highly recommended
to use more specialized options, with field types better matching to use more specialized options, with field types better matching
skipping to change at page 8, line 17 skipping to change at page 9, line 41
0 1 2 3 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 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 | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. variable length data . . variable length data .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Option with variale length data Figure 7: Option with variale length data
Examples of use: Examples of use:
o Client Identifier [RFC3315] o Client Identifier [RFC3315]
o Server Identifier [RFC3315] o Server Identifier [RFC3315]
o Boot File URL [RFC5970] o Boot File URL [RFC5970]
5.6. Option with DNS Wire Format Domain Name List 5.8. Option with DNS Wire Format Domain Name List
This option is used to carry 'domain search' lists or any host or This option is used to carry 'domain search' lists or any host or
domain name: domain name:
0 1 2 3 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 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-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DNS Wire Format Domain Name List | | DNS Wire Format Domain Name List |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Option with DNS Wire Format Domain Name List Figure 8: Option with DNS Wire Format Domain Name List
Examples of use: Examples of use:
o SIP Servers Domain Name List [RFC3319] o SIP Servers Domain Name List [RFC3319] (many domains)
o NIS Domain Name [RFC3898] 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)
5.9. Option with IPv6 Prefix
Some options need to convey IPv6 prefix. Such a prefix includes the
prefix itself and a prefix length. The simple approach would be to
define a 128 bit field denoting a prefix, followed by a 8 bit field
that specifies prefix length. This approach was used in
OPTION_IAPREFIX, defined in [RFC3633]. That approach is no longer
recommended and should not be used anymore.
In many cases configured prefix lengths are /64 or even shorter.
That means that every option conveys many zeroes bits that are
useless. For example for /48 there are 10 bytes of useless data.
This waste is mulitpled by the number of option instances in a
message. Therefore a different approach should be used. Prefixes
should be conveyed as 8 bit prefix length field that is followed by
variable length prefix.
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 9: Option with IPv6 Prefix
The following description of the fields can be included in the draft:
o prefix6-len: 8 bits long field expressing the bit mask length of
the IPv6 prefix specified in the ipv6-prefix field.
o ipv6-prefix: a variable length field that specifies the IPv6
prefix for (explain purpose of the prefix). The field is padded
with zeros up to the nearest octet boundary when prefix6-len is
not divisible by 8.
It should be pointed out that similar optimization does not provide
useful savings in case of IPv4 prefixes. IPv4 prefixes should be
sent as a 32 bits fields.
6. Avoid Conditional Formatting 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.
skipping to change at page 10, line 5 skipping to change at page 12, line 32
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).
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
as a help to make an informed decision in that regard.
On the specific subject of desiring to configure a value using a FQDN On the specific subject of desiring to configure a value using a FQDN
instead of a binary IP address, note that most DHCPv6 server instead of a binary IP address, note that most DHCPv6 server
implementations will happily accept a Domain Name entered by the implementations will happily accept a Domain Name entered by the
administrator, and use DNS resolution to render binary IP addresses administrator, and use DNS resolution to render binary IP addresses
in DHCPv6 replies to clients. Consequently, consider the extra in DHCPv6 replies to clients. Consequently, consider the 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.
8. Suboptions in DHCPv6 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 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 does require a resolution into an actual address. This implies
number of questions that should be answered. First is when should
the resolution be taken. There are couple 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 number of additional failure modes and issues that
should be dealt with:
The client must 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 that the server will return FQDN option, but not the DNS
Servers option. There should be a brief discussion about it;
The DNS may not be reachable;
DNS may be available, but may not have appropriate information
(e.g. no AAAA records for specified FQDN)
Address family must be specified (A, AAAA or any);
What should the client do if there are multiple records available
(use only the first one, use all, use one and switch to the second
if the first fails for whatever reason, etc.);
Multi-homed devices may be connected to different administrative
domains with each domain providing a different information in DNS
(e.g. an enterprise network exposing private domains). Client may
send DNS queries to a different DNS server;
It should be mentioned if Internationalized Domain Names are
allowed. If they are, what kind of DNS option encoding should be
specified.
9. Suboptions in DHCPv6
Most options are conveyed in a DHCPv6 message directly. Although Most options are conveyed in a DHCPv6 message directly. Although
there is no codified normative language for such options, they are there is no codified normative language for such options, they are
often referred to as top-level options. Many options may include often referred to as top-level options. Many options may include
other options. Such inner options are often referred to as sub- other options. Such inner options are often referred to as sub-
options. It should be noted that, contrary to DHCPv4, there is no options. It should be noted that, contrary to DHCPv4, there is no
shortage of option numbers. Therefore all options share a common shortage of option numbers. Therefore all options share a common
option space. For example option type 1 meant different things in option space. For example option type 1 meant different things in
DHCPv4, depending if it was located in top-level or inside of Relay DHCPv4, depending if it was located in top-level or inside of Relay
Agent Information option. There is no such ambiguity in DHCPv6. Agent Information option. There is no such ambiguity in DHCPv6 (with
the exception of [RFC5908]).
Such encapsulation mechanism is not limited to one level. There is Such encapsulation mechanism is not limited to one level. There is
at least one defined option that is encapsulated twice: Identity at least one defined option that is encapsulated twice: Identity
Association for Prefix Delegation (IA_PD, defined in [RFC3633], Association for Prefix Delegation (IA_PD, defined in [RFC3633],
section 9) conveys IA Prefix (IAPREFIX, defined in [RFC3633], section section 9) conveys IA Prefix (IAPREFIX, defined in [RFC3633], section
10). Such delegated prefix may contain an excluded prefix range that 10). Such delegated prefix may contain an excluded prefix range that
is represented by PD_EXCLUDE option that is conveyed as sub-option is represented by PD_EXCLUDE option that is conveyed as sub-option
inside IAPREFIX (PD_EXCLUDE, defined in [RFC6603]). It seems awkward inside IAPREFIX (PD_EXCLUDE, defined in [RFC6603]). It seems awkward
to refer to such options as sub-sub-option, therefore "sub-option" to refer to such options as sub-sub-option, therefore "sub-option"
term is typically used, regardless of the nesting level. term is typically used, regardless of the nesting level.
skipping to change at page 11, line 5 skipping to change at page 14, line 40
avoided, as it increases complexity of the parser. It is much avoided, as it increases complexity of the parser. It is much
easier, faster and less error prone to parse larger number of options easier, faster and less error prone to parse larger number of options
on a single (top-level) scope, than parse options on several scopes. on a single (top-level) scope, than parse options on several scopes.
The use of sub-options should be avoided as much as possible but it The use of sub-options should be avoided as much as possible but it
is better to use sub-options rather than conditional formatting. is better to use sub-options rather than conditional formatting.
It should be noted that currently there is no clear way defined for It should be noted that currently there is no clear way defined for
requesting sub-options. Most known implementations are simply using requesting sub-options. Most known implementations are simply using
top-level ORO for requesting both top-level options and sub-options. top-level ORO for requesting both top-level options and sub-options.
9. Additional States Considered Harmful 10. Additional States Considered Harmful
DHCP is a protocol designed for provisioning nodes. Less experienced DHCP is a protocol designed for provisioning nodes. Less experienced
protocol designers often assume that it is easy to define an option protocol designers often assume that it is easy to define an option
that will convey a different parameter for each node in a network. that will convey a different parameter for each node in a network.
Such problems arose during designs of MAP Such problems arose during designs of MAP
[I-D.mdt-softwire-map-dhcp-option] and 4rd [I-D.ietf-softwire-4rd]. [I-D.ietf-softwire-map-dhcp] and 4rd [I-D.ietf-softwire-4rd]. While
While it would be easier for provisioned nodes to get ready to use it would be easier for provisioned nodes to get ready to use per node
per node option values, such requirement puts exceedingly large loads option values, such requirement puts exceedingly large loads on the
on the server side. Alternatives should be considered, if possible. server side. Alternatives should be considered, if possible. As an
As an example, [I-D.mdt-softwire-map-dhcp-option] was designed in a example, [I-D.ietf-softwire-map-dhcp] was designed in a way that all
way that all nodes are provisioned with the same set of MAP options nodes are provisioned with the same set of MAP options and each
and each provisioned node uses its unique address and delegated provisioned node uses its unique address and delegated prefix to
prefix to generate node-specific information. Such solution does not generate node-specific information. Such solution does not introduce
introduce any additional state for the server and therefore scales any additional state for the server and therefore scales better.
better.
It also should be noted that contrary to DHCPv4, DHCPv6 keeps several It also should be noted that contrary to DHCPv4, DHCPv6 keeps several
timers for renewals. Each IA_NA (addresses) and IA_PD (prefixes) timers for renewals. Each IA_NA (addresses) and IA_PD (prefixes)
contains T1 and T2 timers that designate time after which client will contains T1 and T2 timers that designate time after which client will
initiate renewal. Those timers apply only to its own IA containers. initiate renewal. Those timers apply only to its own IA containers.
For renewing other parameters, please use Information Refresh Time For renewing other parameters, please use Information Refresh Time
Option (defined in [RFC4242]). Introducing additional timers make Option (defined in [RFC4242]). Introducing additional timers make
deployment unnecessarily complex. Please try to avoid it. deployment unnecessarily complex. Please try to avoid it.
10. Is DHCPv6 dynamic? 11. Is DHCPv6 dynamic?
DHCPv6 stands for Dynamic Host Configuration Protocol for IPv6. DHCPv6 stands for Dynamic Host Configuration Protocol for IPv6.
Contrary to its name, is many contexts it is not dynamic. While Contrary to its name, is many contexts it is not dynamic. While
designing DHCPv6 options, it is worth noting that there is no designing DHCPv6 options, it is worth noting that there is no
reliable way to instantly notify clients that something has happened, reliable way to instantly notify clients that something has happened,
e.g. parameter value has changed. There is a RECONFIGURE mechanism, e.g. parameter value has changed. There is a RECONFIGURE mechanism,
but it has several serious drawbacks that makes its use difficult. but it has several serious drawbacks that makes its use difficult.
First, its support is optional and many client implementations do not First, its support is optional and many client implementations do not
support it. To use reconfigure mechanism, server must use its secret support it. To use reconfigure mechanism, server must use its secret
nonce. That means that provisioning server is the only one that can nonce. That means that provisioning server is the only one that can
initiate reconfiguration. Other servers do not know it and cannot initiate reconfiguration. Other servers do not know it and cannot
trigger reconfiguration. Therefore the only reliable way for clients trigger reconfiguration. Therefore the only reliable way for clients
to refresh their configuration is to wait till T1 expires. to refresh their configuration is to wait till T1 expires.
11. Multiple provisioning domains 12. Multiple provisioning domains
In some cases there could be more than one DHCPv6 server on a link, In some cases there could be more than one DHCPv6 server on a link,
with each provisioning a different set of parameters. One notable with each provisioning a different set of parameters. One notable
example of such case is a home network with a connection to two example of such case is a home network with a connection to two
independent ISPs. independent ISPs.
DHCPv6 was not initially designed with multiple provisioning domains. DHCPv6 was not initially designed with multiple provisioning domains.
Although [RFC3315] states that a client that receives more than one Although [RFC3315] states that a client that receives more than one
ADVERTISE message, may respond to one or more, such capability was ADVERTISE message, may respond to one or more, such capability was
never observed in any known implementations. Existing clients will never observed in any known implementations. Existing clients will
pick one server and will continue configuration process with that pick one server and will continue configuration process with that
server, ignoring all other servers. server, ignoring all other servers.
This is a generic DHCP protocol issue and should not be dealt within This is a generic DHCP protocol issue and should not be dealt within
each option separately. This issue is better dealt with using a each option separately. This issue is better dealt with using a
protocol-level solution and fixing this problem should not be protocol-level solution and fixing this problem should not be
attempted on a per option basis. attempted on a per option basis.
12. Considerations for Creating New Formats 13. Considerations for Creating New Formats
If the option simply will not fit into any existing work by using 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. 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 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 format will work in the context of the option presently being
considered. It is equally important to consider if the new format's considered. It is equally important to consider if the new format's
fragments might reasonably have any other uses, and if so, to create fragments might reasonably have any other uses, and if so, to create
the option with the foreknowledge that its parts may later become a the option with the foreknowledge that its parts may later become a
common fragment. common fragment.
One specific consideration to evaluate is whether or not options of a One specific consideration to evaluate is whether or not options of a
similar format would need to have multiple or single values encoded similar format would need to have multiple or single values encoded
(whatever differs from the current option), and how that might be (whatever differs from the current option), and how that might be
accomplished in a similar format. accomplished in a similar format.
13. Option Size 14. Option Size
DHCPv6 [RFC3315] allows for packet sizes up to 64KB. First, through DHCPv6 [RFC3315] allows for packet sizes up to 64KB. First, through
its use of link-local addresses, it steps aside many of the its use of link-local addresses, it steps aside many of the
deployment problems that plague DHCPv4, and is actually an UDP over deployment problems that plague DHCPv4, and is actually an UDP over
IPv6 based protocol (compared to DHCPv4, which is mostly UDP over IPv6 based protocol (compared to DHCPv4, which is mostly UDP over
IPv4 protocol, but with layer 2 hacks). Second, RFC 3315 explicitly IPv4 protocol, but with layer 2 hacks). Second, RFC 3315 explicitly
refers readers to RFC 2460 Section 5, which describes an MTU of 1280 refers readers to RFC 2460 Section 5, which describes an MTU of 1280
octets and a minimum fragment reassembly of 1500 octets. It's octets and a minimum fragment reassembly of 1500 octets. It's
feasible to suggest that DHCPv6 is capable of having larger options 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 deployed over it, and at least no common upper limit is yet known to
skipping to change at page 13, line 13 skipping to change at page 16, line 48
requirements. requirements.
DHCPv6 does allow for multiple instances of a given option, and they DHCPv6 does allow for multiple instances of a given option, and they
are treated as distinct values following the defined format, however are treated as distinct values following the defined format, however
this feature is generally preferred to be restricted to protocol this feature is generally preferred to be restricted to protocol
class features (such as the IA_* series of options). In such cases, 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 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 is recommended to clarify (with normative language) whether a given
DHCPv6 option may appear once or multiple times. DHCPv6 option may appear once or multiple times.
14. Clients Request their Options 15. Clients Request their Options
The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315], is an option The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315], is an option
that serves two purposes - to inform the server what options the that serves two purposes - to inform the server what options the
client supports and is willing to consume. client supports and is willing to consume.
It doesn't make sense for some options to appear on this Option It doesn't make sense for some options to appear on this Option
Request Option, 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 DHCPv6-level internal workings, or are formed on either end by DHCPv6-level
software engaged in some exchange of information. When in doubt, it software engaged in some exchange of information. When in doubt, it
is prudent to assume that any new option must be present on the is prudent to assume that any new option must be present on the
relevant option request list if the client desires to receive 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 Option Request
option, clients MAY include the new option in their packets to Option list, 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 values they desire, and server MAY include the
with the option contents (if they have been so configured). option when the client requested it (and the server has been so
configured).
Example: 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 MAY include option
foo when the client requested it (and the server has been so
configured).
Creators of DHCPv6 options MUST NOT require special ordering of Creators of DHCPv6 options MUST NOT require special ordering of
options either in the relevant request option, or in the order 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 within the packet. Although it is reasonable to expect that
options will be processed in the order they appear in ORO, server options will be processed in the order they appear in ORO, server
software is not required to sort DHCPv6 options into the same order software is not required to sort DHCPv6 options into the same order
in reply messages. It should be noted that any requirement regarding in reply messages. It should be noted that any requirement regarding
option ordering will break down most existing implementations, as option ordering will break down most existing implementations, as
"order is not important" was one of the design priciples of DHCPv6 "order is not important" was one of the design priciples of DHCPv6
and many implementations follow it. For example, there are existing and many implementations follow it. For example, there are existing
implementations that use hash maps for storing options, so forcing implementations that use hash maps for storing options, so forcing
any particular order is not feasible without great deal of work. If 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- options must be processed in any specific order (e.g. due to inter-
dependency), use of option encapsulation should be considered. dependency), use of option encapsulation should be considered.
15. Security Considerations 16. Transition Technologies
Transition from IPv4 to IPv6 is progressing, albeit at somewhat
disappointing pace. 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. Security Considerations
DHCPv6 does have an Authentication mechanism ([RFC3315]) that makes DHCPv6 does have an Authentication mechanism ([RFC3315]) that makes
it possible for DHCPv6 software to discriminate between authentic it possible for DHCPv6 software to discriminate between authentic
endpoints and men in the middle. Other authentication mechanisms may endpoints and men in the middle. Other authentication mechanisms may
optionally be deployed. For example, the Secure DHCPv6 optionally be deployed. For example, the Secure DHCPv6
[I-D.ietf-dhc-secure-dhcpv6], based on Cryptographically Generated [I-D.ietf-dhc-secure-dhcpv6], based on Cryptographically Generated
Addresses (CGA) [RFC3972], can provide source address ownership Addresses (CGA) [RFC3972], can provide source address ownership
validation, message origin authentication and message integrity validation, message origin authentication and message integrity
without requiring symmetric key pairs or supporting from any key without requiring symmetric key pairs or supporting from any key
management system. However, as of now, the mechanism is not widely management system. However, as of now, the mechanism is not widely
skipping to change at page 15, line 5 skipping to change at page 19, line 14
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 implicitly "internal configuration" records of the system, it may be implicitly
trusted without being 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.
16. IANA Considerations 18. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
17. References 19. Acknowledgements
17.1. Informative References Authors would like to thank Simon Perreault, Bernie Volz and Ted
Lemon for their comments.
[RFC1035] Mockapetris, P., "Domain names - implementation and 20. Informative References
specification", STD 13, RFC 1035, November 1987.
[I-D.ietf-dhc-secure-dhcpv6]
Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs",
draft-ietf-dhc-secure-dhcpv6-07 (work in progress),
September 2012.
[I-D.ietf-softwire-4rd]
Jiang, S., Despres, R., Penno, R., Lee, Y., Chen, G., and
M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless
Solution (4rd)", draft-ietf-softwire-4rd-04 (work in
progress), October 2012.
[I-D.ietf-softwire-map-dhcp]
Mrugalski, T., Troan, O., Bao, C., Dec, W., and L. Yeh,
"DHCPv6 Options for Mapping of Address and Port",
draft-ietf-softwire-map-dhcp-01 (work in progress),
August 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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
skipping to change at page 16, line 9 skipping to change at page 20, line 39
IPv6 (DHCPv6)", RFC 4242, November 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.
[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.
[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 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
Options for Network Boot", RFC 5970, September 2010. 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.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix "Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012. Delegation", RFC 6603, May 2012.
17.2. Informative References [RFC6610] Jang, H., Yegin, A., Chowdhury, K., Choi, J., and T.
Lemon, "DHCP Options for Home Information Discovery in
[I-D.ietf-dhc-secure-dhcpv6] Mobile IPv6 (MIPv6)", RFC 6610, May 2012.
Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs",
draft-ietf-dhc-secure-dhcpv6-06 (work in progress),
March 2012.
[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.
[I-D.mdt-softwire-map-dhcp-option]
Mrugalski, T., Boucadair, M., Deng, X., Troan, O., and C.
Bao, "DHCPv6 Options for Mapping of Address and Port",
draft-mdt-softwire-map-dhcp-option-02 (work in progress),
January 2012.
Authors' Addresses Authors' Addresses
David W. Hankins David W. Hankins
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: dhankins@google.com Email: dhankins@google.com
 End of changes. 40 change blocks. 
87 lines changed or deleted 298 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/