draft-ietf-dhc-option-guidelines-16.txt   draft-ietf-dhc-option-guidelines-17.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 26, 2014 ISC Expires: July 11, 2014 ISC
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
S. Krishnan S. Krishnan
Ericsson Ericsson
December 23, 2013 January 7, 2014
Guidelines for Creating New DHCPv6 Options Guidelines for Creating New DHCPv6 Options
draft-ietf-dhc-option-guidelines-16 draft-ietf-dhc-option-guidelines-17
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 26, 2014. This Internet-Draft will expire on July 11, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 31 skipping to change at page 2, line 31
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 . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . 12 5.10. Option with DNS Wire Format Domain Name List . . . . . . 12
6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . 13 6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . 13
7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . 13 7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . 13
8. Choosing between FQDN and address . . . . . . . . . . . . . . 14 8. Choosing between FQDN and address . . . . . . . . . . . . . . 14
9. Encapsulated options in DHCPv6 . . . . . . . . . . . . . . . 18 9. Encapsulated options in DHCPv6 . . . . . . . . . . . . . . . 17
10. Additional States Considered Harmful . . . . . . . . . . . . 19 10. Additional States Considered Harmful . . . . . . . . . . . . 18
11. Configuration changes occur at fixed times . . . . . . . . . 19 11. Configuration changes occur at fixed times . . . . . . . . . 19
12. Multiple provisioning domains . . . . . . . . . . . . . . . . 20 12. Multiple provisioning domains . . . . . . . . . . . . . . . . 20
13. Chartering Requirements and Advice for Responsible Area 13. Chartering Requirements and Advice for Responsible Area
Directors . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Directors . . . . . . . . . . . . . . . . . . . . . . . . . . 20
14. Considerations for Creating New Formats . . . . . . . . . . . 22 14. Considerations for Creating New Formats . . . . . . . . . . . 21
15. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 22 15. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 22
16. Singleton options . . . . . . . . . . . . . . . . . . . . . . 23 16. Singleton options . . . . . . . . . . . . . . . . . . . . . . 22
17. Option Order . . . . . . . . . . . . . . . . . . . . . . . . 24 17. Option Order . . . . . . . . . . . . . . . . . . . . . . . . 23
18. Relay Options . . . . . . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . 27 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? . . . . . . . . 28 22. Should the new document update existing RFCs? . . . . . . . . 27
23. Security Considerations . . . . . . . . . . . . . . . . . . . 28 23. Security Considerations . . . . . . . . . . . . . . . . . . . 28
24. Privacy considerations . . . . . . . . . . . . . . . . . . . 29 24. Privacy considerations . . . . . . . . . . . . . . . . . . . 29
25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
26. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 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 . . . . . . . . . . . . . . . . . . . . . . . 33 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
skipping to change at page 7, line 17 skipping to change at page 7, line 17
Sometimes it is useful to convey a single flag that can take either 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 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 does not
not necessarily mean that absence is "off" (or "false") and presence necessarily mean that absence is "off" (or "false") and presence is
is "on" (or "true"). That is, if it's desired that the default value "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 refleced in the option signifies off/false state, that should be reflected 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
skipping to change at page 14, line 42 skipping to change at page 14, line 42
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 available mobility services, in most network infrastructure, like available mobility services, in most
cases address is more usable choice. For parameters that can be cases addresses are a more usable choice. For parameters that can be
considered application specific configuration, like SMTP servers our considered application specific configuration, like SIP servers, it
SIP servers, it is usually better to use FQDN. 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 previous attempt fails. That type of error FQDN resolution if the previous attempt fails. That type of error
recovery is supported by great number of applications. On the other recovery is supported by a great number of applications. On the
hand, there is typically no API availble for applications to other 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 usually 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, requires defined procedure how multiple addresses on the other hand, requires defined procedure how multiple addresses
should be used (all at once, round robin, try first and fail over to should be used (all at once, round robin, try first and fail over to
the next if it fails etc.). 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 is one way to provide attachement of the host doing resolution. This is one way to provide
localized addressing. However, in order to do this, it is necessary localized addressing. However, in order to do this, it is necessary
to violate the DNS convention that a query on a particular name to violate the DNS convention that a query on a particular name
should always return the same answer (aside from ordering of IP should always return the same answer (aside from ordering of IP
addresses in the response, which is supposed to be varied by the name addresses in the response, which is supposed to be varied by the name
server). This same locality of reference for configuration server). This same locality of reference for configuration
skipping to change at page 16, line 12 skipping to change at page 15, line 38
configuration, and may therefore get a different answer from the DNS configuration, and may therefore get a different answer from the DNS
than was intended. than was intended.
This is particularly a problem when the normal expected use of the 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 on option makes sense with private DNS zone(s), as might be the case on
an enterprise network. It may also be the case that the client has an enterprise network. It may also be the case that the client has
an explicit DNS server configured, and may therefore never query the an explicit DNS server configured, and may therefore never query the
enterprise network's internal DNS server. enterprise network's 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.
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.
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.
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 implements DNS resolution.
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 DNS_SERVERS option [RFC3646] will be That typically means that option DNS_SERVERS [RFC3646] is
used, i.e. client should request DNS_SERVERS in its Option mandatory. This should be mentioned in the draft that defines
Request Option. This should be mentioned in the draft that new option. It is possible that the server will return FQDN
defines new option. It is possible that the server will return option, but not the DNS Servers option. There should be a brief
FQDN option, but not the DNS Servers option. There should be a discussion about it;
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 6 skipping to change at page 17, line 22
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, what kind of DNS option encoding should be allowed. If they are, DNS option encoding should be specified.
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 hardcoding values. That is values have some characteristics of hardcoded 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 verifable using DNSSEC. If the thrustworthiness of the not verifiable 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 24, line 11 skipping to change at page 23, line 44
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.
New documents MUST NOT assume any specific option processing order. 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 instances 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 As [RFC3315] does not impose option order, some implementations use
hash tables to store received options (which is a conformant hash tables to store received options (which is a conformant
behavior). Depending on the hash implementation, the processing behavior). Depending on the hash implementation, the processing
order is almost always different then the order in which options order is almost always different then the order in which options
appeared in the packet on wire. 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 option
space as client/server options. Future DHCPv6 Relay options MUST be number space as client/server options. Future DHCPv6 Relay options
allocated from this single DHCPv6 Option number space. MUST be allocated from this single DHCPv6 Option number space.
E.g. the Relay-Supplied Options Option [RFC6422] may also contain E.g. the Relay-Supplied Options Option [RFC6422] may also contain
some DHCPv6 options as permitted, such as the EAP Re-authentication some DHCPv6 options as permitted, such as the EAP Re-authentication
Protocol (ERP) Local Domain Name DHCPv6 Option [RFC6440]. Protocol (ERP) Local Domain Name DHCPv6 Option [RFC6440].
19. Clients Request their Options 19. Clients Request their Options
The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315], is an option The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315], is an option
that serves two purposes - to inform the server what options the that serves two purposes - to inform the server what options the
client supports and to inform what options the client is willing to client supports and to inform what options the client is willing to
skipping to change at page 29, line 46 skipping to change at page 29, line 30
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 implementing this specification servers. Relay agents and servers communicating with relay agents
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 ingored in real deployments. Even if the almost universally ignored 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 secure Unless underlying transmission technology provides a 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. 25 change blocks. 
98 lines changed or deleted 86 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/