draft-ietf-v6ops-dhcpv6-slaac-problem-00.txt   draft-ietf-v6ops-dhcpv6-slaac-problem-01.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
V6OPS B. Liu DHCPv6/SLAAC Address Configuration Interaction Problem Statement
Internet-Draft Huawei Technologies Co., Ltd draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt
Intended status: Informational R. Bonica
Expires: May 30, 2014 Juniper Networks
S. Jiang
Huawei Technologies Co., Ltd
X. Gong
W. Wang
BUPT University
November 26, 2013
DHCPv6/SLAAC Address Configuration Interaction Problem Statement
draft-ietf-v6ops-dhcpv6-slaac-problem-00
Abstract
This document analyzes the DHCPv6/SLAAC interaction issue on host.
More specifically, the interaction is regarding with the A, M, and O
flags defined in ND protocol. Test results identify that current
implementations in operating systems have varied on interpreting
these flags. The variation might cause some operational issues as
described in the document.
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute working
working documents as Internet-Drafts. The list of current Internet- documents as Internet-Drafts. The list of current Internet-Drafts is
Drafts is at http://datatracker.ietf.org/drafts/current/. 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 May 30, 2014. This Internet-Draft will expire on December 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ................................................. 3
2. Host Behavior of DHCPv6/SLAAC Interaction . . . . . . . . . . 3 2. Host Behavior Definition in Standards ........................ 3
2.1. Relevant RA Flags Defined in Standards . . . . . . . . . 3 2.1. A (Autonomous) Flag ..................................... 4
2.1.1. A (Autonomous) Flag . . . . . . . . . . . . . . . . . 3 2.2. M (Managed) Flag ........................................ 4
2.1.2. M (Managed) Flag . . . . . . . . . . . . . . . . . . 3 2.3. O (Otherconfig) Flag .................................... 4
2.1.3. O (Otherconfig) Flag . . . . . . . . . . . . . . . . 4 3. Problems Statement ........................................... 5
2.2. Behavior of Current Implementations . . . . . . . . . . . 4 3.1. Host Behavior Ambiguity ................................. 5
2.2.1. A flag . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Operational Problems Implication ........................ 6
2.2.2. M flag . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Renumbering ........................................ 6
2.2.3. O flag . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. Cold Start Problem ................................. 6
3. Possible Operational Issues of DHCPv6/SLAAC Interaction . . . 5 3.2.3. Specific Management Patterns ....................... 7
3.1. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 5 4. Conclusions .................................................. 7
3.2. Cold Start Problems . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations ...................................... 7
3.3. Strong Management . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations .......................................... 7
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References ................................................... 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References .................................... 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References .................................. 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments .............................................. 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Test Results of Host Behavior ....................... 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 A.1 Detailed Test Results .................................... 9
8.2. Informative References . . . . . . . . . . . . . . . . . 7 A.1.1 Host Initial Behavior .............................. 10
Appendix A. Test Details of Host Behaviors . . . . . . . . . . . 8 A.1.2 Host Behavior in Flags Transition .................. 10
A.1. Host Transition Behavior . . . . . . . . . . . . . . . . 10 A.2 Observations from the Test .............................. 11
A.2. Host Stateful/Stateless DHCPv6 Behavior . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
In IPv6, both of the DHCPv6 [RFC3315] and Neighbor Discovery In IPv6, both of the DHCPv6 [RFC3315] and Neighbor Discovery [RFC4861]
[RFC4861] protocols could be utilized for automatic IP address protocols could be utilized for automatic IP address configuration
configuration for the hosts. They are known as stateful address for the hosts. They are known as stateful address auto-configuration
auto-configuration and stateless address auto-configuration (SLAAC (, and stateless address auto-configuration (SLAAC, [RFC4862]).
[RFC4862]). Sometimes the two address configuration methods might be Sometimes the two address configuration methods might be both
both available in one network. available in one network.
In ND protocol, there is an M (Managed) flag defined in RA message, In ND protocol, there is an M (Managed) flag defined in RA message,
indicating the hosts there is DHCPv6 service available when the flag indicating the hosts whether there is DHCPv6 service in the network
is set. And there is an O (OtherConfig) flag indicating configure or not. And there is an O (OtherConfig) flag, if set, indicating
information other than addresses (e.g. DNS, Route .etc) is available configure information other than addresses (e.g. DNS, Route .etc) is
through DHCPv6 configuration when it is set. Moreover, there's available through DHCPv6 configuration. Moreover, there's another A
another A (Autonomous) flag defined in ND, which indicating the hosts (Autonomous) flag defined in ND, indicating the hosts to do SLAAC,
to do SLAAC. may also influent the behavior of hosts.
So with these flags, the two address configuration methods are So with these flags, the two address configuration mechanisms are
correlated. But for some reasons, the ND protocol didn't define the somehow correlated. But for some reasons, the ND protocol didn't
flags as prescriptive but only advisory. This means the definition define the flags as prescriptive but only advisory. This ambiguous
is more or less ambiguous, and hosts might vary the behavior of definition might vary the behavior of interpreting the flags by
interpreting the flags because of the ambiguity. In the appendix, we different hosts. This would add additional complexity for both the
provided test results to identify different host operating systems hosts and the network management.
have taken different approaches. This might cause some operational
issues as analyzed in section 3.
2. Host Behavior of DHCPv6/SLAAC Interaction This draft reviews the standard definition of the above mentioned
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 this section, we analyze A, M, and O flags definition, and briefly In the appendix, detailed test results of several major desktop
point out some important test results of host behavior of operating systems' behavior of interpreting the flags are provided.
interpreting these flags in mainstream operating systems According to the test results, we can see the ambiguity problem is
implementations. actually happening in current implementations.
2. Host Behavior Definition in Standards
In this section, we analyzed A, M and O flags definition.
Please note that, A flag has no direct relationship with DHCPv6, but Please note that, A flag has no direct relationship with DHCPv6, but
it is somewhat correlated with M and O flags. it is somewhat correlated with M and O flags.
2.1. Relevant RA Flags Defined in Standards 2.1. A (Autonomous) Flag
2.1.1. A (Autonomous) Flag
In ND Prefix Information Option, when the autonomous address- In ND Prefix Information Option, the autonomous address-configuration
configuration flag (A flag) is set, it indicates that this prefix can flag (A flag)is used to indicate whether this prefix can be used for
be used for SLAAC. SLAAC.
For the host behavior, there is an explicit rule in the SLAAC For the host behavior, there is an explicit rule in the SLAAC
specification [RFC4862]: "If the Autonomous flag is not set, silently specification [RFC4862]: "If the Autonomous flag is not set, silently
ignore the Prefix Information option." ignore the Prefix Information option."
But when A flag is set, the SLAAC protocol didn't provide a But when A flag is set, the SLAAC protocol didn't provide a
prescriptive definition. It is not clear the host "could" do SLAAC prescriptive definition. (However, it is quite obvious that host
or "must" do. should do SLAAC when A flag is set.)
2.1.2. M (Managed) Flag 2.2. M (Managed) Flag
In earlier SLAAC specification [RFC2462], the host behavior of In earlier SLAAC specification [RFC2462], the host behavior of
interpreting M flag is as below: interpreting M flag is as below:
"On receipt of a valid Router Advertisement, a host copies the value "On receipt of a valid Router Advertisement, a host copies the value
of the advertisement's M bit into ManagedFlag. If the value of of the advertisement's M bit into ManagedFlag. If the value of
ManagedFlag changes from FALSE to TRUE, and the host is not already ManagedFlag changes from FALSE to TRUE, and the host is not already
running the stateful address autoconfiguration protocol, the host running the stateful address autoconfiguration protocol, the host
should invoke the stateful address auto-configuration protocol, should invoke the stateful address auto-configuration protocol,
requesting both address information and other information. If the requesting both address information and other information. If the
value of the ManagedFlag changes from TRUE to FALSE, the host should value of the ManagedFlag changes from TRUE to FALSE, the host should
continue running the stateful address auto-configuration, i.e., the continue running the stateful address auto-configuration, i.e., the
change in the value of the ManagedFlag has no effect. If the value change in the value of the ManagedFlag has no effect. If the value
of the flag stays unchanged, no special action takes place. In of the flag stays unchanged, no special action takes place. In
particular, a host MUST NOT reinvoke stateful address configuration particular, a host MUST NOT reinvoke stateful address configuration
if it is already participating in the stateful protocol as a result if it is already participating in the stateful protocol as a result
of an earlier advertisement." of an earlier advertisement."
But in the current SLAAC specification [RFC4862], the relative But in the updated SLAAC specification [RFC4862], the relative
description was removed, the reason was "considering the maturity of description was removed, the reason was "considering the maturity of
implementations and operational experiences. ManagedFlag and implementations and operational experiences. ManagedFlag and
OtherConfigFlag were removed accordingly. (Note that this change OtherConfigFlag were removed accordingly. (Note that this change does
does not mean the use of these flags is deprecated.)". not mean the use of these flags is deprecated.)"
2.1.3. O (Otherconfig) Flag 2.3. O (Otherconfig) Flag
As mentioned above, the situation of O flag is similar with M. In The situation of O flag is similar with above mentioned M flag. In
earlier SLAAC [RFC2462], the host behavior is clear: earlier SLAAC [RFC2462], the host behavior is clear:
"If the value of OtherConfigFlag changes from FALSE to TRUE, the host "If the value of OtherConfigFlag changes from FALSE to TRUE, the host
should invoke the stateful autoconfiguration protocol, requesting should invoke the stateful autoconfiguration protocol, requesting
information (excluding addresses if ManagedFlag is set to FALSE). If information (excluding addresses if ManagedFlag is set to FALSE). If
the value of the OtherConfigFlag changes from TRUE to FALSE, the host the value of the OtherConfigFlag changes from TRUE to FALSE, the host
should continue running the stateful address autoconfiguration should continue running the stateful address autoconfiguration
protocol, i.e., the change in the value of OtherConfigFlag has no protocol, i.e., the change in the value of OtherConfigFlag has no
effect. If the value of the flag stays unchanged, no special action effect. If the value of the flag stays unchanged, no special action
takes place. In particular, a host MUST NOT reinvoke stateful takes place. In particular, a host MUST NOT reinvoke stateful
configuration if it is already participating in the stateful protocol configuration if it is already participating in the stateful protocol
as a result of an earlier advertisement." as a result of an earlier advertisement."
And there's another description of the relationship of M and O flags And there's another description of the relationship of M and O flags
in [RFC2462]: in [RFC2462]:
"In addition, when the value of the ManagedFlag is TRUE, the value of "In addition, when the value of the ManagedFlag is TRUE, the value of
OtherConfigFlag is implicitly TRUE as well. It is not a valid OtherConfigFlag is implicitely TRUE as well. It is not a valid
configuration for a host to use stateful address autoconfiguration to configuration for a host to use stateful address autoconfiguration to
request addresses only, without also accepting other configuration request addresses only, without also accepting other configuration
information." information."
2.2. Behavior of Current Implementations 3. Problems Statement
We did tests of current mainstream desktop/mobile operating systems' 3.1. Host Behavior Ambiguity
behavior (please refer to the appendix for details). This section
only briefly illustrates some important results.
2.2.1. A flag The main problem is standard definition ambiguity which means, on
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.
A flag is a switch to control whether to do SLAAC, and it is #1 Dependency between DHCPv6 and RA
independent with M/O flags, in another word, A is independent with
DHCPv6.
At the non-SLAAC-config state (including DHCPv6-only-configured), all In standards, behavior of DHCPv6 and Neighbor Discovery protocols is
the OSes acted the same with A flag, if A set, they all configured specified respectively. But it is not clear that whether there should
SLAAC, it is obvious and reasonable. But when hosts are SLAAC- be any dependency between them.
configured, and A changed from 1 to 0, the behavior varied, some
deprecated SLAAC while some ignored the RA messages.
2.2.2. M flag More specifically, is RA (with M=1) required to trigger DHCPv6? If
there are no RAs at all, should hosts initiate DHCPv6 by themselves?
M is a key flag to correlate ND and DHCPv6, but the host behavior on #2 Advisory or Prescriptive
M flag is quite different.
In our test, there was one OS treating the flag as prescriptive, it Some platforms interpret the flags as advisory while others might
even released DHCPv6 session when M=0. But the others just treat the interpret them prescriptive. Especially when flags are in transition,
flag as advisory, when SLAAC was done, it won't care about M=1, and e.g. the host is already SLAAC-configured, then M flag changes from
M=0 won't cause operation for the already configured DHCPv6 FALSE to TRUE, it is not clear whether the host should start DHCPv6
addresses. Moreover, the two OSes even would not initiate DHCPv6 or not; or vise versa, the host is already both SLAAC/DHCPv6
session until they receives RA messages with M=1, this behavior has configured, then M flag change from TRUE to FALSE, it is also not
an implication that DHCPv6 somehow depends on ND. clear whether the host should turn DHCPv6 off or not.
2.2.3. O flag #3 "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.
In our tests, when M flag is set, the O flag is implicitly set as #4 Dependencies between the flags
well; in another word, the hosts would not initial stateful DHCPv6
and stateless DHCPv6 respectively. This is reasonable behavior.
But the O flag could be influented by A flag in some OSes. In our The semantics of the flags seems not totally independent, but the
test, there are two OSes that won't initiate stateless DHCPv6 when A standards didn't clearly clarify it. For example, when both M and O
flag is not set, that is to say, it is not applicable to have a flags are TRUE, it is not clear whether the host should initiate one
''stateless DHCPv6 only'' configuration state for some operating stateful DHCPv6 session to get both address and info-configuration or
systems; it is also not applicable for these two OSes to switch initiate two independent sessions of which one is dedicated for
between stateful DHCPv6 and stateless DHCPv6 (according to O flag address provisioning and the other is for information provision. When
changing from 0 to 1 or verse vice). 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. Possible Operational Issues of DHCPv6/SLAAC Interaction 3.2. Operational Problems Implication
According to the abovementioned tests, there are possible operational According to the abovementioned host behavior ambiguity, there might
issues as the following. be operational issues as the following.
3.1. Renumbering 3.2.1. Renumbering
During IPv6 renumbering, the SLAAC-configured hosts could reconfigure During IPv6 renumbering, the SLAAC-configured hosts can reconfigure
IP addresses by receiving ND Router Advertisement (RA) messages IP addresses by receiving ND Router Advertisement (RA) messages
containing new prefix information. The DHCPv6-configured hosts could containing new prefix information. The DHCPv6-configured hosts can
reconfigure addresses by initialing RENEW sessions when the current reconfigure addresses by initialing RENEW sessions when the current
addresses' lease time is expired or receiving the reconfiguration addresses' lease time is expired or receiving the reconfiguration
messages initiated by the DHCPv6 servers. messages initialed by the DHCPv6 servers.
So renumbering won't be a problem when SLAAC-configured hosts would The above mechanisms have an implicit assumption that SLAAC-
remain SLAAC configuration as well as DHCPv6-managed hosts remaining configured hosts will remain SLAAC while DHCPv6-managed hosts will
DHCPv6. But in some situations, SLAAC-configured hosts might need to remain DHCPv6-managed. But in some situations, SLAAC-configured hosts
switch to DHCPv6-managed, or verse vice. In [RFC6879], it described might need to switch to DHCPv6-managed, or vice versa. In [RFC6879],
several renumbering scenarios in enterprise network for this it described several renumbering scenarios in enterprise network for
requirement; for example, the network may split, merge, relocate or this requirement; for example, the network may split, merge, relocate
reorganize. But due to current implementations, this requirement is or reorganize. But due to current implementations, this requirement
not applicable and has been identified as a gap in [RFC7010]. is not applicable and has been identified as a gap in [RFC7010].
3.2. Cold Start Problems 3.2.2. Cold Start Problem
If all nodes, or many nodes, restart at the same time after a power If all nodes, or many nodes, restart at the same time after a power
cut, the results might not consistent. cut, the results might not consistent.
3.3. Strong Management 3.2.3. Specific Management Patterns
Since the host behavior of address configuration is un-controlled and
un-predictable by the network side, it might cause gaps to the
networks that need strong management (for example, the enterprise
networks and the ISP CPE networks). Examples are:
o the administrator wants the hosts to do DHCPv6-only configuration,
it is not applicable for some operating systems due to current
implementation unless manually configure the hosts to DHCPv6-only
model
o the hosts have been SLAAC-configured, then the administrator wants Since the host behavior of address configuration is somehow un-
the hosts to do DHCPv6 simultaneously (e.g. for multihoming) controlled by the network side, it might cause gaps to the networks
that need some specific management patterns. Examples are:
o the administrator wants the hosts to do statelss DHCPv6-only; for - the hosts have been SLAAC-configured, then the network need the
example, the hosts are configured with self-generated addresses hosts to do DHCPv6 simultaneously (e.g. for multihoming).
(e.g. ULA), and they also need to contact the DHCPv6 server for - the network wants the hosts to do stateless DHCPV6-only; for
info- configuration 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 4. Conclusions
o The host behavior of SLAAC/DHCPv6 interaction is ambiguous in - The host behavior of SLAAC/DHCPv6 interaction is ambiguous in
standard. standard.
o The implementations have been varied on this issue. In [RFC4862] - Varied behavior of implementations has been observed. In [RFC4862]
it is said "Removed the text regarding the M and O flags, it is said "Removed the text regarding the M and O flags, considering
considering the maturity of implementations and operational the maturity of implementations and operational experiences." This
experiences." The description seems not true anymore. consideration intended to remain the ambiguity. But in the
perspective of operation, ambiguity normally is problematic.
o It is foreseeable that the un-uniformed host behavior can cause - It is foreseeable that the un-uniformed host behavior can cause
operational issues, e.g. in renumbering and strong management. operational problems.
5. Security Considerations 5. Security Considerations
No more security considerations than the Neighbor Discovery protocol No more security considerations than the Neighbor Discovery protocol
[RFC4861]. [RFC4861].
6. IANA Considerations 6. IANA Considerations
This draft does not request any IANA action. None.
7. Acknowledgements 7. References
The test was done by our research partner BNRC-BUPT (Broad Network 7.1. Normative References
Research Centre in Beijing University of Posts and
Telecommunications). Thanks for the hard efficient work of the
student Xudong Shi and Longyun Yuan.
Valuable comment was received from Brian E Carpenter, Mikael [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
Abrahamsson, Dave Thaler, Lee Howard .etc to improve the draft. "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
This document was produced using the xml2rfc tool [RFC2629]. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
8. References 7.2. Informative References
8.1. Normative References [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and
June 1999. M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, (DHCP) Service for IPv6", RFC 3736, April 2004.
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Address Autoconfiguration", RFC 4862, September 2007. Still Needs Work", RFC 5887, May 2010.
8.2. Informative References [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W.
George, "IPv6 Site Renumbering Gap Analysis", RFC 7010,
September 2013.
[I-D.liu-6renum-dhcpv6-slaac-switching] [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Liu, B., Wang, W., and X. Gong, "DHCPv6/SLAAC Address Network Renumbering Scenarios, Considerations, and Methods",
Configuration Switching for Host Renumbering", draft-liu- RFC 6879, February 2013.
6renum-dhcpv6-slaac-switching-02 (work in progress),
January 2013.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 8. Acknowledgments
Autoconfiguration", RFC 2462, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., The test was done by our research partner BNRC-BUPT (Broad Network
and M. Carney, "Dynamic Host Configuration Protocol for Research Centre in Beijing University of Posts and
IPv6 (DHCPv6)", RFC 3315, July 2003. Telecommunications). Thanks for the hard efficient work of student
Xudong Shi and Longyun Yuan.
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Valuable comments were received from Sheng Jiang, Brian E Carpenter,
Network Renumbering Scenarios, Considerations, and Ron Atkinson, Mikael Abrahamsson, Tatuya Jinmei, Mark Andrews and
Methods", RFC 6879, February 2013. Mark Smith to improve the draft.
[RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. This document was prepared using 2-Word-v2.0.template.dot.
George, "IPv6 Site Renumbering Gap Analysis", RFC 7010,
September 2013.
Appendix A. Test Details of Host Behaviors Appendix A. Test Results of Host Behavior
We did tests of the behavior of interpreting the flags by current
mainstream desktop/mobile operating systems as the following.
A.1 Detailed Test Results
/-----\ /-----\
+---------+ // \\ +---------+ // \\
| DHCPv6 | | Router | | DHCPv6 | | Router |
| server | \\ // | server | \\ //
+----+----+ \--+--/ +----+----+ \--+--/
| | | |
| | | |
| | | |
----+--+----------+----------+---+----- ----+--+----------+----------+---+-----
skipping to change at page 8, line 41 skipping to change at page 9, line 34
+----+---+ +----+---+ +----+---+ +----+---+ +----+---+ +----+---+
| | | | | | | | | | | |
| Host1 | | Host2 | | Host3 | | Host1 | | Host2 | | Host3 |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
Figure 1 Test Environment Figure 1 Test Environment
The 5 elements were all created in Vmware in one computer, for ease The 5 elements were all created in Vmware in one computer, for ease
of operation. of operation.
o Router quagga 0.99-19 soft router installed on Ubuntu 11.04 - 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
o DHCPv6 Server: dibbler-server installed on Ubuntu 11.04 virtual host
host - Host A Window 7 Virtual Host
- Host B Ubuntu 12.10 Virtual Host
o Host A Window 7 Virtual Host - Host C Mac OS X v10.7 Virtual Host
o Host B Ubuntu 12.10 Virtual Host
o Host C Mac OS X v10.7 Virtual Host
Another test was done dedicated for the mobile phone operating Another test was done dedicated for the mobile phone operating
systems. The environment is similar (not in VMware, all are real PC systems. The environment is similar (not in VMware, all are real PC
and mobile phones): and mobile phones):
o Router quagga 0.99-17 soft router installed on Ubuntu 12.10 - Router quagga 0.99-17 soft router installed on Ubuntu 12.10
- DHCPv6 Server: dibbler-server installed on Ubuntu 12.10
o DHCPv6 Server: dibbler-server installed on Ubuntu 12.10 - Host D Android 4.0.4 (kernel: 3.0.16-gfa98030; device: HTC
Incredible S)
o Host D Android 4.0.4 (kernel: 3.0.16-gfa98030; device: HTC - Host E IOS 6.1.3 (model: iPod Touch 4)
Incredible S) (Note: The tested Android version didn't support DHCPv6, so the
following results don't include Android.)
o Host E IOS 6.1.3 (model: iPod Touch 4)
(Note: The tested Android version didn't support DHCPv6 well, so the
following results don't include Android.)A.1 Host Initialing Behavior
Host from non-configured to configured, we tested different A/M/O
combinations in each OS platform. The states are enumerated as the
following, 3 operation systems respectively:
o Window 7/Apple IOS
* 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=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.1 Host Initial Behavior
* A=1&M=1&O=1, SLAAC + DHCPv6
* A=0&M=1&O=0, DHCPv6 only (A=0 or Non-PIO) When hosts are not configured yet, we tested their behavior when
receiving different A/M/O combinations. The results are as the
following:
* A=0&M=1&O=1, DHCPv6 only (A=0 or Non-PIO) o Window 7/Apple IOS
- 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
* A=0&M=0&O=1, non-config o Linux/MAC OS X
- 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 differated As showed above, Linux and MAC OSX acted the same way, but are
from Windows 7 and Apple IOS. The only difference is when different from Windows 7 and Apple IOS. The only difference is when
A=0&M=0&O=1, Windows 7/Apple IOS did stateless DHCPv6 while Linux/MAC A=0&M=0&O=1, Windows 7/Apple IOS did stateless DHCPv6 while Linux/MAC
OSX did nothing. OSX did nothing.
Result summary: A.1.2 Host Behavior in Flags Transition
o A is interpreted as prescript in each OS at the initial state
o M is interpreted as prescript in each OS at the initial state
o O is interpreted as prescript in Windows 7
o A and M are independent in each OS at the initial state
o A and O are not totally independent in Linux and Mac, A=1 is
required for O=1 triggering DHCPv6 info-request
o M and O are not totally independent in each OS. M=1 has the
implication O=1
A.1. Host Transition Behavior
o SLAAC-only host receiving A=0&M=1 o SLAAC-only host receiving M=1
- Window 7 would initiate DHCPv6
- Linux/MAC/IOS would keep SLAAC and don't initiate DHCPv6 unless
SLAAC is expired and no continuous RAs
* Window 7 would deprecate SLAAC and initiate DHCPv6 o DHCPv6-only host receiving A=1
- They all do SLAAC
* Linux/MAC/IOS would keep SLAAC and don't initiate DHCPv6 unless o Stateless DHCPv6-configured host receiving M=1 (while keeping O=1)
SLAAC is expired and no continuous RA - Window 7 would initiate stateful DHCPv6, configuring address as
well as re-configuring other information
- Linux/MAC/IOS no action
o DHCPv6-only host receiving A=1&M=0 o Statefull DHCPv6-configured host receiving M=0 (while keeping O=1)
- Window 7 would release all DHCPv6 configurations including
address and other information, and initiate stateless DHCPv6
- Linux/MAC/IOS no action
* Window 7 would release DHCPv6 and do SLAAC A.2 Observations from the Test
* Linux/MAC/IOS would keep DHCPv6 and do SLAAC o A flag
When the host has been configured, either by SLAAC or DHCPv6, the A flag is a switch to control whether to do SLAAC, and it is
operating systems interpreting the M flag quite differently. Windows independent with M and O flags, in another word, A is independent
7 treats the flag as instruction, it even released DHCPv6 session with DHCPv6.
when M=0. Linux and OS X were likely to treat the flag as advisory,
when SLAAC was done, it won't care about M=1, and M=0 won't cause
operation for the already configured DHCPv6 addresses.
Please refer to [I-D.liu-6renum-dhcpv6-slaac-switching] for more At the non-SLAAC-configured state (either non-configured or DHCPv6-
details. 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.
A.2. Host Stateful/Stateless DHCPv6 Behavior o M flag
o Stateless DHCPv6-configured host receiving M=1 (while keeping O=1) M is a key flag to interact ND and DHCPv6, but the host behaviors on
M flag were quite different.
* Window 7 would initiate stateful DHCPv6, configuring address as At the initialing state, some operating systems would start DHCPv6
well as re-configuring other information only if receiving an RA message with M flag set while some would
initially start DHCPv6 if RAs are absent. This result reflects the
ambiguity problem of #1 Dependency between DHCPv6 and RA in above
text.
* Linux/MAC/IOS no action When the hosts are SLAAC-configured, and then the M flag changes from
FALSE to TRUE, some operating systems would initiate DHCPv6 while
some would not. This reflects the problem #2 Advisory or Prescriptive.
o Statefull DHCPv6-configured host receiving M=0 (while keeping O=1) o O flag
* Window 7 would release all DHCPv6 configurations including In the test, when M flag is set, the O flag is implicitly set as well;
address and other information, and initiate stateless DHCPv6 in another word, the hosts would not initial stateful DHCPv6 and
stateless DHCPv6 respectively. This is a reasonable behavior.
* Linux/MAC/IOS no action But the O flag is not independent from A flag in some operating
systems, which won't initiate stateless DHCPv6 when A flag is FALSE.
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 Authors' Addresses
Bing Liu Bing Liu
Q14-4-A Building
Huawei Technologies Co., Ltd 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
Ron Bonica Ron Bonica
Juniper Networks Juniper Networks
Sterling, Virginia Sterling, Virginia 20164
20164
USA USA
Email: rbonica@juniper.net Email: rbonica@juniper.net
Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
P.R. China
Email: jiangsheng@huawei.com
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. 109 change blocks. 
334 lines changed or deleted 309 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/