draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt   draft-ietf-v6ops-dhcpv6-slaac-problem-02.txt 
Network Working Group B. Liu
Internet Draft Huawei Technologies
Intended status: Informational R. Bonica
Expires: December 20, 2014 Juniper Networks
S. Jiang
Huawei Technologies
X. Gong
W. Wang
BUPT University
June 18, 2014
DHCPv6/SLAAC Address Configuration Interaction Problem Statement V6OPS B. Liu
draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt Internet-Draft S. Jiang
Intended status: Informational Huawei Technologies
Expires: April 17, 2015 R. Bonica
Juniper Networks
X. Gong
W. Wang
BUPT University
October 14, 2014
Status of this Memo DHCPv6/SLAAC Address Configuration Interaction Problem Statement
draft-ietf-v6ops-dhcpv6-slaac-problem-02
Abstract
The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router
Advertisement (RA) message. The RA message contains three flags,
indicating which autoconfiguration mechanisms are available to on-
link hosts. These are the M, O and A flags. The M, O and A flags
are advisory, not prescriptive.
This document describes divergent host behaviors observed in popular
operating systems. It also describes operational problems that
divergent behaviors cause.
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 working Task Force (IETF). Note that other groups may also distribute
documents as Internet-Drafts. The list of current Internet-Drafts is working documents as Internet-Drafts. The list of current Internet-
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 December 18, 2014. This Internet-Draft will expire on April 17, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract
This document analyzes the DHCPv6/SLAAC interaction issue on host.
More specifically, the interaction is regarding with the A, M, and O
flags which are defined in ND protocol. Test results identify that
current implementations in operating systems have varied on
interpreting the flags. The variation might cause some operational
issues as described in the document.
Table of Contents Table of Contents
1. Introduction ................................................. 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Host Behavior Definition in Standards ........................ 3 2. The M, O and A Flags . . . . . . . . . . . . . . . . . . . . 3
2.1. A (Autonomous) Flag ..................................... 4 2.1. M (Managed) Flag . . . . . . . . . . . . . . . . . . . . 3
2.2. M (Managed) Flag ........................................ 4 2.2. O (Otherconfig) Flag . . . . . . . . . . . . . . . . . . 4
2.3. O (Otherconfig) Flag .................................... 4 2.3. A (Autonomous) Flag . . . . . . . . . . . . . . . . . . . 4
3. Problems Statement ........................................... 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Host Behavior Ambiguity ................................. 5 3.1. Divergent Host Behaviors . . . . . . . . . . . . . . . . 4
3.2. Operational Problems Implication ........................ 6 3.2. Operational Problems . . . . . . . . . . . . . . . . . . 5
3.2.1. Renumbering ........................................ 6 3.2.1. Inappropriate Sources . . . . . . . . . . . . . . . . 5
3.2.2. Cold Start Problem ................................. 6 3.2.2. Renumbering . . . . . . . . . . . . . . . . . . . . . 5
3.2.3. Specific Management Patterns ....................... 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. Conclusions .................................................. 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations ...................................... 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations .......................................... 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. References ................................................... 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.1. Normative References .................................... 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7
7.2. Informative References .................................. 8 Appendix A. Test Results . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments .............................................. 8 A.1. Test Environment . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Test Results of Host Behavior ....................... 9 A.2. Host Behavior in the Initial State . . . . . . . . . . . 8
A.1 Detailed Test Results .................................... 9 A.3. Host Behavior in State Transitions . . . . . . . . . . . 9
A.1.1 Host Initial Behavior .............................. 10 Appendix B. Analysis of the Ambiguities . . . . . . . . . . . . 10
A.1.2 Host Behavior in Flags Transition .................. 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
A.2 Observations from the Test .............................. 11
1. Introduction
In IPv6, both of the DHCPv6 [RFC3315] and Neighbor Discovery [RFC4861] 1. Introduction
protocols could be utilized for automatic IP address configuration
for the hosts. They are known as stateful address auto-configuration
and stateless address auto-configuration (SLAAC, [RFC4862]).
Sometimes the two address configuration methods might be both
available in one network.
In ND protocol, there is an M (Managed) flag defined in RA message, IPv6 [RFC2460] hosts invoke Neighbor Discovery (ND) [RFC4861]
indicating the hosts whether there is DHCPv6 service in the network procedures in order to discover which autoconfiguration mechanisms
or not. And there is an O (OtherConfig) flag, if set, indicating are available to them. The following is a list of autoconfiguration
configure information other than addresses (e.g. DNS, Route .etc) is mechanisms:
available through DHCPv6 configuration. Moreover, there's another A
(Autonomous) flag defined in ND, indicating the hosts to do SLAAC,
may also influent the behavior of hosts.
So with these flags, the two address configuration mechanisms are o DHCPv6 [RFC3315]
somehow correlated. But for some reasons, the ND protocol didn't
define the flags as prescriptive but only advisory. This ambiguous
definition might vary the behavior of interpreting the flags by
different hosts. This would add additional complexity for both the
hosts and the network management.
This draft reviews the standard definition of the above mentioned o Stateless Address Autoconfiguration (SLAAC) [RFC4862]
flags, and identifies the potential ambiguous behavior of
interpreting these flags. And then analyzes what operational problems
might be caused by the ambiguous behavior.
In the appendix, detailed test results of several major desktop ND specifies an ICMPv6 [RFC4443] Router Advertisement (RA) message.
operating systems' behavior of interpreting the flags are provided. Routers periodically broadcast the RA message to all on-link nodes.
According to the test results, we can see the ambiguity problem is
actually happening in current implementations.
2. Host Behavior Definition in Standards They also unicast RA messages in response to solicitations. The RA
message contains:
In this section, we analyzed A, M and O flags definition. o an M (Managed) flag
Please note that, A flag has no direct relationship with DHCPv6, but o an O (OtherConfig) flag
it is somewhat correlated with M and O flags.
2.1. A (Autonomous) Flag o zero or more Prefix Information (PI) Options
In ND Prefix Information Option, the autonomous address-configuration The M flag indicates that addresses are available from DHCPv6. The O
flag (A flag)is used to indicate whether this prefix can be used for flag indicates that other configuration information (e.g., DNS-
SLAAC. related information) is available from DHCPv6. The PI Option
includes a prefix, an A (Autonomous) flag and other fields. The A
flag indicates that the prefix can be used for SLAAC. The M, O and A
flags are advisory, not prescriptive. For example, the M flag
indicates that addresses are available from DHCPv6. It does not
indicate that hosts are required to acquire addresses from DHCPv6.
Similar statements can be made about the O and A flags.
For the host behavior, there is an explicit rule in the SLAAC In most cases, the M, O and A flags elicit identical behaviors from
specification [RFC4862]: "If the Autonomous flag is not set, silently most popular operating systems. However, in several cases, the M, O
ignore the Prefix Information option." and A flags elicit divergent behaviors. For example, when a router
changes the settings of the M, O, and A flag from one RA message to
the next, it is likely to elicit one behavior from hosts running one
operating system and another behavior from hosts running a different
operating system.
But when A flag is set, the SLAAC protocol didn't provide a This document describes divergent host behaviors observed in popular
prescriptive definition. (However, it is quite obvious that host operating systems. It also describes operational problems that
should do SLAAC when A flag is set.) divergent behaviors cause.
2.2. M (Managed) Flag 2. The M, O and A Flags
In earlier SLAAC specification [RFC2462], the host behavior of This section briefly reviews how the M, O and A flags are defined in
interpreting M flag is as below: [RFC4861].
"On receipt of a valid Router Advertisement, a host copies the value 2.1. M (Managed) Flag
of the advertisement's M bit into ManagedFlag. If the value of
ManagedFlag changes from FALSE to TRUE, and the host is not already
running the stateful address autoconfiguration protocol, the host
should invoke the stateful address auto-configuration protocol,
requesting both address information and other information. If the
value of the ManagedFlag changes from TRUE to FALSE, the host should
continue running the stateful address auto-configuration, i.e., the
change in the value of the ManagedFlag has no effect. If the value
of the flag stays unchanged, no special action takes place. In
particular, a host MUST NOT reinvoke stateful address configuration
if it is already participating in the stateful protocol as a result
of an earlier advertisement."
But in the updated SLAAC specification [RFC4862], the relative The M flag indicates that addresses are available from IPv6. If the
description was removed, the reason was "considering the maturity of M flag is set, the O flag is redundant and can be ignored because
implementations and operational experiences. ManagedFlag and DHCPv6 will return all available configuration information.
OtherConfigFlag were removed accordingly. (Note that this change does
not mean the use of these flags is deprecated.)"
2.3. O (Otherconfig) Flag M and A flag semantics are independent of one another. The M flag
indicates that addresses are available from DHCPv6, regardless of the
A flag setting. The following setting are all allowed:
The situation of O flag is similar with above mentioned M flag. In o M=0 A=0
earlier SLAAC [RFC2462], the host behavior is clear: o M=0 A=1
"If the value of OtherConfigFlag changes from FALSE to TRUE, the host o M=1 A=0
should invoke the stateful autoconfiguration protocol, requesting
information (excluding addresses if ManagedFlag is set to FALSE). If
the value of the OtherConfigFlag changes from TRUE to FALSE, the host
should continue running the stateful address autoconfiguration
protocol, i.e., the change in the value of OtherConfigFlag has no
effect. If the value of the flag stays unchanged, no special action
takes place. In particular, a host MUST NOT reinvoke stateful
configuration if it is already participating in the stateful protocol
as a result of an earlier advertisement."
And there's another description of the relationship of M and O flags o M=1 A=1
in [RFC2462]:
"In addition, when the value of the ManagedFlag is TRUE, the value of 2.2. O (Otherconfig) Flag
OtherConfigFlag is implicitely TRUE as well. It is not a valid
configuration for a host to use stateful address autoconfiguration to
request addresses only, without also accepting other configuration
information."
3. Problems Statement The O flag indicates that other configuration information (e.g., DNS-
related information) is available from IPv6. If the M flag is set,
the O flag is redundant and can be ignored because DHCPv6 will return
all available configuration information.
3.1. Host Behavior Ambiguity O and A flag semantics are independent of one another. The O flag
indicates that other configuration is available from DHCPv6,
regardless of the A flag setting. The following setting are all
allowed:
The main problem is standard definition ambiguity which means, on o O=0 A=0
interpreting the same messages, different hosts might behave
differently. Thus it could be un-controlled or un-predictable for
administrators on some operations. The ambiguity is summarized as the
following aspects.
#1 Dependency between DHCPv6 and RA o O=0 A=1
In standards, behavior of DHCPv6 and Neighbor Discovery protocols is o O=1 A=0
specified respectively. But it is not clear that whether there should
be any dependency between them.
More specifically, is RA (with M=1) required to trigger DHCPv6? If o O=1 A=1
there are no RAs at all, should hosts initiate DHCPv6 by themselves?
#2 Advisory or Prescriptive 2.3. A (Autonomous) Flag
Some platforms interpret the flags as advisory while others might The A flag indicates that the prefix that is also carried by the PI
interpret them prescriptive. Especially when flags are in transition, option can be used for SLAAC. A flag semantics are independent of M
e.g. the host is already SLAAC-configured, then M flag changes from and O flag semantics. The A flag indicates that the prefix can be
FALSE to TRUE, it is not clear whether the host should start DHCPv6 used by SLAAC, regardless of the M and O flag settings.
or not; or vise versa, the host is already both SLAAC/DHCPv6
configured, then M flag change from TRUE to FALSE, it is also not
clear whether the host should turn DHCPv6 off or not.
#3 "Address Configuring Method" and "Address Lifetime" 3. Problem Statement
When one address configuration method is off, that is, the A flag or
M flag changes from TRUE to FALSE, it is not clear whether the host
should immediately release the corresponding address(es) or just
retain it(them) until expired.
#4 Dependencies between the flags 3.1. Divergent Host Behaviors
The semantics of the flags seems not totally independent, but the The authors tested several popular operating systems in order to
standards didn't clearly clarify it. For example, when both M and O determine what behaviors the M, O and A flag elicit. In some cases,
flags are TRUE, it is not clear whether the host should initiate one the M, A and O flags elicit identical behaviors from most popular
stateful DHCPv6 session to get both address and info-configuration or operating systems. However, in several cases, the M, O and A flags
initiate two independent sessions of which one is dedicated for elicit divergent behaviors. The table below characterizes those
address provisioning and the other is for information provision. When cases:
A and M flags are FALSE and O flag is TRUE, it is not clear whether
the host should initiate a stand-alone stateless DHCPv6 session.
3.2. Operational Problems Implication Host State Input Behavior
According to the abovementioned host behavior ambiguity, there might Host has not No RA Some popular operating systems acquire
be operational issues as the following. acquired any addresses from DHCPv6. Others do not.
addresses
3.2.1. Renumbering Host has not RA Some popular operating systems acquire
acquired any with other information from DHCPv6, regardless
addresses M=0, of the A flag setting. Others do so, but
O=1 only if A=1
During IPv6 renumbering, the SLAAC-configured hosts can reconfigure Host has acquired RA Some operating systems release DHCPv6
IP addresses by receiving ND Router Advertisement (RA) messages addresses from with M addresses immediately. Some release DHCPv6
containing new prefix information. The DHCPv6-configured hosts can DHCPv6 only (M = =0 addresses when they expire.
reconfigure addresses by initialing RENEW sessions when the current 1)
addresses' lease time is expired or receiving the reconfiguration
messages initialed by the DHCPv6 servers.
The above mechanisms have an implicit assumption that SLAAC- Host has acquired RA Some operating systems acquire DHCPv6
configured hosts will remain SLAAC while DHCPv6-managed hosts will addresses from with M addresses immediately. Others do so only
remain DHCPv6-managed. But in some situations, SLAAC-configured hosts SLAAC only (A=1) = 1 if their SLAAC addresses expire and cannot
might need to switch to DHCPv6-managed, or vice versa. In [RFC6879], be refreshed.
it described several renumbering scenarios in enterprise network for
this requirement; for example, the network may split, merge, relocate
or reorganize. But due to current implementations, this requirement
is not applicable and has been identified as a gap in [RFC7010].
3.2.2. Cold Start Problem 3.2. Operational Problems
If all nodes, or many nodes, restart at the same time after a power This section describes operational issues caused by the divergent
cut, the results might not consistent. behaviors, described above.
3.2.3. Specific Management Patterns 3.2.1. Inappropriate Sources
Since the host behavior of address configuration is somehow un- Some operating systems base their decision to acquire configuration
controlled by the network side, it might cause gaps to the networks information upon inappropriate sources. For example, some operating
that need some specific management patterns. Examples are: systems acquire other configuration information if M = 0, O = 1, and
A = 1, but not if M = 0, 0 = 1 and A = 0. In other words, on some
operating systems, it is impossible to acquire other information from
DHCPv6 unless addresses are acquired from either DHCPv6 or SLAAC.
- the hosts have been SLAAC-configured, then the network need the 3.2.2. Renumbering
hosts to do DHCPv6 simultaneously (e.g. for multihoming).
- the network wants the hosts to do stateless DHCPV6-only; for
example, the hosts are configured with self-generated addresses (e.g.
ULA), and they also need to contact the DHCPv6 server for info-
configuration.
4. Conclusions According to [RFC6879] a renumbering exercise can include the
following steps:
- The host behavior of SLAAC/DHCPv6 interaction is ambiguous in o Causing hosts that have acquired addresses from one
standard. autoconfiguration mechanism to release those addresses and acquire
new addresses from another autoconfiguration mechanism
- Varied behavior of implementations has been observed. In [RFC4862] o Causing hosts that have acquired addresses from one
it is said "Removed the text regarding the M and O flags, considering autoconfiguration mechanism to release those addresses and acquire
the maturity of implementations and operational experiences." This new addresses from the same autoconfiguration mechanism
consideration intended to remain the ambiguity. But in the
perspective of operation, ambiguity normally is problematic.
- It is foreseeable that the un-uniformed host behavior can cause o Causing hosts that have acquired addresses from one
operational problems. autoconfiguration mechanism to retain those addresses and acquire
new addresses from another autoconfiguration mechanism
5. Security Considerations Ideally, these steps could be initiated by broadcasting RA message
onto the subnetwork that is being renumbered. Sadly, this is not
possible, because the RA message may elicit a different behavior from
each host. According to Section 3.1, renumbering operations would
have the following limitations:
No more security considerations than the Neighbor Discovery protocol o During a flash switch from DHCPv6 to SLAAC, some operating systems
[RFC4861]. release DHCPv6 acquired addresses immediately, while other will
retain then until they expire. Therefore, results are
unpredictable.
6. IANA Considerations o On some operating systems, if a host has acquired addresses from
SLAAC, it is impossible to acquire additional addresses from
DHCPv6. This may be required as part of a renumbering operation.
None. 4. Security Considerations
7. References As this memo does not introduce any new protocols or procedures, it
does not introduce any new security vulnerabilities.
7.1. Normative References 5. IANA Considerations
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, This draft does not request any IANA action.
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 6. Acknowledgements
Address Autoconfiguration", RFC 4862, September 2007.
7.2. Informative References The authors wish to acknowledge BNRC-BUPT (Broad Network Research
Centre in Beijing University of Posts and Telecommunications) for
their testing efforts. Special thanks to Xudong Shi, Longyun Yuan
and Xiaojian Xue for their extraordinary effort.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address The authors also wish to acknowledge Brian E Carpenter, Ran Atkinson,
Autoconfiguration", RFC 2462, December 1998. Mikael Abrahamsson, Tatuya Jinmei, Mark Andrews and Mark Smith for
their helpful comments.
[RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and 7. References
M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 7.1. Normative References
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
Still Needs Work", RFC 5887, May 2010. (IPv6) Specification", RFC 2460, December 1998.
[RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, Message Protocol (ICMPv6) for the Internet Protocol
September 2013. Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
Network Renumbering Scenarios, Considerations, and Methods", "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
RFC 6879, February 2013. September 2007.
8. Acknowledgments [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
The test was done by our research partner BNRC-BUPT (Broad Network 7.2. Informative References
Research Centre in Beijing University of Posts and
Telecommunications). Thanks for the hard efficient work of student
Xudong Shi and Longyun Yuan.
Valuable comments were received from Sheng Jiang, Brian E Carpenter, [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
Ron Atkinson, Mikael Abrahamsson, Tatuya Jinmei, Mark Andrews and and M. Carney, "Dynamic Host Configuration Protocol for
Mark Smith to improve the draft. IPv6 (DHCPv6)", RFC 3315, July 2003.
This document was prepared using 2-Word-v2.0.template.dot. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
Appendix A. Test Results of Host Behavior [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios, Considerations, and
Methods", RFC 6879, February 2013.
We did tests of the behavior of interpreting the flags by current Appendix A. Test Results
mainstream desktop/mobile operating systems as the following.
A.1 Detailed Test Results A.1. Test Environment
/-----\ /-----\
+---------+ // \\ +---------+ // \\
| DHCPv6 | | Router | | DHCPv6 | | Router |
| server | \\ // | server | \\ //
+----+----+ \--+--/ +----+----+ \--+--/
| | | |
| | | |
| | | |
----+--+----------+----------+---+----- ----+--+----------+----------+---+-----
| | | | | |
| | | | | |
| | | | | |
+----+---+ +----+---+ +----+---+ +----+---+ +----+---+ +----+---+
| | | | | | | | | | | |
| Host1 | | Host2 | | Host3 | | Host 1 | | Host 2 | | Host 3 |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
Figure 1 Test Environment Figure 1: Test Environment
The 5 elements were all created in Vmware in one computer, for ease The test environment depicted Figure 1 in was replicated on a single
of operation. server using VMware. For simplicity of operation, only one host was
run at a time. Network elements were as follows:
- Router quagga 0.99-19 soft router installed on Ubuntu 11.04 o Router: Quagga 0.99-19 soft router installed on Ubuntu 11.04
virtual host virtual host
- DHCPv6 Server: dibbler-server installed on Ubuntu 11.04 virtual
host
- Host A Window 7 Virtual Host
- Host B Ubuntu 12.10 Virtual Host
- Host C Mac OS X v10.7 Virtual Host
Another test was done dedicated for the mobile phone operating o DHCPv6 Server: Dibbler-server installed on Ubuntu 11.04 virtual
systems. The environment is similar (not in VMware, all are real PC host
and mobile phones):
- Router quagga 0.99-17 soft router installed on Ubuntu 12.10 o Host 1: Window 7 / Window 8.1 Virtual Host
- DHCPv6 Server: dibbler-server installed on Ubuntu 12.10
- Host D Android 4.0.4 (kernel: 3.0.16-gfa98030; device: HTC
Incredible S)
- Host E IOS 6.1.3 (model: iPod Touch 4)
(Note: The tested Android version didn't support DHCPv6, so the
following results don't include Android.)
A.1.1 Host Initial Behavior o Host 2: Ubuntu 14.04 (Linux Kernel 3.12.0) Virtual Host
When hosts are not configured yet, we tested their behavior when o Host 3: Mac OS X v10.9 Virtual Host
receiving different A/M/O combinations. The results are as the
following:
o Window 7/Apple IOS o Host 4: IOS 8.0 (model: Apple iPhone 5S, connected via wifi)
- A=0&M=O&O=0, non-config
- A=1&M=0&O=0, SLAAC only
- A=1&M=0&O=1, SLAAC + Stateless DHCPv6
- A=1&M=1&O=0, SLAAC + DHCPv6
- A=1&M=1&O=1, SLAAC + DHCPv6
- A=0&M=1&O=0, DHCPv6 only (A=0 or Non-PIO)
- A=0&M=1&O=1, DHCPv6 only (A=0 or Non-PIO)
- A=0&M=0&O=1, Stateless DHCPv6 only
o Linux/MAC OS X A.2. Host Behavior in the Initial State
- A=0&M=O&O=0, non-config
- A=1&M=0&O=0, SLAAC only
- A=1&M=0&O=1, SLAAC + Stateless DHCPv6
- A=1&M=1&O=0, SLAAC + DHCPv6
- A=1&M=1&O=1, SLAAC + DHCPv6
- A=0&M=1&O=0, DHCPv6 only (A=0 or Non-PIO)
- A=0&M=1&O=1, DHCPv6 only (A=0 or Non-PIO)
- A=0&M=0&O=1, non-config
As showed above, Linux and MAC OSX acted the same way, but are The bullet list below describes host behavior in the initial state,
different from Windows 7 and Apple IOS. The only difference is when when the host has not yet acquired any autoconfiguration information.
A=0&M=0&O=1, Windows 7/Apple IOS did stateless DHCPv6 while Linux/MAC Each bullet item represents an input and the behavior elicited by
OSX did nothing. that input.
A.1.2 Host Behavior in Flags Transition o A=0, M=0, O=0
o SLAAC-only host receiving M=1 * Windows 8.1 acquired addresses and other information from
- Window 7 would initiate DHCPv6 DHCPv6.
- Linux/MAC/IOS would keep SLAAC and don't initiate DHCPv6 unless
SLAAC is expired and no continuous RAs
o DHCPv6-only host receiving A=1 * All other hosts acquired no configuration information.
- They all do SLAAC
o Stateless DHCPv6-configured host receiving M=1 (while keeping O=1) o A=0, M=0, O=1
- Window 7 would initiate stateful DHCPv6, configuring address as
well as re-configuring other information
- Linux/MAC/IOS no action
o Statefull DHCPv6-configured host receiving M=0 (while keeping O=1) * Windows 8.1 acquired addresses and other information from
- Window 7 would release all DHCPv6 configurations including DHCPv6.
address and other information, and initiate stateless DHCPv6
- Linux/MAC/IOS no action
A.2 Observations from the Test * Windows 7, OSX 10.9 and IOS 8.0 acquired other information from
DHCPv6.
o A flag * Ubuntu 14.04 acquired no configuration information.
A flag is a switch to control whether to do SLAAC, and it is o A=0, M=1, O=0
independent with M and O flags, in another word, A is independent
with DHCPv6.
At the non-SLAAC-configured state (either non-configured or DHCPv6- * All hosts acquired addresses and other information from DHCPv6.
configured only), all the operating systems acted the same way in
interpreting A flag. If A flag is TRUE, they all configure SLAAC, it
is obvious and reasonable.
o M flag o A=0, M=1, O=1
* All hosts acquired addresses and other information from DHCPv6.
M is a key flag to interact ND and DHCPv6, but the host behaviors on o A=1, M=0, O=0
M flag were quite different.
At the initialing state, some operating systems would start DHCPv6 * Windows 8.1 acquired addresses from SLAAC and DHCPv6. It also
only if receiving an RA message with M flag set while some would acquired non-address information from DHCPv6.
initially start DHCPv6 if RAs are absent. This result reflects the
ambiguity problem of #1 Dependency between DHCPv6 and RA in above
text.
When the hosts are SLAAC-configured, and then the M flag changes from * All the other host acquired addresses from SLAAC
FALSE to TRUE, some operating systems would initiate DHCPv6 while
some would not. This reflects the problem #2 Advisory or Prescriptive.
o O flag o A=1, M=0, O=1
In the test, when M flag is set, the O flag is implicitly set as well; * Windows 8.1 acquired addresses from SLAAC and DHCPv6. It also
in another word, the hosts would not initial stateful DHCPv6 and acquired other information from DHCPv6.
stateless DHCPv6 respectively. This is a reasonable behavior.
But the O flag is not independent from A flag in some operating * All the other hosts acquired addresses from SLAAC and other
systems, which won't initiate stateless DHCPv6 when A flag is FALSE. information from DHCPv6.
That is to say, it is not applicable to have a "stateless DHCPv6
only" configuration state for some operating systems; it is also not
applicable for these operating systems to switch between stateful
DHCPv6 and stateless DHCPv6 (according to O flag changing from TRUE
to FALSE or vice versa). This reflects the problem #4 Dependencies
between the flags.
Authors' Addresses o A=1, M=1, O=0
* All hosts acquired addresses from SLAAC and DHCPv6. They also
acquired other information from DHCPv6.
o A=1, M=1, O=1
* All hosts acquired addresses from SLAAC and DHCPv6. They also
acquired other information from DHCPv6.
As showed above, four inputs result in divergent behaviors.
A.3. Host Behavior in State Transitions
The bullet list below describes behavior elicited during state
transitions. The value x can represents both 0 and 1.
o Old state (M = x, O = x, A = 1) , New state (M = x, O = x, A = 0)
(This means a SLAAC-configured host, which is regardless of DHCPv6
configured or not, reveiving A transitiong from 1 to 0. )
* All the hosts retain SLAAC addresses until they expire
o Old state (M = 0, O = x, A = 1), New state (M = 1, O = x, A = 1)
(This means a SLAAC-only host receiving M transisioning from 0 to
1.)
* Windows 7 acquires addresses from DHCPv6, immediately.
* Ubuntu 14.04/OSX 10.9/IOS 8.0 acquires addresses from DHCPv6
only if the SLAAC addresses are allowed to expire
* Windows 8.1 was not tested because it always acquire addresses
from DHCPv6 regardless of the M flag setting.
o Old state (M = 1, O = x, A = x), New state (M = 0, O = x, A = x)
(This means a DHCPv6-configured host receiving M transitioning
from 1 to 0.)
* Windows 7 immediately released the DHCPv6 address
* Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0 keep the DHCPv6
addresses until they expire
o Old state (M = 1, O = x, A = 0), New state (M = 1, O = x, A = 1)
(This means a DHCPv6-only host receiving A transisioning from 0 to
1.)
* All host acquire addresses from SLAAC
o Old state (M = 0, O = 1, A = x), New state (M = 1, O = 1, A = x)
(This means a Stateless DHCPv6-configured host [RFC3736], which is
regardless of SLAAC configured or not, receiving M transisioning
from 0 to 1 with keeping O=1 )
* Windows 7 acquires addresses and refreshes other information
from DHCPv6
* Ubuntu 14.04/OSX 10.9/IOS 8.0 does nothing
* Windows 8.1 was not tested because it always acquire addresses
from DHCPv6 regardless of the M flag setting.
o Old state (M = 1, O = 1, A = x), New state (M = 0, O = 1, A = x)
(This means a Stateful DHCPv6-configured host, which is regardless
of SLAAC configured or not, receiving M transisioning from 0 to 1
with keeping O=1 )
* Windows 7 released all DHCPv6 addresses and refreshes all
DHCPv6 other information.
* Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0 does nothing
Appendix B. Analysis of the Ambiguities
Following is a comprehensive analysis of the ambiguities as defined
in the standards. In theory, all the ambiguities might cause
divergent host behavior. Some of the divergence has been identified
by the tests while some haven't. It is worth to document all the
ambiguities.
1. Dependency between DHCPv6 and RA
In standards, behavior of DHCPv6 and Neighbor Discovery protocols
is specified respectively. But it is not clear that whether there
should be any dependency between them. More specifically, is RA
(with M=1) required to trigger DHCPv6? If there are no RAs at
all, should hosts initiate DHCPv6 by themselves?
2. Behaviors of Flag Transition
When flags are in transition, e.g. the host is already SLAAC-
configured, then M flag changes from FALSE to TRUE, it is not
clear whether the host should start DHCPv6 or not; or vise versa,
the host is already both SLAAC/DHCPv6 configured, then M flag
change from TRUE to FALSE, it is also not clear whether the host
should turn DHCPv6 off or not.
3. Distinction between "Address Configuring Method" and "Address
Lifetime"
When one address configuration method is off, that is, the A flag
or M flag changes from TRUE to FALSE, it is not clear whether the
host should immediately release the corresponding address(es) or
just retain it(them) until expired.
4. Dependencies between the flags
The semantics of the flags seems not totally independent, but the
standards didn't clearly clarify it. For example, when both M and
O flags are TRUE, it is not clear whether the host should initiate
one stateful DHCPv6 session to get both address and info-
configuration or initiate two independent sessions of which one is
dedicated for address provisioning and the other is for
information provision. When A and M flags are FALSE and O flag is
TRUE, it is not clear whether the host should initiate a stand-
alone stateless DHCPv6 session.
Authors' Addresses
Bing Liu Bing Liu
Q14-4-A Building Huawei Technologies
Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road
Zhong-Guan-Cun Environment Protection Park, No.156 Beiqing Rd. Hai-Dian District, Beijing, 100095
Hai-Dian District, Beijing
P.R. China P.R. China
Email: leo.liubing@huawei.com Email: leo.liubing@huawei.com
Sheng Jiang
Huawei Technologies
Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
P.R. China
Email: jiangsheng@huawei.com
Ron Bonica Ron Bonica
Juniper Networks Juniper Networks
Sterling, Virginia 20164 Sterling, Virginia
20164
USA USA
Email: rbonica@juniper.net Email: rbonica@juniper.net
Xiangyang Gong Xiangyang Gong
BUPT University
No.3 Teaching Building No.3 Teaching Building
Beijing University of Posts and Telecommunications (BUPT) Beijing University of Posts and Telecommunications (BUPT)
No.10 Xi-Tu-Cheng Rd. No.10 Xi-Tu-Cheng Rd.
Hai-Dian District, Beijing Hai-Dian District, Beijing
P.R. China P.R. China
Email: xygong@bupt.edu.cn Email: xygong@bupt.edu.cn
Wendong Wang Wendong Wang
BUPT University
No.3 Teaching Building No.3 Teaching Building
Beijing University of Posts and Telecommunications (BUPT) Beijing University of Posts and Telecommunications (BUPT)
No.10 Xi-Tu-Cheng Rd. No.10 Xi-Tu-Cheng Rd.
Hai-Dian District, Beijing Hai-Dian District, Beijing
P.R. China P.R. China
Email: wdwang@bupt.edu.cn Email: wdwang@bupt.edu.cn
 End of changes. 112 change blocks. 
355 lines changed or deleted 389 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/