V6OPS B. Liu
Internet-Draft Huawei Technologies Co., Ltd
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
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 30, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Liu, et al. Expires May 30, 2014 [Page 1]
Internet-Draft DHCPv6/SLAAC PS November 2013
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Host Behavior of DHCPv6/SLAAC Interaction . . . . . . . . . . 3
2.1. Relevant RA Flags Defined in Standards . . . . . . . . . 3
2.1.1. A (Autonomous) Flag . . . . . . . . . . . . . . . . . 3
2.1.2. M (Managed) Flag . . . . . . . . . . . . . . . . . . 3
2.1.3. O (Otherconfig) Flag . . . . . . . . . . . . . . . . 4
2.2. Behavior of Current Implementations . . . . . . . . . . . 4
2.2.1. A flag . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. M flag . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.3. O flag . . . . . . . . . . . . . . . . . . . . . . . 5
3. Possible Operational Issues of DHCPv6/SLAAC Interaction . . . 5
3.1. Renumbering . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Cold Start Problems . . . . . . . . . . . . . . . . . . . 6
3.3. Strong Management . . . . . . . . . . . . . . . . . . . . 6
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Test Details of Host Behaviors . . . . . . . . . . . 8
A.1. Host Transition Behavior . . . . . . . . . . . . . . . . 10
A.2. Host Stateful/Stateless DHCPv6 Behavior . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
In IPv6, both of the DHCPv6 [RFC3315] and Neighbor Discovery
[RFC4861] 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,
indicating the hosts there is DHCPv6 service available when the flag
is set. And there is an O (OtherConfig) flag indicating configure
Liu, et al. Expires May 30, 2014 [Page 2]
Internet-Draft DHCPv6/SLAAC PS November 2013
information other than addresses (e.g. DNS, Route .etc) is available
through DHCPv6 configuration when it is set. Moreover, there's
another A (Autonomous) flag defined in ND, which indicating the hosts
to do SLAAC.
So with these flags, the two address configuration methods are
correlated. But for some reasons, the ND protocol didn't define the
flags as prescriptive but only advisory. This means the definition
is more or less ambiguous, and hosts might vary the behavior of
interpreting the flags because of the ambiguity. In the appendix, we
provided test results to identify different host operating systems
have taken different approaches. This might cause some operational
issues as analyzed in section 3.
2. Host Behavior of DHCPv6/SLAAC Interaction
In this section, we analyze A, M, and O flags definition, and briefly
point out some important test results of host behavior of
interpreting these flags in mainstream operating systems
implementations.
Please note that, A flag has no direct relationship with DHCPv6, but
it is somewhat correlated with M and O flags.
2.1. Relevant RA Flags Defined in Standards
2.1.1. A (Autonomous) Flag
In ND Prefix Information Option, when the autonomous address-
configuration flag (A flag) is set, it indicates that this prefix can
be used for SLAAC.
For the host behavior, there is an explicit rule in the SLAAC
specification [RFC4862]: "If the Autonomous flag is not set, silently
ignore the Prefix Information option."
But when A flag is set, the SLAAC protocol didn't provide a
prescriptive definition. It is not clear the host "could" do SLAAC
or "must" do.
2.1.2. M (Managed) Flag
In earlier SLAAC specification [RFC2462], the host behavior of
interpreting M flag is as below:
"On receipt of a valid Router Advertisement, a host copies the value
of the advertisement's M bit into ManagedFlag. If the value of
ManagedFlag changes from FALSE to TRUE, and the host is not already
Liu, et al. Expires May 30, 2014 [Page 3]
Internet-Draft DHCPv6/SLAAC PS November 2013
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 current SLAAC specification [RFC4862], the relative
description was removed, the reason was "considering the maturity of
implementations and operational experiences. ManagedFlag and
OtherConfigFlag were removed accordingly. (Note that this change
does not mean the use of these flags is deprecated.)".
2.1.3. O (Otherconfig) Flag
As mentioned above, the situation of O flag is similar with M. In
earlier SLAAC [RFC2462], the host behavior is clear:
"If the value of OtherConfigFlag changes from FALSE to TRUE, the host
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
in [RFC2462]:
"In addition, when the value of the ManagedFlag is TRUE, the value of
OtherConfigFlag is implicitly 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."
2.2. Behavior of Current Implementations
We did tests of current mainstream desktop/mobile operating systems'
behavior (please refer to the appendix for details). This section
only briefly illustrates some important results.
Liu, et al. Expires May 30, 2014 [Page 4]
Internet-Draft DHCPv6/SLAAC PS November 2013
2.2.1. A flag
A flag is a switch to control whether to do SLAAC, and it is
independent with M/O flags, in another word, A is independent with
DHCPv6.
At the non-SLAAC-config state (including DHCPv6-only-configured), all
the OSes acted the same with A flag, if A set, they all configured
SLAAC, it is obvious and reasonable. But when hosts are SLAAC-
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
M is a key flag to correlate ND and DHCPv6, but the host behavior on
M flag is quite different.
In our test, there was one OS treating the flag as prescriptive, it
even released DHCPv6 session when M=0. But the others just 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. Moreover, the two OSes even would not initiate DHCPv6
session until they receives RA messages with M=1, this behavior has
an implication that DHCPv6 somehow depends on ND.
2.2.3. O flag
In our tests, when M flag is set, the O flag is implicitly set as
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
test, there are two OSes that won't initiate stateless DHCPv6 when A
flag is not set, 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 two OSes to switch
between stateful DHCPv6 and stateless DHCPv6 (according to O flag
changing from 0 to 1 or verse vice).
3. Possible Operational Issues of DHCPv6/SLAAC Interaction
According to the abovementioned tests, there are possible operational
issues as the following.
3.1. Renumbering
During IPv6 renumbering, the SLAAC-configured hosts could reconfigure
IP addresses by receiving ND Router Advertisement (RA) messages
Liu, et al. Expires May 30, 2014 [Page 5]
Internet-Draft DHCPv6/SLAAC PS November 2013
containing new prefix information. The DHCPv6-configured hosts could
reconfigure addresses by initialing RENEW sessions when the current
addresses' lease time is expired or receiving the reconfiguration
messages initiated by the DHCPv6 servers.
So renumbering won't be a problem when SLAAC-configured hosts would
remain SLAAC configuration as well as DHCPv6-managed hosts remaining
DHCPv6. But in some situations, SLAAC-configured hosts might need to
switch to DHCPv6-managed, or verse vice. In [RFC6879], 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. Cold Start Problems
If all nodes, or many nodes, restart at the same time after a power
cut, the results might not consistent.
3.3. Strong Management
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
the hosts to do DHCPv6 simultaneously (e.g. for multihoming)
o the administrator wants the hosts to do statelss 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
o The host behavior of SLAAC/DHCPv6 interaction is ambiguous in
standard.
o The implementations have been varied on this issue. In [RFC4862]
it is said "Removed the text regarding the M and O flags,
considering the maturity of implementations and operational
experiences." The description seems not true anymore.
Liu, et al. Expires May 30, 2014 [Page 6]
Internet-Draft DHCPv6/SLAAC PS November 2013
o It is foreseeable that the un-uniformed host behavior can cause
operational issues, e.g. in renumbering and strong management.
5. Security Considerations
No more security considerations than the Neighbor Discovery protocol
[RFC4861].
6. IANA Considerations
This draft does not request any IANA action.
7. Acknowledgements
The test was done by our research partner BNRC-BUPT (Broad Network
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
Abrahamsson, Dave Thaler, Lee Howard .etc to improve the draft.
This document was produced using the xml2rfc tool [RFC2629].
8. References
8.1. Normative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
8.2. Informative References
[I-D.liu-6renum-dhcpv6-slaac-switching]
Liu, B., Wang, W., and X. Gong, "DHCPv6/SLAAC Address
Configuration Switching for Host Renumbering", draft-liu-
6renum-dhcpv6-slaac-switching-02 (work in progress),
January 2013.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
Liu, et al. Expires May 30, 2014 [Page 7]
Internet-Draft DHCPv6/SLAAC PS November 2013
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios, Considerations, and
Methods", RFC 6879, February 2013.
[RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W.
George, "IPv6 Site Renumbering Gap Analysis", RFC 7010,
September 2013.
Appendix A. Test Details of Host Behaviors
/-----\
+---------+ // \\
| DHCPv6 | | Router |
| server | \\ //
+----+----+ \--+--/
| |
| |
| |
----+--+----------+----------+---+-----
| | |
| | |
| | |
+----+---+ +----+---+ +----+---+
| | | | | |
| Host1 | | Host2 | | Host3 |
+--------+ +--------+ +--------+
Figure 1 Test Environment
The 5 elements were all created in Vmware in one computer, for ease
of operation.
o Router quagga 0.99-19 soft router installed on Ubuntu 11.04
virtual host
o DHCPv6 Server: dibbler-server installed on Ubuntu 11.04 virtual
host
o Host A Window 7 Virtual Host
o Host B Ubuntu 12.10 Virtual Host
o Host C Mac OS X v10.7 Virtual Host
Liu, et al. Expires May 30, 2014 [Page 8]
Internet-Draft DHCPv6/SLAAC PS November 2013
Another test was done dedicated for the mobile phone operating
systems. The environment is similar (not in VMware, all are real PC
and mobile phones):
o Router quagga 0.99-17 soft router installed on Ubuntu 12.10
o DHCPv6 Server: dibbler-server installed on Ubuntu 12.10
o Host D Android 4.0.4 (kernel: 3.0.16-gfa98030; device: HTC
Incredible S)
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
Liu, et al. Expires May 30, 2014 [Page 9]
Internet-Draft DHCPv6/SLAAC PS November 2013
* 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
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
OSX did nothing.
Result summary:
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
* Window 7 would deprecate SLAAC and initiate DHCPv6
* Linux/MAC/IOS would keep SLAAC and don't initiate DHCPv6 unless
SLAAC is expired and no continuous RA
o DHCPv6-only host receiving A=1&M=0
* Window 7 would release DHCPv6 and do SLAAC
* Linux/MAC/IOS would keep DHCPv6 and do SLAAC
When the host has been configured, either by SLAAC or DHCPv6, the
operating systems interpreting the M flag quite differently. Windows
7 treats the flag as instruction, it even released DHCPv6 session
when M=0. Linux and OS X were likely to treat the flag as advisory,
Liu, et al. Expires May 30, 2014 [Page 10]
Internet-Draft DHCPv6/SLAAC PS November 2013
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
details.
A.2. Host Stateful/Stateless DHCPv6 Behavior
o Stateless DHCPv6-configured host receiving M=1 (while keeping 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)
* Window 7 would release all DHCPv6 configurations including
address and other information, and initiate stateless DHCPv6
* Linux/MAC/IOS no action
Liu, et al. Expires May 30, 2014 [Page 11]
Internet-Draft DHCPv6/SLAAC PS November 2013
Authors' Addresses
Bing Liu
Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
P.R. China
Email: leo.liubing@huawei.com
Ron Bonica
Juniper Networks
Sterling, Virginia
20164
USA
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
BUPT University
No.3 Teaching Building
Beijing University of Posts and Telecommunications (BUPT)
No.10 Xi-Tu-Cheng Rd.
Hai-Dian District, Beijing
P.R. China
Email: xygong@bupt.edu.cn
Liu, et al. Expires May 30, 2014 [Page 12]
Internet-Draft DHCPv6/SLAAC PS November 2013
Wendong Wang
BUPT University
No.3 Teaching Building
Beijing University of Posts and Telecommunications (BUPT)
No.10 Xi-Tu-Cheng Rd.
Hai-Dian District, Beijing
P.R. China
Email: wdwang@bupt.edu.cn
