draft-ietf-dhc-option-guidelines-10.txt   draft-ietf-dhc-option-guidelines-11.txt 
Dynamic Host Configuration Working D. Hankins Dynamic Host Configuration Working Group D. Hankins
Group Google Internet-Draft Google
Internet-Draft T. Mrugalski Updates: 3315 (if approved) T. Mrugalski
Updates: 3315 (if approved) M. Siodelski Intended status: Standards Track M. Siodelski
Intended status: Standards Track ISC Expires: October 11, 2013 ISC
Expires: August 29, 2013 S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
S. Krishnan S. Krishnan
Ericsson Ericsson
February 25, 2013 April 09, 2013
Guidelines for Creating New DHCPv6 Options Guidelines for Creating New DHCPv6 Options
draft-ietf-dhc-option-guidelines-10 draft-ietf-dhc-option-guidelines-11
Abstract Abstract
This document provides guidance to prospective DHCPv6 Option This document provides guidance to prospective DHCPv6 Option
developers to help them creating option formats that are easily developers to help them creating option formats that are easily
adoptable by existing DHCPv6 software. This document updates adoptable by existing DHCPv6 software. This document updates
RFC3315. RFC3315.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 29, 2013. This Internet-Draft will expire on October 11, 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 . . . . . . . . . . . . . . . . . . . . . . 4 3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . 9
5.7. Option with variable length data . . . . . . . . . . . . . 9 5.7. Option with variable length data . . . . . . . . . . . . 9
5.8. Option with DNS Wire Format Domain Name List . . . . . . . 10 5.8. Option with DNS Wire Format Domain Name List . . . . . . 10
6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . . 10 6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . 10
7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . 11
8. Choosing between FQDN and address . . . . . . . . . . . . . . 11 8. Choosing between FQDN and address . . . . . . . . . . . . . . 11
9. Suboptions in DHCPv6 . . . . . . . . . . . . . . . . . . . . . 13 9. Encapsulated options in DHCPv6 . . . . . . . . . . . . . . . 13
10. Additional States Considered Harmful . . . . . . . . . . . . . 13 10. Additional States Considered Harmful . . . . . . . . . . . . 14
11. Is DHCPv6 dynamic? . . . . . . . . . . . . . . . . . . . . . . 14 11. Is DHCPv6 dynamic? . . . . . . . . . . . . . . . . . . . . . 14
12. Multiple provisioning domains . . . . . . . . . . . . . . . . 14 12. Multiple provisioning domains . . . . . . . . . . . . . . . . 15
13. Considerations for Creating New Formats . . . . . . . . . . . 15 13. Considerations for Creating New Formats . . . . . . . . . . . 15
14. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 15 14. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 15
15. Clients Request their Options . . . . . . . . . . . . . . . . 16 15. Clients Request their Options . . . . . . . . . . . . . . . . 16
16. Transition Technologies . . . . . . . . . . . . . . . . . . . 16 16. Transition Technologies . . . . . . . . . . . . . . . . . . . 17
17. Security Considerations . . . . . . . . . . . . . . . . . . . 17 17. Recommended sections in the new document . . . . . . . . . . 17
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 17.1. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 18
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 17.2. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 19
20. Informative References . . . . . . . . . . . . . . . . . . . . 18 17.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 18. Should the new document update existing RFCs? . . . . . . . . 19
19. Security Considerations . . . . . . . . . . . . . . . . . . . 20
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
22. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 5, line 36 skipping to change at page 5, line 33
options already allocated, and consider which of those solve a options already allocated, and consider which of those solve a
similar problem. So, the following list of common option format similar problem. So, the following list of common option format
fragments is provided as a shorthand. Please note that it is not fragments is provided as a shorthand. Please note that it is not
complete in terms of exampling every option format ever devised. It complete in terms of exampling every option format ever devised. It
is only a list of option format fragments which are used in two or is only a list of option format fragments which are used in two or
more options. more options.
5.1. Option with IPv6 addresses 5.1. Option with IPv6 addresses
This option format is used to carry one or many IPv6 addresses. 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 7, line 4 skipping to change at page 7, line 4
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 take absent option designating the default, i.e. administrator has to
explicit actions to deploy the oposite of the default value. take explicit actions to deploy the oposite 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:
skipping to change at page 7, line 44 skipping to change at page 7, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 is option-length is set to 1 + length of the IPv6 prefix. prefix6-len
one octet long and specifies the length in bits of the IPv6 prefix. is one octet long and specifies the length in bits of the IPv6
Typically allowed values are 0 to 128. 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. This field is padded with zeros up to the nearest octet
boundary when prefix6-len is not divisible by 8. boundary when prefix6-len is not divisible by 8. This can be
expressed using the following equation: >prefix6-len<+7/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
option-length of 9, prefix-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.
It should be noted that Prefix Delegation mechanism used in [RFC3633] It should be noted that Prefix Delegation mechanism used in [RFC3633]
uses constant length prefixes. The concern about option length was uses constant length prefixes. The concern about option length was
not well understood at the time of its publication. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit-integer | | 32-bit-integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Option with 32-bit-integer value Figure 4: Option with 32-bit-integer value
skipping to change at page 11, line 20 skipping to change at page 11, line 24
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
than triples the work of the software involved, requiring support for than triples the work of the software involved, requiring support for
not merely one format, but support to produce and digest all three. not merely one format, but support to produce and digest all three.
Furthermore, code development and testing must cover all possible Furthermore, code development and testing must cover all possible
combinations of defined formats. Since clients cannot predict what combinations of defined formats. Since clients cannot predict what
values the server will provide, they must request all formats. So in values the server will provide, they must request all formats. So in
the case where the server is configured with all formats, DHCPv6 the case where the server is configured with all formats, DHCPv6
option space is wasted on option contents that are redundant. message bandwidth is wasted on option contents that are redundant.
Also, the DHCPv6 option space is wasted, as three new option codes
are required, rather than one.
It also becomes unclear which types of values are mandatory, and how It also becomes unclear which types of values are mandatory, and how
configuring some of the options may influence the others. For configuring some of the options may influence the others. For
example, if an operator configures the URL only, should the server example, if an operator configures the URL only, should the server
synthesize a domain name and IP address? synthesize a domain name and IP address?
A single configuration value on a host is probably presented to the A single configuration value on a host is probably presented to the
operator (or other software on the machine) in a single field or operator (or other software on the machine) in a single field or
channel. If that channel has a natural format, then any alternative channel. If that channel has a natural format, then any alternative
formats merely make more work for intervening software in providing formats merely make more work for intervening software in providing
skipping to change at page 12, line 28 skipping to change at page 12, line 33
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 number of additional failure modes and issues that
should be dealt with: should be dealt with:
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;
The DNS may not be reachable; 2. The DNS may not be reachable;
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);
Address family must be specified (A, AAAA or any); 4. Address family must be specified (A, AAAA or any);
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 second (use only the first one, use all, use one and switch to the
if the first fails for whatever reason, etc.); second if the first fails for whatever reason, etc.);
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 a different information in DNS
(e.g. an enterprise network exposing private domains). Client may (e.g. an enterprise network exposing private domains). Client
send DNS queries to a different DNS server; may send DNS queries to a different DNS server;
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. Suboptions 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 sub- other options. Such inner options are often referred to as
options. It should be noted that, contrary to DHCPv4, there is no encapsulated or nested options. Those options are sometimes called
shortage of option numbers. Therefore all options share a common sub-options, but this term is not precise and thus discouraged. It
option space. For example option type 1 meant different things in is recommened to use term "encapsulated" as this terminology is used
DHCPv4, depending if it was located in top-level or inside of Relay in [RFC3315]. The difference between encapsulated and sub-options
Agent Information option. There is no such ambiguity in DHCPv6 (with are that the former uses normal DHCPv6 option space codes, while the
the exception of [RFC5908]). latter uses option space specific to a given parent option. It
should be noted that, contrary to DHCPv4, there is no shortage of
option numbers. Therefore almost all options share a common option
space. For example option type 1 meant different things in DHCPv4,
depending if it was located in top-level or inside of Relay Agent
Information option. There is no such ambiguity in DHCPv6 (with the
unfortunate exception of [RFC5908]).
From the implementation perspective, it is easier to implement
encapsulated option rather than sub-option, as the implementor do not
have to deal with separate option spaces and can use the same buffer
parser in several places throughout the code.
Such encapsulation mechanism is not limited to one level. There is Such encapsulation mechanism is not limited to one level. There is
at least one defined option that is encapsulated twice: Identity at least one defined option that is encapsulated twice: Identity
Association for Prefix Delegation (IA_PD, defined in [RFC3633], Association for Prefix Delegation (IA_PD, defined in [RFC3633],
section 9) conveys IA Prefix (IAPREFIX, defined in [RFC3633], section section 9) conveys IA Prefix (IAPREFIX, defined in [RFC3633], section
10). Such delegated prefix may contain an excluded prefix range that 10). Such delegated prefix may contain an excluded prefix range that
is represented by PD_EXCLUDE option that is conveyed as sub-option is represented by PD_EXCLUDE option that is conveyed as sub-option
inside IAPREFIX (PD_EXCLUDE, defined in [RFC6603]). It seems awkward inside IAPREFIX (PD_EXCLUDE, defined in [RFC6603]). It seems awkward
to refer to such options as sub-sub-option, therefore "sub-option" to refer to such options as sub-sub-option or doubly encapsulated
term is typically used, regardless of the nesting level. option, therefore "encapsulated option" term is typically used,
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 usually be
avoided, as it increases complexity of the parser. It is much avoided, as it increases complexity of the parser. It is much
easier, faster and less error prone to parse larger number of options easier, faster and less error prone to parse larger number of options
on a single (top-level) scope, than parse options on several scopes. on a single (top-level) scope, than parse options on several scopes.
The use of sub-options should be avoided as much as possible but it The use of sub-options should be avoided as much as possible but it
is better to use sub-options rather than conditional formatting. is better to use sub-options rather than conditional formatting.
It should be noted that currently there is no clear way defined for It should be noted that currently there is no clear way defined for
skipping to change at page 14, line 25 skipping to change at page 14, line 47
For renewing other parameters, please use Information Refresh Time For renewing other parameters, please use Information Refresh Time
Option (defined in [RFC4242]). Introducing additional timers make Option (defined in [RFC4242]). Introducing additional timers make
deployment unnecessarily complex and should be avoided. deployment unnecessarily complex and should be avoided.
11. Is DHCPv6 dynamic? 11. Is DHCPv6 dynamic?
DHCPv6 stands for Dynamic Host Configuration Protocol for IPv6. DHCPv6 stands for Dynamic Host Configuration Protocol for IPv6.
Contrary to its name, in many contexts it is not dynamic. While Contrary to its name, in many contexts it is not dynamic. While
designing DHCPv6 options, it is worth noting that there is no designing DHCPv6 options, it is worth noting that there is no
reliable way to instantly notify clients that something has happened, reliable way to instantly notify clients that something has happened,
e.g. parameter value has changed. There is a RECONFIGURE mechanism, e.g. parameter value has changed. There is a RECONFIGURE mechanism,
but it has several serious drawbacks that makes its use difficult. but it has several serious drawbacks that makes its use difficult.
First, its support is optional and many client implementations do not First, its support is optional and many client implementations do not
support it. To use reconfigure mechanism, server must use its secret support it. To use reconfigure mechanism, server must use its secret
nonce. That means that provisioning server is the only one that can nonce. That means that provisioning server is the only one that can
initiate reconfiguration. Other servers do not know it and cannot initiate reconfiguration. Other servers do not know it and cannot
trigger reconfiguration. Therefore the only reliable way for clients trigger reconfiguration. Therefore the only reliable way for clients
to refresh their configuration is to wait till T1 expires. to refresh their configuration is to wait until T1 expires.
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 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
skipping to change at page 15, line 24 skipping to change at page 15, line 43
considered. It is equally important to consider if the new format's considered. It is equally important to consider if the new format's
fragments might reasonably have any other uses, and if so, to create fragments might reasonably have any other uses, and if so, to create
the option with the foreknowledge that its parts may later become a the option with the foreknowledge that its parts may later become a
common fragment. common fragment.
One specific consideration to evaluate is whether or not options of a One specific consideration to evaluate is whether or not options of a
similar format would need to have multiple or single values encoded similar format would need to have multiple or single values encoded
(whatever differs from the current option), and how that might be (whatever differs from the current option), and how that might be
accomplished in a similar format. accomplished in a similar format.
The matter of size considerations is further discussed in Section 14.
14. Option Size 14. Option Size
DHCPv6 [RFC3315] allows for packet sizes up to 64KB. First, through DHCPv6 [RFC3315] allows for packet sizes up to 64KB. First, through
its use of link-local addresses, it steps aside many of the its use of link-local addresses, it steps aside many of the
deployment problems that plague DHCPv4, and is actually an UDP over deployment problems that plague DHCPv4, and is actually an UDP over
IPv6 based protocol (compared to DHCPv4, which is mostly UDP over IPv6 based protocol (compared to DHCPv4, which is mostly UDP over
IPv4 protocol, but with layer 2 hacks). Second, RFC 3315 explicitly IPv4 protocol, but with layer 2 hacks). Second, RFC 3315 explicitly
refers readers to RFC 2460 Section 5, which describes an MTU of 1280 refers readers to RFC 2460 Section 5, which describes an MTU of 1280
octets and a minimum fragment reassembly of 1500 octets. It's octets and a minimum fragment reassembly of 1500 octets. It's
feasible to suggest that DHCPv6 is capable of having larger options feasible to suggest that DHCPv6 is capable of having larger options
deployed over it, and at least no common upper limit is yet known to deployed over it, and at least no common upper limit is yet known to
have been encoded by its implementors. It is impossible to describe have been encoded by its implementors. It is impossible to describe
any fixed limit that cleanly divides those too big from the workable. any fixed limit that 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. requirements. A common sense still applies here. It is better to
split distinct values into separate octects rather than propose
overly complex bit shifting operations to save up several bits (or
even an octet or two) that would be padded to the next octet boundary
anyway.
DHCPv6 does allow for multiple instances of a given option, and they DHCPv6 does allow for multiple instances of a given option, and they
are treated as distinct values following the defined format, however are treated as distinct values following the defined format, however
this feature is generally preferred to be restricted to protocol this feature is generally preferred to be restricted to protocol
class features (such as the IA_* series of options). In such cases, class features (such as the IA_* series of options). In such cases,
it is better to define an option as an array if it is possible. It it is better to define an option as an array if it is possible. It
is recommended to clarify (with normative language) whether a given is recommended to clarify (with normative language) whether a given
DHCPv6 option may appear once or multiple times. DHCPv6 option may appear once or multiple times.
15. Clients Request their Options 15. Clients Request their Options
skipping to change at page 16, line 19 skipping to change at page 16, line 41
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 a frequent mistake of option draft authors, then, to create It is tempting to put a text that requires the client to include new
text that implies that a server will simply provide the new option, option in Option Request Option list, similar to this text: "Clients
and clients will digest it. Generally, it's best to also specify MUST place the foo option code on the Option Request Option list,
that clients MUST place the new option code on the Option Request clients MAY include option foo in their packets as hints for the
Option list, clients MAY include the new option in their packets to server as values the desire, and servers MUST include option foo when
servers with hints as values they desire, and server MAY include the the client requested it (and the server has been so configured)".
option when the client requested it (and the server has been so Such a text is discouraged as there are several issues with it.
configured). First, it assumes that client implementation that supports a given
option will always want to use it. This is not true. The second and
Example: Clients MUST place the foo option code on the Option Request more important reason is that such a text essentially duplicates
Option list, clients MAY include option foo in their packets as hints mechanism already defined in [RFC3315]. It is better to simply refer
for the server as values the desire, and servers MAY include option to existing mechanism rather than define it again. See Section 17
foo when the client requested it (and the server has been so for proposed examples on how to do that.
configured).
Creators of DHCPv6 options MUST NOT require special ordering of Creators of DHCPv6 options MUST NOT require special ordering of
options either in the relevant request option, or in the order of options either in the relevant request option, or in the order of
options within the packet. Although it is reasonable to expect that options within the packet. Although it is reasonable to expect that
options will be processed in the order they appear in ORO, server options will be processed in the order they appear in ORO, server
software is not required to sort DHCPv6 options into the same order software is not required to sort DHCPv6 options into the same order
in reply messages. It should be noted that any requirement regarding in reply messages. It should be noted that any requirement regarding
option ordering will break down most existing implementations, as option ordering will break down most existing implementations, as
"order is not important" was one of the design priciples of DHCPv6 "order is not important" was one of the design priciples of DHCPv6
and many implementations follow it. For example, there are existing and many implementations follow it. For example, there are existing
implementations that use hash maps for storing options, so forcing implementations that use hash maps for storing options, so forcing
any particular order is not feasible without great deal of work. If any particular order is not feasible without great deal of work. If
options must be processed in any specific order (e.g. due to inter- options must be processed in any specific order (e.g. due to inter-
dependency), use of option encapsulation should be considered. dependency), use of option encapsulation should be considered.
16. Transition Technologies 16. Transition Technologies
Transition from IPv4 to IPv6 is progressing, albeit at somewhat Transition from IPv4 to IPv6 is progressing, albeit at somewhat
disappointing pace. Many transition technologies are proposed to disappointing pace. Many transition technologies are proposed to
speed it up. As a natural consequence there are also DHCP options speed it up. As a natural consequence there are also DHCP options
proposed to provision those proposals. The inevitable question is proposed to provision those proposals. The inevitable question is
that whether the required parameters should be delivered over DHCPv4 that whether the required parameters should be delivered over DHCPv4
or DHCPv6. Authors often don't give much thought about it and simply or DHCPv6. Authors often don't give much thought about it and simply
pick DHCPv6 without realizing the consequences. IPv6 is expected to pick DHCPv6 without realizing the consequences. IPv6 is expected to
stay with us for many decades, and so is DHCPv6. There is no stay with us for many decades, and so is DHCPv6. There is no
mechanism available to deprecate an option in DHCPv6, so any options mechanism available to deprecate an option in DHCPv6, so any options
defined will stay with us as long as DHCPv6 protocol itself. It defined will stay with us as long as DHCPv6 protocol itself. It
seems likely that such options defined to transition from IPv4 will seems likely that such options defined to transition from IPv4 will
outlive IPv4 by many decades. From that perspective it is better to outlive IPv4 by many decades. From that perspective it is better to
implement provisioning of the transition technologies in DHCPv4, implement provisioning of the transition technologies in DHCPv4,
which will be obsoleted together with IPv4. which will be obsoleted together with IPv4.
17. Security Considerations 17. Recommended sections in the new document
There are three major entities in DHCPv6 protocol: server, relay
agent, and client. There is also a separate entity called requestor,
which is a special client-like type that participates in leasequery
protocol [RFC5007] and [RFC5460]. It is very helpful for
implementors to include separate sections that describe operation for
those three major components. Even when a given entity does not
participate, it is useful to have a very short section stating that
it must not send a given option and must ignore it when received.
Similar section for requestor is not required, unless the new option
has anything to do with requestor (or it is likely that the reader
may think that is has). It should be noted that while in majority of
deployments, requestor is colocated with relay agent, those are two
separate entities from the protocol perspective and they may be used
separately. There are stand-alone requestor implementations
available.
The following sections include proposed text for such sections. That
text is not required to appear, but it is appropriate in most cases.
Additional or modified text specific to a given option is often
required.
Although requestor is somewhat uncommon functionality, its existence
should be noted, especially when allowing or disallowing options to
appear in certain message or being sent be certain entities.
Additional message types may appear in the future, besides types
defined in [RFC3315]. Therefore authors are encouraged to
familiarize themselves with a list of currently defined DHCPv6
messages available on IANA website [iana].
Typically new options are requested by clients and assigned by
server, so there is no specific relay behavior. Nevertheless it is
good to include a section for relay agent behaviour and simply state
that there are no additional requirements for relays. The same
applies for client behavior if the options are to be exchanged
between relay and server.
Section that contain option definition MUST include formal
verification procedure. Often it is very simple, e.g. option that
conveys IPv6 address must be exactly 16 bytes long, but sometimes the
rules are more complex. It is recommeded to refer to existing
documents (e.g. section 8 of RFC3315 for domain name enconding)
rather than trying to repeat such rules.
17.1. DHCPv6 Client Behavior
Client MAY request option foo, as defined in [RFC3315], sections
17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5 and 22.7. As a convenience to
the reader, we mention here that the client includes requested option
codes in Option Request Option.
Optional text (if client's hints make sense): Client also MAY include
option foo in its SOLICIT, REQUEST, RENEW, REBIND and INFORMATION-
REQUEST messages as a hint for the server regarding preferred option
values.
Optional text (if the option contains FQDN): If the client request an
option that conveys FQDN, it is expected that content of that option
will be resolved using DNS. Hence the following text may be useful:
Client that requests option foo SHOULD also request option
OPTION_DNS_SERVERS specified in [RFC3646].
Client MUST discard option foo if it is invalid (i.e. did not pass
validation steps defined in Section X.Y).
Optional text (if option foo in expected to be exchanged between
relays or request and server): Option foo is exchanged between relays
and servers only. Clients are not aware of the usage of option foo.
Clients MUST ignore received option foo.
17.2. DHCPv6 Server Behavior
Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in
regards of option assignment. As a convenience to the reader, we
mention here that the server will send option foo only if configured
with specific values for foo and client requested it.
Optional text: Server MUST NOT send more than one instance of foo
option.
Optional text (if server is never supposed to receive option foo):
Server MUST ignore incoming foo option.
17.3. DHCPv6 Relay Agent Behavior
Optional text (if foo option is exchanged between clients and server
or between requestors and servers): There are no additional
requirements for relays.
Optional text (if relays are expected to insert or consume option
foo): Relay agents MAY include option foo when forwarding packets
from clients to the server.
18. Should the new document update existing RFCs?
Authors often ask themselves a question whether their proposal
updates exist RFCs, especially 3315. During time of writing this
document there were 79 options defined. Had all documents that
defined them also updated RFC3315, its comprehension of such a
document would be extremely difficult. It should be noted that
"extends" and "updates" are two very different verbs. If a new draft
defines a new option that clients request and servers provide, it
merely extends current standards, so "updates 3315" is not required
in the new document header. On the other hand, if the new draft
changes something in already defined behavior, e.g. servers must
discard incoming messages if option foo is invalid or missing, then
the "updates" phrase is warranted.
19. Security Considerations
DHCPv6 does have an Authentication mechanism ([RFC3315]) that makes DHCPv6 does have an Authentication mechanism ([RFC3315]) that makes
it possible for DHCPv6 software to discriminate between authentic it possible for DHCPv6 software to discriminate between authentic
endpoints and men in the middle. Other authentication mechanisms may endpoints and men in the middle. Other authentication mechanisms may
optionally be deployed. For example, the Secure DHCPv6 optionally be deployed. For example, the Secure DHCPv6
[I-D.ietf-dhc-secure-dhcpv6], based on Cryptographically Generated [I-D.ietf-dhc-secure-dhcpv6], based on Cryptographically Generated
Addresses (CGA) [RFC3972], can provide source address ownership Addresses (CGA) [RFC3972], can provide source address ownership
validation, message origin authentication and message integrity validation, message origin authentication and message integrity
without requiring symmetric key pairs or supporting from any key without requiring symmetric key pairs or supporting from any key
management system. However, as of now, the mechanism is not widely management system. However, as of now, the mechanism is not widely
skipping to change at page 18, line 18 skipping to change at page 21, line 8
address, or local broadcast address, and depending on the protocol address, or local broadcast address, and depending on the protocol
this may lead to undesirable results. A domain name field may be this may lead to undesirable results. A domain name field may be
filled with contrived contents that exceed the limitations placed filled with contrived contents that exceed the limitations placed
upon domain name formatting - as this value is possibly delivered to upon domain name formatting - as this value is possibly delivered to
"internal configuration" records of the system, it may be implicitly "internal configuration" records of the system, it may be implicitly
trusted without being validated. trusted without being validated.
So it behooves an option's definition to contain any validation So it behooves an option's definition to contain any validation
measures as can reasonably be made. measures as can reasonably be made.
18. IANA Considerations 20. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
19. Acknowledgements 21. 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.
20. Informative References 22. Informative References
[I-D.ietf-dhc-secure-dhcpv6] [I-D.ietf-dhc-secure-dhcpv6]
Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", draft-
draft-ietf-dhc-secure-dhcpv6-07 (work in progress), ietf-dhc-secure-dhcpv6-07 (work in progress), September
September 2012. 2012.
[I-D.ietf-softwire-4rd] [I-D.ietf-softwire-4rd]
Jiang, S., Despres, R., Penno, R., Lee, Y., Chen, G., and Jiang, S., Despres, R., 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-04 (work in
progress), October 2012. progress), October 2012.
[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", for Mapping of Address and Port", draft-ietf-softwire-map-
draft-ietf-softwire-map-dhcp-03 (work in progress), dhcp-03 (work in progress), February 2013.
February 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol Protocol (DHCPv6) Options for Session Initiation Protocol
skipping to change at page 19, line 43 skipping to change at page 22, line 31
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.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February
2009.
[RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) [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.
[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,
<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
Email: dhankins@google.com Email: dhankins@google.com
Tomasz Mrugalski Tomek Mrugalski
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Phone: +1 650 423 1345 Phone: +1 650 423 1345
Email: tomasz.mrugalski@gmail.com Email: tomasz.mrugalski@gmail.com
Marcin Siodelski Marcin Siodelski
950 Charter Street 950 Charter Street
 End of changes. 38 change blocks. 
105 lines changed or deleted 254 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/