draft-ietf-v6ops-dhcpv6-slaac-problem-03.txt   draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt 
V6OPS B. Liu V6OPS B. Liu
Internet-Draft S. Jiang Internet-Draft S. Jiang
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: April 30, 2015 R. Bonica Expires: November 3, 2015 X. Gong
Juniper Networks
X. Gong
W. Wang W. Wang
BUPT University BUPT University
October 27, 2014 May 2, 2015
DHCPv6/SLAAC Address Configuration Interaction Problem Statement DHCPv6/SLAAC Interaction Problems on Address Auto-configuration
draft-ietf-v6ops-dhcpv6-slaac-problem-03 draft-ietf-v6ops-dhcpv6-slaac-problem-04
Abstract Abstract
The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router
Advertisement (RA) message. The RA message contains three flags, Advertisement (RA) message. The RA message contains three flags,
indicating which autoconfiguration mechanisms are available to on- indicating which auto-configuration mechanisms are available to on-
link hosts. These are the M, O and A flags. The M and O flags are link hosts. These are the M, O and A flags. The M and O flags are
advisory, not prescriptive. advisory, not prescriptive.
This document describes divergent host behaviors observed in popular This document describes divergent host behaviors observed in popular
operating systems. It also describes operational problems that operating systems. It also describes operational problems that
divergent behaviors cause. divergent behaviors might cause.
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 documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015. This Internet-Draft will expire on November 3, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The M, O and A Flags . . . . . . . . . . . . . . . . . . . . 3 2. The M, O and A Flags . . . . . . . . . . . . . . . . . . . . 3
2.1. M (Managed) Flag . . . . . . . . . . . . . . . . . . . . 3 2.1. M (Managed) Flag . . . . . . . . . . . . . . . . . . . . 3
2.2. O (Otherconfig) Flag . . . . . . . . . . . . . . . . . . 4 2.2. O (Otherconfig) Flag . . . . . . . . . . . . . . . . . . 4
2.3. A (Autonomous) Flag . . . . . . . . . . . . . . . . . . . 4 2.3. A (Autonomous) Flag . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Behavior Ambiguity Analysis . . . . . . . . . . . . . . . . . 4
3.1. Divergent Host Behaviors . . . . . . . . . . . . . . . . 4 4. Observed Divergent Host Behaviors . . . . . . . . . . . . . . 5
3.2. Operational Problems . . . . . . . . . . . . . . . . . . 5 5. Operational Problems . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Inappropriate Sources . . . . . . . . . . . . . . . . 5 5.1. Inappropriate Sources . . . . . . . . . . . . . . . . . . 6
3.2.2. Renumbering . . . . . . . . . . . . . . . . . . . . . 5 5.2. Renumbering Issues . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Test Results . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Test Results . . . . . . . . . . . . . . . . . . . . 8
A.1. Test Environment . . . . . . . . . . . . . . . . . . . . 7 A.1. Test Environment . . . . . . . . . . . . . . . . . . . . 8
A.2. Host Behavior in the Initial State . . . . . . . . . . . 8 A.2. Host Behavior in the Initial State . . . . . . . . . . . 9
A.3. Host Behavior in State Transitions . . . . . . . . . . . 10 A.3. Host Behavior in State Transitions . . . . . . . . . . . 11
Appendix B. Analysis of the Ambiguities . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
IPv6 [RFC2460] hosts invoke Neighbor Discovery (ND) [RFC4861] IPv6 [RFC2460] hosts invoke Neighbor Discovery (ND) [RFC4861]
procedures in order to discover which autoconfiguration mechanisms procedures in order to discover which auto-configuration mechanisms
are available to them. The following is a list of autoconfiguration are available to them. The following is a list of auto-configuration
mechanisms: mechanisms:
o DHCPv6 [RFC3315] o DHCPv6 [RFC3315]
o Stateless Address Autoconfiguration (SLAAC) [RFC4862] o Stateless Address Autoconfiguration (SLAAC) [RFC4862]
ND specifies an ICMPv6 [RFC4443] Router Advertisement (RA) message. ND specifies an ICMPv6 [RFC4443] Router Advertisement (RA) message.
Routers periodically broadcast the RA message to all on-link nodes. Routers periodically broadcast the RA message to all on-link nodes.
They also unicast RA messages in response to solicitations. The RA They also unicast RA messages in response to solicitations. The RA
message contains: message contains:
o an M (Managed) flag o an M (Managed) flag
o an O (OtherConfig) flag o an O (OtherConfig) flag
o zero or more Prefix Information (PI) Options o zero or more Prefix Information (PI) Options
The M flag indicates that addresses are available from DHCPv6. The O The M flag indicates that addresses are available from DHCPv6. The O
skipping to change at page 3, line 26 skipping to change at page 3, line 23
related information) is available from DHCPv6. The PI Option related information) is available from DHCPv6. The PI Option
includes a prefix, an A (Autonomous) flag and other fields. The A includes a prefix, an A (Autonomous) flag and other fields. The A
flag indicates that the prefix can be used for SLAAC. The M and O flag indicates that the prefix can be used for SLAAC. The M and O
flags are advisory, not prescriptive (although A flag is also flags are advisory, not prescriptive (although A flag is also
advisory in definition in standard, it is quite prescriptive in advisory in definition in standard, it is quite prescriptive in
implementations). For example, the M flag indicates that addresses implementations). For example, the M flag indicates that addresses
are available from DHCPv6. It does not indicate that hosts are are available from DHCPv6. It does not indicate that hosts are
required to acquire addresses from DHCPv6. Similar statements can be required to acquire addresses from DHCPv6. Similar statements can be
made about the O flag. made about the O flag.
In most cases, the M, O and A flags elicit identical behaviors from Because of the advisory definition of the flags, in some cases
most popular operating systems. However, in several cases, the M, O different operating systems appear divergent behaviors. This
and A flags elicit divergent behaviors. For example, when a router document analyzes possible divergent host behaviors might happen
changes the settings of the M, O, and A flag from one RA message to (some of the possible divergent behaviors are already observed in
the next, it is likely to elicit one behavior from hosts running one popular operating systems) and the operational problems might caused
operating system and another behavior from hosts running a different by divergent behaviors.
operating system.
This document describes divergent host behaviors observed in popular
operating systems. It also describes operational problems that
divergent behaviors cause.
2. The M, O and A Flags 2. The M, O and A Flags
This section briefly reviews how the M, O and A flags are defined in This section briefly reviews how the M, O and A flags are defined in
[RFC4861]. [RFC4861].
2.1. M (Managed) Flag 2.1. M (Managed) Flag
The M flag indicates that addresses are available from DHCPv6. If The M flag indicates that addresses are available from DHCPv6. If
the M flag is set, the O flag is redundant and can be ignored because the M flag is set, the O flag is redundant and can be ignored because
skipping to change at page 4, line 40 skipping to change at page 4, line 32
o O=1 A=1 o O=1 A=1
2.3. A (Autonomous) Flag 2.3. A (Autonomous) Flag
The A flag indicates that the prefix that is also carried by the PI The A flag indicates that the prefix that is also carried by the PI
option can be used for SLAAC. A flag semantics are independent of M option can be used for SLAAC. A flag semantics are independent of M
and O flag semantics. The A flag indicates that the prefix can be and O flag semantics. The A flag indicates that the prefix can be
used by SLAAC, regardless of the M and O flag settings. used by SLAAC, regardless of the M and O flag settings.
3. Problem Statement 3. Behavior Ambiguity Analysis
3.1. Divergent Host Behaviors The flags definition ambiguity 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.
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, it is
unclear whether RA (with M=1) is required to trigger DHCPv6; in
other words, It is unclear whether hosts should initiate DHCPv6 by
themselves If there are no RAs at all.
2) Interpretation on Flags 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) Relationship 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 (one is
dedicated for address configuration and the other is for
information configuration). 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.
Divergent behaviors on all the four aspects have been observed among
some popular operating systems as described in Section 4 below.
4. Observed Divergent Host Behaviors
The authors tested several popular operating systems in order to The authors tested several popular operating systems in order to
determine what behaviors the M, O and A flag elicit. In some cases, determine what behaviors the M, O and A flag elicit. In some cases,
the M, A and O flags elicit identical behaviors from most popular the M, O and A flags elicit divergent behaviors. The table below
operating systems. However, in several cases, the M, O and A flags characterizes those cases. For test details, please refer to
elicit divergent behaviors. The table below characterizes those Appendix A.
cases:
Host State Input Behavior Host State Input Behavior
Host has not No RA Some popular operating systems acquire Host has not No RA Some popular operating systems acquire
acquired any addresses from DHCPv6. Others do not. acquired any addresses from DHCPv6. Others do not.
addresses addresses
Host has not RA Some popular operating systems acquire Host has not RA Some popular operating systems acquire
acquired any with other information from DHCPv6, regardless acquired any with other information from DHCPv6, regardless
addresses M=0, of the A flag setting. Others do so, but addresses M=0, of the A flag setting. Others do so, but
O=1 only if A=1 O=1 only if A=1
Host has acquired RA Some operating systems release DHCPv6 Host has acquired RA Some operating systems release DHCPv6
addresses from with M addresses immediately. Some release DHCPv6 addresses from with M addresses immediately. Some release DHCPv6
DHCPv6 only (M = =0 addresses when they expire. DHCPv6 only (M = =0 addresses when they expire.
1) 1)
Host has acquired RA Some operating systems acquire DHCPv6 Host has acquired RA Some operating systems acquire DHCPv6
addresses from with M addresses immediately. Others do so only addresses from with M addresses immediately. Others do so only if
SLAAC only (A=1) = 1 if their SLAAC addresses expire and cannot SLAAC only (A=1) = 1 their SLAAC addresses expire and cannot be
be refreshed. refreshed.
3.2. Operational Problems 5. Operational Problems
This section describes operational issues caused by the divergent This section describes operational issues caused by the divergent
behaviors, described above. behaviors, described above.
3.2.1. Inappropriate Sources 5.1. Inappropriate Sources
Some operating systems base their decision to acquire configuration Some operating systems base their decision to acquire configuration
information upon inappropriate sources. For example, some operating information upon inappropriate sources. For example, some operating
systems acquire other configuration information if M = 0, O = 1, and systems acquire other configuration information if M=0, O=1, and A=1,
A = 1, but not if M = 0, 0 = 1 and A = 0. In other words, on some but not if M=0, O=1 and A=0. In other words, on some operating
operating systems, it is impossible to acquire other information from systems, it is impossible to acquire other information from DHCPv6
DHCPv6 unless addresses are acquired from either DHCPv6 or SLAAC. (stateless DHCPv6 configuration) unless addresses are acquired from
either DHCPv6 or SLAAC.
3.2.2. Renumbering 5.2. Renumbering Issues
According to [RFC6879] a renumbering exercise can include the According to [RFC6879] a renumbering exercise can include the
following steps: following steps:
o Causing hosts that have acquired addresses from one o Causing hosts that have acquired addresses from one auto-
autoconfiguration mechanism to release those addresses and acquire configuration mechanism to release those addresses and acquire new
new addresses from another autoconfiguration mechanism addresses from another auto-configuration mechanism
o Causing hosts that have acquired addresses from one o Causing hosts that have acquired addresses from one auto-
autoconfiguration mechanism to release those addresses and acquire configuration mechanism to release those addresses and acquire new
new addresses from the same autoconfiguration mechanism addresses from the same auto-configuration mechanism
o Causing hosts that have acquired addresses from one o Causing hosts that have acquired addresses from one auto-
autoconfiguration mechanism to retain those addresses and acquire configuration mechanism to retain those addresses and acquire new
new addresses from another autoconfiguration mechanism addresses from another auto-configuration mechanism
Ideally, these steps could be initiated by broadcasting RA message Ideally, these steps could be initiated by broadcasting RA message
onto the subnetwork that is being renumbered. Sadly, this is not onto the subnetwork that is being renumbered. Sadly, this is not
possible, because the RA message may elicit a different behavior from possible, because the RA message may elicit a different behavior from
each host. According to Section 3.1, renumbering operations would each host. According to Section 4, renumbering operations would have
have the following limitations: the following limitations:
o When M flag is turned off, some operating systems release DHCPv6 o When M flag is turned off, some operating systems release DHCPv6
acquired addresses immediately, while other will retain then until acquired addresses immediately, while other will retain then until
they expire. This means a flash switch from DHCPv6 to SLAAC would they expire. This means a flash switch from DHCPv6 to SLAAC would
happen on some hosts. Normally, the "make-before-break" approach happen on some hosts. Normally, the "make-before-break" approach
proposed in [RFC4192] is considered better than flash renumbering. proposed in [RFC4192] is considered better than flash renumbering.
o On some operating systems, if a host has acquired addresses from o On some operating systems, if a host has acquired addresses from
SLAAC, it is impossible to acquire additional addresses from SLAAC, it is impossible to acquire additional addresses from
DHCPv6. This may be required as part of a renumbering operation. DHCPv6. This may be required as part of a renumbering operation.
4. Security Considerations 6. Security Considerations
As this memo does not introduce any new protocols or procedures, it As this memo does not introduce any new protocols or procedures, it
does not introduce any new security vulnerabilities. does not introduce any new security vulnerabilities.
5. IANA Considerations 7. IANA Considerations
This draft does not request any IANA action. This draft does not request any IANA action.
6. Acknowledgements 8. Acknowledgements
The authors wish to acknowledge BNRC-BUPT (Broad Network Research The authors wish to acknowledge BNRC-BUPT (Broad Network Research
Centre in Beijing University of Posts and Telecommunications) for Centre in Beijing University of Posts and Telecommunications) for
their testing efforts. Special thanks to Xudong Shi, Longyun Yuan their testing efforts. Special thanks to Xudong Shi, Longyun Yuan
and Xiaojian Xue for their extraordinary effort. and Xiaojian Xue for their extraordinary effort.
Special thanks to Ron Bonica who made a lot of significant
contribution to this draft, including draft editing and presentations
which dramatically improved this work.
The authors also wish to acknowledge Brian E Carpenter, Ran Atkinson, The authors also wish to acknowledge Brian E Carpenter, Ran Atkinson,
Mikael Abrahamsson, Tatuya Jinmei, Mark Andrews and Mark Smith for Mikael Abrahamsson, Tatuya Jinmei, Mark Andrews and Mark Smith for
their helpful comments. their helpful comments.
7. References 9. References
7.1. Normative References 9.1. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
7.2. Informative References 9.2. Informative References
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
skipping to change at page 8, line 44 skipping to change at page 9, line 44
o Host 2: Ubuntu 14.04 (Linux Kernel 3.12.0) Virtual Host o Host 2: Ubuntu 14.04 (Linux Kernel 3.12.0) Virtual Host
o Host 3: Mac OS X v10.9 Virtual Host o Host 3: Mac OS X v10.9 Virtual Host
o Host 4: IOS 8.0 (model: Apple iPhone 5S, connected via wifi) o Host 4: IOS 8.0 (model: Apple iPhone 5S, connected via wifi)
A.2. Host Behavior in the Initial State A.2. Host Behavior in the Initial State
The bullet list below describes host behavior in the initial state, The bullet list below describes host behavior in the initial state,
when the host has not yet acquired any autoconfiguration information. when the host has not yet acquired any auto-configuration
Each bullet item represents an input and the behavior elicited by information. Each bullet item represents an input and the behavior
that input. elicited by that input.
o A=0, M=0, O=0 o A=0, M=0, O=0
* Windows 8.1 acquired addresses and other information from * Windows 8.1 acquired addresses and other information from
DHCPv6. DHCPv6.
* All other hosts acquired no configuration information. * All other hosts acquired no configuration information.
o A=0, M=0, O=1 o A=0, M=0, O=1
skipping to change at page 10, line 12 skipping to change at page 11, line 12
As showed above, four inputs result in divergent behaviors. As showed above, four inputs result in divergent behaviors.
A.3. Host Behavior in State Transitions A.3. Host Behavior in State Transitions
The bullet list below describes behavior elicited during state The bullet list below describes behavior elicited during state
transitions. The value x can represents both 0 and 1. 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) 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 (This means a SLAAC-configured host, which is regardless of DHCPv6
configured or not, receiving A transitioning from 1 to 0. ) configured or not, receiving A in transition from 1 to 0. )
* All the hosts retain SLAAC addresses until they expire * 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) 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 transitioning from 0 to (This means a SLAAC-only host receiving M in transition from 0 to
1.) 1.)
* Windows 7 acquires addresses from DHCPv6, immediately. * Windows 7 acquires addresses from DHCPv6, immediately.
* Ubuntu 14.04/OSX 10.9/IOS 8.0 acquires addresses from DHCPv6 * Ubuntu 14.04/OSX 10.9/IOS 8.0 acquires addresses from DHCPv6
only if the SLAAC addresses are allowed to expire only if the SLAAC addresses are allowed to expire
* Windows 8.1 was not tested because it always acquire addresses * Windows 8.1 was not tested because it always acquire addresses
from DHCPv6 regardless of the M flag setting. 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) 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 (This means a DHCPv6-configured host receiving M in transition
from 1 to 0.) from 1 to 0.)
* Windows 7 immediately released the DHCPv6 address * Windows 7 immediately released the DHCPv6 address
* Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0 keep the DHCPv6 * Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0 keep the DHCPv6
addresses until they expire addresses until they expire
o Old state (M = 1, O = x, A = 0), New state (M = 1, O = x, A = 1) 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 transitioning from 0 to (This means a DHCPv6-only host receiving A in transition from 0 to
1.) 1.)
* All host acquire addresses from SLAAC * All host acquire addresses from SLAAC
o Old state (M = 0, O = 1, A = x), New state (M = 1, O = 1, A = x) 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 (This means a Stateless DHCPv6-configured host [RFC3736], which is
regardless of SLAAC configured or not, receiving M transitioning regardless of SLAAC configured or not, receiving M in transition
from 0 to 1 with keeping O=1 ) from 0 to 1 with keeping O=1 )
* Windows 7 acquires addresses and refreshes other information * Windows 7 acquires addresses and refreshes other information
from DHCPv6 from DHCPv6
* Ubuntu 14.04/OSX 10.9/IOS 8.0 does nothing * Ubuntu 14.04/OSX 10.9/IOS 8.0 does nothing
* Windows 8.1 was not tested because it always acquire addresses * Windows 8.1 was not tested because it always acquire addresses
from DHCPv6 regardless of the M flag setting. 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) 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 (This means a Stateful DHCPv6-configured host, which is regardless
of SLAAC configured or not, receiving M transitioning from 0 to 1 of SLAAC configured or not, receiving M in transition from 0 to 1
with keeping O=1 ) with keeping O=1 )
* Windows 7 released all DHCPv6 addresses and refreshes all * Windows 7 released all DHCPv6 addresses and refreshes all
DHCPv6 other information. DHCPv6 other information.
* Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0 does nothing * 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 Authors' Addresses
Bing Liu Bing Liu
Huawei Technologies Huawei Technologies
Q14, Huawei Campus, No.156 Beiqing Road Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095 Hai-Dian District, Beijing, 100095
P.R. China P.R. China
Email: leo.liubing@huawei.com Email: leo.liubing@huawei.com
Sheng Jiang Sheng Jiang
Huawei Technologies Huawei Technologies
Q14, Huawei Campus, No.156 Beiqing Road Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095 Hai-Dian District, Beijing, 100095
P.R. China P.R. China
Email: jiangsheng@huawei.com Email: jiangsheng@huawei.com
Ron Bonica
Juniper Networks
Sterling, Virginia
20164
USA
Email: rbonica@juniper.net
Xiangyang Gong Xiangyang Gong
BUPT University 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
 End of changes. 39 change blocks. 
134 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/