One document matched: draft-ietf-v6ops-dhcpv6-slaac-problem-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-v6ops-dhcpv6-slaac-problem-06"
ipr="trust200902">
<front>
<title abbrev="DHCPv6/SLAAC Interact Problems">DHCPv6/SLAAC Interaction
Problems on Address and DNS Configuration</title>
<author fullname="Bing Liu" initials="B." surname="Liu">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Q14, Huawei Campus, No.156 Beiqing Road</street>
<city>Hai-Dian District, Beijing, 100095</city>
<country>P.R. China</country>
</postal>
<email>leo.liubing@huawei.com</email>
</address>
</author>
<author fullname="Sheng Jiang" initials="S." surname="Jiang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Q14, Huawei Campus, No.156 Beiqing Road</street>
<city>Hai-Dian District, Beijing, 100095</city>
<country>P.R. China</country>
</postal>
<email>jiangsheng@huawei.com</email>
</address>
</author>
<author fullname="Xiangyang Gong" initials="X." surname="Gong">
<organization>BUPT University</organization>
<address>
<postal>
<street>No.3 Teaching Building</street>
<street>Beijing University of Posts and Telecommunications
(BUPT)</street>
<street>No.10 Xi-Tu-Cheng Rd.</street>
<city>Hai-Dian District, Beijing</city>
<country>P.R. China</country>
</postal>
<email>xygong@bupt.edu.cn</email>
</address>
</author>
<author fullname="Wendong Wang" initials="W." surname="Wang ">
<organization>BUPT University</organization>
<address>
<postal>
<street>No.3 Teaching Building</street>
<street>Beijing University of Posts and Telecommunications
(BUPT)</street>
<street>No.10 Xi-Tu-Cheng Rd.</street>
<city>Hai-Dian District, Beijing</city>
<country>P.R. China</country>
</postal>
<email>wdwang@bupt.edu.cn</email>
</address>
</author>
<author fullname="Enno Rey" initials="E." surname="Rey">
<organization>ERNW GmbH</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email>erey@ernw.de</email>
<uri/>
</address>
</author>
<date day="5" month="February" year="2016"/>
<area>OPS Area</area>
<workgroup>V6OPS</workgroup>
<keyword>IPv6 Address Configuration</keyword>
<keyword>DHCPv6</keyword>
<keyword>SLAAC</keyword>
<abstract>
<t>The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router
Advertisement (RA) message. The RA message contains three flags,
indicating the availability of address auto-configuration mechanisms and
other configuration such as DNS-related configuration. These are the M,
O, and A flags, which by definition are advisory, not prescriptive.</t>
<t>This document describes divergent host behaviors observed in popular
operating systems. It also discusses operational problems that the
divergent behaviors might cause.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="RFC2460">IPv6</xref> hosts could invoke <xref
target="RFC4861">Neighbor Discovery (ND)</xref> to to discover which
auto-configuration mechanisms are available to them. There are two
auto-configuration mechanisms in IPv6:</t>
<t><list style="symbols">
<t><xref target="RFC3315">DHCPv6 </xref></t>
<t><xref target="RFC4862">Stateless Address Autoconfiguration
(SLAAC) </xref></t>
</list>ND specifies an <xref target="RFC4443">ICMPv6-based </xref>
Router Advertisement (RA) message. Routers periodically multicast the RA
messages to all on-link nodes. They also unicast RA messages in response
to solicitations. The RA message contains (but not limited to):</t>
<t><list style="symbols">
<t>an M (Managed) flag, indicating that addresses are available from
DHCPv6 or not</t>
<t>an O (OtherConfig) flag, indicating that other configuration
information (e.g., DNS-related information) is available from DHCPv6
or not</t>
<t>zero or more Prefix Information (PI) Options<list style="empty">
<t hangText="">an A (Autonomous) flag is included, indicating
that the prefix can be used for SLAAC or not</t>
</list></t>
</list>The M and O flags are advisory, not prescriptive. For example,
the M flag indicates that addresses are available from DHCPv6, but It
does not indicate that hosts are required to acquire addresses from
DHCPv6. Similar statements can be made about the O flag. (A flag is also
advisory by definition in standard, but it is quite prescriptive in
implementations according to the test results in the appendix.)</t>
<t>Because of the advisory definition of the flags, in some cases
different operating systems appear divergent behaviors. This document
analyzes possible divergent host behaviors might happen (most of the
possible divergent behaviors are already observed in popular operating
systems) and the operational problems might caused by divergent
behaviors.</t>
</section>
<section anchor="ExistDefine" title="The M, O and A Flags">
<t>This section briefly reviews how the M, O and A flags are defined in
ND<xref target="RFC4861"/> and SLAAC<xref target="RFC4862"/>.</t>
<section title="Flags Definition">
<t><list style="symbols">
<t>M (Managed) Flag<list style="empty">
<t>As decribed in <xref target="RFC4861"/>, "When set, it
indicates that addresses are available via Dynamic Host
Configuration Protocol".</t>
</list></t>
<t>O (Otherconfig) Flag<list style="empty">
<t>"When set, it indicates that other configuration
information is available via DHCPv6. Examples of such
information are DNS-related information or information on
other servers within the network." <xref
target="RFC4861"/></t>
<t>"If neither M nor O flags are set, this indicates that no
information is available via DHCPv6" . <xref
target="RFC4861"/></t>
</list></t>
<t>A (Autonomous) Flag<list style="empty">
<t>A flag is defined in the PIO, "When set indicates that this
prefix can be used for stateless address configuration as
specified in <xref target="RFC4862"/>.".</t>
</list></t>
</list></t>
</section>
<section title="Flags Relationship">
<t>Per <xref target="RFC4861"/>, "If the M flag is set, the O flag is
redundant and can be ignored because DHCPv6 will return all available
configuration information.".</t>
<t>There is no explicit description of the relationship between A flag
and the M/O flags.</t>
<t/>
</section>
</section>
<section title="Behavior Ambiguity Analysis">
<t>The ambiguity of the flags definition means that when interpreting
the same messages, different hosts might behave differently. The
ambiguity space is analyzed as the following aspects.</t>
<t>1) Dependency between DHCPv6 and RA<list style="hanging">
<t>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.</t>
</list></t>
<t>2) Overlapping configuration between DHCPv6 and RA<list
style="hanging">
<t>When address and DNS configuration are both available from DHCPv6
and RA, it is not clear how to deal with the overlapping
information. Should the hosts accept all the information? If the
information conflicts, which one should take higher priority?</t>
<t>For DNS configuration, <xref target="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 <xref target="RFC6106"/>). But for
address configuration, there's no such guidance.</t>
</list></t>
<t>3) Interpretation on Flags Transition</t>
<t><list style="hanging">
<t hangText="-">Impact on SLAAC/DHCPv6 on and off <list
style="empty">
<t>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 configured by both SLAAC and DHCPv6,
then M flag change from TRUE to FALSE, it is also not clear
whether the host should turn DHCPv6 off or not.</t>
</list></t>
<t hangText="-">Impact on address lifetime<list style="empty">
<t>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 one host should immediately release the corresponding
address or just retain it until the lifetime expires.</t>
</list></t>
</list></t>
<t>4) Relationship between the Flags<list style="hanging">
<t>As described above, the relationship between A flag and M/O flags
is unspecified.</t>
<t>It could be reasonably deduced that M flag should be independent
from A flag. In other words, the M flag only cares DHCPv6 address
configuration, while the A flag only cares SLAAC.</t>
<t>But for A flag and O flag, ambiguity could possibly happen. For
example, when A is FALSE (when M is also FALSE) and O is TRUE, it is
not clear whether the host should initiate a stand-alone stateless
DHCPv6 session.</t>
</list></t>
<t>Divergent behaviors on all these aspects have been observed among
some popular operating systems as described in <xref target="diverge"/>
below.</t>
</section>
<section anchor="diverge" title="Observed Divergent Host Behaviors">
<t>The authors tested several popular operating systems in order to
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
characterizes those cases. For test details, please refer to <xref
target="testing"/>.</t>
<t>Operation diverges in two ways: one is regarding to address
auto-configuration; the other is regarding to DNS configuration.</t>
<section title="Divergent Behavior on Address Auto-Configuration">
<t>Divergence 1-1<list style="symbols">
<t>Host state: has not acquired any addresses.</t>
<t>Input: no RA.</t>
<t>Divergent Behavior<list style="empty">
<t hangText="-">1) Acquiring addresses from DHCPv6.</t>
<t hangText="-">2) No DHCPv6 action.</t>
</list></t>
</list>Divergence 1-2<list style="symbols">
<t>Host state: has acquired addresses from DHCPv6 only (M =
1).</t>
<t>Input: RA with M =0.</t>
<t>Divergent Behavior<list style="empty">
<t hangText="-">1) Releasing DHCPv6 addresses immediately.</t>
<t hangText="-">2) Releasing DHCPv6 addresses when they
expire.</t>
</list></t>
</list></t>
<t>Divergence 1-3<list style="symbols">
<t>Host state: has acquired addresses from SLAAC only (A=1).</t>
<t>Input: RA with M =1.</t>
<t>Divergent Behavior<list style="empty">
<t hangText="-">1) Acquiring DHCPv6 addresses immediately.</t>
<t hangText="-">2) Acquiring DHCPv6 addresses only if their
SLAAC addresses expire and cannot be refreshed.</t>
</list></t>
</list></t>
</section>
<section title="Divergent Behavior on DNS Configuration">
<t>Divergence 2-1<list style="symbols">
<t>Host state: has not acquired any addresses or information.</t>
<t>Input: RA with M=0, O=1, no RDNSS; and a DHCPv6 server on the
same link providing RDNSS (regardless of address
provisioning).</t>
<t>Divergent Behavior<list style="empty">
<t hangText="-">1) Acquiring RDNNS from DHCPv6, regardless of
the A flag setting.</t>
<t hangText="-">2) Acquiring RDNNS from DHCPv6 only if
A=1.</t>
</list></t>
</list>Divergence 2-2</t>
<t>(This divergence is only for those operations systems which
support<xref target="RFC6106"/>.)<list style="symbols">
<t>Host state: has not acquired any addresses or information.</t>
<t>Input: RA with M=0/1, A=1, O=1 and an RDNSS is advertised; and
a DHCPv6 server on the same link providing IPv6 addresses and
RDNSS.</t>
<t>Divergent Behavior<list style="empty">
<t hangText="-">1) Getting RDNSS from both the RAs and the
DHCPv6 server, and the RDNSS obtained from the router has a
higher priority.</t>
<t hangText="-">2) Getting RDNSS from both the RAs and the
DHCPv6 server, but the RDNSS obtained from the DHCPv6 server
has a higher priority.</t>
<t hangText="-">3) Getting RDNSS from the router, and a
"domain search list" information only from the DHCPv6
server(no RDNSS).</t>
</list></t>
</list>Divergence 2-3</t>
<t>(This divergence is only for those operations systems which
support<xref target="RFC6106"/>.)<list style="symbols">
<t>Host state: has acquired address and RDNSS from the first
router's RAs (M=0, O=0, PIO with A=1, and RDNSS advertised).</t>
<t>Input: another router advertising M=1, O=1, no prefix
information; and a DHCPv6 server on the same link providing IPv6
addresses and RDNSS.</t>
<t>Divergent Behavior<list style="empty">
<t hangText="-">1) Never getting any information (neither IPv6
address nor RDNSS) from the DHCPv6 server.</t>
<t hangText="-">2) Getting an IPv6 address and RDNSS from the
DHCPv6 server while retaining the address and RDNSS obtained
from the RAs of the first router. <list style="empty">
<t>(More details: the RDNSS obtained from the first router
has a higher priority; when they receive again RAs from
the first router, they lose/forget the information (IPv6
address and RDNSS) obtained from the DHCPv6 server.)</t>
</list></t>
</list></t>
</list></t>
<t>Divergence 2-4</t>
<t>(This divergence is only for those operations systems which
support<xref target="RFC6106"/>.)<list style="symbols">
<t>Host state: has acquired address and RDNSS from the DHCPv6
server indicated by the first router (M=1, O=1, no PIO or RDNSS
advertised).</t>
<t>Input: another router advertising M=0, O=0, PIO with A=1, and
RNDSS.</t>
<t>Divergent Behavior<list style="empty">
<t hangText="-">1) Getting address and RDNSS from the second
router's RAs, and releasing the IPv6 address and the RDNSS
obtained from the DHCPv6 server. <list style="empty">
<t>(More details: when receiving RAs from the first router
again, it performs the DHCPv6 Confirm/Reply procedure and
gets 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.)</t>
</list></t>
<t hangText="-">2) Getting address and RDNSS from the second
router's RAs, and retaining the IPv6 address and the "Domain
Search list" obtained from the DHCPv6 server. (It did not get
the RDNSS from the DHCPv6 server, as described in Divergence
2-2.) <list style="empty">
<t>(More details: when receiving RAs from the first router
again, there is no change; all the obtained information is
retained.)</t>
</list></t>
<t hangText="-">3) Getting address but no RDNSS from the
second router's RAs, and also retaining the IPv6 address and
the RDNSS obtained from the DHCPv6 server. <list style="empty">
<t>(More details: when receiving RAs from the first router
again, there is no change; all the obtained information is
retained.)</t>
</list></t>
</list></t>
</list></t>
</section>
</section>
<section title="Operational Problems">
<t>This section is not a full collection of the potential problems. It
is some operational issues that the authors could see at current
stage.</t>
<section title="Standalone Stateless DHCPv6 Configuration not available">
<t>It is impossible for some hosts to acquire stateless DHCPv6
configuration unless addresses are acquired from either DHCPv6 or
SLAAC (Which requires M flag or A flag is TURE).</t>
</section>
<section title="Renumbering Issues">
<t>According to <xref target="RFC6879"/> a renumbering exercise can
include the following steps:</t>
<t><list style="symbols">
<t>Causing a host to<list style="empty">
<t hangText="-">release the SLAAC address and acquire a new
address from DHCPv6; or vice-versa.</t>
<t hangText="-">release the current SLAAC address and acquire
another new SLAAC address (might comes from different
source).</t>
<t hangText="-">retain current SLAAC or DHCPv6 address and
acquire another new address from DHCPv6 or SLAAC.</t>
</list></t>
</list>Ideally, these steps could be initiated by multicasting RA
messages onto the link that is being renumbered. Sadly, this is not
possible, because the RA messages may elicit a different behavior from
each host.</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
<t>If an attacker wants to perform MiTM (Man in The Middle) using a
rogue DNS while legitimates RAs with the O flag set are sent to enforce
the use of a DHCPv6 server, the attacker can spoof RAs with the same
settings with the legitimate prefix (in order to remain undetectable)
but advertising the 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.</t>
<t>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.</t>
<t>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.</t>
<t>(Note: the security considerations for specific operating systems are
based on the detailed test results as described in <xref
target="testing"/>.)</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This draft does not request any IANA action.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors wish to acknowledge BNRC-BUPT (Broad Network Research
Centre in Beijing University of Posts and Telecommunications) for their
testing efforts. Special thanks to Xudong Shi, Longyun Yuan and Xiaojian
Xue for their extraordinary effort.</t>
<t>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.</t>
<t>The authors also wish to acknowledge Brian E Carpenter, Ran Atkinson,
Mikael Abrahamsson, Tatuya Jinmei, Mark Andrews and Mark Smith for their
helpful comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2460'?>
<?rfc include='reference.RFC.4443'?>
<?rfc include='reference.RFC.4861'?>
<?rfc include='reference.RFC.4862'?>
<?rfc include='reference.RFC.6106'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3315'?>
<?rfc include='reference.RFC.3736'?>
<?rfc include='reference.RFC.6879'?>
</references>
<section anchor="testing" title="Test Results">
<t>The authors from two orgnizations tested different scenarios
independent of each other. The following text decribes the two test sets
respectively.</t>
<section title="Test Set 1">
<t/>
<section anchor="TestEnvi" title="Test Environment">
<t>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:</t>
<t><list style="symbols">
<t>Router: Quagga 0.99-19 soft router installed on Ubuntu 11.04
virtual host</t>
<t>DHCPv6 Server: Dibbler-server installed on Ubuntu 11.04
virtual host</t>
<t>Host 1: Window 7 / Window 8.1 Virtual Host</t>
<t>Host 2: Ubuntu 14.04 (Linux Kernel 3.12.0) Virtual Host</t>
<t>Host 3: Mac OS X v10.9 Virtual Host</t>
<t>Host 4: IOS 8.0 (model: Apple iPhone 5S, connected via
wifi)</t>
</list></t>
</section>
<section title="Address Auto-configuration Behavior in the Initial State">
<t>The bullet list below describes host behavior in the initial
state, when the host has not yet acquired any auto-configuration
information. Each bullet item represents an input and the behavior
elicited by that input.</t>
<t><list style="symbols">
<t>A=0, M=0, O=0 <list style="symbols">
<t>Windows 8.1 acquired addresses and other information from
DHCPv6.</t>
<t>All other hosts acquired no configuration
information.</t>
</list></t>
<t>A=0, M=0, O=1<list style="symbols">
<t>Windows 8.1 acquired addresses and other information from
DHCPv6.</t>
<t>Windows 7, OSX 10.9 and IOS 8.0 acquired other
information from DHCPv6.</t>
<t>Ubuntu 14.04 acquired no configuration information.</t>
</list></t>
<t>A=0, M=1, O=0<list style="symbols">
<t>All hosts acquired addresses and other information from
DHCPv6.</t>
</list></t>
<t>A=0, M=1, O=1<list style="symbols">
<t>All hosts acquired addresses and other information from
DHCPv6.</t>
</list></t>
<t>A=1, M=0, O=0<list style="symbols">
<t>Windows 8.1 acquired addresses from SLAAC and DHCPv6. It
also acquired non-address information from DHCPv6.</t>
<t>All the other host acquired addresses from SLAAC</t>
</list></t>
<t>A=1, M=0, O=1<list style="symbols">
<t>Windows 8.1 acquired addresses from SLAAC and DHCPv6. It
also acquired other information from DHCPv6.</t>
<t>All the other hosts acquired addresses from SLAAC and
other information from DHCPv6.</t>
</list></t>
<t>A=1, M=1, O=0<list style="symbols">
<t>All hosts acquired addresses from SLAAC and DHCPv6. They
also acquired other information from DHCPv6.</t>
</list></t>
<t>A=1, M=1, O=1<list style="symbols">
<t>All hosts acquired addresses from SLAAC and DHCPv6. They
also acquired other information from DHCPv6.</t>
</list></t>
</list>As showed above, four inputs result in divergent
behaviors.</t>
</section>
<section title="Address Auto-configuration Behavior in State Transitions">
<t>The bullet list below describes behavior elicited during state
transitions. The value x can represents both 0 and 1.<list
style="symbols">
<t>Old state (M = x, O = x, A = 1) , New state (M = x, O = x, A
= 0)<vspace blankLines="0"/>(This means a SLAAC-configured host,
which is regardless of DHCPv6 configured or not, receiving A in
transition from 1 to 0. )<list style="symbols">
<t hangText="-">All the hosts retain SLAAC addresses until
they expire</t>
</list></t>
<t>Old state (M = 0, O = x, A = 1), New state (M = 1, O = x, A =
1) <vspace blankLines="0"/>(This means a SLAAC-only host
receiving M in transition from 0 to 1.)<list style="symbols">
<t hangText="-">Windows 7 acquires addresses from DHCPv6,
immediately.</t>
<t hangText="-">Ubuntu 14.04/OSX 10.9/IOS 8.0 acquires
addresses from DHCPv6 only if the SLAAC addresses are
allowed to expire</t>
<t hangText="-">Windows 8.1 was not tested because it always
acquire addresses from DHCPv6 regardless of the M flag
setting.</t>
</list></t>
<t>Old state (M = 1, O = x, A = x), New state (M = 0, O = x, A =
x) <vspace blankLines="0"/>(This means a DHCPv6-configured host
receiving M in transition from 1 to 0.)<list style="symbols">
<t hangText="-">Windows 7 immediately released the DHCPv6
address</t>
<t hangText="-">Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0
keep the DHCPv6 addresses until they expire</t>
</list></t>
<t>Old state (M = 1, O = x, A = 0), New state (M = 1, O = x, A =
1)<vspace blankLines="0"/>(This means a DHCPv6-only host
receiving A in transition from 0 to 1.)<list style="symbols">
<t hangText="-">All host acquire addresses from SLAAC</t>
</list></t>
<t>Old state (M = 0, O = 1, A = x), New state (M = 1, O = 1, A =
x)<vspace blankLines="0"/>(This means a Stateless
DHCPv6-configured host <xref target="RFC3736"/>, which is
regardless of SLAAC configured or not, receiving M in transition
from 0 to 1 with keeping O=1 )<list style="symbols">
<t hangText="-">Windows 7 acquires addresses and refreshes
other information from DHCPv6</t>
<t hangText="-">Ubuntu 14.04/OSX 10.9/IOS 8.0 does
nothing</t>
<t hangText="-">Windows 8.1 was not tested because it always
acquire addresses from DHCPv6 regardless of the M flag
setting.</t>
</list></t>
<t>Old state (M = 1, O = 1, A = x), New state (M = 0, O = 1, A =
x) <vspace blankLines="0"/>(This means a Stateful
DHCPv6-configured host, which is regardless of SLAAC configured
or not, receiving M in transition from 0 to 1 with keeping O=1
)<list style="symbols">
<t hangText="-">Windows 7 released all DHCPv6 addresses and
refreshes all DHCPv6 other information.</t>
<t hangText="-">Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0
does nothing</t>
</list></t>
</list></t>
</section>
</section>
<section title="Test Set 2">
<t/>
<section title="Test Environment">
<t>This test was built on real devices. All the devices are located
on the same link.</t>
<t><list style="symbols">
<t>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.</t>
<t>Two routers Cisco 4321 using Cisco IOS Software version
15.5(1)S.</t>
<t>The following OS as clients:<list style="symbols">
<t>Fedora 21, kernel version 3.18.3-201 x64</t>
<t>Ubuntu 14.04.1 LTS, kernel version 3.13.0-44-generic
(rdnssd packet installed)</t>
<t>CentOS 7, kernel version 3.10.0-123.13.2.el7</t>
<t>Mac OS-X 10.10.2 Yosemite 14.0.0 Darwin</t>
<t>Windows 7</t>
<t>Windows 8.1</t>
</list></t>
</list></t>
</section>
<section title="Address/DNS Auto-configuration Behavior of Using Only One IPv6 Router and a DHCPv6 Server">
<t>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.</t>
<t>Case 1: One Router with the Management Flag not Set and a DHCPv6
Server<list style="symbols">
<t>Set up<list style="symbols">
<t>One IPv6 Router with M=0, A=1, O=0 and an RDNSS is
advertised</t>
<t>A DHCPv6 server on the same link advertising IPv6
addresses and RDNSS</t>
</list></t>
<t>Results<list style="symbols">
<t>Fedora 21, MAC OS-X, CentOS 7 and Ubuntu 14.04 get an
IPv6 address and an RDNSS from the IPv6 router only.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</list></t>
<t>Case 2: One Router with Conflicting Parameters and a DHCPv6
Server<list style="symbols">
<t>Set up<list style="symbols">
<t>One IPv6 Router with M=0, A=1, O=1 and an RDNSS is
advertised</t>
<t>A DHCPv6 server on the same link advertising IPv6
addresses and RDNSS</t>
</list></t>
<t>Results<list style="symbols">
<t>Fedora 21, Centos 7 and Ubuntu 14.04 get IPv6 address
using SLAAC only (no address from the DHCPv6 server).<list
style="symbols">
<t>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.</t>
<t>Ubuntu 14.04 gets an RDNSS from the router, and a
"domain search list" information from the DHCPv6 server
– but not RDNSS information.</t>
</list></t>
<t>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.</t>
<t>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.</t>
</list></t>
</list></t>
<t>Case 3: Same as Case 2 but Without a DHCPv6 Server<list
style="symbols">
<t>Set up<list style="symbols">
<t>One IPv6 Router with M=0, A=1, O=1 and an RDNSS is
advertised</t>
<t>no DHCPv6 present</t>
</list></t>
<t>Results<list style="symbols">
<t>Windows 7 and Windows 8.1 get an IPv6 address using SLAAC
but they do not get RDNSS information.</t>
<t>MAC OS-X, Fedora 21, Centos 7 and Ubuntu 14.04 get an
IPv6 address using SLAAC and RDNSS from the RAs.</t>
</list></t>
</list></t>
<t>Case 4: All Flags are Set and a DHCPv6 Server is Present<list
style="symbols">
<t>Set up<list style="symbols">
<t>One IPv6 Router with M=1, A=1, O=1 and an RDNSS is
advertised</t>
<t>A DHCPv6 server on the same link advertising IPv6
addresses and RDNSS</t>
</list></t>
<t>Results<list style="symbols">
<t>Fedora 21 and Centos 7:<list style="symbols">
<t>They get IPv6 address both from SLAAC and DHCPv6
server.</t>
<t>They get RDNSS both from RAs and DHCPv6 server.</t>
<t>The DNS of the RAs has higher priority.</t>
</list></t>
<t>Ubuntu 14.04:<list style="symbols">
<t>It gets IPv6 address both using SLAAC and from the
DHCPv6 server.</t>
<t>It gets RDNSS from RAs only.</t>
<t>From the DHCPv6 server it only gets "Domain Search
List" information, no RDNSS.</t>
</list></t>
<t>MAC OS-X:<list style="symbols">
<t>It gets IPv6 addresses both using SLAAC and from the
DHCPv6 server.</t>
<t>It also gets RDNSS both from RAs and the DHCPv6
server.</t>
<t>The DNS server of the DHCPv6 has higher priority.</t>
</list></t>
<t>Windows 7 and Windows 8.1:<list style="symbols">
<t>They get IPv6 address both from SLAAC and DHCPv6
server.</t>
<t>They get RDNSS only from the DHCPv6 server.</t>
</list></t>
</list></t>
</list></t>
<t>Case 5: All Flags are Set and There is No DHCPv6 Server is
Present<list style="symbols">
<t>Set up<list style="symbols">
<t>One IPv6 Router with M=1, A=1, O=1 and an RDNSS is
advertised</t>
<t>no DHCPv6 is present</t>
</list></t>
<t>Results<list style="symbols">
<t>Windows 7 and Windows 8.1 get an IPv6 address using SLAAC
but no RDNSS information.</t>
<t>MAC OS-X, Fedora 21, Centos 7, Ubuntu 14.04 get an IPv6
address using SLAAC and RDNSS from the RAs.</t>
</list></t>
</list></t>
<t>Case 6: A Prefix is Advertised by RAs but the 'A' flag is not
Set<list style="symbols">
<t>Set up<list style="symbols">
<t>An IPv6 Router with M=0, A=0 (while a prefix information
is advertised), O=0 and an RDNSS is advertised.</t>
<t>DHCPv6 is present</t>
</list></t>
<t>Results<list style="symbols">
<t>Fedora 21, Centos 7, Ubuntu 14.04 and MAC OS-X:<list
style="symbols">
<t>They do not get any IPv6 address (neither from the
RAs, nor from the DHCPv6).</t>
<t>They get a RDNSS from the router only (not from
DHCPv6).</t>
</list></t>
<t>Windows 8.1<list style="symbols">
<t>They get IPv6 address and RDNSS from the DHCPv6
server ("last resort" behaviour).</t>
<t>They do not get any information (neither IPv6 address
not RDNSS) from the router.</t>
</list></t>
<t>Windows 7:<list style="symbols">
<t>They get nothing (neither IPv6 address nor RDNSS)
from any source (RA or DHCPv6).</t>
</list></t>
</list></t>
</list></t>
<t/>
</section>
<section title="Address/DNS Auto-configuration Behavior of Using Two IPv6 Router and a DHCPv6 Server">
<t>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.</t>
<t>Case 7: Router 1 Advertising M=0, O=0 and RDNSS, and then Router
2 advertising M=1, O=1 while DHCPv6 is Present<list style="symbols">
<t>Set up<list style="symbols">
<t>Initially:<list style="symbols">
<t>One IPv6 router with M=0, O=0, A=1 and RDNSS
advertised and 15 seconds time interval of the RAs</t>
</list></t>
<t>After a while (when clients are configured by the RAs of
the above router):<list style="symbols">
<t>Another IPv6 router with M=1, O=1, no advertised
prefix information, and 30 seconds time interval of the
RAs.</t>
<t>A DHCPv6 server on the same link providing IPv6
addresses and RDNSS.</t>
</list></t>
</list></t>
<t>Results<list style="symbols">
<t>MAC OS-X and Ubuntu 14.04:<list style="symbols">
<t>Initially they get address and RDNSS from the first
router.</t>
<t>When they receive RAs from the second router, they
never get any information (IPv6 address or RDNSS) from
the DHCPv6 server.</t>
</list></t>
<t>Windows 7:<list style="symbols">
<t>Initially they get address from the first router
– no RDNSS.</t>
<t>When they receive RAs from the second router, they
never get any information (IPv6 address or RDNSS) from
the DHCPv6 server.</t>
</list></t>
<t>Fedora 21 and Centos 7:<list style="symbols">
<t>Initially they get IPv6 address and RDNSS from the
RAs of the first router. o</t>
<t>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</t>
<t>When they receive again RAs from the first router,
they lose/forget the information (IPv6 address and
RDNSS) obtained from the DHCPv6 server.</t>
</list></t>
<t>Windows 8.1:<list style="symbols">
<t>Initially, they get just an IPv6 address from the
first router 1 - no RDNSS information (since they do not
implement RFC 6106).</t>
<t>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.</t>
<t>When they receive RA from the first router, they
retain all the obtained so far information (there isn't
any change).</t>
</list></t>
</list></t>
</list></t>
<t>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<list
style="symbols">
<t>Set up<list style="symbols">
<t>Initially:<list style="symbols">
<t>One IPv6 router with M=1, O=1, no advertised prefix
information, and 30 seconds time interval of the
RAs.</t>
<t>A DHCPv6 server on the same link advertising IPv6
addresses and RDNSS.</t>
</list></t>
<t>After a while (when clients are configured by the RAs of
the above router):<list style="symbols">
<t>Another IPv6 router with M=0, O=0, A=1, RDNSS
advertised and 15 seconds time interval of the RAs.</t>
</list></t>
</list></t>
<t>Results<list style="symbols">
<t>Fedora 21 and Centos 7:<list style="symbols">
<t>At first, they get information (IPv6 address and
RDNSS) from the DHCPv6 server.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>Ubuntu 14.04:<list style="symbols">
<t>At first, it gets information (IPv6 address and
RDNSS) from the DHCPv6 server.</t>
<t>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.</t>
<t>When it receives RAs from the first router, there is
no change; it retains all the obtained information.</t>
</list></t>
<t>Windows 7:<list style="symbols">
<t>Initially they get IPv6 address and RDNSS from the
DHCPv6 server.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>Windows 8.1:<list style="symbols">
<t>Initially they get information (IPv6 address and
RDNSS) from the DHCPv6 server.</t>
<t>When they receive RAs from the second router, they
never get any information from them.</t>
</list></t>
<t>MAC OS-X:<list style="symbols">
<t>Initially it gets information (IPv6 address and
RDNSS) from the DHCPv6 server.</t>
<t>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.</t>
<t>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).</t>
</list></t>
</list></t>
</list></t>
</section>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:13:10 |