<?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-07"
     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="17" month="August" 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
                      &ndash; 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
                      &ndash; 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>
