One document matched: draft-yourtchenko-chown-rupik-v6ops-dad-3x-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4862 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?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="2"?> <!-- 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 popular PIs -->
<rfc  category="info" docName="draft-yourtchenko-chown-rupik-v6ops-dad-3x-00" ipr="trust200902">
  <front>
    <title abbrev="DAD And Packet Triplication">DAD And Packet Triplication</title>
    <author fullname="Andrew Yourtchenko" initials="A" surname="Yourtchenko">
      <organization>cisco</organization>
      <address>
        <postal>
      <street>7a de Kleetlaan</street>
      <city>Diegem</city>
<!-- <region/> -->
      <code>1831</code>
      <country>Belgium</country>
        </postal>
      <phone>+32 2 704 5494</phone>
<!-- <facsimile/> -->
      <email>ayourtch@cisco.com</email>
<!-- <uri/> -->
      </address>
    </author>
    <author fullname="Tim Chown" initials="T" surname="Chown">
      <organization>University of Southampton</organization>
      <address>
        <postal>
      <street></street>
      <city>Southampton</city>
      <region>Hampshire</region>
      <code>SO17 1BJ</code>
      <country>United Kingdom</country>
        </postal>
<!-- <phone/> -->
<!-- <facsimile/> -->
      <email>tjc@ecs.soton.ac.uk</email>
<!-- <uri/> -->
      </address>
    </author>
    <author fullname="Seb Rupik" initials="S" surname="Rupik">
      <organization>University of Southampton</organization>
      <address>
        <postal>
      <street></street>
      <city>Southampton</city>
      <region>Hampshire</region>
      <code>SO17 1BJ</code>
      <country>United Kingdom</country>
        </postal>
<!-- <phone/> -->
<!-- <facsimile/> -->
      <email>snr@ecs.soton.ac.uk</email>
<!-- <uri/> -->
      </address>
    </author>
    <date year="2014" />
<!-- <area/> -->
<!-- <workgroup/> -->
      <keyword>dad, ipv6</keyword>
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
    <abstract>
      <t>
This draft captures the observation of IPv6 Duplicate Address Detection behavior in the case of excessive packet replication (3x), the latter caused by by a misbehaving device in the network. Also it compares the operation of IPv6 vs. IPv4 as a result.      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
      <t>
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
        this document are to be interpreted as described in
        <xref target="RFC2119"/>.
      </t>
      <t>
        The aim of this document is to highlight the difference in the behavior of IPv6 compared 
        to IPv4 in a somewhat esoteric corner case, where every multicast packet was replicated 
        by the network in 3 copies during the delivery to the clients.
      </t>
      <t>
        The excessive replication in this particular case did not cause the avalanche one would expect, because the replication 
        happened on the very last point - at the network-client attachment. So, the only result was the client receiving 3x more
        of multicast traffic than they should, with all three copies being in short succession. We will call this 
        "Multicast Triplication" further on.
      </t>
    </section>
    <section title="Observed Effects of Multicast Triplication">
      <t>
        The result of triplication in a dualstack network was that IPv6 stacks on 
        the clients did not function. We could observe that it was due to 
        Duplicate Address Detection failure. At the same time IPv4 continued to function.
      </t>
      <t>
        The reason for IPv6 DAD failing in this case is encoded in <xref target="RFC4862"/>, section 5.4.3, 
        which instructs the hosts to treat the replication of more than 2x to be the sign of a collision:
      </t>
      <t>
        If the actual number of Neighbor Solicitations received exceeds
        the number expected based on the loopback semantics (e.g., the
        interface does not loop back the packet, yet one or more
        solicitations was received), the tentative address is a duplicate.
        This condition occurs when two nodes run Duplicate Address
        Detection simultaneously and transmit solicitations at roughly the
        same time.
      </t>
      <t>
        The user-observable behavior was different in different operating systems: some of them
        continued to use the address regardless, and some of them did not. This created 
        significant confusion for the administrators.
      </t>
    </section>
    <section title="Discussion">
      <t>
        We can argue which of the outcomes is "better" - either to make provisions to
        remain up in the face of Nx replication (N>2), or to fail early and provide
        the sign to the user that something in the network would be fixed.
      </t>
      <t>
        However, we thought it might be useful to document this. If there are further
        enhancements to DAD that increase its robustness, this corner case might be one 
        of the corner cases a "better" DAD might attempt to handle.
      </t>
    </section>
    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
      </t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>
        None.
      </t>
    </section>
    <section anchor="Security" title="Security Considerations">
      <t>
        The observed behavior means that if someone can see the multicast 
        traffic on the segment and create two additional copies for any multicast packet sent,
        they can shut down the IPv6 on the hosts on the entire link - as none of IPv6 addresses
        will be able to pass the DAD. However, these capabilities also mean that the attacker
        could just trigger a regular DAD as well, with the same effect. Therefore, the existing 
        security solutions should address this scenario.
      </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      &RFC2119;
      &RFC4862;
    </references>
  </back>
</rfc>