draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt   draft-ietf-v6ops-dhcpv6-slaac-problem-05.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: November 3, 2015 X. Gong Expires: January 7, 2016 X. Gong
W. Wang W. Wang
BUPT University BUPT University
May 2, 2015 E. Rey
ERNW GmbH
July 6, 2015
DHCPv6/SLAAC Interaction Problems on Address Auto-configuration DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration
draft-ietf-v6ops-dhcpv6-slaac-problem-04 draft-ietf-v6ops-dhcpv6-slaac-problem-05
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 auto-configuration mechanisms are available to on- indicating the availability of address auto-configuration mechanisms
link hosts. These are the M, O and A flags. The M and O flags are and other configuration. These are the M, O, and A flags. These
advisory, not prescriptive. flags by definition are 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 discusses operational problems that
divergent behaviors might 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 November 3, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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. Flags Definition . . . . . . . . . . . . . . . . . . . . 3
2.2. O (Otherconfig) Flag . . . . . . . . . . . . . . . . . . 4 2.2. Flags Relationship . . . . . . . . . . . . . . . . . . . 4
2.3. A (Autonomous) Flag . . . . . . . . . . . . . . . . . . . 4
3. Behavior Ambiguity Analysis . . . . . . . . . . . . . . . . . 4 3. Behavior Ambiguity Analysis . . . . . . . . . . . . . . . . . 4
4. Observed Divergent Host Behaviors . . . . . . . . . . . . . . 5 4. Observed Divergent Host Behaviors . . . . . . . . . . . . . . 5
5. Operational Problems . . . . . . . . . . . . . . . . . . . . 6 5. Operational Problems . . . . . . . . . . . . . . . . . . . . 8
5.1. Inappropriate Sources . . . . . . . . . . . . . . . . . . 6 5.1. Inappropriate Sources . . . . . . . . . . . . . . . . . . 8
5.2. Renumbering Issues . . . . . . . . . . . . . . . . . . . 6 5.2. Renumbering Issues . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Test Results . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Test Results . . . . . . . . . . . . . . . . . . . . 11
A.1. Test Environment . . . . . . . . . . . . . . . . . . . . 8 A.1. Test Set 1 . . . . . . . . . . . . . . . . . . . . . . . 11
A.2. Host Behavior in the Initial State . . . . . . . . . . . 9 A.1.1. Test Environment . . . . . . . . . . . . . . . . . . 11
A.3. Host Behavior in State Transitions . . . . . . . . . . . 11 A.1.2. Address Auto-configuration Behavior in the Initial
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 State . . . . . . . . . . . . . . . . . . . . . . . . 11
A.1.3. Address Auto-configuration Behavior in State
Transitions . . . . . . . . . . . . . . . . . . . . . 12
A.2. Test Set 2 . . . . . . . . . . . . . . . . . . . . . . . 14
A.2.1. Test Environment . . . . . . . . . . . . . . . . . . 14
A.2.2. Address/DNS Auto-configuration Behavior of Using Only
One IPv6 Router and a DHCPv6 Server . . . . . . . . . 14
A.2.3. Address/DNS Auto-configuration Behavior of Using Two
IPv6 Router and a DHCPv6 Server . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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 auto-configuration mechanisms procedures in order to discover which auto-configuration mechanisms
are available to them. The following is a list of auto-configuration are available to them. The following is a list of auto-configuration
mechanisms: mechanisms:
o DHCPv6 [RFC3315] o DHCPv6 [RFC3315]
skipping to change at page 3, line 13 skipping to change at page 3, line 22
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
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 PIO (Prefix
includes a prefix, an A (Autonomous) flag and other fields. The A Information Option) includes a prefix, an A (Autonomous) flag and
flag indicates that the prefix can be used for SLAAC. The M and O other fields. The A flag indicates that the prefix can be used for
flags are advisory, not prescriptive (although A flag is also SLAAC. The M and O flags are advisory, not prescriptive (although A
advisory in definition in standard, it is quite prescriptive in flag is also advisory in definition in standard, it is quite
implementations). For example, the M flag indicates that addresses prescriptive in implementations). For example, the M flag indicates
are available from DHCPv6. It does not indicate that hosts are that addresses are available from DHCPv6. It does not indicate that
required to acquire addresses from DHCPv6. Similar statements can be hosts are required to acquire addresses from DHCPv6. Similar
made about the O flag. statements can be made about the O flag.
Because of the advisory definition of the flags, in some cases Because of the advisory definition of the flags, in some cases
different operating systems appear divergent behaviors. This different operating systems appear divergent behaviors. This
document analyzes possible divergent host behaviors might happen document analyzes possible divergent host behaviors might happen
(some of the possible divergent behaviors are already observed in (some of the possible divergent behaviors are already observed in
popular operating systems) and the operational problems might caused popular operating systems) and the operational problems might caused
by divergent behaviors. by divergent behaviors.
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. Flags Definition
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
DHCPv6 will return all available configuration information.
M and A flag semantics are independent of one another. The M flag
indicates that addresses are available from DHCPv6, regardless of the
A flag setting. The following settings are all allowed:
o M=0 A=0
o M=0 A=1
o M=1 A=0
o M=1 A=1
2.2. O (Otherconfig) Flag o M (Managed) Flag
The O flag indicates that other configuration information (e.g., DNS- As decribed in [RFC4861], "When set, it indicates that
related information) is available from DHCPv6. If the M flag is set, addresses are available via Dynamic Host Configuration
the O flag is redundant and can be ignored because DHCPv6 will return Protocol".
all available configuration information.
O and A flag semantics are independent of one another. The O flag o O (Otherconfig) Flag
indicates that other configuration is available from DHCPv6, "When set, it indicates that other configuration information is
regardless of the A flag setting. The following settings are all available via DHCPv6. Examples of such information are DNS-
allowed: related information or information on other servers within the
network." [RFC4861]
o O=0 A=0 Besides, [RFC4861]also defines "If neither M nor O flags are
set, this indicates that no information is available via
DHCPv6" .
o O=0 A=1 o A (Autonomous) Flag
o O=1 A=0 A flag is defined in the PIO, "When set indicates that this
prefix can be used for stateless address configuration as
specified in [RFC4862].".
o O=1 A=1 2.2. Flags Relationship
2.3. A (Autonomous) Flag Per [RFC4861], "If the M flag is set, the O flag is redundant and can
be ignored because DHCPv6 will return all available configuration
information.".
The A flag indicates that the prefix that is also carried by the PI M/O flags semantics are independent of A flag's. The M/O flags
option can be used for SLAAC. A flag semantics are independent of M indicate that addresses or other configuration are available from
and O flag semantics. The A flag indicates that the prefix can be DHCPv6, regardless of the A flag setting. Vice versa, The A flag
used by SLAAC, regardless of the M and O flag settings. indicates that the prefix can be used by SLAAC, regardless of the M/O
flags settings.
3. Behavior Ambiguity Analysis 3. Behavior Ambiguity Analysis
The flags definition ambiguity means, on interpreting the same The flags definition ambiguity means, on interpreting the same
messages, different hosts might behave differently. Thus it could be messages, different hosts might behave differently. Thus it could be
un-controlled or un-predictable for administrators on some un-controlled or un-predictable for administrators on some
operations. The ambiguity is summarized as the following aspects. operations. The ambiguity is summarized as the following aspects.
1) Dependency between DHCPv6 and RA 1) Dependency between DHCPv6 and RA
In standards, behavior of DHCPv6 and Neighbor Discovery protocols In standards, behavior of DHCPv6 and Neighbor Discovery protocols
is specified respectively. But it is not clear that whether there is specified respectively. But it is not clear that whether there
should be any dependency between them. More specifically, it is should be any dependency between them. More specifically, it is
unclear whether RA (with M=1) is required to trigger DHCPv6; in unclear whether RA (with M=1) is required to trigger DHCPv6; in
other words, It is unclear whether hosts should initiate DHCPv6 by other words, It is unclear whether hosts should initiate DHCPv6 by
themselves If there are no RAs at all. themselves If there are no RAs at all.
2) Interpretation on Flags Transition 2) Overlapped configuration between DHCPv6 and RA
When address and DNS configuration are both available from DHCPv6
and RA, it is not clear how to deal with the overlapped
information. Should the hosts accept all the information? Which
one should be in the higher priority?
For DNS configuration, [RFC6106] clearly specifies "In the case
where the DNS options of RDNSS and DNSSL can be obtained from
multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep
some DNS options from all sources" and "the DNS information from
DHCP takes precedence over that from RA for DNS queries"
(Section 5.3.1 of [RFC6106]). But for address configuration,
there's no such guidance.
3) Interpretation on Flags 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) Relationship between Address Configuring Method and Address Transition might caused by the same source that changes the
previous configuration; or cause by another source which has
different configuration.
4) Relationship 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 5) Relationship 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, can A flag
O flags are TRUE, it is not clear whether the host should initiate influence the behavior of O flag? (Specifically, when A and M
one stateful DHCPv6 session to get both address and info- flags are FALSE and O flag is TRUE, it is not clear whether the
configuration or initiate two independent sessions (one is host should initiate a stand-alone stateless DHCPv6 session.)
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 Divergent behaviors on all the five aspects have been observed among
some popular operating systems as described in Section 4 below. some popular operating systems as described in Section 4 below.
4. Observed Divergent Host Behaviors 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, O and A flags elicit divergent behaviors. The table below the M, O and A flags elicit divergent behaviors. The table below
characterizes those cases. For test details, please refer to characterizes those cases. For test details, please refer to
Appendix A. Appendix A.
Host State Input Behavior The divergence contains two aspect: one is regarding to address auto-
configuration; the other is regarding to DNS configuration.
Host has not No RA Some popular operating systems acquire Host State Input Behavior
acquired any addresses from DHCPv6. Others do not. ------------------ ----- --------------------------------------------
addresses
Host has not RA Some popular operating systems acquire Host has not No RA Some popular operating systems acquire
acquired any with other information from DHCPv6, regardless acquired any addresses from DHCPv6. Others do not.
addresses M=0, of the A flag setting. Others do so, but addresses
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 addresses immediately. Some release DHCPv6
DHCPv6 only (M = =0 addresses when they expire. DHCPv6 only (M = 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 if addresses from with addresses immediately. Others do so only if
SLAAC only (A=1) = 1 their SLAAC addresses expire and cannot be SLAAC only (A=1) M = 1 their SLAAC addresses expire and cannot be
refreshed. refreshed.
Divergent Behaviors on Address Auto-Configuration
Host State Input Behavior
----------- ------------- -------------------------------------------
Host has RA with M=0, Some popular operating systems acquire
not O=1, no RDNNS from DHCPv6, regardless of the A flag
acquired RDNSS; A setting. Others do so, but only if A=1.
any DHCPv6 server
addresses on the same
or link
information providing
RDNSS
(regardless
of address
provisioning)
Host has RA with (Only for those operations systems which
not M=0/1, A=1, support [RFC6106]) 1) getting RDNSS from
acquired O=1 and an both the RAs and the DHCPv6 server, and the
any RDNSS is RDNSS obtained from the router has a higher
addresses advertised;A priority. 2) getting RDNSS from both, but
or DHCPv6 server the RDNSS obtained from the DHCPv6 server
information on the same has a higher priority. 3) getting an RDNSS
link from the router, and a "domain search list"
providing information from the DHCPv6 server- but not
IPv6 RDNSS information.
addresses and
RDNSS
Host has Another (Only for those operations systems which
acquired router support [RFC6106]) 1) never get any
address and advertising information (IPv6 address or RDNSS) from
RDNSS from M=1, O=1, no the DHCPv6 server. 2) When receiving an RA
the first prefix from router 2, getting an IPv6 address and
router information; RDNSS from the DHCPv6 server while
(M=0, O=0, A DHCPv6 retaining the address and RDNSS obtained
A=1 and server on the from the RAs of the first router. The RDNSS
RDNSS same link obtained from the first router has a higher
advertised) providing priority; when they receive again RAs from
IPv6 the first router, they lose/forget the
addresses and information (IPv6 address and RDNSS)
RDNSS obtained from the DHCPv6 server.
Host has Another (Only for those operations systems which
acquired router support [RFC6106]) 1) When they receive RAs
address and advertising from the second router, they get
RDNSS from M=0, O=0, address(es) and RDNSS from these RAs. At
the first A=1, and the same time, the IPv6 address and the
router RNDSS RDNSS obtained from the DHCPv6 server are
(M=1, O=1, gone. When they receives again an RA from
no PIO or the first router, they perform the DHCPv6
RDNSS Confirm/Reply procedure and they get an
advertised) IPv6 address and RDNSS from the DHCPv6
server while retaining the ones obtained
from the RAs of the second router.
Moreover, the RDNSS from router 1 has
higher priority than the one from DHCPv6.
2) When it receives RAs from the second
router, it also gets information from it,
but it does not lose the information
obtained from the DHCPv6 server. It retains
both. It only gets "Domain Search list"
from the DHCPv6 server-no RDNSS
information. When it receives RAs from the
first router, there is no change; it
retains all the obtained information. 3)
When it gets RAs from the second router, it
also gets a SLAAC IPv6 address but no RDNSS
information from the RAs of this router. It
also does not lose any information obtained
from DHCPv6. When it gets RAs from the
first router again, the situation does not
change (IPv6 addresses from both the DHCPv6
and SLAAC process are retained, but RDNSS
information only from the DHCPv6 server).
Divergent Behaviors on DNS Configuration
5. 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.
5.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
skipping to change at page 7, line 27 skipping to change at page 9, line 17
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.
6. Security Considerations 6. Security Considerations
As this memo does not introduce any new protocols or procedures, it (Note: the security considerations for specific operating systems are
does not introduce any new security vulnerabilities. based on the detailed test results as described in Appendix A.)
An attacker, without having to install a rogue router, can install a
rogue DHCPv6 server and provide IPv6 addresses to Windows 8.1
systems. This can allow her to interact with these systems in a
different scope, which, for instance, is not monitored by an IDPS
system.
If you want to perform MiTM using a rogue DNS while legitimate RAs
with the O flag set are sent to enforce the use of a DHCPv6 server,
you can spoof RAs with the same settings with the legitimate prefix
(in order to remain undetectable) but advertising YOUR (attacker's)
DNS using RDNSS. In this case, Fedora 21, Centos 7 and Ubuntu 14.04
will use the rogue RDNSS (advertised by the RAs) as a first option.
Fedora 21 and Centos 7 behaviour cannot be explored for a MiTM attack
using a rogue DNS information either, since the one obtained by the
RAs of the first router has a higher priority.
The behaviour of Fedora 21, Centos 7 and Windows 7 can be exploited
for DoS purposes. A rogue IPv6 router not only provides its own
information to the clients, but it also removes the previous obtained
(legitimate) information. The Fedora and Centos behaviour can also
be exploited for MiTM purposes by advertising rogue RDNSS by RAs
which include RDNSS information.
7. IANA Considerations 7. IANA Considerations
This draft does not request any IANA action. This draft does not request any IANA action.
8. 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
skipping to change at page 8, line 23 skipping to change at page 10, line 33
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.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010.
9.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,
September 2005. 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 The authors from two orgnizations tested different scenarios
/-----\ independent of each other. The following text decribes the two test
+---------+ // \\ sets respectively.
| DHCPv6 | | Router |
| server | \\ //
+----+----+ \--+--/
| |
| |
| |
----+--+----------+----------+---+-----
| | |
| | |
| | |
+----+---+ +----+---+ +----+---+
| | | | | |
| Host 1 | | Host 2 | | Host 3 |
+--------+ +--------+ +--------+
Figure 1: Test Environment A.1. Test Set 1
The test environment depicted Figure 1 in was replicated on a single A.1.1. Test Environment
server using VMware. For simplicity of operation, only one host was
run at a time. Network elements were as follows: The test environment was replicated on a single server using VMware.
For simplicity of operation, only one host was run at a time.
Network elements were as follows:
o Router: Quagga 0.99-19 soft router installed on Ubuntu 11.04 o Router: Quagga 0.99-19 soft router installed on Ubuntu 11.04
virtual host virtual host
o DHCPv6 Server: Dibbler-server installed on Ubuntu 11.04 virtual o DHCPv6 Server: Dibbler-server installed on Ubuntu 11.04 virtual
host host
o Host 1: Window 7 / Window 8.1 Virtual Host o Host 1: Window 7 / Window 8.1 Virtual Host
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.1.2. Address Auto-configuration 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 auto-configuration when the host has not yet acquired any auto-configuration
information. Each bullet item represents an input and the behavior information. Each bullet item represents an input and the behavior
elicited by 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.
skipping to change at page 11, line 5 skipping to change at page 12, line 47
* All hosts acquired addresses from SLAAC and DHCPv6. They also * All hosts acquired addresses from SLAAC and DHCPv6. They also
acquired other information from DHCPv6. acquired other information from DHCPv6.
o A=1, M=1, O=1 o A=1, M=1, O=1
* All hosts acquired addresses from SLAAC and DHCPv6. They also * All hosts acquired addresses from SLAAC and DHCPv6. They also
acquired other information from DHCPv6. acquired other information from DHCPv6.
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.1.3. Address Auto-configuration 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 in transition 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
skipping to change at page 12, line 17 skipping to change at page 14, line 13
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 in transition 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
A.2. Test Set 2
A.2.1. Test Environment
This test was built on real devices. All the devices are located on
the same link.
o A DHCPv6 Server and specifically, a DHCP ISC Version 4.3.1
installed in CentOs 6.6. The DHCPv6 server is configured to
provide both IPv6 addresses and RDNSS information.
o Two routers Cisco 4321 using Cisco IOS Software version 15.5(1)S.
o The following OS as clients:
* Fedora 21, kernel version 3.18.3-201 x64
* Ubuntu 14.04.1 LTS, kernel version 3.13.0-44-generic (rdnssd
packet installed)
* CentOS 7, kernel version 3.10.0-123.13.2.el7
* Mac OS-X 10.10.2 Yosemite 14.0.0 Darwin
* Windows 7
* Windows 8.1
A.2.2. Address/DNS Auto-configuration Behavior of Using Only One IPv6
Router and a DHCPv6 Server
In these scenarios there is two one router and, unless otherwise
specified, one DHCPv6 server on the same link. The behaviour of the
router and of the DHCPv6 server remain unchanged during the tests.
Case 1: One Router with the Management Flag not Set and a DHCPv6
Server
o Set up
* One IPv6 Router with M=0, A=1, O=0 and an RDNSS is advertised
* A DHCPv6 server on the same link advertising IPv6 addresses and
RDNSS
o Results
* Fedora 21, MAC OS-X, CentOS 7 and Ubuntu 14.04 get an IPv6
address and an RDNSS from the IPv6 router only.
* Windows 7 get an IPv6 address from the router only, but they do
not get any DNS information, neither from the router nor from
the DHCPv6 server. They also do not get IPv6 address from the
DHCPv6 server.
* Windows 8.1 get an IPv6 address from both the IPv6 router and
the DHCPv6 server, despite the fact that the Management flag
(M) is not set. They get RDNSS information from the DHCPv6
only.
Case 2: One Router with Conflicting Parameters and a DHCPv6 Server
o Set up
* One IPv6 Router with M=0, A=1, O=1 and an RDNSS is advertised
* A DHCPv6 server on the same link advertising IPv6 addresses and
RDNSS
o Results
* Fedora 21, Centos 7 and Ubuntu 14.04 get IPv6 address using
SLAAC only (no address from the DHCPv6 server).
+ Fedora 21, Centos 7 get RDNSS from both the RAs and the
DHCPv6 server. The RDNSS obtained from the router has a
higher priority though.
+ Ubuntu 14.04 gets an RDNSS from the router, and a "domain
search list" information from the DHCPv6 server - but not
RDNSS information.
* MAC OS-X also gets RDNSS from both, IPv6 address using SLAAC
(no IPv6 address from the DHCPv6 server) but the RDNSS obtained
from the DHCPv6 server is first (it has a higher priority).
However, the other obtained from the RAs is also present.
* Windows 7 and Windows 8.1 obtain IPv6 addresses using SLAAC and
RDNSS from the DHCPv6 server. They do not get IPv6 address
from the DHCPv6 server. Compare the Windows 8.1 behaviour with
the previous case.
Case 3: Same as Case 2 but Without a DHCPv6 Server
o Set up
* One IPv6 Router with M=0, A=1, O=1 and an RDNSS is advertised
* no DHCPv6 present
o Results
* Windows 7 and Windows 8.1 get an IPv6 address using SLAAC but
they do not get RDNSS information.
* MAC OS-X, Fedora 21, Centos 7 and Ubuntu 14.04 get an IPv6
address using SLAAC and RDNSS from the RAs.
Case 4: All Flags are Set and a DHCPv6 Server is Present
o Set up
* One IPv6 Router with M=1, A=1, O=1 and an RDNSS is advertised
* A DHCPv6 server on the same link advertising IPv6 addresses and
RDNSS
o Results
* Fedora 21 and Centos 7:
+ They get IPv6 address both from SLAAC and DHCPv6 server.
+ They get RDNSS both from RAs and DHCPv6 server.
+ The DNS of the RAs has higher priority.
* Ubuntu 14.04:
+ It gets IPv6 address both using SLAAC and from the DHCPv6
server.
+ It gets RDNSS from RAs only.
+ From the DHCPv6 server it only gets "Domain Search List"
information, no RDNSS.
* MAC OS-X:
+ It gets IPv6 addresses both using SLAAC and from the DHCPv6
server.
+ It also gets RDNSS both from RAs and the DHCPv6 server.
+ The DNS server of the DHCPv6 has higher priority.
* Windows 7 and Windows 8.1:
+ They get IPv6 address both from SLAAC and DHCPv6 server.
+ They get RDNSS only from the DHCPv6 server.
Case 5: All Flags are Set and There is No DHCPv6 Server is Present
o Set up
* One IPv6 Router with M=1, A=1, O=1 and an RDNSS is advertised
* no DHCPv6 is present
o Results
* Windows 7 and Windows 8.1 get an IPv6 address using SLAAC but
no RDNSS information.
* MAC OS-X, Fedora 21, Centos 7, Ubuntu 14.04 get an IPv6 address
using SLAAC and RDNSS from the RAs.
Case 6: A Prefix is Advertised by RAs but the 'A' flag is not Set
o Set up
* An IPv6 Router with M=0, A=0 (while a prefix information is
advertised), O=0 and an RDNSS is advertised.
* DHCPv6 is present
o Results
* Fedora 21, Centos 7, Ubuntu 14.04 and MAC OS-X:
+ They do not get any IPv6 address (neither from the RAs, nor
from the DHCPv6).
+ They get a RDNSS from the router only (not from DHCPv6).
* Windows 8.1
+ They get IPv6 address and RDNSS from the DHCPv6 server
("last resort" behaviour).
+ They do not get any information (neither IPv6 address not
RDNSS) from the router.
* Windows 7:
+ They get nothing (neither IPv6 address nor RDNSS) from any
source (RA or DHCPv6).
A.2.3. Address/DNS Auto-configuration Behavior of Using Two IPv6 Router
and a DHCPv6 Server
these scenarios there are two routers on the same link. At first,
only one router is present (resembling the "legitimate router)",
while the second one joins the link after the clients first
configured by the RAs of the first router. Our goal is to examine
the behaviour of the clients during the interchange of the RAs from
the two different routers.
Case 7: Router 1 Advertising M=0, O=0 and RDNSS, and then Router 2
advertising M=1, O=1 while DHCPv6 is Present
o Set up
* Initially:
+ One IPv6 router with M=0, O=0, A=1 and RDNSS advertised and
15 seconds time interval of the RAs
* After a while (when clients are configured by the RAs of the
above router):
+ Another IPv6 router with M=1, O=1, no advertised prefix
information, and 30 seconds time interval of the RAs.
+ A DHCPv6 server on the same link providing IPv6 addresses
and RDNSS.
o Results
* MAC OS-X and Ubuntu 14.04:
+ Initially they get address and RDNSS from the first router.
+ When they receive RAs from the second router, they never get
any information (IPv6 address or RDNSS) from the DHCPv6
server.
* Windows 7:
+ Initially they get address from the first router - no RDNSS.
+ When they receive RAs from the second router, they never get
any information (IPv6 address or RDNSS) from the DHCPv6
server.
* Fedora 21 and Centos 7:
+ Initially they get IPv6 address and RDNSS from the RAs of
the first router. o
+ When they receive an RA from router 2, they also get an IPv6
address and RDNSS from the DHCPv6 server while retaining the
ones (IPv6 address and RDNSS) obtained from the RAs of the
first router. The RDNSS obtained from the first router has
a higher priority than the one obtained from the DHCPv6
server (probably because it was received first). o
+ When they receive again RAs from the first router, they
lose/forget the information (IPv6 address and RDNSS)
obtained from the DHCPv6 server.
* Windows 8.1:
+ Initially, they get just an IPv6 address from the first
router 1 - no RDNSS information (since they do not implement
RFC 6106).
+ When they receive RAs from the second router, then they also
get an IPv6 address from the DHCPv6 server, as well as RDNSS
from it. They do not lose the IPv6 address obtained by the
first router using SLAAC.
+ When they receive RA from the first router, they retain all
the obtained so far information (there isn't any change).
Case 8: (Router 2) Initially M=1, O=1 and DHCPv6, then 2nd Router
(Router 1) Rogue RAs Using M=0, O=0 and RDNSS Provided
o Set up
* Initially:
+ One IPv6 router with M=1, O=1, no advertised prefix
information, and 30 seconds time interval of the RAs.
+ A DHCPv6 server on the same link advertising IPv6 addresses
and RDNSS.
* After a while (when clients are configured by the RAs of the
above router):
+ Another IPv6 router with M=0, O=0, A=1, RDNSS advertised and
15 seconds time interval of the RAs.
o Results
* Fedora 21 and Centos 7:
+ At first, they get information (IPv6 address and RDNSS) from
the DHCPv6 server.
+ When they receive RAs from the second router, they get
address(es) and RDNSS from these RAs. At the same time, the
IPv6 address and the RDNSS obtained from the DHCPv6 server
are gone.
+ When they receives again an RA from the first router, they
perform the DHCPv6 Confirm/Reply procedure and they get an
IPv6 address and RDNSS from the DHCPv6 server while
retaining the ones obtained from the RAs of the second
router. Moreover, the RDNSS from router 1 has higher
priority than the one from DHCPv6.
* Ubuntu 14.04:
+ At first, it gets information (IPv6 address and RDNSS) from
the DHCPv6 server.
+ When it receives RAs from the second router, it also gets
information from it, but it does not lose the information
obtained from the DHCPv6 server. It retains both. It only
gets "Domain Search list" from the DHCPv6 server-no RDNSS
information.
+ When it receives RAs from the first router, there is no
change; it retains all the obtained information.
* Windows 7:
+ Initially they get IPv6 address and RDNSS from the DHCPv6
server.
+ When they get RAs from the second router, they lose this
information (IPv6 address and RDNSS obtained from the DHCPv6
server) and they get only SLAAC addresses using the RAs of
the second router-no RDNSS.
+ When they receive RAs from the first router again, they get
RDNSS and IPv6 address from the DHCPv6 server, but they also
keep the SLAAC addresses.
* Windows 8.1:
+ Initially they get information (IPv6 address and RDNSS) from
the DHCPv6 server.
+ When they receive RAs from the second router, they never get
any information from them.
* MAC OS-X:
+ Initially it gets information (IPv6 address and RDNSS) from
the DHCPv6 server.
+ When it gets RAs from the second router, it also gets a
SLAAC IPv6 address but no RDNSS information from the RAs of
this router. It also does not lose any information obtained
from DHCPv6.
+ When it gets RAs from the first router again, the situation
does not change (IPv6 addresses from both the DHCPv6 and
SLAAC process are retained, but RDNSS information only from
the DHCPv6 server).
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
Xiangyang Gong Xiangyang Gong
BUPT University BUPT University
skipping to change at page 13, line 4 skipping to change at page 22, line 21
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
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: wdwang@bupt.edu.cn Email: wdwang@bupt.edu.cn
Enno Rey
ERNW GmbH
Email: erey@ernw.de
 End of changes. 40 change blocks. 
123 lines changed or deleted 595 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/