draft-ietf-v6ops-dhcpv6-slaac-problem-02.txt   draft-ietf-v6ops-dhcpv6-slaac-problem-03.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 17, 2015 R. Bonica Expires: April 30, 2015 R. Bonica
Juniper Networks Juniper Networks
X. Gong X. Gong
W. Wang W. Wang
BUPT University BUPT University
October 14, 2014 October 27, 2014
DHCPv6/SLAAC Address Configuration Interaction Problem Statement DHCPv6/SLAAC Address Configuration Interaction Problem Statement
draft-ietf-v6ops-dhcpv6-slaac-problem-02 draft-ietf-v6ops-dhcpv6-slaac-problem-03
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 autoconfiguration mechanisms are available to on-
link hosts. These are the M, O and A flags. The M, O and A flags link hosts. These are the M, O and A flags. The M and O flags are
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 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 17, 2015. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
3.2.2. Renumbering . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. Renumbering . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Test Results . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Test Results . . . . . . . . . . . . . . . . . . . . 7
A.1. Test Environment . . . . . . . . . . . . . . . . . . . . 7 A.1. Test Environment . . . . . . . . . . . . . . . . . . . . 7
A.2. Host Behavior in the Initial State . . . . . . . . . . . 8 A.2. Host Behavior in the Initial State . . . . . . . . . . . 8
A.3. Host Behavior in State Transitions . . . . . . . . . . . 9 A.3. Host Behavior in State Transitions . . . . . . . . . . . 10
Appendix B. Analysis of the Ambiguities . . . . . . . . . . . . 10 Appendix B. Analysis of the Ambiguities . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 autoconfiguration mechanisms
are available to them. The following is a list of autoconfiguration are available to them. The following is a list of autoconfiguration
mechanisms: mechanisms:
o DHCPv6 [RFC3315] o DHCPv6 [RFC3315]
skipping to change at page 3, line 18 skipping to change at page 3, line 18
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
flag indicates that other configuration information (e.g., DNS- flag indicates that other configuration information (e.g., DNS-
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, O and A flag indicates that the prefix can be used for SLAAC. The M and O
flags are advisory, not prescriptive. For example, the M flag flags are advisory, not prescriptive (although A flag is also
indicates that addresses are available from DHCPv6. It does not advisory in definition in standard, it is quite prescriptive in
indicate that hosts are required to acquire addresses from DHCPv6. implementations). For example, the M flag indicates that addresses
Similar statements can be made about the O and A flags. 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 flag.
In most cases, the M, O and A flags elicit identical behaviors from In most cases, the M, O and A flags elicit identical behaviors from
most popular operating systems. However, in several cases, the M, O most popular operating systems. However, in several cases, the M, O
and A flags elicit divergent behaviors. For example, when a router 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 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 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 and another behavior from hosts running a different
operating system. operating system.
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 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 IPv6. If the The M flag indicates that addresses are available from DHCPv6. If
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
DHCPv6 will return all available configuration information. DHCPv6 will return all available configuration information.
M and A flag semantics are independent of one another. The M flag M and A flag semantics are independent of one another. The M flag
indicates that addresses are available from DHCPv6, regardless of the indicates that addresses are available from DHCPv6, regardless of the
A flag setting. The following setting are all allowed: A flag setting. The following settings are all allowed:
o M=0 A=0 o M=0 A=0
o M=0 A=1 o M=0 A=1
o M=1 A=0 o M=1 A=0
o M=1 A=1 o M=1 A=1
2.2. O (Otherconfig) Flag 2.2. O (Otherconfig) Flag
The O flag indicates that other configuration information (e.g., DNS- The O flag indicates that other configuration information (e.g., DNS-
related information) is available from IPv6. If the M flag is set, related information) is available from DHCPv6. If the M flag is set,
the O flag is redundant and can be ignored because DHCPv6 will return the O flag is redundant and can be ignored because DHCPv6 will return
all available configuration information. all available configuration information.
O and A flag semantics are independent of one another. The O flag O and A flag semantics are independent of one another. The O flag
indicates that other configuration is available from DHCPv6, indicates that other configuration is available from DHCPv6,
regardless of the A flag setting. The following setting are all regardless of the A flag setting. The following settings are all
allowed: allowed:
o O=0 A=0 o O=0 A=0
o O=0 A=1 o O=0 A=1
o O=1 A=0 o O=1 A=0
o O=1 A=1 o O=1 A=1
skipping to change at page 6, line 15 skipping to change at page 6, line 15
o Causing hosts that have acquired addresses from one o Causing hosts that have acquired addresses from one
autoconfiguration mechanism to retain those addresses and acquire autoconfiguration mechanism to retain those addresses and acquire
new addresses from another autoconfiguration mechanism new addresses from another autoconfiguration 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 3.1, renumbering operations would
have the following limitations: have the following limitations:
o During a flash switch from DHCPv6 to SLAAC, some operating systems o When M flag is turned off, some operating systems release DHCPv6
release DHCPv6 acquired addresses immediately, while other will acquired addresses immediately, while other will retain then until
retain then until they expire. Therefore, results are they expire. This means a flash switch from DHCPv6 to SLAAC would
unpredictable. happen on some hosts. Normally, the "make-before-break" approach
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 4. 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.
skipping to change at page 7, line 25 skipping to change at page 7, line 25
7.2. Informative References 7.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
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios, Considerations, and Network Renumbering Scenarios, Considerations, and
Methods", RFC 6879, February 2013. Methods", RFC 6879, February 2013.
Appendix A. Test Results Appendix A. Test Results
A.1. Test Environment A.1. Test Environment
/-----\ /-----\
+---------+ // \\ +---------+ // \\
| DHCPv6 | | Router | | DHCPv6 | | Router |
| server | \\ // | server | \\ //
+----+----+ \--+--/ +----+----+ \--+--/
| | | |
| | | |
| | | |
----+--+----------+----------+---+----- ----+--+----------+----------+---+-----
| | | | | |
skipping to change at page 9, line 40 skipping to change at page 10, 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, reveiving A transitiong from 1 to 0. ) configured or not, receiving A transitioning 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 transisioning from 0 to (This means a SLAAC-only host receiving M transitioning 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 transitioning
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 transisioning from 0 to (This means a DHCPv6-only host receiving A transitioning 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 transisioning regardless of SLAAC configured or not, receiving M transitioning
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 transisioning from 0 to 1 of SLAAC configured or not, receiving M transitioning 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 Appendix B. Analysis of the Ambiguities
Following is a comprehensive analysis of the ambiguities as defined Following is a comprehensive analysis of the ambiguities as defined
skipping to change at page 11, line 23 skipping to change at page 11, line 43
2. Behaviors of Flag Transition 2. Behaviors of Flag Transition
When flags are in transition, e.g. the host is already SLAAC- When flags are in transition, e.g. the host is already SLAAC-
configured, then M flag changes from FALSE to TRUE, it is not configured, then M flag changes from FALSE to TRUE, it is not
clear whether the host should start DHCPv6 or not; or vise versa, clear whether the host should start DHCPv6 or not; or vise versa,
the host is already both SLAAC/DHCPv6 configured, then M flag the host is already both SLAAC/DHCPv6 configured, then M flag
change from TRUE to FALSE, it is also not clear whether the host change from TRUE to FALSE, it is also not clear whether the host
should turn DHCPv6 off or not. should turn DHCPv6 off or not.
3. Distinction between "Address Configuring Method" and "Address 3. Distinction between "Address Configuring Method" and "Address
Lifetime" Lifetime"
When one address configuration method is off, that is, the A flag 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 or M flag changes from TRUE to FALSE, it is not clear whether the
host should immediately release the corresponding address(es) or host should immediately release the corresponding address(es) or
just retain it(them) until expired. just retain it(them) until expired.
4. Dependencies between the flags 4. Dependencies between the flags
The semantics of the flags seems not totally independent, but the The semantics of the flags seems not totally independent, but the
standards didn't clearly clarify it. For example, when both M and 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 O flags are TRUE, it is not clear whether the host should initiate
one stateful DHCPv6 session to get both address and info- one stateful DHCPv6 session to get both address and info-
configuration or initiate two independent sessions of which one is configuration or initiate two independent sessions of which one is
dedicated for address provisioning and the other is for dedicated for address provisioning and the other is for
information provision. When A and M flags are FALSE and O flag is 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- TRUE, it is not clear whether the host should initiate a stand-
alone stateless DHCPv6 session. alone stateless DHCPv6 session.
 End of changes. 23 change blocks. 
32 lines changed or deleted 37 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/