draft-ietf-dhc-option-guidelines-09.txt   draft-ietf-dhc-option-guidelines-10.txt 
Dynamic Host Configuration Working D. Hankins Dynamic Host Configuration Working D. Hankins
Group Google Group Google
Internet-Draft T. Mrugalski Internet-Draft T. Mrugalski
Updates: 3315 (if approved) M. Siodelski Updates: 3315 (if approved) M. Siodelski
Intended status: Standards Track ISC Intended status: Standards Track ISC
Expires: June 23, 2013 S. Jiang Expires: August 29, 2013 S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
S. Krishnan S. Krishnan
Ericsson Ericsson
December 20, 2012 February 25, 2013
Guidelines for Creating New DHCPv6 Options Guidelines for Creating New DHCPv6 Options
draft-ietf-dhc-option-guidelines-09 draft-ietf-dhc-option-guidelines-10
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 June 23, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . . 4 3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . . 4
4. General Principles . . . . . . . . . . . . . . . . . . . . . . 4 4. General Principles . . . . . . . . . . . . . . . . . . . . . . 4
5. Reusing Other Options . . . . . . . . . . . . . . . . . . . . 5 5. Reusing Other Options . . . . . . . . . . . . . . . . . . . . 5
5.1. Option with IPv6 addresses . . . . . . . . . . . . . . . . 5 5.1. Option with IPv6 addresses . . . . . . . . . . . . . . . . 5
5.2. Option with 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 . . . . . . . . . . . . . 8 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
5.9. Option with IPv6 Prefix . . . . . . . . . . . . . . . . . 10 6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . . 10
6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . . 11
7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Choosing between FQDN and address . . . . . . . . . . . . . . 12 8. Choosing between FQDN and address . . . . . . . . . . . . . . 11
9. Suboptions in DHCPv6 . . . . . . . . . . . . . . . . . . . . . 14 9. Suboptions in DHCPv6 . . . . . . . . . . . . . . . . . . . . . 13
10. Additional States Considered Harmful . . . . . . . . . . . . . 14 10. Additional States Considered Harmful . . . . . . . . . . . . . 13
11. Is DHCPv6 dynamic? . . . . . . . . . . . . . . . . . . . . . . 15 11. Is DHCPv6 dynamic? . . . . . . . . . . . . . . . . . . . . . . 14
12. Multiple provisioning domains . . . . . . . . . . . . . . . . 15 12. Multiple provisioning domains . . . . . . . . . . . . . . . . 14
13. Considerations for Creating New Formats . . . . . . . . . . . 16 13. Considerations for Creating New Formats . . . . . . . . . . . 15
14. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 16 14. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 15
15. Clients Request their Options . . . . . . . . . . . . . . . . 16 15. Clients Request their Options . . . . . . . . . . . . . . . . 16
16. Transition Technologies . . . . . . . . . . . . . . . . . . . 17 16. Transition Technologies . . . . . . . . . . . . . . . . . . . 16
17. Security Considerations . . . . . . . . . . . . . . . . . . . 18 17. Security Considerations . . . . . . . . . . . . . . . . . . . 17
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
20. Informative References . . . . . . . . . . . . . . . . . . . . 19 20. Informative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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 29 skipping to change at page 5, line 29
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 preferrable 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
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
skipping to change at page 7, line 20 skipping to change at page 7, line 20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Sometimes there is a need to convey IPv6 prefix. The information to
that should be delivered to the user is a 128-bit IPv6 prefix be carried by an option includes the 128-bit IPv6 prefix together
together with a prefix length that takes values from 0 to 128. Using with a length of this prefix taking values from 0 to 128. Using the
the simplest approach, the option would convey that information as simplest approach, the option could convey this data in two fixed
is. However, in many cases /64 or shorter prefixes are used. That length fields: one carrying prefix length, another carrying the
means that remaining 128 - prefix length bits are zeros. That means prefix. However, in many cases /64 or shorter prefixes are used.
that in typical case case of /64 prefixes the option would contains This implies that the large part of the prefix data carried by the
at least 8 bytes of useless zeros. That should be avoided. For that option would have its bits set to zero and would be unused. In order
reason the recommended format for storing prefixes is as follows: to avoid carrying unused data, it is recommended to store prefix in
the variable length data field. The appropriate option format is
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_MAP_DMR | 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. prefix6-len is
it one octet long and specifies prefix length of the IPv6 prefix one octet long and specifies the length in bits of the IPv6 prefix.
expressed in bits. Typically allowed values are 0 to 128. 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.
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]
It should be noted that Prefix Delegation mechanism used in [RFC3633] It should be noted that Prefix Delegation mechanism used in [RFC3633]
skipping to change at page 10, line 32 skipping to change at page 10, line 33
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)
5.9. Option with IPv6 Prefix
Some options need to convey IPv6 prefix. Such a prefix includes the
prefix itself and a prefix length. The simple approach would be to
define a 128 bit field denoting a prefix, followed by a 8 bit field
that specifies prefix length. This approach was used in
OPTION_IAPREFIX, defined in [RFC3633]. That approach is no longer
recommended and should not be used anymore.
In many cases configured prefix lengths are /64 or even shorter.
That means that every option conveys many zeroes bits that are
useless. For example for /48 there are 10 bytes of useless data.
This waste is mulitpled by the number of option instances in a
message. Therefore a different approach should be used. Prefixes
should be conveyed as 8 bit prefix length field that is followed by
variable length prefix.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix6-len | |
+-+-+-+-+-+-+-+-+ ipv6-prefix |
| (variable length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Option with IPv6 Prefix
The following description of the fields can be included in the draft:
o prefix6-len: 8 bits long field expressing the bit mask length of
the IPv6 prefix specified in the ipv6-prefix field.
o ipv6-prefix: a variable length field that specifies the IPv6
prefix for (explain purpose of the prefix). The field is padded
with zeros up to the nearest octet boundary when prefix6-len is
not divisible by 8.
It should be pointed out that similar optimization does not provide
useful savings in case of IPv4 prefixes. IPv4 prefixes should be
sent as a 32 bits fields.
6. Avoid Conditional Formatting 6. Avoid Conditional Formatting
Placing a octet at the start of the option which informs the software Placing an octet at the start of the option which informs the
how to process the remaining octets of the option may appear simple software how to process the remaining octets of the option may appear
to the casual observer. But the only conditional formatting methods simple to the casual observer. But the only conditional formatting
that are in widespread use today are 'protocol' class options. So methods that are in widespread use today are 'protocol' class
conditional formatting requires new code to be written, as well as options. Therefore the conditional formatting requires new code to
introduces an implementation problem; as it requires that all be written, as well as introduces an implementation problem; as it
speakers implement all current and future conditional formats. requires that all speakers implement all current and future
conditional formats.
Conditional formatting is not recommended, except in cases where the Conditional formatting is not recommended, except in cases where the
DHCPv6 option has already been deployed experimentally, and all but DHCPv6 option has already been deployed experimentally, and all but
one conditional format is deprecated. 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 a 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 values the server will provide, they must request all formats. So in
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. option space is wasted on option contents that are redundant.
It also becomes unclear which types of values are mandatory, and how It also becomes unclear which types of values are mandatory, and how
configuring some of the options may influence the others. For configuring some of the options may influence the others. For
example, if an operator configures the URL only, should the server example, if an operator configures the URL only, should the server
synthesize a domain name and IP address? synthesize a domain name and IP address?
A single configuration value on a host is probably presented to the A single configuration value on a host is probably presented to the
operator (or other software on the machine) in a single field or operator (or other software on the machine) in a single field or
channel. If that channel has a natural format, then any alternative channel. If that channel has a natural format, then any alternative
skipping to change at page 13, line 11 skipping to change at page 12, line 16
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 does require a resolution into an actual address. This implies FQDN does require a resolution into an actual address. This implies
number of questions that should be answered. First is when should the question when the FQDN resolution should be taken. There are a
the resolution be taken. There are couple possible answers: a) by couple of possible answers: a) by the server, when it is started, b)
the server, when it is started, b) by the server, when it is about to by the server, when it is about to send an option, c) by the client,
send an option, c) by the client, immediately after receiving an immediately after receiving an option, d) by the client, when the
option, d) by the client, when the content of the option is actually content of the option is actually consumed. For a), b) and possibly
consumed. For a), b) and possibly c), the option should really c), the option should really convey an address, not FQDN. The only
convey an address, not FQDN. The only real incentive to use FQDN is real incentive to use FQDN is case d). It is the only case that
case d). It is the only case that allows possible changes in the DNS allows possible changes in the DNS to be picked up by clients.
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. 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;
skipping to change at page 15, line 14 skipping to change at page 14, line 17
provisioned node uses its unique address and delegated prefix to provisioned node uses its unique address and delegated prefix to
generate node-specific information. Such solution does not introduce generate node-specific information. Such solution does not introduce
any additional state for the server and therefore scales better. 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 For renewing other parameters, please use Information Refresh Time
Option (defined in [RFC4242]). Introducing additional timers make Option (defined in [RFC4242]). Introducing additional timers make
deployment unnecessarily complex. Please try to avoid it. deployment unnecessarily complex 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, is 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 till 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
ADVERTISE message, may respond to one or more, such capability was ADVERTISE message, may respond to one or more of them, such
never observed in any known implementations. Existing clients will capability was never observed in any known implementations. Existing
pick one server and will continue configuration process with that clients will pick one server and will continue configuration process
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. Considerations for Creating New Formats
If the option simply will not fit into any existing work by using If the option simply will not fit into any existing work by using
fragments, the last recourse is to create a new format to fit. fragments, the last recourse is to create a new format to fit.
skipping to change at page 17, line 5 skipping to change at page 16, line 9
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
The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315], is an option The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315], is an option
that serves two purposes - to inform the server what options the that serves two purposes - to inform the server what options the
client supports and is willing to consume. client supports and to inform what options the client is willing to
consume.
It doesn't make sense for some options to appear on this Option It doesn't make sense for some options to 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 a frequent mistake of option draft authors, then, to create
text that implies that a server will simply provide the new option, text that implies that a server will simply provide the new option,
and clients will digest it. Generally, it's best to also specify and clients will digest it. Generally, it's best to also specify
that clients MUST place the new option code on the Option Request that clients MUST place the new option code on the Option Request
skipping to change at page 19, line 7 skipping to change at page 18, line 11
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 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 18. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
skipping to change at page 19, line 37 skipping to change at page 18, line 41
draft-ietf-dhc-secure-dhcpv6-07 (work in progress), draft-ietf-dhc-secure-dhcpv6-07 (work in progress),
September 2012. September 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., Bao, C., Dec, W., and L. Yeh, Mrugalski, T., Troan, O., Dec, W., Bao, C.,
"DHCPv6 Options for Mapping of Address and Port", leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options
draft-ietf-softwire-map-dhcp-01 (work in progress), for Mapping of Address and Port",
August 2012. draft-ietf-softwire-map-dhcp-03 (work in progress),
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 21, line 29 skipping to change at page 20, line 33
Tomasz Mrugalski Tomasz 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
Redwood City, CA 94063
USA
Phone: Phone: +1 650 423 1431
Email: msiodelski@gmail.com Email: msiodelski@gmail.com
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095 Hai-Dian District, Beijing, 100095
P.R. China P.R. China
Email: jiangsheng@huawei.com Email: jiangsheng@huawei.com
Suresh Krishnan Suresh Krishnan
 End of changes. 27 change blocks. 
112 lines changed or deleted 74 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/