draft-ietf-dhc-option-guidelines-15.txt   draft-ietf-dhc-option-guidelines-16.txt 
Dynamic Host Configuration Working Group D. Hankins Dynamic Host Configuration Working Group D. Hankins
Internet-Draft Google Internet-Draft Google
Updates: 3315 (if approved) T. Mrugalski Updates: 3315 (if approved) T. Mrugalski
Intended status: Best Current Practice M. Siodelski Intended status: Best Current Practice M. Siodelski
Expires: June 12, 2014 ISC Expires: June 26, 2014 ISC
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
S. Krishnan S. Krishnan
Ericsson Ericsson
December 9, 2013 December 23, 2013
Guidelines for Creating New DHCPv6 Options Guidelines for Creating New DHCPv6 Options
draft-ietf-dhc-option-guidelines-15 draft-ietf-dhc-option-guidelines-16
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. It also provides guidelines adoptable by existing DHCPv6 software. It also provides guidelines
for expert reviewers to evaluate new registrations. This document for expert reviewers to evaluate new registrations. This document
updates RFC3315. updates RFC3315.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 12, 2014. This Internet-Draft will expire on June 26, 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . 4 3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . 4
4. General Principles . . . . . . . . . . . . . . . . . . . . . 5 4. General Principles . . . . . . . . . . . . . . . . . . . . . 4
5. Reusing Other Options Formats . . . . . . . . . . . . . . . . 5 5. Reusing Other Options Formats . . . . . . . . . . . . . . . . 5
5.1. Option with IPv6 addresses . . . . . . . . . . . . . . . 6 5.1. Option with IPv6 addresses . . . . . . . . . . . . . . . 6
5.2. Option with a single flag (boolean) . . . . . . . . . . . 7 5.2. Option with a single flag (boolean) . . . . . . . . . . . 7
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 . . . . . . . . . . . . 9 5.5. Option with 16-bit integer value . . . . . . . . . . . . 9
5.6. Option with 8-bit integer value . . . . . . . . . . . . . 9 5.6. Option with 8-bit integer value . . . . . . . . . . . . . 9
5.7. Option with URI . . . . . . . . . . . . . . . . . . . . . 10 5.7. Option with URI . . . . . . . . . . . . . . . . . . . . . 9
5.8. Option with Text String . . . . . . . . . . . . . . . . . 11 5.8. Option with Text String . . . . . . . . . . . . . . . . . 11
5.9. Option with variable length data . . . . . . . . . . . . 12 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 . . . . . . 12
6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . 13 6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . 13
7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . 14 7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . 13
8. Choosing between FQDN and address . . . . . . . . . . . . . . 14 8. Choosing between FQDN and address . . . . . . . . . . . . . . 14
9. Encapsulated options in DHCPv6 . . . . . . . . . . . . . . . 17 9. Encapsulated options in DHCPv6 . . . . . . . . . . . . . . . 18
10. Additional States Considered Harmful . . . . . . . . . . . . 18 10. Additional States Considered Harmful . . . . . . . . . . . . 19
11. Configuration changes occur at fixed times . . . . . . . . . 19 11. Configuration changes occur at fixed times . . . . . . . . . 19
12. Multiple provisioning domains . . . . . . . . . . . . . . . . 19 12. Multiple provisioning domains . . . . . . . . . . . . . . . . 20
13. Chartering Requirements and Advice for Responsible Area 13. Chartering Requirements and Advice for Responsible Area
Directors . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Directors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
14. Considerations for Creating New Formats . . . . . . . . . . . 21 14. Considerations for Creating New Formats . . . . . . . . . . . 22
15. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 21 15. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 22
16. Singleton options . . . . . . . . . . . . . . . . . . . . . . 22 16. Singleton options . . . . . . . . . . . . . . . . . . . . . . 23
17. Option Order . . . . . . . . . . . . . . . . . . . . . . . . 23 17. Option Order . . . . . . . . . . . . . . . . . . . . . . . . 24
18. Relay Options . . . . . . . . . . . . . . . . . . . . . . . . 23 18. Relay Options . . . . . . . . . . . . . . . . . . . . . . . . 24
19. Clients Request their Options . . . . . . . . . . . . . . . . 24 19. Clients Request their Options . . . . . . . . . . . . . . . . 24
20. Transition Technologies . . . . . . . . . . . . . . . . . . . 25 20. Transition Technologies . . . . . . . . . . . . . . . . . . . 25
21. Recommended sections in the new document . . . . . . . . . . 25 21. Recommended sections in the new document . . . . . . . . . . 25
21.1. DHCPv6 Client Behavior Text . . . . . . . . . . . . . . 26 21.1. DHCPv6 Client Behavior Text . . . . . . . . . . . . . . 26
21.2. DHCPv6 Server Behavior Text . . . . . . . . . . . . . . 26 21.2. DHCPv6 Server Behavior Text . . . . . . . . . . . . . . 27
21.3. DHCPv6 Relay Agent Behavior Text . . . . . . . . . . . . 27 21.3. DHCPv6 Relay Agent Behavior Text . . . . . . . . . . . . 27
22. Should the new document update existing RFCs? . . . . . . . . 27 22. Should the new document update existing RFCs? . . . . . . . . 28
23. Security Considerations . . . . . . . . . . . . . . . . . . . 28 23. Security Considerations . . . . . . . . . . . . . . . . . . . 28
24. Privacy considerations . . . . . . . . . . . . . . . . . . . 29 24. Privacy considerations . . . . . . . . . . . . . . . . . . . 29
25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
26. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 26. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
27. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 27. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
27.1. Normative References . . . . . . . . . . . . . . . . . . 30 27.1. Normative References . . . . . . . . . . . . . . . . . . 30
27.2. Informative References . . . . . . . . . . . . . . . . . 30 27.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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 6, line 20 skipping to change at page 6, line 13
requirement though. In some cases splitting one complex option into requirement though. In some cases splitting one complex option into
two or more simple options introduces inter-option dependencies that two or more simple options introduces inter-option dependencies that
should be avoided. In such a case, it is usually better to keep one should be avoided. In such a case, it is usually better to keep one
complex option. complex option.
5.1. Option with IPv6 addresses 5.1. Option with IPv6 addresses
This option format is used to carry one or many IPv6 addresses. In This option format is used to carry one or many IPv6 addresses. In
some cases the number of allowed address is limited (e.g. to one): some cases the number of allowed address is limited (e.g. to one):
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| ipv6-address | | ipv6-address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| ipv6-address | | ipv6-address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Option with IPv6 address Figure 1: Option with IPv6 address
Examples of use: Examples of use:
o DHCPv6 server unicast address (a single address only) [RFC3315] o DHCPv6 server unicast address (a single address only) [RFC3315]
o SIP Servers IPv6 Address List [RFC3319] o SIP Servers IPv6 Address List [RFC3319]
o DNS Recursive Name Server [RFC3646] o DNS Recursive Name Server [RFC3646]
skipping to change at page 7, line 29 skipping to change at page 7, line 22
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 The absence of the option represents the default value and the
presence of the option represents the other value, but that this does presence of the option represents the other value, but that this does
not necessarily mean that absence is "off" (or "false") and presence 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 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 for a bistable option is "true"/"on", then the presence of that
option would turn it off (make it false). If the option presence option would turn it off (make it false). If the option presence
signifies off/false state, that should be reflected in the option signifies off/false state, that should be refleced in the option
name, e.g. OPTION_DISABLE_FOO. 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:
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 an IPv6 prefix. The information Sometimes there is a need to convey an IPv6 prefix. The information
skipping to change at page 8, line 50 skipping to change at page 8, line 44
It should be noted that the IAPREFIX option defined by [RFC3633] uses It should be noted that the IAPREFIX option defined by [RFC3633] uses
a full length 16-octet prefix field. The concern about option length a full length 16-octet prefix field. The concern about option length
was not well understood at the time of its publication. was not well understood at the time of its publication.
5.4. Option with 32-bit integer value 5.4. Option with 32-bit integer value
This option format can be used to carry 32 bit-signed or unsigned This option format can be used to carry 32 bit-signed or unsigned
integer value: integer value:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit-integer | | 32-bit-integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Option with 32-bit-integer value Figure 4: Option with 32-bit-integer value
Examples of use: Examples of use:
o Information Refresh Time [RFC4242] o Information Refresh Time [RFC4242]
5.5. Option with 16-bit integer value 5.5. Option with 16-bit integer value
This option format can be used to carry 16-bit signed or unsigned This option format can be used to carry 16-bit signed or unsigned
integer values: integer values:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-bit-integer | | 16-bit-integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Option with 16-bit integer value Figure 5: Option with 16-bit integer value
Examples of use: Examples of use:
o Elapsed Time [RFC3315] o Elapsed Time [RFC3315]
5.6. Option with 8-bit integer value 5.6. Option with 8-bit integer value
This option format can be used to carry 8-bit integer values: This option format can be used to carry 8-bit integer values:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8-bit-integer | | 8-bit-integer |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 6: Option with 8-bit integer value Figure 6: Option with 8-bit integer value
Examples of use: Examples of use:
o DHCPv6 Preference [RFC3315] o DHCPv6 Preference [RFC3315]
5.7. Option with URI 5.7. Option with URI
A Uniform Resource Identifier (URI) [RFC3986] is a compact sequence A Uniform Resource Identifier (URI) [RFC3986] is a compact sequence
of characters that identifies an abstract or physical resource. The of characters that identifies an abstract or physical resource. The
term "Uniform Resource Locator" (URL) refers to the subset of URIs term "Uniform Resource Locator" (URL) refers to the subset of URIs
that, in addition to identifying a resource, provide a means of that, in addition to identifying a resource, provide a means of
locating the resource by describing its primary access mechanism locating the resource by describing its primary access mechanism
(e.g., its network "location"). This option format can be used to (e.g., its network "location"). This option format can be used to
carry a single URI: carry a single URI:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. URI (variable length) . . URI (variable length) .
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Option with URI Figure 7: Option with URI
Examples of use: Examples of use:
o Boot File URL [RFC5970] o Boot File URL [RFC5970]
An alternate encoding to support multiple URIs is available. An An alternate encoding to support multiple URIs is available. An
option must be defined to use either the single URI format above or option must be defined to use either the single URI format above or
the multiple URI format below depending on whether a single is always the multiple URI format below depending on whether a single is always
sufficient or if multiple URIs are possible. sufficient or if multiple URIs are possible.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. uri-data . . uri-data .
. . . . . . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
skipping to change at page 11, line 30 skipping to change at page 11, line 21
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
include any terminator (such as a null byte). The null byte is include any terminator (such as a null byte). The null byte is
treated as any other character and does not have any special meaning. treated as any other character and does not have any special meaning.
This option format can be used to carry a text string: 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
Examples of use: Examples of use:
o Timezone Options for DHCPv6 [RFC4833] o Timezone Options for DHCPv6 [RFC4833]
An alternate encoding to support multiple text strings is available. An alternate encoding to support multiple text strings is available.
An option must be defined to use either the single text string format An option must be defined to use either the single text string format
above or the multiple text string format below depending on whether a above or the multiple text string format below depending on whether a
single is always sufficient or if multiple text strings are possible. single is always sufficient or if multiple text strings are possible.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len |
| option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . .
. . . text-data .
. text-data . . . . . .
. . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Option with multiple text strings Figure 10: Option with multiple text strings
Each instance of the text-data is formatted as follows: Each instance of the text-data is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| text-len | String | | text-len | String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
The text-len is two octets long and specifies the length of the The text-len is two octets long and specifies the length of the
skipping to change at page 12, line 36 skipping to change at page 12, line 26
This option can be used to carry variable length data of any kind. This option can be used to carry variable length data of any kind.
Internal representation of carried data is option specific. Whenever Internal representation of carried data is option specific. Whenever
this format is used by the new option being defined, the data this format is used by the new option being defined, the data
encoding should be documented. encoding should be documented.
This option format provides a lot of flexibility to pass data of This option format provides a lot of flexibility to pass data of
almost any kind. Though, whenever possible it is highly recommended almost any kind. Though, whenever possible it is highly recommended
to use more specialized options, with field types better matching to use more specialized options, with field types better matching
carried data types. carried data types.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. variable length data . . variable length data .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Option with variable length data Figure 11: Option with variable length data
Examples of use: Examples of use:
o Client Identifier [RFC3315] o Client Identifier [RFC3315]
o Server Identifier [RFC3315] o Server Identifier [RFC3315]
5.10. Option with DNS Wire Format Domain Name List 5.10. Option with DNS Wire Format Domain Name List
This option is used to carry 'domain search' lists or any host or This option is used to carry 'domain search' lists or any host or
domain name. It uses the same format as described in Section 5.9, domain name. It uses the same format as described in Section 5.9,
but with the special data encoding, described in section 8 of but with the special data encoding, described in section 8 of
[RFC3315]. This data encoding supports carrying multiple instances [RFC3315]. This data encoding supports carrying multiple instances
of hosts or domain names in a single option, by terminating each of hosts or domain names in a single option, by terminating each
instance with the byte value of 0. instance with the byte value of 0.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length | | option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DNS Wire Format Domain Name List | | DNS Wire Format Domain Name List |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 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 LoST Server Domain name [RFC5223]
skipping to change at page 14, line 52 skipping to change at page 14, line 41
Some parameters may be specified as FQDN or an address. In most Some parameters may be specified as FQDN or an address. In most
cases one or the other should be used. This section discusses pros cases one or the other should be used. This section discusses pros
and cons of each approach and is intended to help make an informed and cons of each approach and is intended to help make an informed
decision in that regard. It is strongly discouraged to define both decision in that regard. It is strongly discouraged to define both
option types at the same time (see Section 7), unless there is option types at the same time (see Section 7), unless there is
sufficient motivation to do so. sufficient motivation to do so.
There is no single recommendation that works for every case. It very There is no single recommendation that works for every case. It very
much depends on the nature of the parameter being configured. For much depends on the nature of the parameter being configured. For
parameters that are network specific or represent certain aspects of parameters that are network specific or represent certain aspects of
network infrastructure, like NTP servers, available mobility services network infrastructure, like available mobility services, in most
etc., in most cases address is more usable choice. For parameters cases address is more usable choice. For parameters that can be
that can be considered application specific configuration, like SIP considered application specific configuration, like SMTP servers our
servers, it is usually better to use FQDN. SIP servers, it is usually better to use FQDN.
Applications are often better suited to deal with FQDN failures than Applications are often better suited to deal with FQDN failures than
with address failures. Most operating systems provide a way to retry with address failures. Most operating systems provide a way to retry
FQDN resolution if the previous attempt fails. That type of error FQDN resolution if previous attempt fails. That type of error
recovery is supported by a great number of applications. On the recovery is supported by great number of applications. On the other
other hand, there is typically no API availble for applications to hand, there is typically no API availble for applications to
reconfigure over DHCP to get a new address value if the one received reconfigure over DHCP to get a new address value if the one received
is no longer appropriate. This problem may be partially addressed by is no longer appropriate. This problem may be usually addressed by
providing a list of addresses, rather than just a single one. That, providing a list of addresses, rather than just a single one. That,
on the other hand, complicates client operation, as some kind of on the other hand, requires defined procedure how multiple addresses
failover procedure has to be defined and implemented. should be used (all at once, round robin, try first and fail over to
the next if it fails etc.).
On the specific subject of desiring to configure a value using a FQDN
instead of an address, note that most DHCPv6 server implementations
will accept a Domain Name entered by the administrator, and use DNS
resolution to render binary IP addresses in DHCPv6 replies to
clients. Consequently, consider the extra packet overhead incurred
on the client's end to perform DNS resolution itself. The client may
be operating on a battery and packet transmission is a small drain of
battery power (usually negligible if done once, but repeated many
times may become significant), 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.
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 that the client implement DNS resolution.
FQDN provide a higher level of indirection and ambiguity. In many FQDN provide a higher level of indirection and ambiguity. In many
cases that may be considered a benefit, but can be considered a flaw cases that may be considered a benefit, but can be considered a flaw
in others. For example, one operator suggested to have the same name in others. For example, one operator suggested to have the same name
being resolved to different addresses depending on the point of being resolved to different addresses depending on the point of
attachement of the host doing resolution. This allows pointing at attachement of the host doing resolution. This is one way to provide
more localized services. However, such a practice requires violating localized addressing. However, in order to do this, it is necessary
DNS principles ('split horizon'), and hence is not recommended. to violate the DNS convention that a query on a particular name
should always return the same answer (aside from ordering of IP
addresses in the response, which is supposed to be varied by the name
server). This same locality of reference for configuration
information can be achieved directly using DHCP, since the DHCP
server must know the network topology in order to provide IP address
or prefix configuration.
The other type of ambiguity is related to multiple provisioning The other type of ambiguity is related to multiple provisioning
domains (see Section 12), and may get a different answer from the DNS domains (see Section 12). The stub resolver on the DHCP client
depending on which interface or DNS server is used to do the cannot at present be assumed to make the DNS query for a DHCP-
resolution. This is particularly a problem when the normal expected supplied FQDN on the same interface on which it received its DHCP
use of the option makes sense with private DNS zone(s), as might be configuration, and may therefore get a different answer from the DNS
the case with a corporate VPN. It may also be the case that the than was intended.
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
the question when the FQDN resolution should be conducted. There are
a couple of possible answers: a) by the server, when it is started,
b) by the server, when it is about to send an option, c) by the
client, immediately after receiving an option, d) by the client, when
the content of the option is actually consumed. For a), b) and
possibly c), the option should really convey an address, not FQDN.
The only real incentive to use FQDN is case d). It is the only case
that 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 This is particularly a problem when the normal expected use of the
clients to notice any configuration changes. Consider a case where a option makes sense with private DNS zone(s), as might be the case on
server configures a service A using address and service B using FQDN. an enterprise network. It may also be the case that the client has
When an administrator decides to update the configuration, he or she an explicit DNS server configured, and may therefore never query the
can update the DHCP server configuration to change both services. If enterprise network's internal DNS server.
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 FQDN does require a resolution into an actual address. This implies
the DHCP software. An address option is simpler to use, its the question when the FQDN resolution should be taken. There are a
validation is trivial (multiple of 16 constitutes a valid option), is couple of possible answers: a) by the server, when it is started, b)
explicit and does not allow any ambiguity. It is faster (does not by the server, when it is about to send an option, c) by the client,
require extra round trip time), so it is more efficient, which can be immediately after receiving an option, d) by the client, when the
especially important for energy restricted devices. It also does not content of the option is actually consumed. For a), b) and possibly
require having resolution capability. c), the option should really convey an address, not FQDN. The only
real incentive to use FQDN is case d). It is the only case that
allows possible changes in the DNS to be picked up by clients.
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 [RFC3646] is That typically means that DNS_SERVERS option [RFC3646] will be
mandatory. This should be mentioned in the draft that defines used, i.e. client should request DNS_SERVERS in its Option
new option. It is possible that the server will return FQDN Request Option. This should be mentioned in the draft that
option, but not the DNS Servers option. There should be a brief defines new option. It is possible that the server will return
discussion about it; FQDN 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); the 4. Address family must be specified (A, AAAA or any); the
information being configured may require specific address family information being configured may require specific address family
(e.g. IPv6), but there may be a DNS record only of another type (e.g. IPv6), but there may be a DNS record only of another type
(e.g. A only with IPv4 address). (e.g. A only with IPv4 address).
skipping to change at page 17, line 22 skipping to change at page 17, line 6
second if the first fails for whatever reason, etc.); This may be second if the first fails for whatever reason, etc.); This may be
an issue if there is an expectation that the parameter being an issue if there is an expectation that the parameter being
configured will need exactly one address; 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, DNS option encoding should be specified. allowed. If they are, what kind of DNS option encoding should be
specified.
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 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.
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.
Simply speaking protocol designers don't know what the TTL or the T1
time will be, so they can't make assumptions about whether a DHCP
option will be refreshed more quickly based on T1 or TTL.
Address options that are used with overly long T1 (renew timer) Address options that are used with overly long T1 (renew timer)
values have some characteristics of hardcoded values. That is values have some characteristics of hardcoding values. That is
strongly discouraged. See [RFC4085] for an in depth discussion. If strongly discouraged. See [RFC4085] for an in depth discussion. If
the option may appear in Information-Request, its lifetime should be the option may appear in Information-Request, its lifetime should be
controlled using information refresh time option [RFC4242]. controlled using information refresh time option [RFC4242].
One specific case that makes the choice between address and FQDN not One specific case that makes the choice between address and FQDN not
obvious is a DNSSEC bootstrap scenario. DNSSEC validation imposes a obvious is a DNSSEC bootstrap scenario. DNSSEC validation imposes a
requirement for clock sync (to the accuracy reasonably required to requirement for clock sync (to the accuracy reasonably required to
consider signature inception and expiry times). This often implies consider signature inception and expiry times). This often implies
usage of NTP configuration. However, if the NTP is provided as FQDN, usage of NTP configuration. However, if the NTP is provided as FQDN,
there is no way to validate its DNSSEC signature. This is somewhat there is no way to validate its DNSSEC signature. This is somewhat
weak argument though, as providing NTP server as an address is also weak argument though, as providing NTP server as an address is also
not verifiable using DNSSEC. If the thrustworthiness of the not verifable using DNSSEC. If the thrustworthiness of the
configuration provided by DHCP server is in question, DHCPv6 offers configuration provided by DHCP server is in question, DHCPv6 offers
authentication mechanisms that allow server authentication. 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
skipping to change at page 23, line 5 skipping to change at page 23, line 21
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. not.
Documents that define new options SHOULD state whether these options Documents that define new options SHOULD state whether these options
are singletons or not. Unless otherwise specified, newly defined are singletons or not. Unless otherwise specified, newly defined
options are considered to be singletons. If multiple instances are options are considered to be singletons. If multiple instances are
allowed, the document MUST explain how to use them. Care should be 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 taken to not assume the they will be processed in the order they
appear in the message. See Section 17 for more details. 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.
skipping to change at page 27, line 39 skipping to change at page 28, line 15
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, modifies header. On the other hand, if a new document replaces or modifies
existing behavior, includes clarifications or other corrections, it existing behavior, includes clarifications or other corrections, it
should be noted that it updates the other document. For example, should be noted that it updates the other document. For example,
[RFC6644] clearly updates [RFC3315] as it replaces existing with new [RFC6644] clearly updates [RFC3315] as it replaces existing with new
text. text.
If in doubt, authors should try to answer a question whether If in doubt, authors should try to answer a question whether
implementor reading the base RFC alone (without reading the new implementor reading the base RFC alone (without reading the new
draft) would be able to properly implement the software. If the base draft) would be able to properly implement the software. If the base
RFC is sufficient, that the new draft most probably does not update 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 the base RFC. On the other hand, if reading your draft is necessary
skipping to change at page 29, line 23 skipping to change at page 29, line 46
24. Privacy considerations 24. Privacy considerations
As discussed in Section 23 the DHCPv6 packets are typically As discussed in Section 23 the DHCPv6 packets are typically
transmitted in the clear, so they are susceptible to eavesdropping. transmitted in the clear, so they are susceptible to eavesdropping.
This should be considered when defining options that may convey This should be considered when defining options that may convey
personally identifying information (PII) or any other type of personally identifying information (PII) or any other type of
sensitive data. sensitive data.
If the transmission of sensitive or confidential content is required, If the transmission of sensitive or confidential content is required,
it is still possible to secure communication between relay agents and it is still possible to secure communication between relay agents and
servers. Relay agents and servers communicating with relay agents servers. Relay agents and servers implementing this specification
must support the use of IPsec Encapsulating Security Payload (ESP) MUST support the use of IPsec Encapsulating Security Payload (ESP)
with encryption in transport mode, according to Section 3.1.1 of with encryption in transport mode, according to Section 3.1.1 of
[RFC4303] and Section 21.1 of [RFC3315]. Sadly, this requirement is [RFC4303] and Section 21.1 of [RFC3315]. Sadly, this requirement is
almost universally ignored in real deployments. Even if the almost universally ingored in real deployments. Even if the
communication path between relay agents and server is secured, the communication path between relay agents and server is secured, the
path between clients and relay agents or server is not. path between clients and relay agents or server is not.
Unless underlying transmission technology provides a secure Unless underlying transmission technology provides secure
transmission channel, the DHCPv6 options SHOULD NOT include PII or transmission channel, the DHCPv6 options SHOULD NOT include PII or
other sensitive information. If there are special circumstances that other sensitive information. If there are special circumstances that
warrant sending such information over unsecured DHCPv6, the dangers warrant sending such information over unsecured DHCPv6, the dangers
MUST be clearly discussed in security considerations. MUST be clearly discussed in security considerations.
25. IANA Considerations 25. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
26. Acknowledgements 26. Acknowledgements
 End of changes. 44 change blocks. 
199 lines changed or deleted 221 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/