draft-ietf-dhc-option-guidelines-14.txt   draft-ietf-dhc-option-guidelines-15.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: Best Current Practice M. Siodelski
Intended status: BCP ISC Expires: June 12, 2014 ISC
Expires: March 22, 2014 S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
S. Krishnan S. Krishnan
Ericsson Ericsson
September 18, 2013 December 9, 2013
Guidelines for Creating New DHCPv6 Options Guidelines for Creating New DHCPv6 Options
draft-ietf-dhc-option-guidelines-14 draft-ietf-dhc-option-guidelines-15
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. It also provides guidelines
RFC3315. for expert reviewers to evaluate new registrations. This document
updates RFC3315.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 22, 2014. This Internet-Draft will expire on June 12, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . . 5 3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . 4
4. General Principles . . . . . . . . . . . . . . . . . . . . . . 5 4. General Principles . . . . . . . . . . . . . . . . . . . . . 5
5. Reusing Other Options Formats . . . . . . . . . . . . . . . . 6 5. Reusing Other Options Formats . . . . . . . . . . . . . . . . 5
5.1. Option with IPv6 addresses . . . . . . . . . . . . . . . . 7 5.1. Option with IPv6 addresses . . . . . . . . . . . . . . . 6
5.2. Option with a single flag (boolean) . . . . . . . . . . . 8 5.2. Option with a single flag (boolean) . . . . . . . . . . . 7
5.3. Option with IPv6 prefix . . . . . . . . . . . . . . . . . 8 5.3. Option with IPv6 prefix . . . . . . . . . . . . . . . . . 7
5.4. Option with 32-bit integer value . . . . . . . . . . . . . 9 5.4. Option with 32-bit integer value . . . . . . . . . . . . 8
5.5. Option with 16-bit integer value . . . . . . . . . . . . . 10 5.5. Option with 16-bit integer value . . . . . . . . . . . . 9
5.6. Option with 8-bit integer value . . . . . . . . . . . . . 10 5.6. Option with 8-bit integer value . . . . . . . . . . . . . 9
5.7. Option with URI . . . . . . . . . . . . . . . . . . . . . 10 5.7. Option with URI . . . . . . . . . . . . . . . . . . . . . 10
5.8. Option with Text String . . . . . . . . . . . . . . . . . 11 5.8. Option with Text String . . . . . . . . . . . . . . . . . 11
5.9. Option with variable length data . . . . . . . . . . . . . 13 5.9. Option with variable length data . . . . . . . . . . . . 12
5.10. Option with DNS Wire Format Domain Name List . . . . . . . 13 5.10. Option with DNS Wire Format Domain Name List . . . . . . 13
6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . . 14 6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . 13
7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . 14
8. Choosing between FQDN and address . . . . . . . . . . . . . . 15 8. Choosing between FQDN and address . . . . . . . . . . . . . . 14
9. Encapsulated options in DHCPv6 . . . . . . . . . . . . . . . . 16 9. Encapsulated options in DHCPv6 . . . . . . . . . . . . . . . 17
10. Additional States Considered Harmful . . . . . . . . . . . . . 17 10. Additional States Considered Harmful . . . . . . . . . . . . 18
11. Configuration changes occur at fixed times . . . . . . . . . . 18 11. Configuration changes occur at fixed times . . . . . . . . . 19
12. Multiple provisioning domains . . . . . . . . . . . . . . . . 19 12. Multiple provisioning domains . . . . . . . . . . . . . . . . 19
13. Chartering Requirements and Advice for Responsible ADs . . . . 19 13. Chartering Requirements and Advice for Responsible Area
14. Considerations for Creating New Formats . . . . . . . . . . . 20 Directors . . . . . . . . . . . . . . . . . . . . . . . . . . 20
15. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 21 14. Considerations for Creating New Formats . . . . . . . . . . . 21
16. Singleton options . . . . . . . . . . . . . . . . . . . . . . 21 15. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 21
17. Option Order . . . . . . . . . . . . . . . . . . . . . . . . . 22 16. Singleton options . . . . . . . . . . . . . . . . . . . . . . 22
18. Relay Options . . . . . . . . . . . . . . . . . . . . . . . . 22 17. Option Order . . . . . . . . . . . . . . . . . . . . . . . . 23
19. Clients Request their Options . . . . . . . . . . . . . . . . 23 18. Relay Options . . . . . . . . . . . . . . . . . . . . . . . . 23
20. Transition Technologies . . . . . . . . . . . . . . . . . . . 24 19. Clients Request their Options . . . . . . . . . . . . . . . . 24
21. Recommended sections in the new document . . . . . . . . . . . 24 20. Transition Technologies . . . . . . . . . . . . . . . . . . . 25
21.1. DHCPv6 Client Behavior Text . . . . . . . . . . . . . . . 25 21. Recommended sections in the new document . . . . . . . . . . 25
21.2. DHCPv6 Server Behavior Text . . . . . . . . . . . . . . . 26 21.1. DHCPv6 Client Behavior Text . . . . . . . . . . . . . . 26
21.3. DHCPv6 Relay Agent Behavior Text . . . . . . . . . . . . . 26 21.2. DHCPv6 Server Behavior Text . . . . . . . . . . . . . . 26
22. Should the new document update existing RFCs? . . . . . . . . 26 21.3. DHCPv6 Relay Agent Behavior Text . . . . . . . . . . . . 27
23. Security Considerations . . . . . . . . . . . . . . . . . . . 27 22. Should the new document update existing RFCs? . . . . . . . . 27
24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 23. Security Considerations . . . . . . . . . . . . . . . . . . . 28
25. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 24. Privacy considerations . . . . . . . . . . . . . . . . . . . 29
26. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
26.1. Normative References . . . . . . . . . . . . . . . . . . . 28 26. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
26.2. Informative References . . . . . . . . . . . . . . . . . . 28 27. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 27.1. Normative References . . . . . . . . . . . . . . . . . . 30
27.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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 8 skipping to change at page 4, line 15
o If the option would work well in the particular deployment o If the option would work well in the particular deployment
environment the proponents currently envision, but has equally environment the proponents currently envision, but has equally
valid uses in some other environment where the proposed option valid uses in some other environment where the proposed option
format would fail or would produce inconsistent results. 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.
This document is envisaged as a help for protocol developers that
define new options and for expert reviewers that review submitted
proposals.
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
skipping to change at page 8, line 7 skipping to change at page 7, line 15
DHCPv6 [RFC4280] DHCPv6 [RFC4280]
o MIPv6 Home Agent Address [RFC6610] (a single address only) o MIPv6 Home Agent Address [RFC6610] (a single address only)
o NTP server [RFC5908] (a single address only) o NTP server [RFC5908] (a single address only)
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 take either
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 take
explicit actions to deploy the opposite of the default value. explicit actions to deploy the opposite of the default value.
The absence of the option represents the default value and the
presence of the option represents the other value, but that this does
not necessarily mean that absence is "off" (or "false") and presence
is "on" (or "true"). That is, if it's desired that the default value
for a bistable option is "true"/"on", then the presence of that
option would turn it off (make it false). If the option presence
signifies off/false state, that should be reflected in the option
name, e.g. OPTION_DISABLE_FOO.
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 9, line 10 skipping to change at page 8, line 16
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 | | prefix6len | 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. option-length is set to 1 + length of the IPv6 prefix.
prefix6-len is one octet long and specifies the length in bits of the prefix6len is one octet long and specifies the length in bits of the
IPv6 prefix. Typically allowed values are 0 to 128. 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. The length is (prefix6-len + 7) / 8. This field is padded prefix. The length is (prefix6len + 7) / 8. This field is padded
with zero bits up to the nearest octet boundary when prefix6-len is with zero bits up to the nearest octet boundary when prefix6len is
not divisible by 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, prefix6-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 contain 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.
skipping to change at page 11, line 43 skipping to change at page 11, line 10
Figure 8: Option with multiple URIs Figure 8: Option with multiple URIs
Each instance of the uri-data is formatted as follows: Each instance of the uri-data is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| uri-len | URI | | uri-len | URI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
The uri-len is two octets long and specifies the length of the uri The uri-len is two octets long and specifies the length of the uri
data. data. Although URI format in theory supports up to 64k of data, in
practice large chunks of data may be problematic. See Section 15 for
details.
5.8. Option with Text String 5.8. Option with Text String
A text string is a sequence of characters that have no semantics. A text string is a sequence of characters that have no semantics.
The encoding of the text string MUST be specified. Unless otherwise The encoding of the text string MUST be specified. Unless otherwise
specified, all text strings in newly defined options are expected to specified, all text strings in newly defined options are expected to
be Unicode strings that are encoded using UTF-8 [RFC3629] in Net- be Unicode strings that are encoded using UTF-8 [RFC3629] in Net-
Unicode form [RFC5198]. Please note that all strings containing only Unicode form [RFC5198]. Please note that all strings containing only
7 bit ASCII characters are also valid UTF-8 Net-Unicode strings. 7 bit ASCII characters are also valid UTF-8 Net-Unicode strings.
If a data format has semantics other than just being text, it is not 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 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 string, because they have different semantics. A string must not
enclude any terminator (such as a null byte). This option format can include any terminator (such as a null byte). The null byte is
be used to carry a text string: treated as any other character and does not have any special meaning.
This option format can be used to carry a text string:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. String . . String .
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Option with text string Figure 9: Option with text string
skipping to change at page 14, line 11 skipping to change at page 13, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: 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 LoST Server Domain name [RFC5223]
o LIS Domain name [RFC5986]
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
skipping to change at page 15, line 17 skipping to change at page 14, line 42
formats merely make more work for intervening software in providing formats merely make more work for intervening software in providing
conversions. conversions.
So the best advice is to choose the one method that best fulfills the So the best advice is to choose the one method that best fulfills the
requirements, be that for simplicity (such as with an IP address and requirements, be that for simplicity (such as with an IP address and
port pair), late binding (such as with DNS), or completeness (such as port pair), late binding (such as with DNS), or completeness (such as
with a URL). with a URL).
8. Choosing between FQDN and address 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. In most
allowed to define both option types at the same time (see section cases one or the other should be used. This section discusses pros
Section 7), so one of them must be chosen. This section is intended and cons of each approach and is intended to help make an informed
to help make an informed decision in that regard. decision in that regard. It is strongly discouraged to define both
option types at the same time (see Section 7), unless there is
sufficient motivation to do so.
On the specific subject of desiring to configure a value using a FQDN There is no single recommendation that works for every case. It very
instead of a binary IP address, note that most DHCPv6 server much depends on the nature of the parameter being configured. For
implementations will happily accept a Domain Name entered by the parameters that are network specific or represent certain aspects of
administrator, and use DNS resolution to render binary IP addresses network infrastructure, like NTP servers, available mobility services
in DHCPv6 replies to clients. Consequently, consider the extra etc., in most cases address is more usable choice. For parameters
packet overhead incurred on the client's end to perform DNS that can be considered application specific configuration, like SIP
resolution itself. The client may be operating on a battery and servers, it is usually better to use FQDN.
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
least two factors to consider in making a decision on format.
Unless there are specific reasons to do otherwise, address should be Applications are often better suited to deal with FQDN failures than
used. It is simpler to use, its validation is trivial (length of 16 with address failures. Most operating systems provide a way to retry
constitutes a valid option), is explicit and does not allow any FQDN resolution if the previous attempt fails. That type of error
ambiguity. It is faster (does not require extra resolution efforts), recovery is supported by a great number of applications. On the
so it is more efficient, which can be especially important for energy other hand, there is typically no API availble for applications to
restricted devices. reconfigure over DHCP to get a new address value if the one received
is no longer appropriate. This problem may be partially addressed by
providing a list of addresses, rather than just a single one. That,
on the other hand, complicates client operation, as some kind of
failover procedure has to be defined and implemented.
FQDN options are discouraged for options intended to configure hosts, FQDN provide a higher level of indirection and ambiguity. In many
because hosts may have multiple provisioning domains (see cases that may be considered a benefit, but can be considered a flaw
Section 12), and may get a different answer from the DNS depending on in others. For example, one operator suggested to have the same name
the provisioning domain. This is particularly a problem when the being resolved to different addresses depending on the point of
normal expected use of the option makes sense with private DNS attachement of the host doing resolution. This allows pointing at
zone(s), as might be the case with a corporate VPN. more localized services. However, such a practice requires violating
DNS principles ('split horizon'), and hence is not recommended.
The other type of ambiguity is related to multiple provisioning
domains (see Section 12), and may get a different answer from the DNS
depending on which interface or DNS server is used to do the
resolution. 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. It may also be the case that the
client has explicit DNS server configured so may not be using the
corporate internal DNS server.
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 conducted. There are
couple of possible answers: a) by the server, when it is started, b) a couple of possible answers: a) by the server, when it is started,
by the server, when it is about to send an option, c) by the client, b) by the server, when it is about to send an option, c) by the
immediately after receiving an option, d) by the client, when the client, immediately after receiving an option, d) by the client, when
content of the option is actually consumed. For a), b) and possibly the content of the option is actually consumed. For a), b) and
c), the option should really convey an address, not FQDN. The only possibly c), the option should really convey an address, not FQDN.
real incentive to use FQDN is case d). It is the only case that The only real incentive to use FQDN is case d). It is the only case
allows possible changes in the DNS to be picked up by clients. that allows possible changes in the DNS to be picked up by clients.
It may be generalized that the preference for address or FQDN depends
on its envisaged usage. Short lived (immediately consumed) data
should be address based, while long timed information is better
served with FQDN.
If the parameter is expected to be used by constrained devices (low
power, battery operated, low capabilities) or in very lossy networks,
it may be appealing to drop the requirement of having DNS resolution
being performed and use addresses. Another example of a constrained
device is a network booted device, where despite the fact that the
node itself is very capable once it's booted, the boot prom is quite
constrained.
Another aspect that should be considered is time required for the
clients to notice any configuration changes. Consider a case where a
server configures a service A using address and service B using FQDN.
When an administrator decides to update the configuration, he or she
can update the DHCP server configuration to change both services. If
the clients do not support reconfigure (which is an optional feature
of RFC3315, but in some environments, e.g. cable modems, is
mandatory), the configuration will be updated on clients after T1
timer elapses. Depending on the nature of the change (is it a new
server added to a cluster of already operating servers or a new
server that replaces the only available server that crashed?), this
may be an issue. On the other hand, updating service B may be
achieved with DNS record update. That information may be cached by
caching DNS servers for up to TTL. Depending on the values of T1 and
TTL, one update may be faster than another. Furthermore, depending
on the nature of the change (planned modification or unexpected
failure), T1 or TTL may be lowered before the change to speed up new
configuration adoption.
Addresses have a benefit of being easier to implemented and handle by
the DHCP software. An address option is simpler to use, its
validation is trivial (multiple of 16 constitutes a valid option), is
explicit and does not allow any ambiguity. It is faster (does not
require extra round trip time), so it is more efficient, which can be
especially important for energy restricted devices. It also does not
require having resolution capability.
FQDN imposes a 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 [RFC3646] is
should be mentioned in the draft that defines new option. It is mandatory. This should be mentioned in the draft that defines
possible that the server will return FQDN option, but not the DNS new option. It is possible that the server will return FQDN
Servers option. There should be a brief discussion about it; option, but not the DNS 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); the
information being configured may require specific address family
(e.g. IPv6), but there may be a DNS record only of another type
(e.g. A only with IPv4 address).
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.); This may be
an issue if there is an expectation that the parameter being
configured will need exactly one address;
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 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, DNS option encoding should be specified.
specified.
Address options that are used with overly long T1 (renew timer)
values have some characteristics of hardcoded values. That is
strongly discouraged. See [RFC4085] for an in depth discussion. If
the option may appear in Information-Request, its lifetime should be
controlled using information refresh time option [RFC4242].
One specific case that makes the choice between address and FQDN not
obvious is a DNSSEC bootstrap scenario. DNSSEC validation imposes a
requirement for clock sync (to the accuracy reasonably required to
consider signature inception and expiry times). This often implies
usage of NTP configuration. However, if the NTP is provided as FQDN,
there is no way to validate its DNSSEC signature. This is somewhat
weak argument though, as providing NTP server as an address is also
not verifiable using DNSSEC. If the thrustworthiness of the
configuration provided by DHCP server is in question, DHCPv6 offers
authentication mechanisms that allow server authentication.
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 actually means something else, and sub-options, but this term actually means something else, and
therefore should never be used to describe encapsulated options. It therefore should never be used to describe encapsulated options. It
is recommended to use term "encapsulated" as this terminology is used is recommended to use term "encapsulated" as this terminology is used
in [RFC3315]. The difference between encapsulated and sub-options in [RFC3315]. The difference between encapsulated and sub-options
are that the former uses normal DHCPv6 option numbers, while the are that the former uses normal DHCPv6 option numbers, while the
latter uses option number space specific to a given parent option. latter uses option number space specific to a given parent option.
It should be noted that, contrary to DHCPv4, there is no shortage of It should be noted that, contrary to DHCPv4, there is no shortage of
option numbers. Therefore almost all options share a common option option numbers. Therefore almost all options share a common option
space. For example option type 1 meant different things in DHCPv4, space. For example option type 1 meant different things in DHCPv4,
depending if it was located in top-level or inside of Relay Agent depending if it was located in top-level or inside of Relay Agent
Information option. There is no such ambiguity in DHCPv6 (with the Information option. There is no such ambiguity in DHCPv6 (with the
unfortunate exception of [RFC5908],which was published without exception of [RFC5908], which SHOULD NOT be used as a template for
following the advice provided during the DHC working group review, future DHCP option definitions).
and contains many errors. [RFC5908] 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 options rather than sub-options, as the implementers do encapsulated options rather than sub-options, as the implementers do
not have to deal with separate option spaces and can use the same not have to deal with separate option spaces and can use the same
buffer parser in several places throughout the code. buffer parser in several places throughout the code.
Such encapsulation is not limited to one level. There is at least Such encapsulation is not limited to one level. There is at least
one defined option that is encapsulated twice: Identity Association one defined option that is encapsulated twice: Identity Association
for Prefix Delegation (IA_PD, defined in [RFC3633], section 9) for Prefix Delegation (IA_PD, defined in [RFC3633], section 9)
conveys IA Prefix (IAPREFIX, defined in [RFC3633], section 10). Such conveys IA Prefix (IAPREFIX, defined in [RFC3633], section 10). Such
skipping to change at page 19, line 41 skipping to change at page 20, line 36
resolution done by the DHCP server is more likely to behave resolution done by the DHCP server is more likely to behave
predictably than DNS resolution done on a multi-interface or multi- predictably than DNS resolution done on a multi-interface or multi-
homed client. homed client.
This is a generic DHCP protocol issue and should not be dealt within This is a generic DHCP protocol issue and should not be dealt within
each option separately. This issue is better dealt with using a each option separately. This issue is better dealt with using a
protocol-level solution and fixing this problem should not be protocol-level solution and fixing this problem should not be
attempted on a per option basis. Work is ongoing in the IETF to attempted on a per option basis. Work is ongoing in the IETF to
provide a systematic solution to this problem. provide a systematic solution to this problem.
13. Chartering Requirements and Advice for Responsible ADs 13. Chartering Requirements and Advice for Responsible Area Directors
Adding a simple DHCP option is straightforward, and generally Adding a simple DHCP option is straightforward, and generally
something that any working group can do, perhaps with some help from something that any working group can do, perhaps with some help from
designated DHCP experts. However, when new fragment types need to be designated DHCP experts. However, when new fragment types need to be
devised, this requires the attention of DHCP experts, and should not devised, this requires the attention of DHCP experts, and should not
be done in a working group that doesn't have a quorum of such be done in a working group that doesn't have a quorum of such
experts. This is true whether the new fragment type has the same experts. This is true whether the new fragment type has the same
structure as an existing fragment type, but has different semantics. structure as an existing fragment type but has different semantics,
It is equally true when the new format has a new structure. or the new format has a new structure.
Responsible Area Directors for working groups that wish to add a work Responsible Area Directors for working groups that wish to add a work
item to a working group charter to define a new DHCP option should 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 get clarity from the working group as to whether the new option will
simple DHCP option with no new fragment type or new fragment require a new fragment type or new semantics, or whether it is a
semantics, or whether it in fact will require new fragment types. A simple DHCP option that fits existing definitions.
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.
If a working group needs a new fragment type, it is preferable to If a working group needs a new fragment type, it is preferable to see
seek out a working group whose members already have sufficient if another working group exists whose members already have sufficient
expertise to evaluate the new work and try to come up with a new expertise to evaluate the new work. If such a working group is
format that generalizes well and can be reused, rather than a single- available, the work should be chartered in that working group
use fragment type. If such a working group is available, the work instead. If there is no other working group with DHCP expertise that
should be chartered in that working group as a separate draft that can define the new fragment type, the responsible AD should seek help
documents the new fragment type. The working group that needs the from known DHCP experts within the IETF to provide advice and
new fragment type can then define their new option referencing the frequent early review as the original working group defines the new
new fragment type document. This work can generally be done in fragment type.
parallel so as not to delay the process significantly.
In the event that there is no working group with DHCP expertise that In either case, the new option should be defined in a separate
can define the new fragment type, the responsible AD should seek out document, and the work should focus on defining a new format that
help from known DHCP experts within the IETF to provide advice and generalizes well and can be reused, rather than a single-use fragment
frequent early review as the working group defines the new fragment type. The working group that needs the new fragment type can define
type. The new fragment type should still be done in a separate their new option referencing the new fragment type document, and the
document, even if it's done in the same working group, so as to work can generally be done in parallel, avoiding unnecessary delays.
foster reuse of the new fragment type. The responsible AD should Having the definition in its own document will foster reuse of the
work with the working group chairs and designated DHCP experts to new fragment type.
ensure that new fragment type document has in fact been carefully
reviewed by the experts and appears satisfactory. The responsible AD should work with all relevant working group chairs
and DHCP experts to ensure that the new fragment type document has in
fact been carefully reviewed by the experts and appears satisfactory.
Responsible area directors for working groups that are considering Responsible area directors for working groups that are considering
defining options that actually update the DHCP protocol, as opposed defining options that actually update the DHCP protocol, as opposed
to simple options, should go through a process similar to that to simple options, should go through a process similar to that
described above when trying to determine where to do the work. Under described above when trying to determine where to do the work. Under
no circumstances should a working group be given a charter no circumstances should a working group be given a charter
deliverable to define a new DHCP option, and then on the basis of deliverable to define a new DHCP option, and then on the basis of
that charter item actually make updates to the DHCP protocol. that charter item actually make updates to the DHCP protocol.
14. Considerations for Creating New Formats 14. Considerations for Creating New Formats
skipping to change at page 21, line 43 skipping to change at page 22, line 33
DHCPv6 does allow for multiple instances of a given option, and they DHCPv6 does allow for multiple instances of a given option, and they
are treated as distinct values following the defined format, however are treated as distinct values following the defined format, however
this feature is generally preferred to be restricted to protocol this feature is generally preferred to be restricted to protocol
class features (such as the IA_* series of options). In such cases, class features (such as the IA_* series of options). In such cases,
it is better to define an option as an array if it is possible. It it is better to define an option as an array if it is possible. It
is recommended to clarify (with normative language) whether a given is recommended to clarify (with normative language) whether a given
DHCPv6 option may appear once or multiple times. The default DHCPv6 option may appear once or multiple times. The default
assumption is only once. assumption is only once.
In general, if a lot of data needs to be configured (i.e. large In general, if a lot of data needs to be configured (for example,
option lengths), DHCPv6 may not be the best choice to deliver such some option lengths are quite large), DHCPv6 may not be the best
configuration information and SHOULD simply be used to deliver an URI choice to deliver such configuration information and SHOULD simply be
that specifies how to obtain the actual configuration information. used to deliver a URI that specifies where to obtain the actual
configuration information.
16. Singleton options 16. Singleton options
Although [RFC3315] states that each option type MAY appear more than Although [RFC3315] states that each option type MAY appear more than
once, the original idea was that multiple instances are reserved for once, the original idea was that multiple instances are reserved for
stateful options, like IA_NA or IA_PD. For most other options it is stateful options, like IA_NA or IA_PD. For most other options it is
usually expected that they will appear at most once. Such options usually expected that they will appear at most once. Such options
are called singleton options. Sadly, RFCs have often failed to are called singleton options. Sadly, RFCs have often failed to
clearly specify whether a given option can appear more than once or clearly specify whether a given option can appear more than once or
not. Documents that define new options SHOULD state whether these not.
options are singletons or not. Unless otherwise specified, newly
defined options are considered to be singletons. Documents that define new options SHOULD state whether these options
are singletons or not. Unless otherwise specified, newly defined
options are considered to be singletons. If multiple instances are
allowed, the document MUST explain how to use them. Care should be
taken to not assume the they will be processed in the other they
appear in the message. See Section 17 for more details.
When deciding whether a single or multiple option instances are When deciding whether a single or multiple option instances are
allowed in a message, take into consideration how the content of the allowed in a message, take into consideration how the content of the
option will be used. Depending on the service being configured it option will be used. Depending on the service being configured it
may or may not make sense to have multiple values configured. If may or may not make sense to have multiple values configured. If
multiple values make sense, it is better to explicitly allow that by multiple values make sense, it is better to explicitly allow that by
using option format that allows multiple values within one option using option format that allows multiple values within one option
instance. instance.
Allowing multiple option instances often leads to confusion. Allowing multiple option instances often leads to confusion.
skipping to change at page 22, line 40 skipping to change at page 23, line 35
other values provided in other instances of the AFTR option. Others other values provided in other instances of the AFTR option. Others
assumed that if there are multiple options, the client will somehow assumed that if there are multiple options, the client will somehow
do a load balancing between provided tunnel endpoints. Neither do a load balancing between provided tunnel endpoints. Neither
failover nor load balancing was defined for DS-Lite architecture, so failover nor load balancing was defined for DS-Lite architecture, so
it caused confusion. It was eventually decided to allow only one it caused confusion. It was eventually decided to allow only one
instance of the AFTR option. instance of the AFTR option.
17. Option Order 17. Option Order
Option order, either the order among many DHCPv6 options or the order Option order, either the order among many DHCPv6 options or the order
of multiple instances of the same option, SHOULD NOT be significant of multiple instances of the same option, SHOULD NOT be significant.
and MUST NOT be assumed. New documents MUST NOT assume any specific option processing order.
As there is no explicit order for multiple instance of the same As there is no explicit order for multiple instance of the same
option, an option definition SHOULD instead restrict ordering by option, an option definition SHOULD instead restrict ordering by
using a single option that contains ordered fields. using a single option that contains ordered fields.
As [RFC3315] does not impose option order, some implementations use
hash tables to store received options (which is a conformant
behavior). Depending on the hash implementation, the processing
order is almost always different then the order in which options
appeared in the packet on wire.
18. Relay Options 18. Relay Options
In DHCPv4, all relay options are organized as sub-options within DHCP In DHCPv4, all relay options are organized as sub-options within DHCP
Relay Agent Information Option[RFC3046]. And an independent number Relay Agent Information Option[RFC3046]. And an independent number
space called "DHCP Relay Agent Sub-options" is maintained by IANA. space called "DHCP Relay Agent Sub-options" is maintained by IANA.
Different from DHCPv4, in DHCPv6, Relay options are defined in the Different from DHCPv4, in DHCPv6, Relay options are defined in the
same way as client/server options, and they too use the same number same way as client/server options, and they too use the same number
space as client/server options. Future DHCPv6 Relay options MUST be space as client/server options. Future DHCPv6 Relay options MUST be
allocated from this single DHCPv6 Option number space. allocated from this single DHCPv6 Option number space.
skipping to change at page 26, line 44 skipping to change at page 27, line 39
22. 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. In April 2013 there were about updates exist RFCs, especially 3315. In April 2013 there were about
80 options defined. Had all documents that defined them also updated 80 options defined. Had all documents that defined them also updated
RFC3315, comprehension of such a document set would be extremely RFC3315, comprehension of such a document set would be extremely
difficult. It should be noted that "extends" and "updates" are two difficult. It should be noted that "extends" and "updates" are two
very different verbs. If a new draft defines a new option that very different verbs. If a new draft defines a new option that
clients request and servers provide, it merely extends current clients request and servers provide, it merely extends current
standards, so "updates 3315" is not required in the new document standards, so "updates 3315" is not required in the new document
header. On the other hand, if a new document replaces or modifies header. On the other hand, if a new document replaces, modifies
existing behavior, it should be noted that it updates the other existing behavior, includes clarifications or other corrections, it
document. For example, [RFC6644] clearly updates [RFC3315] as it should be noted that it updates the other document. For example,
replaces existing with new text. [RFC6644] clearly updates [RFC3315] as it replaces existing with new
text.
If in doubt, authors should try to answer a question whether
implementor reading the base RFC alone (without reading the new
draft) would be able to properly implement the software. If the base
RFC is sufficient, that the new draft most probably does not update
the base RFC. On the other hand, if reading your draft is necessary
to properly implement the base RFC, then the new draft most likely
updates the base RFC.
23. 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 man-in-the-middle. Other authentication mechanisms may endpoints and man-in-the-middle. Other authentication mechanisms may
optionally be deployed. optionally be deployed. Sadly, as of late 2013, the authentication
in DHCPv6 is rarely used and support for it is not common in existing
implementations. Some specific deployment types make it mandatory
(or parts of thereof, e.g. DOCSIS3.0 compatible cable modems require
reconfigure-key support), so in certain cases specific authentication
aspects can be relied upon. That is not true in the generic case,
though.
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 27, line 47 skipping to change at page 29, line 4
address, or local multicast 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.
Authors of drafts defining new DHCP options are therefore strongly Authors of drafts defining new DHCP options are therefore strongly
advised to explicitly define validation measures that recipients of advised to explicitly define validation measures that recipients of
such options are required to do before processing such options. such options are required to do before processing such options.
However, validation measures already defined by RFC3315 or other However, validation measures already defined by RFC3315 or other
specifications referenced by the new option document are redundant, specifications referenced by the new option document are redundant,
and can introduce errors, so authors are equally strongly advised to and can introduce errors, so authors are equally strongly advised to
refer to the base specification for any such validation language refer to the base specification for any such validation language
rather than copying it into the new specification. rather than copying it into the new specification.
24. IANA Considerations Also see Section 24.
24. Privacy considerations
As discussed in Section 23 the DHCPv6 packets are typically
transmitted in the clear, so they are susceptible to eavesdropping.
This should be considered when defining options that may convey
personally identifying information (PII) or any other type of
sensitive data.
If the transmission of sensitive or confidential content is required,
it is still possible to secure communication between relay agents and
servers. Relay agents and servers communicating with relay agents
must support the use of IPsec Encapsulating Security Payload (ESP)
with encryption in transport mode, according to Section 3.1.1 of
[RFC4303] and Section 21.1 of [RFC3315]. Sadly, this requirement is
almost universally ignored in real deployments. Even if the
communication path between relay agents and server is secured, the
path between clients and relay agents or server is not.
Unless underlying transmission technology provides a secure
transmission channel, the DHCPv6 options SHOULD NOT include PII or
other sensitive information. If there are special circumstances that
warrant sending such information over unsecured DHCPv6, the dangers
MUST be clearly discussed in security considerations.
25. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
25. Acknowledgements 26. Acknowledgements
Authors would like to thank Simon Perreault, Bernie Volz, Ted Lemon, Authors would like to thank Simon Perreault, Bernie Volz, Ted Lemon,
Bud Millwood and Ralph Droms for their comments. Bud Millwood, Ralph Droms, Barry Leiba, Benoit Claise, Brian
Haberman, Richard Barnes, Stephen Farrell and Steward Bryant for
their comments.
26. References 27. References
26.1. Normative References 27.1. Normative References
[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.
26.2. Informative References 27.2. Informative References
[I-D.ietf-dhc-v4configuration] [I-D.ietf-dhc-v4configuration]
Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration
Over IPv6 Only Networks", Over IPv6 Only Networks", draft-ietf-dhc-
draft-ietf-dhc-v4configuration-01 (work in progress), v4configuration-03 (work in progress), December 2013.
May 2013.
[I-D.ietf-softwire-4rd] [I-D.ietf-softwire-4rd]
Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and
M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless
Solution (4rd)", draft-ietf-softwire-4rd-06 (work in Solution (4rd)", draft-ietf-softwire-4rd-07 (work in
progress), July 2013. progress), October 2013.
[I-D.ietf-softwire-map-dhcp] [I-D.ietf-softwire-map-dhcp]
Mrugalski, T., Deng, X., Troan, O., Bao, C., Dec, W., and Mrugalski, T., Troan, O., Dec, W., Bao, C.,
l. leaf.yeh.sdo@gmail.com, "DHCPv6 Options for leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options
configuration of Softwire Address and Port Mapped for configuration of Softwire Address and Port Mapped
Clients", draft-ietf-softwire-map-dhcp-04 (work in Clients", draft-ietf-softwire-map-dhcp-06 (work in
progress), July 2013. progress), November 2013.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
RFC 3046, January 2001. 3046, January 2001.
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol Protocol (DHCPv6) Options for Session Initiation Protocol
(SIP) Servers", RFC 3319, July 2003. (SIP) Servers", RFC 3319, July 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
skipping to change at page 29, line 22 skipping to change at page 31, line 10
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003. December 2003.
[RFC3898] Kalusivalingam, V., "Network Information Service (NIS) [RFC3898] Kalusivalingam, V., "Network Information Service (NIS)
Configuration Options for Dynamic Host Configuration Configuration Options for Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004. Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66, RFC
RFC 3986, January 2005. 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.
[RFC4085] Plonka, D., "Embedding Globally-Routable Internet
Addresses Considered Harmful", BCP 105, RFC 4085, June
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.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, October 2006. Option", RFC 4704, October 2006.
[RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP", [RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP", RFC
RFC 4833, April 2007. 4833, April 2007.
[RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., [RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S.,
and A. Yegin, "Link-Layer Event Notifications for and A. Yegin, "Link-Layer Event Notifications for
Detecting Network Attachments", RFC 4957, August 2007. Detecting Network Attachments", RFC 4957, August 2007.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007. "DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, March 2008. Interchange", RFC 5198, March 2008.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
February 2009. Location-to-Service Translation (LoST) Servers Using the
Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
August 2008.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February
2009.
[RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) [RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP)
Server Option for DHCPv6", RFC 5908, June 2010. Server Option for DHCPv6", RFC 5908, June 2010.
[RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
Options for Network Boot", RFC 5970, September 2010. Options for Network Boot", RFC 5970, September 2010.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986, September
2010.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059, Detecting Network Attachment in IPv6", RFC 6059, November
November 2010. 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", [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC
RFC 6422, December 2011. 6422, December 2011.
[RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication [RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication
Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440,
December 2011. December 2011.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix "Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012. Delegation", RFC 6603, May 2012.
[RFC6610] Jang, H., Yegin, A., Chowdhury, K., Choi, J., and T. [RFC6610] Jang, H., Yegin, A., Chowdhury, K., Choi, J., and T.
Lemon, "DHCP Options for Home Information Discovery in Lemon, "DHCP Options for Home Information Discovery in
Mobile IPv6 (MIPv6)", RFC 6610, May 2012. Mobile IPv6 (MIPv6)", RFC 6610, May 2012.
[RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in [RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in
DHCPv6 Reconfigure Messages", RFC 6644, July 2012. DHCPv6 Reconfigure Messages", RFC 6644, July 2012.
[iana] IANA, "DHCPv6 parameters (IANA webpage)", November 2003, [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
Email: dhankins@google.com Email: dhankins@google.com
Tomek Mrugalski Tomek Mrugalski
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
 End of changes. 58 change blocks. 
184 lines changed or deleted 346 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/