draft-ietf-dhc-option-guidelines-11.txt   draft-ietf-dhc-option-guidelines-12.txt 
Dynamic Host Configuration Working Group D. Hankins Dynamic Host Configuration Working Group D. Hankins
Internet-Draft Google Internet-Draft Google
Updates: 3315 (if approved) T. Mrugalski Updates: 3315 (if approved) T. Mrugalski
Intended status: Standards Track M. Siodelski Intended status: Best Current Practice M. Siodelski
Expires: October 11, 2013 ISC Expires: December 31, 2013 ISC
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
S. Krishnan S. Krishnan
Ericsson Ericsson
April 09, 2013 June 29, 2013
Guidelines for Creating New DHCPv6 Options Guidelines for Creating New DHCPv6 Options
draft-ietf-dhc-option-guidelines-11 draft-ietf-dhc-option-guidelines-12
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
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 October 11, 2013. This Internet-Draft will expire on December 31, 2013.
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 . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . 3 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 a single flag (boolean) . . . . . . . . . . . 6 5.2. Option with a single flag (boolean) . . . . . . . . . . . 6
5.3. Option with IPv6 prefix . . . . . . . . . . . . . . . . . 7 5.3. Option with IPv6 prefix . . . . . . . . . . . . . . . . . 7
5.4. Option with 32-bit integer value . . . . . . . . . . . . 8 5.4. Option with 32-bit integer value . . . . . . . . . . . . 8
5.5. Option with 16-bit integer value . . . . . . . . . . . . 8 5.5. Option with 16-bit integer value . . . . . . . . . . . . 8
5.6. Option with 8-bit integer value . . . . . . . . . . . . . 9 5.6. Option with 8-bit integer value . . . . . . . . . . . . . 8
5.7. Option with variable length data . . . . . . . . . . . . 9 5.7. Option with URI . . . . . . . . . . . . . . . . . . . . . 9
5.8. Option with DNS Wire Format Domain Name List . . . . . . 10 5.8. Option with Text String . . . . . . . . . . . . . . . . . 10
6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . 10 5.9. Option with variable length data . . . . . . . . . . . . 11
7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . 11 5.10. Option with DNS Wire Format Domain Name List . . . . . . 12
8. Choosing between FQDN and address . . . . . . . . . . . . . . 11 6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . 12
9. Encapsulated options in DHCPv6 . . . . . . . . . . . . . . . 13 7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . 13
10. Additional States Considered Harmful . . . . . . . . . . . . 14 8. Choosing between FQDN and address . . . . . . . . . . . . . . 13
11. Is DHCPv6 dynamic? . . . . . . . . . . . . . . . . . . . . . 14 9. Encapsulated options in DHCPv6 . . . . . . . . . . . . . . . 15
12. Multiple provisioning domains . . . . . . . . . . . . . . . . 15 10. Additional States Considered Harmful . . . . . . . . . . . . 16
13. Considerations for Creating New Formats . . . . . . . . . . . 15 11. Configuration changes occur at fixed times . . . . . . . . . 16
14. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. Multiple provisioning domains . . . . . . . . . . . . . . . . 17
15. Clients Request their Options . . . . . . . . . . . . . . . . 16 13. Chartering Requirements and Advice for Responsible ADs . . . 17
16. Transition Technologies . . . . . . . . . . . . . . . . . . . 17 14. Considerations for Creating New Formats . . . . . . . . . . . 19
17. Recommended sections in the new document . . . . . . . . . . 17 15. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 19
17.1. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 18 16. Singleton options . . . . . . . . . . . . . . . . . . . . . . 20
17.2. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 19 17. Option Order . . . . . . . . . . . . . . . . . . . . . . . . 20
17.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . 19 18. Relay Options . . . . . . . . . . . . . . . . . . . . . . . . 21
18. Should the new document update existing RFCs? . . . . . . . . 19 19. Clients Request their Options . . . . . . . . . . . . . . . . 21
19. Security Considerations . . . . . . . . . . . . . . . . . . . 20 20. Transition Technologies . . . . . . . . . . . . . . . . . . . 22
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 21. Recommended sections in the new document . . . . . . . . . . 22
21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 21.1. DHCPv6 Client Behavior Text . . . . . . . . . . . . . . 23
22. Informative References . . . . . . . . . . . . . . . . . . . 21 21.2. DHCPv6 Server Behavior Text . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 21.3. DHCPv6 Relay Agent Behavior Text . . . . . . . . . . . . 24
22. Should the new document update existing RFCs? . . . . . . . . 24
23. Security Considerations . . . . . . . . . . . . . . . . . . . 25
24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
25. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
26. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
26.1. Normative References . . . . . . . . . . . . . . . . . . 26
26.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 3, line 35 skipping to change at page 3, line 37
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.
So although a given solution would work, and might even be space, So although a given solution would work, and might even be space,
time, or aesthetically optimal, a given option is presented with a time, or aesthetically optimal, a given option is presented with a
series of ever-worsening challenges to be adopted; series of ever-worsening challenges to be adopted:
o If it doesn't fit neatly into existing config files. o If it doesn't fit neatly into existing config files.
o If it requries new source code changes to be adopted, and hence o If it requires source code changes to be adopted, and hence
upgrades of deployed software. upgrades of deployed software.
o If it does not share its deployment fate in a general manner with o If it does not share its deployment fate in a general manner with
other options, standing alone in requiring code changes or other options, standing alone in requiring code changes or
reworking configuration file syntaxes. reworking configuration file syntaxes.
o If the option would work well in the particular deployment
environment the proponents currently envision, but has equally
valid uses in some other environment where the proposed option
format would fail or would produce inconsistent results.
There are many things DHCPv6 option creators can do to avoid the There are many things DHCPv6 option creators can do to avoid the
pitfalls in this list entirely, or failing that, to make software pitfalls in this list entirely, or failing that, to make software
implementors lives easier and improve its chances for widespread implementors lives easier and improve its chances for widespread
adoption. adoption.
3. When to Use DHCPv6 3. When to Use DHCPv6
Principally, DHCPv6 carries configuration parameters for its clients. Principally, DHCPv6 carries configuration parameters for its clients.
Any knob, dial, slider, or checkbox on the client system, such as "my Any knob, dial, slider, or checkbox on the client system, such as "my
domain name servers", "my hostname", or even "my shutdown domain name servers", "my hostname", or even "my shutdown
temperature" are candidates for being configured by 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
skipping to change at page 4, line 14 skipping to change at page 4, line 22
Principally, DHCPv6 carries configuration parameters for its clients. Principally, DHCPv6 carries configuration parameters for its clients.
Any knob, dial, slider, or checkbox on the client system, such as "my Any knob, dial, slider, or checkbox on the client system, such as "my
domain name servers", "my hostname", or even "my shutdown domain name servers", "my hostname", or even "my shutdown
temperature" are candidates for being configured by 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 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 in addition to the existence of a configuration
parameter, one must also ask themselves if it is reasonable for this parameter, one must also ask themselves if it is reasonable for this
parameter to be set by the directly attached network's parameter to be set by the directly attached network's
administrators. administrators.
Note that the client still reserves the right to ignore 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 (for example, due to having a value manually
configured by its own operator). Bear in mind that doing so might configured by its own operator). Bear in mind that doing so might
cause the client to be rejected network attachment privileges, and cause the client to be rejected network attachment privileges, and
this is one main reason for the use of DHCPv6 in corporate this is one of the main reasons for the use of DHCPv6 in corporate
enterprises. enterprises.
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 simplification. More specifically, the option's adoptability is reuse. The option should be created in such
option should be created in such a way that does not require any new a way that does not require any new or special case software to
or special case software to support. If old software currently support. If old software currently deployed and in the field can
deployed and in the field can adopt the option through supplied adopt the option through supplied configuration facilities then it's
configuration facilities then it's fairly certain that new software fairly certain that new software can easily formally adopt it.
can easily formally adopt it.
There are at least two classes of DHCPv6 options: A bulk class of There are at least two classes of DHCPv6 options: simple options
options which are provided explicitly to carry data from one side of which are provided explicitly to carry data from one side of the
the DHCPv6 exchange to the other (such as nameservers, domain names, DHCPv6 exchange to the other (such as nameservers, domain names, or
or time servers), and a protocol class of options which require time servers), and a protocol class of options which require special
special processing on the part of the DHCPv6 software or are used processing on the part of the DHCPv6 software or are used during
during special processing (such as the Fully Qualified Domain Name special processing (such as the Fully Qualified Domain Name (FQDN)
(FQDN) option [RFC4704]), and so forth; these options carry data that option [RFC4704]), and so forth; these options carry data that is the
is the result of a routine in some DHCPv6 software. result of a routine in some DHCPv6 software.
The guidelines laid out here should be applied in a relaxed manner The guidelines laid out here should be applied in a relaxed manner
for the protocol class of options. Wherever special case code is for the protocol class of options. Wherever special case code is
already required to adopt the DHCPv6 option, it is substantially more already required to adopt the DHCPv6 option, it is substantially more
reasonable to format the option in a less generic fashion, if there reasonable to format the option in a less generic fashion, if there
are measurable benefits to doing so. are measurable benefits to doing so.
5. Reusing Other Options 5. Reusing Other Options
The easiest approach to manufacturing trivially deployable DHCPv6 The easiest approach to manufacturing trivially deployable DHCPv6
Options is to assemble the option out of whatever common fragments Options is to assemble the option out of whatever common fragments
fit - possibly allowing a group of fragments to repeat to fill the fit - possibly allowing a group of data elements to repeat to fill
remaining space (if present) and so provide multiple values. Place the remaining space (if present) and so provide multiple values.
all fixed size values at the start of the option, and any variable/ Place all fixed size values at the start of the option, and any
indeterminate sized value at the tail end of the option. variable/indeterminate sized value at the tail end of the option.
This estimates that implementations will be able to reuse code paths This means that implementations will likely be able to reuse code
designed to support the other options. paths designed to support the other options.
There is a tradeoff between the adoptability of previously defined There is a tradeoff between the adoptability of previously defined
option formats, and the advantages that new or specialized formats option formats, and the advantages that new or specialized formats
can provide. In general, it is usually preferrable 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 similar problem. So, the following list of common option format data
fragments 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. It complete in terms of exampling every option format ever devised.
is only a list of option format fragments which are used in two or
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. In 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): 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 27 skipping to change at page 6, line 12
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Option with IPv6 address Figure 1: Option with IPv6 address
Examples of use: Examples of use:
o DHCPv6 server unicast address [RFC3315] o DHCPv6 server unicast address (a single address only) [RFC3315]
o SIP Servers IPv6 Address List [RFC3319] o SIP Servers IPv6 Address List [RFC3319]
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
skipping to change at page 7, line 4 skipping to change at page 6, line 38
o NTP Multicast address [RFC5908] (a single address only) o NTP Multicast address [RFC5908] (a single address only)
5.2. Option with a single flag (boolean) 5.2. Option with a single flag (boolean)
Sometimes it is useful to convey a single flag that can either take 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 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 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 without any content. It is the presence or absence of the option
that conveys the value. This approach has the additional benefit of that conveys the value. This approach has the additional benefit of
absent option designating the default, i.e. administrator has to absent option designating the default, i.e. administrator has to take
take explicit actions to deploy the oposite of the default value. explicit actions to deploy the opposite of the default 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Option for conveying boolean Figure 2: Option for conveying boolean
Examples of use: Examples of use:
o DHCPv6 rapid-commit [RFC3315] o DHCPv6 rapid-commit [RFC3315]
5.3. Option with IPv6 prefix 5.3. Option with IPv6 prefix
Sometimes there is a need to convey IPv6 prefix. The information to Sometimes there is a need to convey an IPv6 prefix. The information
be carried by an option includes the 128-bit IPv6 prefix together to be carried by such an option includes the 128-bit IPv6 prefix
with a length of this prefix taking values from 0 to 128. Using the together with a length of this prefix taking values from 0 to 128.
simplest approach, the option could convey this data in two fixed Using the simplest approach, the option could convey this data in two
length fields: one carrying prefix length, another carrying the fixed length fields: one carrying prefix length, another carrying the
prefix. However, in many cases /64 or shorter prefixes are used. prefix. However, in many cases /64 or shorter prefixes are used.
This implies that the large part of the prefix data carried by the This implies that the large part of the prefix data carried by the
option would have its bits set to zero and would be unused. In order option would have its bits set to zero and would be unused. In order
to avoid carrying unused data, it is recommended to store prefix in to avoid carrying unused data, it is recommended to store prefix in
the variable length data field. The appropriate option format is the variable length data field. The appropriate option format is
defined as follows: defined as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix6-len | ipv6-prefix | | prefix6-len | ipv6-prefix |
+-+-+-+-+-+-+-+-+ (variable length) | +-+-+-+-+-+-+-+-+ (variable length) |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Option with IPv6 Prefix Figure 3: Option with IPv6 Prefix
option-length is set to 1 + length of the IPv6 prefix. prefix6-len option-length is set to 1 + length of the IPv6 prefix.
is one octet long and specifies the length in bits of the IPv6
prefix. Typically allowed values are 0 to 128. prefix6-len is one octet long and specifies the length in bits of the
IPv6 prefix. Typically allowed values are 0 to 128.
ipv6-prefix field is a variable length field that specifies the IPv6 ipv6-prefix field is a variable length field that specifies the IPv6
prefix. This field is padded with zeros up to the nearest octet prefix. The length is (prefix6-len + 7) / 8. This field is padded
boundary when prefix6-len is not divisible by 8. This can be with zero bits up to the nearest octet boundary when prefix6-len is
expressed using the following equation: >prefix6-len<+7/8 not divisible by 8.
Examples of use: Examples of use:
o Default Mapping Rule [I-D.ietf-softwire-map-dhcp] o Default Mapping Rule [I-D.ietf-softwire-map-dhcp]
For example, the prefix 2001:db8::/60 would be encoded with an For example, the prefix 2001:db8::/60 would be encoded with an
option-length of 9, prefix-len would be set to 60, the ipv6-prefix option-length of 9, prefix6-len would be set to 60, the ipv6-prefix
would be 8 octets and would contains octets 20 01 0d b8 00 00 00 00. would be 8 octets and would contain octets 20 01 0d b8 00 00 00 00.
It should be noted that Prefix Delegation mechanism used in [RFC3633] It should be noted that the IAPREFIX option defined by [RFC3633] uses
uses constant length prefixes. The concern about option length was a full length 16-octet prefix field. The concern about option length
not well understood at the time of its publication. was not well understood at the time of its publication.
5.4. Option with 32-bit integer value 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 |
skipping to change at page 9, line 28 skipping to change at page 9, line 12
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8-bit-integer | | 8-bit-integer |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 6: 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.7. Option with variable length data 5.7. Option with URI
A Uniform Resource Identifier (URI) [RFC3986] is a compact sequence
of characters that identifies an abstract or physical resource. The
term "Uniform Resource Locator" (URL) refers to the subset of URIs
that, in addition to identifying a resource, provide a means of
locating the resource by describing its primary access mechanism
(e.g., its network "location"). This option format can be used to
carry a single URI:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. URI (variable length) .
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Option with URI
Examples of use:
o Boot File URL [RFC5970]
An alternate encoding to support multiple URIs is available. An
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
sufficient or if multiple URLs are possible.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. uri-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Option with multiple URIs
Each instance of the uri-data is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| uri-len | URI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
The uri-len is two octets long and specifies the length of the uri
data.
5.8. Option with Text String
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
string MUST be specified. 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 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. String .
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Option with text string
Examples of use:
o Timezone Options for DHCPv6 [RFC4833]
An alternate encoding to support multiple text strings is available.
An option must be defined to use either the single text string format
above or the multiple text string format below depending on whether a
single is always sufficient or if multiple text strings are possible.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. text-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Option with multiple text strings
Each instance of the text-data is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| text-len | String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
The text-len is two octets long and specifies the length of the
string.
5.9. 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. Whenever
the existing DHCPv6 options use NVT-ASCII strings to encode: this format is used by the new option being defined, the data
filenames, host or domain names, protocol features or textual encoding should be documented.
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
carried data types. carried data types.
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 7: Option with variale length data Figure 11: Option with variable 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] 5.10. 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. It uses the same format as described in Section 5.9,
but with the special data encoding, described in section 8 of
[RFC3315]. This data encoding supports carrying multiple instances
of hosts or domain names in a single option, by terminating each
instance with the byte value of 0.
0 1 2 3 0 1 2 3
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 8: Option with DNS Wire Format Domain Name List Figure 12: Option with DNS Wire Format Domain Name List
Examples of use: Examples of use:
o SIP Servers Domain Name List [RFC3319] (many domains) o SIP Servers Domain Name List [RFC3319] (many domains)
o NIS Domain Name (many domains) [RFC3898] (many domains) o NIS Domain Name (many domains) [RFC3898] (many domains)
o DS-Lite AFTR location [RFC6334] (a single FQDN) o DS-Lite AFTR location [RFC6334] (a single FQDN)
o Home Network Identifier [RFC6610] (a single FQDN) o Home Network Identifier [RFC6610] (a single FQDN)
o Home Agent FQDN [RFC6610] (a single FQDN) o Home Agent FQDN [RFC6610] (a single FQDN)
6. Avoid Conditional Formatting 6. Avoid Conditional Formatting
Placing an octet at the start of the option which informs the Placing an octet at the start of the option which informs the
software how to process the remaining octets of the option may appear software how to process the remaining octets of the option may appear
simple to the casual observer. But the only conditional formatting simple to the casual observer. But the only conditional formatting
methods that are in widespread use today are 'protocol' class methods that are in widespread use today are 'protocol' class
options. Therefore the conditional formatting requires new code to options. Therefore conditional formatting requires new code to be
be written, as well as introduces an implementation problem; as it written and complicates future interoperability should new
requires that all speakers implement all current and future conditional formats be added; and existing code has to ignore
conditional formats. conditional format that it does not support.
Conditional formatting is not recommended, except in cases where the
DHCPv6 option has already been deployed experimentally, and all but
one conditional format is deprecated.
7. Avoid Aliasing 7. Avoid Aliasing
Options are said to be aliases of each other if they provide input to Options are said to be aliases of each other if they provide input to
the same configuration parameter. A commonly proposed example is to the same configuration parameter. A commonly proposed example is to
configure the location of some new service ("my foo server") using a configure the location of some new service ("my foo server") using a
binary IP address, a domain name field, and an URL. This kind of binary IP address, a domain name field, and an URL. This kind of
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
skipping to change at page 11, line 49 skipping to change at page 13, line 45
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 8. Choosing between FQDN and address
Some parameters may be specified as FQDN or an address. It is not 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 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 Section 7), so one of them must be chosen. This section is intended
as a help to make an informed decision in that regard. to help 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.
Unless there are specific reasons to do otherwise, address should be Unless there are specific reasons to do otherwise, address should be
used. It is simpler to use, its validation is trivial (length of 16 used. It is simpler to use, its validation is trivial (length of 16
constitutes a valid option), is explicit and does not allow any constitutes a valid option), is explicit and does not allow any
ambiguity. It is faster (does not require extra resolution efforts), ambiguity. It is faster (does not require extra resolution efforts),
so it is more efficient, which can be especially important for energy so it is more efficient, which can be especially important for energy
restricted devices. restricted devices.
FQDN options are discouraged for options intended to configure hosts,
because hosts may have multiple provisioning domains (see
Section 12), and may get a different answer from the DNS depending on
the provisioning domain. This is particularly a problem when the
normal expected use of the option makes sense with private DNS
zone(s), as might be the case with a corporate VPN.
FQDN does require a resolution into an actual address. This implies FQDN does require a resolution into an actual address. This implies
the question when the FQDN resolution should be taken. There are a the question when the FQDN resolution should be taken. There are a
couple of possible answers: a) by the server, when it is started, b) couple of possible answers: a) by the server, when it is started, b)
by the server, when it is about to send an option, c) by the client, 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 immediately after receiving an option, d) by the client, when the
content of the option is actually consumed. For a), b) and possibly content of the option is actually consumed. For a), b) and possibly
c), the option should really convey an address, not FQDN. The only 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 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. allows possible changes in the DNS to be picked up by clients.
FQDN imposes number of additional failure modes and issues that FQDN imposes a number of additional failure modes and issues that
should be dealt with: should be dealt with:
1. The client must have a knowledge about available DNS servers. 1. The client must have a knowledge about available DNS servers.
That typically means that option DNS_SERVERS is mandatory. This That typically means that option DNS_SERVERS is mandatory. This
should be mentioned in the draft that defines new option. It is should be mentioned in the draft that defines new option. It is
possible that the server will return FQDN option, but not the DNS possible that the server will return FQDN option, but not the DNS
Servers option. There should be a brief discussion about it; Servers option. There should be a brief discussion about it;
2. The DNS may not be reachable; 2. The DNS may not be reachable;
3. DNS may be available, but may not have appropriate information 3. DNS may be available, but may not have appropriate information
(e.g. no AAAA records for specified FQDN); (e.g. no AAAA records for specified FQDN);
4. Address family must be specified (A, AAAA or any); 4. Address family must be specified (A, AAAA or any);
5. What should the client do if there are multiple records available 5. What should the client do if there are multiple records available
(use only the first one, use all, use one and switch to the (use only the first one, use all, use one and switch to the
second if the first fails for whatever reason, etc.); second if the first fails for whatever reason, etc.);
6. Multi-homed devices may be connected to different administrative 6. Multi-homed devices may be connected to different administrative
domains with each domain providing a different information in DNS domains with each domain providing different information in DNS
(e.g. an enterprise network exposing private domains). Client (e.g. an enterprise network exposing private domains). Client
may send DNS queries to a different DNS server; may send DNS queries to a different DNS server;
7. It should be mentioned if Internationalized Domain Names are 7. It should be mentioned if Internationalized Domain Names are
allowed. If they are, what kind of DNS option encoding should be allowed. If they are, what kind of DNS option encoding should be
specified. specified.
9. Encapsulated options in DHCPv6 9. Encapsulated options 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 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 is not precise and thus discouraged. It sub-options, but this term actually means something else, and
is recommened to use term "encapsulated" as this terminology is used therefore should never be used to describe encapsulated options. It
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 space codes, while the
latter uses option space specific to a given parent option. It latter uses option space specific to a given parent option. It
should be noted that, contrary to DHCPv4, there is no shortage of 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]). unfortunate exception of [RFC5908], which never got proper review
from the DHC working group and contains many errors, and should not
under any 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 option rather than sub-option, as the implementor do not encapsulated options rather than sub-options, as the implementers do
have to deal with separate option spaces and can use the same buffer not have to deal with separate option spaces and can use the same
parser in several places throughout the code. buffer parser in several places throughout the code.
Such encapsulation mechanism is not limited to one level. There is Such encapsulation is not limited to one level. There is at least
at least one defined option that is encapsulated twice: Identity one defined option that is encapsulated twice: Identity Association
Association for Prefix Delegation (IA_PD, defined in [RFC3633], for Prefix Delegation (IA_PD, defined in [RFC3633], section 9)
section 9) conveys IA Prefix (IAPREFIX, defined in [RFC3633], section conveys IA Prefix (IAPREFIX, defined in [RFC3633], section 10). Such
10). Such delegated prefix may contain an excluded prefix range that delegated prefix may contain an excluded prefix range that is
is represented by PD_EXCLUDE option that is conveyed as sub-option 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 configuration means for more complex mechanisms, it may
be tempting to simply use sub-options. That should usually be be tempting to simply use sub-options. That should be avoided, as it
avoided, as it increases complexity of the parser. It is much increases complexity of the parser. It is much easier, faster and
easier, faster and less error prone to parse larger number of options less error prone to parse a larger number of options on a single
on a single (top-level) scope, than parse options on several scopes. (top-level) scope, than parse options on several scopes. The use of
The use of sub-options should be avoided as much as possible but it sub-options should be avoided as much as possible, but it is better
is better to use sub-options rather than conditional formatting. 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 encapsulated
options.
10. 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 clients. Less
protocol designers often assume that it is easy to define an option experienced protocol designers often assume that it is easy to define
that will convey a different parameter for each node in a network. an option that will convey a different parameter for each client in a
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 nodes to get ready to use per node it would be easier for provisioned clients to get ready to use per
option values, such requirement puts exceedingly large loads on the client option values, such requirement puts exceedingly large loads
server side. Alternatives should be considered, if possible. As an on the server side. The new extensions may introduce new
implementation complexity and additional database state on the
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
nodes are provisioned with the same set of MAP options and each clients are provisioned with the same set of MAP options and each
provisioned node uses its unique address and delegated prefix to provisioned client uses its unique address and delegated prefix to
generate node-specific information. Such solution does not introduce generate client-specific information. Such a solution does not
any additional state for the server and therefore scales better. introduce any additional state for the server and therefore scales
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 Refreshing other parameters should be initiated after a time
Option (defined in [RFC4242]). Introducing additional timers make specified in the Information Refresh Time Option (defined in
deployment unnecessarily complex and should be avoided. [RFC4242]), carried in the Reply message and returned in response to
Information-Request message. Introducing additional timers make
deployment unnecessarily complex and SHOULD be avoided.
11. Is DHCPv6 dynamic? 11. Configuration changes occur at fixed times
In general, DHCPv6 clients only refresh configuration data from the
DHCP server when the T1 timer expires. Although there is a
RECONFIGURE mechanism that allows a DHCP server to request that
clients initiate reconfiguration, support for this mechanism is
optional and cannot be relied upon.
DHCPv6 stands for Dynamic Host Configuration Protocol for IPv6. Even when DHCP clients refresh their configuration information, not
Contrary to its name, in many contexts it is not dynamic. While all consumers of DHCP-sourced configuration data notice these
designing DHCPv6 options, it is worth noting that there is no changes. For instance, if a server is started using parameters
reliable way to instantly notify clients that something has happened, received in an early DHCP transaction, but does not check for updates
e.g. parameter value has changed. There is a RECONFIGURE mechanism, from DHCP, it may well continue to use the same parameter
but it has several serious drawbacks that makes its use difficult. indefinitely. Modern notification systems take care of reconfiguring
First, its support is optional and many client implementations do not services when the client moves to a new network, but it's worth
support it. To use reconfigure mechanism, server must use its secret bearing in mind that a renew may not actually result in the client
nonce. That means that provisioning server is the only one that can taking up new configuration information that it receives.
initiate reconfiguration. Other servers do not know it and cannot
trigger reconfiguration. Therefore the only reliable way for clients In light of the above, when designing an option you should take into
to refresh their configuration is to wait until T1 expires. consideration the fact that your option may hold stale data that will
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 provisioning a different set of parameters. One notable
example of such 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. 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 of them, such ADVERTISE message, may respond to one or more of them, such
capability was never observed in any known implementations. Existing capability was never observed in any known implementations. Existing
clients will pick one server and will continue configuration process clients will pick one server and will continue configuration process
with that server, ignoring all other servers. with that 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.
13. Considerations for Creating New Formats 13. Chartering Requirements and Advice for Responsible ADs
Adding a simple DHCP option is straightforward, and generally
something that any working group can do, perhaps with some help from
designated DHCP experts. However, when new fragment types need to be
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
experts. This is true whether the new fragment type has the same
structure as an existing fragment type, but has different semantics.
It is equally true when the new format has a new structure.
If the option simply will not fit into any existing work by using Responsible Area Directors for working groups that wish to add a work
fragments, the last recourse is to create a new format to fit. item to a working group charter to define a new DHCP option should
get clarity from the working group as to whether the new option is a
simple DHCP option with no new fragment type or new fragment
semantics, or whether it in fact will require new fragment types. A
working group charter item should explicitly state which of these two
types is required; if it is not known at the time of chartering, the
charter should state that the working group will study the question
and recharter or seek help elsewhere if a new fragment type is to be
defined.
When doing so, it is not enough to gauge whether or not the option If a working group needs a new fragment type, it is preferable to
format will work in the context of the option presently being seek out a working group whose members already have sufficient
considered. It is equally important to consider if the new format's expertise to evaluate the new work and try to come up with a new
fragments might reasonably have any other uses, and if so, to create format that generalizes well and can be reused, rather than a single-
the option with the foreknowledge that its parts may later become a use fragment type. If such a working group is available, the work
common fragment. should be chartered in that working group as a separate draft that
documents the new fragment type. The working group that needs the
new fragment type can then define their new option referencing the
new fragment type document. This work can generally be done in
parallel so as not to delay the process significantly.
One specific consideration to evaluate is whether or not options of a In the event that there is no working group with DHCP expertise that
similar format would need to have multiple or single values encoded can define the new fragment type, the responsible AD should seek out
(whatever differs from the current option), and how that might be help from known DHCP experts within the IETF to provide advice and
accomplished in a similar format. frequent early review as the working group defines the new fragment
type. The new fragment type should still be done in a separate
document, even if it's done in the same working group, so as to
foster reuse of the new fragment type. The responsible AD should
work with the working group chairs and designated DHCP experts to
ensure that new fragment type document has in fact been carefully
reviewed by the experts and appears satisfactory.
The matter of size considerations is further discussed in Section 14. Responsible area directors for working groups that are considering
defining options that actually update the DHCP protocol, as opposed
to simple options, should go through a process similar to that
described above when trying to determine where to do the work. Under
no circumstances should a working group be given a charter
deliverable to define a new DHCP option, and then on the basis of
that charter item actually make updates to the DHCP protocol.
14. Option Size 14. Considerations for Creating New Formats
When defining new options, one specific consideration to evaluate is
whether or not options of a similar format would need to have
multiple or single values encoded (whatever differs from the current
option), and how that might be accomplished in a similar format.
When defining a new option, it is best to synthesize the option
format using fragment types already in use. However, in some cases
there may be no fragment type that accomplishes the intended purpose.
The matter of size considerations and option order are further
discussed in Section 15 and Section 17.
15. 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 avoids many of the deployment
deployment problems that plague DHCPv4, and is actually an UDP over problems that plague DHCPv4, and is actually an UDP over IPv6 based
IPv6 based protocol (compared to DHCPv4, which is mostly UDP over protocol (compared to DHCPv4, which is mostly UDP over IPv4 protocol,
IPv4 protocol, but with layer 2 hacks). Second, RFC 3315 explicitly but with layer 2 hacks). Second, RFC 3315 explicitly refers readers
refers readers to RFC 2460 Section 5, which describes an MTU of 1280 to RFC 2460 Section 5, which describes an MTU of 1280 octets and a
octets and a minimum fragment reassembly of 1500 octets. It's minimum fragment reassembly of 1500 octets. It's feasible to suggest
feasible to suggest that DHCPv6 is capable of having larger options that DHCPv6 is capable of having larger options deployed over it, and
deployed over it, and at least no common upper limit is yet known to at least no common upper limit is yet known to have been encoded by
have been encoded by its implementors. It is impossible to describe its implementors. It is impossible to describe any fixed limit that
any fixed limit that cleanly divides those too big from the workable. cleanly divides those too big from the workable.
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. A common sense still applies here. It is better to requirements. Common sense still applies here. It is better to
split distinct values into separate octects rather than propose split distinct values into separate octets rather than propose overly
overly complex bit shifting operations to save up several bits (or complex bit shifting operations to save several bits (or even an
even an octet or two) that would be padded to the next octet boundary octet or two) that would be padded to the next octet boundary anyway.
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. DHCPv6 option may appear once or multiple times. The default
assumption is only once.
15. Clients Request their Options Relay agents have to do fragment reassembly and fragmentation on
transmission. So while fragmentation is allowed, if a new option
results in significant fragmentation, it probably isn't a good choice
for DHCP configuration; instead DHCP should simply point to a URI
where the configuration information can be obtained.
16. Singleton options
Although [RFC3315] states that each option type MAY appear more than
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
usually expected that they will appear at most once. Such options
are called singleton options. Sadly, it is often not clearly
specified in RFCs that were published up to this date whether only
one or more option instances are allowed. Documents that define new
defined options SHOULD state whether new options are singletons or
not. Unless otherwise specified, new defined options are singletons.
When deciding whether a single or multiple option instances are
allowed in a message, take into consideration how the content of the
option will be used. Depending on the service being configured it
may or may not make sense to have multiple values configured. If
multiple values make sense, it is better to explicitly allow that by
using option format that allows multiple values within one option
instance.
Allowing multiple option instances often leads to confusion.
Consider the following example. Basic DS-Lite architecture assumes
that the B4 element (DHCPv6 client) will receive AFTR option and
establish a single tunnel to configured tunnel termination point
(AFTR). During standardization process of [RFC6334] there was a
discussion whether multiple instances of DS-Lite tunnel option should
be allowed. This created an unfounded expectation that the clients
receiving multiple instances of the option will somehow know when one
tunnel endpoint goes off-line and do some sort of failover between
other values provided in other instances of the AFTR option. Others
assumed that if there are multiple options, the client will somehow
do a load balancing between provided tunnel endpoints. Neither
failover nor load balancing was defined for DS-Lite architecture, so
it caused confusion. It was eventually decided to allow only one
instance of the AFTR option.
17. Option Order
Option order, either the order among many DHCPv6 options or the order
of multiple instances of the same option, SHOULD NOT be significant
and MUST NOT be assumed. An exception may be security relevant
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
option, an option definition SHOULD instead restrict the order within
the option by using a list of items rather than a single item.
18. Relay Options
In DHCPv4, all relay options are organized as sub-options within DHCP
Relay Agent Information Option[RFC3046]. And an independent number
space called "DHCP Relay Agent Sub-options" is maintained by IANA.
Different from DHCPv4, in DHCPv6, Relay options are defined in the
same way as client/server options, and they too use the same number
space as client/server options. Future DHCPv6 Relay options MUST be
allocated from this single DHCPv6 Option code space.
However, the Relay-Supplied Options Option [RFC6422] may also contain
some DHCPv6 options as permitted, such as the EAP Re-authentication
Protocol (ERP) Local Domain Name DHCPv6 Option [RFC6440].
19. Clients Request their Options
The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315], is an option 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 It doesn't make sense for some options to be requested using Option
Request Option, such as those formed by elements of the protocol's 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 tempting to put a text that requires the client to include 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 a text is discouraged as there are several issues with it. Such text is discouraged as there are several issues with it. First,
First, it assumes that client implementation that supports a given it assumes that client implementation that supports a given option
option will always want to use it. This is not true. The second and will always want to use it. This is not true. The second and more
more important reason is that such a text essentially duplicates important reason is that such text essentially duplicates mechanism
mechanism already defined in [RFC3315]. It is better to simply refer already defined in [RFC3315]. It is better to simply refer to the
to existing mechanism rather than define it again. See Section 17 existing mechanism rather than define it again. See Section 21 for
for proposed examples on how to do that. proposed examples on how to do that.
Creators of DHCPv6 options MUST NOT require special ordering of Creators of DHCPv6 options should 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.
option ordering will break down most existing implementations, as
"order is not important" was one of the design priciples of DHCPv6
and many implementations follow it. For example, there are existing
implementations that use hash maps for storing options, so forcing
any particular order is not feasible without great deal of work. If
options must be processed in any specific order (e.g. due to inter-
dependency), use of option encapsulation should be considered.
16. Transition Technologies 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
odd byte boundaries.
Transition from IPv4 to IPv6 is progressing, albeit at somewhat 20. Transition Technologies
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. Recommended sections in the new document Transition from IPv4 to IPv6 is progressing. Many transition
technologies are proposed to speed it up. As a natural consequence
there are also DHCP options proposed to provision those proposals.
The inevitable question is 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.
When the network infrastructure becomes IPv6-only, the support for
IPv4-only nodes may still be needed. In this scenario, provisioning
IPv4 configuration over IPv6-only networks
[I-D.ietf-dhc-v4configuration] may be needed.
21. Recommended sections in the new document
There are three major entities in DHCPv6 protocol: server, relay There are three major entities in DHCPv6 protocol: server, relay
agent, and client. There is also a separate entity called requestor, agent, and client. It is very helpful for implementers to include
which is a special client-like type that participates in leasequery separate sections that describe operation for those three major
protocol [RFC5007] and [RFC5460]. It is very helpful for entities. Even when a given entity does not participate, it is
implementors to include separate sections that describe operation for useful to have a very short section stating that it must not send a
those three major components. Even when a given entity does not given option and must ignore it when received.
participate, it is useful to have a very short section stating that
it must not send a given option and must ignore it when received.
Similar section for requestor is not required, unless the new option There is also a separate entity called requestor, which is a special
has anything to do with requestor (or it is likely that the reader client-like type that participates in leasequery protocol [RFC5007]
may think that is has). It should be noted that while in majority of and [RFC5460]. A similar section for the requestor is not required,
deployments, requestor is colocated with relay agent, those are two unless the new option has anything to do with requestor (or it is
separate entities from the protocol perspective and they may be used likely that the reader may think that is has). It should be noted
separately. There are stand-alone requestor implementations that while in the majority of deployments, requestor is co-located
available. with relay agent, those are two separate entities from the protocol
perspective and they may be used separately. There are stand-alone
requestor implementations available.
The following sections include proposed text for such sections. That The following sections include proposed text for such sections. That
text is not required to appear, but it is appropriate in most cases. text is not required to appear, but it is appropriate in most cases.
Additional or modified text specific to a given option is often Additional or modified text specific to a given option is often
required. required.
Although requestor is somewhat uncommon functionality, its existence Although requestor is somewhat uncommon functionality, its existence
should be noted, especially when allowing or disallowing options to should be noted, especially when allowing or disallowing options to
appear in certain message or being sent be certain entities. appear in certain message or being sent by certain entities.
Additional message types may appear in the future, besides types Additional message types may appear in the future, besides types
defined in [RFC3315]. Therefore authors are encouraged to defined in [RFC3315]. Therefore authors are encouraged to
familiarize themselves with a list of currently defined DHCPv6 familiarize themselves with a list of currently defined DHCPv6
messages available on IANA website [iana]. messages available on IANA website [iana].
Typically new options are requested by clients and assigned by Typically new options are requested by clients and assigned by the
server, so there is no specific relay behavior. Nevertheless it is server, so there is no specific relay behavior. Nevertheless it is
good to include a section for relay agent behaviour and simply state good to include a section for relay agent behavior and simply state
that there are no additional requirements for relays. The same that there are no additional requirements for relays. The same
applies for client behavior if the options are to be exchanged applies for client behavior if the options are to be exchanged
between relay and server. between relay and server.
Section that contain option definition MUST include formal Sections that contain option definitions MUST include formal
verification procedure. Often it is very simple, e.g. option that verification procedure. Often it is very simple, e.g. option that
conveys IPv6 address must be exactly 16 bytes long, but sometimes the conveys IPv6 address must be exactly 16 bytes long, but sometimes the
rules are more complex. It is recommeded to refer to existing rules are more complex. It is recommeded to refer to existing
documents (e.g. section 8 of RFC3315 for domain name enconding) documents (e.g. section 8 of RFC3315 for domain name encoding) rather
rather than trying to repeat such rules. than trying to repeat such rules.
17.1. DHCPv6 Client Behavior 21.1. DHCPv6 Client Behavior Text
Client MAY request option foo, as defined in [RFC3315], sections Clients MAY request option foo, as defined in [RFC3315], sections
17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5 and 22.7. As a convenience to 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5 and 22.7. As a convenience to
the reader, we mention here that the client includes requested option the reader, we mention here that the client includes requested option
codes in Option Request Option. codes in Option Request Option.
Optional text (if client's hints make sense): Client also MAY include Optional text (if client's hints make sense): Client also MAY include
option foo in its SOLICIT, REQUEST, RENEW, REBIND and INFORMATION- option foo in its SOLICIT, REQUEST, RENEW, REBIND and INFORMATION-
REQUEST messages as a hint for the server regarding preferred option REQUEST messages as a hint for the server regarding preferred option
values. values.
Optional text (if the option contains FQDN): If the client request an Optional text (if the option contains FQDN): If the client requests
option that conveys FQDN, it is expected that content of that option an option that conveys an FQDN, it is expected that the contents of
will be resolved using DNS. Hence the following text may be useful: that option will be resolved using DNS. Hence the following text may
Client that requests option foo SHOULD also request option be useful: Clients that request option foo SHOULD also request option
OPTION_DNS_SERVERS specified in [RFC3646]. OPTION_DNS_SERVERS specified in [RFC3646].
Client MUST discard option foo if it is invalid (i.e. did not pass Clients MUST discard option foo if it is invalid (i.e. did not pass
validation steps defined in Section X.Y). validation steps defined in Section X.Y).
Optional text (if option foo in expected to be exchanged between Optional text (if option foo in expected to be exchanged between
relays or request and server): Option foo is exchanged between relays relays and servers): Option foo is exchanged between relays and
and servers only. Clients are not aware of the usage of option foo. servers only. Clients are not aware of the usage of option foo.
Clients MUST ignore received option foo. Clients MUST ignore received option foo.
17.2. DHCPv6 Server Behavior 21.2. DHCPv6 Server Behavior Text
Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in
regards of option assignment. As a convenience to the reader, we regards to option assignment. As a convenience to the reader, we
mention here that the server will send option foo only if configured mention here that the server will send option foo only if configured
with specific values for foo and client requested it. with specific values for foo and the client requested it.
Optional text: Server MUST NOT send more than one instance of foo Optional text: Option foo is a singleton. Servers MUST NOT send more
option. than one instance of foo option.
Optional text (if server is never supposed to receive option foo): Optional text (if server is never supposed to receive option foo):
Server MUST ignore incoming foo option. Servers MUST ignore incoming foo option.
17.3. DHCPv6 Relay Agent Behavior 21.3. DHCPv6 Relay Agent Behavior Text
It's never appropriate for a relay agent to add options to a message
heading toward the client, and relay agents don't actually construct
Relay-Reply messages anyway.
Optional text (if foo option is exchanged between clients and server Optional text (if foo option is exchanged between clients and server
or between requestors and servers): There are no additional or between requestors and servers): There are no additional
requirements for relays. requirements for relays.
Optional text (if relays are expected to insert or consume option Optional text (if relays are expected to insert or consume option
foo): Relay agents MAY include option foo when forwarding packets foo): Relay agents MAY include option foo in a Relay-Forw when
from clients to the server. forwarding packets from clients to the servers.
18. Should the new document update existing RFCs? 22. Should the new document update existing RFCs?
Authors often ask themselves a question whether their proposal Authors often ask themselves a question whether their proposal
updates exist RFCs, especially 3315. During time of writing this updates exist RFCs, especially 3315. In April 2013 there were about
document there were 79 options defined. Had all documents that 80 options defined. Had all documents that defined them also updated
defined them also updated RFC3315, its comprehension of such a RFC3315, comprehension of such a document set would be extremely
document would be extremely difficult. It should be noted that difficult. It should be noted that "extends" and "updates" are two
"extends" and "updates" are two very different verbs. If a new draft very different verbs. If a new draft defines a new option that
defines a new option that clients request and servers provide, it clients request and servers provide, it merely extends current
merely extends current standards, so "updates 3315" is not required standards, so "updates 3315" is not required in the new document
in the new document header. On the other hand, if the new draft header. On the other hand, if a new document replaces or modifies
changes something in already defined behavior, e.g. servers must existing behavior, it should be noted that it updates the other
discard incoming messages if option foo is invalid or missing, then document. For example, [RFC6644] clearly updates [RFC3315] as it
the "updates" phrase is warranted. replaces existing with new text.
19. Security Considerations 23. 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 man-in-the-middle. Other authentication mechanisms may
optionally be deployed. For example, the Secure DHCPv6 optionally be deployed.
[I-D.ietf-dhc-secure-dhcpv6], based on Cryptographically Generated
Addresses (CGA) [RFC3972], can provide source address ownership
validation, message origin authentication and message integrity
without requiring symmetric key pairs or supporting from any key
management system. However, as of now, the mechanism is not widely
deployed. It also does not provide end-to-end encryption.
So, while creating a new option, it is prudent to assume that the So, while creating a new option, it is prudent to assume that the
DHCPv6 packet contents are always transmitted in the clear, and DHCPv6 packet contents are always transmitted in the clear, and
actual production use of the software will probably be vulnerable at actual production use of the software will probably be vulnerable at
least to man-in-the-middle attacks from within the network, even least to man-in-the-middle attacks from within the network, even
where the network itself is protected from external attacks by where the network itself is protected from external attacks by
firewalls. In particular, some DHCPv6 message exchanges are firewalls. In particular, some DHCPv6 message exchanges are
transmitted to multicast addresses that are likely broadcast anyway. transmitted to multicast addresses that are likely broadcast anyway.
If an option is of a specific fixed length, it is useful to remind If an option is of a specific fixed length, it is useful to remind
skipping to change at page 20, line 46 skipping to change at page 25, line 42
If an option may be of variable size (such as having indeterminate If an option may be of variable size (such as having indeterminate
length fields, such as domain names or text strings), it is advisable length fields, such as domain names or text strings), it is advisable
to explicitly remind the implementor to be aware of the potential for to explicitly remind the implementor to be aware of the potential for
long options. Either define a reasonable upper limit (and suggest long options. Either define a reasonable upper limit (and suggest
validating it), or explicitly remind the implementor that an option validating it), or explicitly remind the implementor that an option
may be exceptionally long (to be prepared to handle errors rather may be exceptionally long (to be prepared to handle errors rather
than truncate values). than truncate values).
For some option contents, out of bound values may be used to breach For some option contents, out of bound values may be used to breach
security. An IP address field might be made to carry a loopback security. An IP address field might be made to carry a loopback
address, or local broadcast address, and depending on the protocol address, or local multicast 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 Authors of drafts defining new DHCP options are therefore strongly
measures as can reasonably be made. advised to explicitly define validation measures that recipients of
such options are required to do before processing such options.
20. IANA Considerations However, validation measures already defined by RFC3315 or other
specifications referenced by the new option document are redundant,
and can introduce errors, so authors are equally strongly advised to
refer to the base specification for any such validation language
rather than copying it into the new specification.
24. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
21. Acknowledgements 25. Acknowledgements
Authors would like to thank Simon Perreault, Bernie Volz and Ted Authors would like to thank Simon Perreault, Bernie Volz and Ted
Lemon for their comments. Lemon for their comments.
22. Informative References 26. References
[I-D.ietf-dhc-secure-dhcpv6] 26.1. Normative References
Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", draft-
ietf-dhc-secure-dhcpv6-07 (work in progress), September [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2012. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
26.2. Informative References
[I-D.ietf-dhc-v4configuration]
Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration
Over IPv6 Only Networks", draft-ietf-dhc-
v4configuration-01 (work in progress), May 2013.
[I-D.ietf-softwire-4rd] [I-D.ietf-softwire-4rd]
Jiang, S., Despres, R., 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-04 (work in Solution (4rd)", draft-ietf-softwire-4rd-05 (work in
progress), October 2012. progress), April 2013.
[I-D.ietf-softwire-map-dhcp] [I-D.ietf-softwire-map-dhcp]
Mrugalski, T., Troan, O., Dec, W., Bao, C., Mrugalski, T., Troan, O., Dec, W., Bao, C.,
leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options
for Mapping of Address and Port", draft-ietf-softwire-map- for Mapping of Address and Port", draft-ietf-softwire-map-
dhcp-03 (work in progress), February 2013. dhcp-03 (work in progress), February 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
Requirement Levels", BCP 14, RFC 2119, March 1997. 3046, January 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration [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.
[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.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
RFC 3972, March 2005. Resource Identifier (URI): Generic Syntax", STD 66, 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.
[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
4833, April 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 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February
2009. 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.
[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
6422, December 2011.
[RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication
Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440,
December 2011.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, [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.
[iana] IANA, , "DHCPv6 parameters (IANA webpage)", November 2003, [RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in
DHCPv6 Reconfigure Messages", RFC 6644, July 2012.
[iana] IANA, ., "DHCPv6 parameters (IANA webpage)", November
2003,
<http://www.iana.org/assignments/dhcpv6-parameters/>. <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. 105 change blocks. 
299 lines changed or deleted 575 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/