draft-ietf-dhc-option-guidelines-13.txt   draft-ietf-dhc-option-guidelines-14.txt 
Dynamic Host Configuration Working Group D. Hankins Dynamic Host Configuration Working D. Hankins
Internet-Draft Google Group Google
Updates: 3315 (if approved) T. Mrugalski Internet-Draft T. Mrugalski
Intended status: Best Current Practice M. Siodelski Updates: 3315 (if approved) M. Siodelski
Expires: January 30, 2014 ISC Intended status: BCP ISC
S. Jiang Expires: March 22, 2014 S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
S. Krishnan S. Krishnan
Ericsson Ericsson
July 29, 2013 September 18, 2013
Guidelines for Creating New DHCPv6 Options Guidelines for Creating New DHCPv6 Options
draft-ietf-dhc-option-guidelines-13 draft-ietf-dhc-option-guidelines-14
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. This document updates adoptable by existing DHCPv6 software. This document updates
RFC3315. 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 January 30, 2014. This Internet-Draft will expire on March 22, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . 4 3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . . 5
4. General Principles . . . . . . . . . . . . . . . . . . . . . 4 4. General Principles . . . . . . . . . . . . . . . . . . . . . . 5
5. Reusing Other Options Formats . . . . . . . . . . . . . . . . 5 5. Reusing Other Options Formats . . . . . . . . . . . . . . . . 6
5.1. Option with IPv6 addresses . . . . . . . . . . . . . . . 5 5.1. Option with IPv6 addresses . . . . . . . . . . . . . . . . 7
5.2. Option with a single flag (boolean) . . . . . . . . . . . 6 5.2. Option with a single flag (boolean) . . . . . . . . . . . 8
5.3. Option with IPv6 prefix . . . . . . . . . . . . . . . . . 7 5.3. Option with IPv6 prefix . . . . . . . . . . . . . . . . . 8
5.4. Option with 32-bit integer value . . . . . . . . . . . . 8 5.4. Option with 32-bit integer value . . . . . . . . . . . . . 9
5.5. Option with 16-bit integer value . . . . . . . . . . . . 8 5.5. Option with 16-bit integer value . . . . . . . . . . . . . 10
5.6. Option with 8-bit integer value . . . . . . . . . . . . . 9 5.6. Option with 8-bit integer value . . . . . . . . . . . . . 10
5.7. Option with URI . . . . . . . . . . . . . . . . . . . . . 9 5.7. Option with URI . . . . . . . . . . . . . . . . . . . . . 10
5.8. Option with Text String . . . . . . . . . . . . . . . . . 10 5.8. Option with Text String . . . . . . . . . . . . . . . . . 11
5.9. Option with variable length data . . . . . . . . . . . . 11 5.9. Option with variable length data . . . . . . . . . . . . . 13
5.10. Option with DNS Wire Format Domain Name List . . . . . . 12 5.10. Option with DNS Wire Format Domain Name List . . . . . . . 13
6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . 12 6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . . 14
7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . 13 7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Choosing between FQDN and address . . . . . . . . . . . . . . 13 8. Choosing between FQDN and address . . . . . . . . . . . . . . 15
9. Encapsulated options in DHCPv6 . . . . . . . . . . . . . . . 15 9. Encapsulated options in DHCPv6 . . . . . . . . . . . . . . . . 16
10. Additional States Considered Harmful . . . . . . . . . . . . 16 10. Additional States Considered Harmful . . . . . . . . . . . . . 17
11. Configuration changes occur at fixed times . . . . . . . . . 17 11. Configuration changes occur at fixed times . . . . . . . . . . 18
12. Multiple provisioning domains . . . . . . . . . . . . . . . . 17 12. Multiple provisioning domains . . . . . . . . . . . . . . . . 19
13. Chartering Requirements and Advice for Responsible ADs . . . 17 13. Chartering Requirements and Advice for Responsible ADs . . . . 19
14. Considerations for Creating New Formats . . . . . . . . . . . 19 14. Considerations for Creating New Formats . . . . . . . . . . . 20
15. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 19 15. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 21
16. Singleton options . . . . . . . . . . . . . . . . . . . . . . 20 16. Singleton options . . . . . . . . . . . . . . . . . . . . . . 21
17. Option Order . . . . . . . . . . . . . . . . . . . . . . . . 20 17. Option Order . . . . . . . . . . . . . . . . . . . . . . . . . 22
18. Relay Options . . . . . . . . . . . . . . . . . . . . . . . . 21 18. Relay Options . . . . . . . . . . . . . . . . . . . . . . . . 22
19. Clients Request their Options . . . . . . . . . . . . . . . . 21 19. Clients Request their Options . . . . . . . . . . . . . . . . 23
20. Transition Technologies . . . . . . . . . . . . . . . . . . . 22 20. Transition Technologies . . . . . . . . . . . . . . . . . . . 24
21. Recommended sections in the new document . . . . . . . . . . 22 21. Recommended sections in the new document . . . . . . . . . . . 24
21.1. DHCPv6 Client Behavior Text . . . . . . . . . . . . . . 23 21.1. DHCPv6 Client Behavior Text . . . . . . . . . . . . . . . 25
21.2. DHCPv6 Server Behavior Text . . . . . . . . . . . . . . 24 21.2. DHCPv6 Server Behavior Text . . . . . . . . . . . . . . . 26
21.3. DHCPv6 Relay Agent Behavior Text . . . . . . . . . . . . 24 21.3. DHCPv6 Relay Agent Behavior Text . . . . . . . . . . . . . 26
22. Should the new document update existing RFCs? . . . . . . . . 24 22. Should the new document update existing RFCs? . . . . . . . . 26
23. Security Considerations . . . . . . . . . . . . . . . . . . . 25 23. Security Considerations . . . . . . . . . . . . . . . . . . . 27
24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
25. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 25. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
26. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 26. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
26.1. Normative References . . . . . . . . . . . . . . . . . . 26 26.1. Normative References . . . . . . . . . . . . . . . . . . . 28
26.2. Informative References . . . . . . . . . . . . . . . . . 26 26.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
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
skipping to change at page 4, line 24 skipping to change at page 5, line 22
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 DHCPv6. temperature" are candidates for being configured by DHCPv6.
The presence of such a knob isn't enough, because DHCPv6 also The presence of such a knob isn't enough, because DHCPv6 also
presents the extension of an administrative domain - the operator of presents the extension of an administrative domain - the operator of
the network to which the client is currently attached. Someone runs the network to which the client is currently attached. Someone runs
not only the local switching network infrastructure that the client not only the local switching network infrastructure that the client
is 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 the accessing the external Internet via local assist services that the
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, even if a configuration parameter can potentially
parameter, one must also ask themselves if it is reasonable for this delivered by DHCPv6, it is necessary to evaluate whether it is
parameter to be set by the directly attached network's reasonable for this parameter to be under the control of the
administrators. administrator of whatever network a client is attached to at any
given time.
Note that the client is not required to configure any of these values Note that the client is not required to configure any of these values
received via DHCPv6 (for example, due to having a value manually received via DHCPv6 (e.g., due to having these values locally
configured by its own operator). Bear in mind that doing so might configured by its own administrator). But it needs to be noted that
cause the client to be rejected network attachment privileges, and overriding DHCPv6-provided values may cause the client to be denied
this is one of the main reasons for the use of DHCPv6 in corporate certain services in the network to which it has attached. The
enterprises. possibility of having higher level of control over client node
configuration is one of the reasons that DHCPv6 is preferred in
enterprise networks.
4. General Principles 4. General Principles
The primary guiding principle to follow in order to enhance an The primary guiding principle to follow in order to enhance an
option's adoptability is reuse. The option should be created in such option's adoptability is reuse. The option should be created in such
a way that does not require any new or special case software to a way that does not require any new or special case software to
support. If old software currently deployed and in the field can support. If old software currently deployed and in the field can
adopt the option through supplied configuration facilities then it's adopt the option through supplied configuration facilities then it's
fairly certain that new software can easily formally adopt it. fairly certain that new software can easily formally adopt it.
skipping to change at page 5, line 35 skipping to change at page 6, line 39
can provide. In general, it is usually preferable to reuse can provide. In general, it is usually preferable to reuse
previously used option formats. previously used option formats.
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 data similar problem. So, the following list of common option format data
elements is provided as a shorthand. Please note that it is not elements is provided as a shorthand. Please note that it is not
complete in terms of exampling every option format ever devised. complete in terms of exampling every option format ever devised.
If more complex options are needed, those basic formats mentioned If more complex options are needed, those basic formats mentioned
here may be considered privimites (or 'fragment types') that can be here may be considered as primitives (or 'fragment types') that can
used to build more complex formats. It should be noted that it is be used to build more complex formats. It should be noted that it is
often easier to implement two options with trivial formats than one often easier to implement two options with trivial formats than one
option with more complex format. That is not unconditional option with more complex format. That is not unconditional
requirement though. In some cases splitting one complex option into requirement though. In some cases splitting one complex option into
two or more simple options introduces inter-option dependencies that two or more simple options introduces inter-option dependencies that
should be avoided. In such a case, it is usually better to keep one should be avoided. In such a case, it is usually better to keep one
complex option. complex option.
5.1. Option with IPv6 addresses 5.1. Option with IPv6 addresses
This option format is used to carry one or many IPv6 addresses. In This option format is used to carry one or many IPv6 addresses. In
skipping to change at page 10, line 4 skipping to change at page 11, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. URI (variable length) . . URI (variable length) .
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Option with URI Figure 7: Option with URI
Examples of use: Examples of use:
o Boot File URL [RFC5970] o Boot File URL [RFC5970]
An alternate encoding to support multiple URIs is available. An An alternate encoding to support multiple URIs is available. An
option must be defined to use either the single URI format above or option must be defined to use either the single URI format above or
the multiple URL format below depending on whether a single is always the multiple URI format below depending on whether a single is always
sufficient or if multiple URLs are possible. sufficient or if multiple URIs are possible.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. uri-data . . uri-data .
. . . . . . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 33 skipping to change at page 11, line 48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| uri-len | URI | | uri-len | URI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
The uri-len is two octets long and specifies the length of the uri The uri-len is two octets long and specifies the length of the uri
data. data.
5.8. Option with Text String 5.8. Option with Text String
A text string is a sequence of characters that have no semantics. A text string is a sequence of characters that have no semantics.
The encoding (such as 7-bit ASCII, NVT-ASCII, UTF-8) of the text The encoding of the text string MUST be specified. Unless otherwise
string MUST be specified. If a data format has semantics other than specified, all text strings in newly defined options are expected to
just being text, it is not a string. E.g., a FQDN is not a string, be Unicode strings that are encoded using UTF-8 [RFC3629] in Net-
and a URI is also not a string, because they have different Unicode form [RFC5198]. Please note that all strings containing only
semantics. A string must not enclude any terminator (such as a null 7 bit ASCII characters are also valid UTF-8 Net-Unicode strings.
byte). This option format can be used to carry a text string:
If a data format has semantics other than just being text, it is not
a string. E.g., a FQDN is not a string, and a URI is also not a
string, because they have different semantics. A string must not
enclude any terminator (such as a null byte). This option format can
be used to carry a text string:
0 1 2 3 0 1 2 3
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. String . . String .
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Option with text string Figure 9: Option with text string
skipping to change at page 13, line 29 skipping to change at page 14, line 44
aliasing is undesirable, and is not recommended. aliasing is undesirable, and is not recommended.
In this case, where three different formats are supposed, it more In this case, where three different formats are supposed, it more
than triples the work of the software involved, requiring support for than triples the work of the software involved, requiring support for
not merely one format, but support to produce and digest all three. not merely one format, but support to produce and digest all three.
Furthermore, code development and testing must cover all possible Furthermore, code development and testing must cover all possible
combinations of defined formats. Since clients cannot predict what combinations of defined formats. Since clients cannot predict what
values the server will provide, they must request all formats. So in values the server will provide, they must request all formats. So in
the case where the server is configured with all formats, DHCPv6 the case where the server is configured with all formats, DHCPv6
message bandwidth is wasted on option contents that are redundant. message bandwidth is wasted on option contents that are redundant.
Also, the DHCPv6 option space is wasted, as three new option codes Also, the DHCPv6 option number space is wasted, as three new option
are required, rather than one. codes are required, rather than one.
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).
skipping to change at page 15, line 33 skipping to change at page 16, line 50
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 other options. Such inner options are often referred to as
encapsulated or nested options. Those options are sometimes called encapsulated or nested options. Those options are sometimes called
sub-options, but this term actually means something else, and sub-options, but this term actually means something else, and
therefore should never be used to describe encapsulated options. It therefore should never be used to describe encapsulated options. It
is recommended to use term "encapsulated" as this terminology is used is recommended to use term "encapsulated" as this terminology is used
in [RFC3315]. The difference between encapsulated and sub-options in [RFC3315]. The difference between encapsulated and sub-options
are that the former uses normal DHCPv6 option space codes, while the are that the former uses normal DHCPv6 option numbers, while the
latter uses option space specific to a given parent option. It latter uses option number space specific to a given parent option.
should be noted that, contrary to DHCPv4, there is no shortage of It should be noted that, contrary to DHCPv4, there is no shortage of
option numbers. Therefore almost all options share a common option option numbers. Therefore almost all options share a common option
space. For example option type 1 meant different things in DHCPv4, space. For example option type 1 meant different things in DHCPv4,
depending if it was located in top-level or inside of Relay Agent depending if it was located in top-level or inside of Relay Agent
Information option. There is no such ambiguity in DHCPv6 (with the Information option. There is no such ambiguity in DHCPv6 (with the
unfortunate exception of [RFC5908], which never got proper review unfortunate exception of [RFC5908],which was published without
from the DHC working group and contains many errors, and should not following the advice provided during the DHC working group review,
under any circumstances be used as a template for future DHCP option and contains many errors. [RFC5908] SHOULD NOT under any
definitions). circumstances be used as a template for future DHCP option
definitions.
From the implementation perspective, it is easier to implement From the implementation perspective, it is easier to implement
encapsulated options rather than sub-options, as the implementers do encapsulated options rather than sub-options, as the implementers do
not have to deal with separate option spaces and can use the same not have to deal with separate option spaces and can use the same
buffer parser in several places throughout the code. buffer parser in several places throughout the code.
Such encapsulation is not limited to one level. There is at least Such encapsulation is not limited to one level. There is at least
one defined option that is encapsulated twice: Identity Association one defined option that is encapsulated twice: Identity Association
for Prefix Delegation (IA_PD, defined in [RFC3633], section 9) for Prefix Delegation (IA_PD, defined in [RFC3633], section 9)
conveys IA Prefix (IAPREFIX, defined in [RFC3633], section 10). Such conveys IA Prefix (IAPREFIX, defined in [RFC3633], section 10). Such
delegated prefix may contain an excluded prefix range that is delegated prefix may contain an excluded prefix range that is
represented by PD_EXCLUDE option that is conveyed as encapsulated represented by PD_EXCLUDE option that is conveyed as encapsulated
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 or doubly encapsulated to refer to such options as sub-sub-option or doubly encapsulated
option, therefore "encapsulated option" term is typically used, option, therefore "encapsulated option" term is typically used,
regardless of the nesting level. regardless of the nesting level.
When defining configuration means for more complex mechanisms, it may When defining a DHCP-based configuration mechanism for a protocol
be tempting to simply use sub-options. That should be avoided, as it that requires something more complex than a single option, it may be
increases complexity of the parser. It is much easier, faster and tempting to group configuration values using sub-options. That
less error prone to parse a larger number of options on a single should preferably be avoided, as it increases complexity of the
(top-level) scope, than parse options on several scopes. The use of parser. It is much easier, faster and less error prone to parse a
sub-options should be avoided as much as possible, but it is better large number of options on a single (top-level) scope, than parse
to use sub-options rather than conditional formatting. options on several scopes. The use of sub-options should be avoided
as much as possible, but it 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 encapsulated top-level ORO for requesting both top-level options and encapsulated
options. options.
10. Additional States Considered Harmful 10. Additional States Considered Harmful
DHCP is a protocol designed for provisioning clients. Less DHCP is a protocol designed for provisioning clients. Less
experienced protocol designers often assume that it is easy to define experienced protocol designers often assume that it is easy to define
an option that will convey a different parameter for each client in a an option that will convey a different parameter for each client in a
network. Such problems arose during designs of MAP network. Such problems arose during designs of MAP
[I-D.ietf-softwire-map-dhcp] and 4rd [I-D.ietf-softwire-4rd]. While [I-D.ietf-softwire-map-dhcp] and 4rd [I-D.ietf-softwire-4rd]. While
it would be easier for provisioned clients to get ready to use per it would be easier for provisioned clients to get ready to use per-
client option values, such requirement puts exceedingly large loads client option values, such requirement puts exceedingly large loads
on the server side. The new extensions may introduce new on the server side. The new extensions may introduce new
implementation complexity and additional database state on the implementation complexity and additional database state on the
server. Alternatives should be considered, if possible. As an server. Alternatives should be considered, if possible. As an
example, [I-D.ietf-softwire-map-dhcp] was designed in a way that all example, [I-D.ietf-softwire-map-dhcp] was designed in a way that all
clients are provisioned with the same set of MAP options and each clients are provisioned with the same set of MAP options and each
provisioned client uses its unique address and delegated prefix to provisioned client uses its unique address and delegated prefix to
generate client-specific information. Such a solution does not generate client-specific information. Such a solution does not
introduce any additional state for the server and therefore scales introduce any additional state for the server and therefore scales
better. better.
skipping to change at page 17, line 20 skipping to change at page 18, line 42
DHCP server when the T1 timer expires. Although there is a DHCP server when the T1 timer expires. Although there is a
RECONFIGURE mechanism that allows a DHCP server to request that RECONFIGURE mechanism that allows a DHCP server to request that
clients initiate reconfiguration, support for this mechanism is clients initiate reconfiguration, support for this mechanism is
optional and cannot be relied upon. optional and cannot be relied upon.
Even when DHCP clients refresh their configuration information, not Even when DHCP clients refresh their configuration information, not
all consumers of DHCP-sourced configuration data notice these all consumers of DHCP-sourced configuration data notice these
changes. For instance, if a server is started using parameters changes. For instance, if a server is started using parameters
received in an early DHCP transaction, but does not check for updates received in an early DHCP transaction, but does not check for updates
from DHCP, it may well continue to use the same parameter from DHCP, it may well continue to use the same parameter
indefinitely. Modern notification systems take care of reconfiguring indefinitely. There are a few operating systems that take care of
services when the client moves to a new network, but it's worth reconfiguring services when the client moves to a new network(e.g.
bearing in mind that a renew may not actually result in the client based on mechanisms like [RFC4436], [RFC4957] or [RFC6059]), but it's
taking up new configuration information that it receives. worth bearing in mind that a renew may not always result in the
client taking up new configuration information that it receives.
In light of the above, when designing an option you should take into In light of the above, when designing an option you should take into
consideration the fact that your option may hold stale data that will consideration the fact that your option may hold stale data that will
only be updated at an arbitrary time in the future. only be updated at an arbitrary time in the future.
12. 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 providing a different set of parameters. One notable
example of such a case is a home network with a connection to two example of such a case is a home network with a connection to two
independent ISPs. independent ISPs.
DHCPv6 was not initially designed with multiple provisioning domains. The DHCPv6 protocol specification does not provide clear advice on
Although [RFC3315] states that a client that receives more than one how to handle multiple provisioning sources. Although [RFC3315]
ADVERTISE message, may respond to one or more of them, such states that a client that receives more than one ADVERTISE message,
capability was never observed in any known implementations. Existing may respond to one or more of them, such capability has not been
clients will pick one server and will continue configuration process observed in existing implementations. Existing clients will pick one
with that server, ignoring all other servers. server and will continue configuration process with that server,
ignoring all other servers.
In addition, a node that acts as a DHCPv6 client may be connected to
more than one physical network. In this case, it will in most cases
operate a separate DHCP client state machine on each interface,
acquiring different, possibly conflicting information through each.
This information will not be acquired in any synchronized way.
Existing nodes cannot be assumed to systematically segregate
configuration information on the basis of its source; as a result, it
is quite possible that a node may receive an FQDN on one network
interface, but do the DNS resolution on a different network
interface, using different DNS servers. As a consequence, DNS
resolution done by the DHCP server is more likely to behave
predictably than DNS resolution done on a multi-interface or multi-
homed client.
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. Work is ongoing in the IETF to
provide a systematic solution to this problem.
13. Chartering Requirements and Advice for Responsible ADs 13. Chartering Requirements and Advice for Responsible ADs
Adding a simple DHCP option is straightforward, and generally Adding a simple DHCP option is straightforward, and generally
something that any working group can do, perhaps with some help from something that any working group can do, perhaps with some help from
designated DHCP experts. However, when new fragment types need to be designated DHCP experts. However, when new fragment types need to be
devised, this requires the attention of DHCP experts, and should not devised, this requires the attention of DHCP experts, and should not
be done in a working group that doesn't have a quorum of such be done in a working group that doesn't have a quorum of such
experts. This is true whether the new fragment type has the same experts. This is true whether the new fragment type has the same
structure as an existing fragment type, but has different semantics. structure as an existing fragment type, but has different semantics.
skipping to change at page 19, line 30 skipping to change at page 21, line 23
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 avoids many of the deployment its use of link-local addresses, it avoids many of the deployment
problems that plague DHCPv4, and is actually an UDP over IPv6 based problems that plague DHCPv4, and is actually an UDP over IPv6 based
protocol (compared to DHCPv4, which is mostly UDP over IPv4 protocol, protocol (compared to DHCPv4, which is mostly UDP over IPv4 protocol,
but with layer 2 hacks). Second, RFC 3315 explicitly refers readers but with layer 2 hacks). Second, RFC 3315 explicitly refers readers
to RFC 2460 Section 5, which describes an MTU of 1280 octets and a 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 minimum fragment reassembly of 1500 octets. It's feasible to suggest
that DHCPv6 is capable of having larger options deployed over it, and 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 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 its implementors. It is not really possible to describe a fixed
cleanly divides those too big from the workable. limit that cleanly divides workable option sizes from those that are
too big.
It is advantageous to prefer option formats which contain the desired It is advantageous to prefer option formats which contain the desired
information in the smallest form factor that satisfies the information in the smallest form factor that satisfies the
requirements. Common sense still applies here. It is better to requirements. Common sense still applies here. It is better to
split distinct values into separate octets rather than propose overly split distinct values into separate octets rather than propose overly
complex bit shifting operations to save several bits (or even an complex bit shifting operations to save several bits (or even an
octet or two) that would be padded to the next octet boundary anyway. octet or two) that would be padded to the next octet boundary anyway.
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. The default DHCPv6 option may appear once or multiple times. The default
assumption is only once. assumption is only once.
Relay agents have to do fragment reassembly and fragmentation on In general, if a lot of data needs to be configured (i.e. large
transmission. So while fragmentation is allowed, if a new option option lengths), DHCPv6 may not be the best choice to deliver such
results in significant fragmentation, it probably isn't a good choice configuration information and SHOULD simply be used to deliver an URI
for DHCP configuration; instead DHCP should simply point to a URI that specifies how to obtain the actual configuration information.
where the configuration information can be obtained.
16. Singleton options 16. Singleton options
Although [RFC3315] states that each option type MAY appear more than Although [RFC3315] states that each option type MAY appear more than
once, the original idea was that multiple instances are reserved for once, the original idea was that multiple instances are reserved for
stateful options, like IA_NA or IA_PD. For most other options it is stateful options, like IA_NA or IA_PD. For most other options it is
usually expected that they will appear at most once. Such options usually expected that they will appear at most once. Such options
are called singleton options. Sadly, it is often not clearly are called singleton options. Sadly, RFCs have often failed to
specified in RFCs that were published up to this date whether only clearly specify whether a given option can appear more than once or
one or more option instances are allowed. Documents that define new not. Documents that define new options SHOULD state whether these
defined options SHOULD state whether new options are singletons or options are singletons or not. Unless otherwise specified, newly
not. Unless otherwise specified, new defined options are singletons. defined options are considered to be singletons.
When deciding whether a single or multiple option instances are When deciding whether a single or multiple option instances are
allowed in a message, take into consideration how the content of the allowed in a message, take into consideration how the content of the
option will be used. Depending on the service being configured it option will be used. Depending on the service being configured it
may or may not make sense to have multiple values configured. If may or may not make sense to have multiple values configured. If
multiple values make sense, it is better to explicitly allow that by multiple values make sense, it is better to explicitly allow that by
using option format that allows multiple values within one option using option format that allows multiple values within one option
instance. instance.
Allowing multiple option instances often leads to confusion. Allowing multiple option instances often leads to confusion.
skipping to change at page 21, line 4 skipping to change at page 22, line 38
receiving multiple instances of the option will somehow know when one receiving multiple instances of the option will somehow know when one
tunnel endpoint goes off-line and do some sort of failover between tunnel endpoint goes off-line and do some sort of failover between
other values provided in other instances of the AFTR option. Others other values provided in other instances of the AFTR option. Others
assumed that if there are multiple options, the client will somehow assumed that if there are multiple options, the client will somehow
do a load balancing between provided tunnel endpoints. Neither do a load balancing between provided tunnel endpoints. Neither
failover nor load balancing was defined for DS-Lite architecture, so failover nor load balancing was defined for DS-Lite architecture, so
it caused confusion. It was eventually decided to allow only one it caused confusion. It was eventually decided to allow only one
instance of the AFTR option. instance of the AFTR option.
17. Option Order 17. Option Order
Option order, either the order among many DHCPv6 options or the order Option order, either the order among many DHCPv6 options or the order
of multiple instances of the same option, SHOULD NOT be significant of multiple instances of the same option, SHOULD NOT be significant
and MUST NOT be assumed. An exception may be security relevant and MUST NOT be assumed.
options, which are often created last and put at the last position,
or whose location indicates the protected range.
As there is no explicit order for multiple instance of the same As there is no explicit order for multiple instance of the same
option, an option definition SHOULD instead restrict the order within option, an option definition SHOULD instead restrict ordering by
the option by using a list of items rather than a single item. using a single option that contains ordered fields.
18. Relay Options 18. Relay Options
In DHCPv4, all relay options are organized as sub-options within DHCP In DHCPv4, all relay options are organized as sub-options within DHCP
Relay Agent Information Option[RFC3046]. And an independent number Relay Agent Information Option[RFC3046]. And an independent number
space called "DHCP Relay Agent Sub-options" is maintained by IANA. space called "DHCP Relay Agent Sub-options" is maintained by IANA.
Different from DHCPv4, in DHCPv6, Relay options are defined in the Different from DHCPv4, in DHCPv6, Relay options are defined in the
same way as client/server options, and they too use the same number same way as client/server options, and they too use the same number
space as client/server options. Future DHCPv6 Relay options MUST be space as client/server options. Future DHCPv6 Relay options MUST be
allocated from this single DHCPv6 Option code space. allocated from this single DHCPv6 Option number space.
However, the Relay-Supplied Options Option [RFC6422] may also contain E.g. the Relay-Supplied Options Option [RFC6422] may also contain
some DHCPv6 options as permitted, such as the EAP Re-authentication some DHCPv6 options as permitted, such as the EAP Re-authentication
Protocol (ERP) Local Domain Name DHCPv6 Option [RFC6440]. Protocol (ERP) Local Domain Name DHCPv6 Option [RFC6440].
19. Clients Request their Options 19. 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 to inform what options the client is willing to client supports and to inform what options the client is willing to
consume. consume.
It doesn't make sense for some options to be requested using Option For some options, such as the options required for the functioning of
Request Option, such as those formed by elements of the protocol's the DHCPv6 protocol itself, it doesn't make sense to require that
internal workings, or are formed on either end by DHCPv6-level they be explicitly requested using the Option Request Option. In all
software engaged in some exchange of information. When in doubt, it other cases, it is prudent to assume that any new option must be
is prudent to assume that any new option must be present on the present on the relevant option request list if the client desires to
relevant option request list if the client desires to receive it. receive it.
It is tempting to add text that requires the client to include a new It is tempting to add text that requires the client to include a new
option in Option Request Option list, similar to this text: "Clients option in Option Request Option list, similar to this text: "Clients
MUST place the foo option code on the Option Request Option list, MUST place the foo option code on the Option Request Option list,
clients MAY include option foo in their packets as hints for the clients MAY include option foo in their packets as hints for the
server as values the desire, and servers MUST include option foo when server as values the desire, and servers MUST include option foo when
the client requested it (and the server has been so configured)". the client requested it (and the server has been so configured)".
Such text is discouraged as there are several issues with it. First, Such text is discouraged as there are several issues with it. First,
it assumes that client implementation that supports a given option it assumes that client implementation that supports a given option
will always want to use it. This is not true. The second and more will always want to use it. This is not true. The second and more
important reason is that such text essentially duplicates mechanism important reason is that such text essentially duplicates mechanism
already defined in [RFC3315]. It is better to simply refer to the already defined in [RFC3315]. It is better to simply refer to the
existing mechanism rather than define it again. See Section 21 for existing mechanism rather than define it again. See Section 21 for
proposed examples on how to do that. proposed examples on how to do that.
Creators of DHCPv6 options should not require special ordering of Creators of DHCPv6 options cannot not assume special ordering of
options either in the relevant request option, or in the order of options either as they appear in the option request option, or as
options within the packet. Although it is reasonable to expect that they appear within the packet. Although it is reasonable to expect
options will be processed in the order they appear in ORO, server that options will be processed in the order they appear in ORO,
software is not required to sort DHCPv6 options into the same order server software is not required to sort DHCPv6 options into the same
in reply messages. order in reply messages.
It should also be noted that options values are never aligned within It should also be noted that options values are never aligned within
the DHCP packet, even the option code and option length may appear on the DHCP packet, even the option code and option length may appear on
odd byte boundaries. odd byte boundaries.
20. Transition Technologies 20. Transition Technologies
Transition from IPv4 to IPv6 is progressing. Many transition Transition from IPv4 to IPv6 is progressing. Many transition
technologies are proposed to speed it up. As a natural consequence technologies are proposed to speed it up. As a natural consequence
there are also DHCP options proposed to provision those proposals. there are also DHCP options proposed to provision those proposals.
skipping to change at page 22, line 36 skipping to change at page 24, line 24
thought about it and simply pick DHCPv6 without realizing the thought about it and simply pick DHCPv6 without realizing the
consequences. IPv6 is expected to stay with us for many decades, and consequences. IPv6 is expected to stay with us for many decades, and
so is DHCPv6. There is no mechanism available to deprecate an option 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 in DHCPv6, so any options defined will stay with us as long as DHCPv6
protocol itself. It seems likely that such options defined to protocol itself. It seems likely that such options defined to
transition from IPv4 will outlive IPv4 by many decades. From that transition from IPv4 will outlive IPv4 by many decades. From that
perspective it is better to implement provisioning of the transition perspective it is better to implement provisioning of the transition
technologies in DHCPv4, which will be obsoleted together with IPv4. technologies in DHCPv4, which will be obsoleted together with IPv4.
When the network infrastructure becomes IPv6-only, the support for When the network infrastructure becomes IPv6-only, the support for
IPv4-only nodes may still be needed. In this scenario, provisioning IPv4-only nodes may still be needed. In such a scenario, a mechanism
IPv4 configuration over IPv6-only networks for providing IPv4 configuration information over IPv6-only networks
[I-D.ietf-dhc-v4configuration] may be needed. such as [I-D.ietf-dhc-v4configuration] may be needed.
21. Recommended sections in the new document 21. Recommended sections in the new document
There are three major entities in DHCPv6 protocol: server, relay There are three major entities in DHCPv6 protocol: server, relay
agent, and client. It is very helpful for implementers to include agent, and client. It is very helpful for implementers to include
separate sections that describe operation for those three major separate sections that describe operation for those three major
entities. Even when a given entity does not participate, it is entities. Even when a given entity does not participate, it is
useful to have a very short section stating that it must not send a useful to have a very short section stating that it must not send a
given option and must ignore it when received. given option and must ignore it when received.
skipping to change at page 26, line 35 skipping to change at page 28, line 29
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.
26.2. Informative References 26.2. Informative References
[I-D.ietf-dhc-v4configuration] [I-D.ietf-dhc-v4configuration]
Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration
Over IPv6 Only Networks", draft-ietf-dhc- Over IPv6 Only Networks",
v4configuration-01 (work in progress), May 2013. draft-ietf-dhc-v4configuration-01 (work in progress),
May 2013.
[I-D.ietf-softwire-4rd] [I-D.ietf-softwire-4rd]
Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and
M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless
Solution (4rd)", draft-ietf-softwire-4rd-06 (work in Solution (4rd)", draft-ietf-softwire-4rd-06 (work in
progress), July 2013. progress), July 2013.
[I-D.ietf-softwire-map-dhcp] [I-D.ietf-softwire-map-dhcp]
Mrugalski, T., Deng, X., Troan, O., Bao, C., Dec, W., and Mrugalski, T., Deng, X., Troan, O., Bao, C., Dec, W., and
l. leaf.yeh.sdo@gmail.com, "DHCPv6 Options for l. leaf.yeh.sdo@gmail.com, "DHCPv6 Options for
configuration of Softwire Address and Port Mapped configuration of Softwire Address and Port Mapped
Clients", draft-ietf-softwire-map-dhcp-04 (work in Clients", draft-ietf-softwire-map-dhcp-04 (work in
progress), July 2013. progress), July 2013.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
3046, January 2001. RFC 3046, January 2001.
[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.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, January 2005. RFC 3986, January 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.
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Time Option for Dynamic Host Configuration Protocol for Time Option for Dynamic Host Configuration Protocol for
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.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March 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", RFC [RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP",
4833, April 2007. RFC 4833, April 2007.
[RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S.,
and A. Yegin, "Link-Layer Event Notifications for
Detecting Network Attachments", RFC 4957, August 2007.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007. "DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
2009. Interchange", RFC 5198, March 2008.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
February 2009.
[RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) [RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP)
Server Option for DHCPv6", RFC 5908, June 2010. 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.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059,
November 2010.
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
RFC 6334, August 2011. RFC 6334, August 2011.
[RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options",
6422, December 2011. RFC 6422, December 2011.
[RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication [RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication
Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440,
December 2011. December 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.
[RFC6610] Jang, H., Yegin, A., Chowdhury, K., Choi, J., and T. [RFC6610] Jang, H., Yegin, A., Chowdhury, K., Choi, J., and T.
Lemon, "DHCP Options for Home Information Discovery in Lemon, "DHCP Options for Home Information Discovery in
Mobile IPv6 (MIPv6)", RFC 6610, May 2012. Mobile IPv6 (MIPv6)", RFC 6610, May 2012.
[RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in [RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in
DHCPv6 Reconfigure Messages", RFC 6644, July 2012. DHCPv6 Reconfigure Messages", RFC 6644, July 2012.
[iana] IANA, ., "DHCPv6 parameters (IANA webpage)", November [iana] IANA, "DHCPv6 parameters (IANA webpage)", November 2003,
2003,
<http://www.iana.org/assignments/dhcpv6-parameters/>. <http://www.iana.org/assignments/dhcpv6-parameters/>.
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
 End of changes. 44 change blocks. 
150 lines changed or deleted 193 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/