One document matched: draft-yourtchenko-6man-dad-issues-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 RFC2462 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2462.xml">
<!ENTITY RFC4429 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4429.xml">
<!ENTITY RFC4862 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC4903 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4903.xml">
<!ENTITY RFC5227 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5227.xml">
<!ENTITY RFC6275 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6275.xml">
<!ENTITY RFC6620 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6620.xml">
<!ENTITY RFC6957 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6957.xml">
<!ENTITY I-D.ietf-6man-enhanced-dad SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-enhanced-dad.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-6man-dad-issues-00" ipr="trust200902">
  <front>
    <title abbrev="DAD issues">A survey of issues related to IPv6 Duplicate Address Detection</title>
    <author fullname="Andrew Yourtchenko" initials="A." surname="Yourtchenko">
      <organization>cisco</organization>
      <address>
        <postal>
      <street>6b de Kleetlaan</street>
      <city>Diegem</city>
<!-- <region/> -->
      <code>1831</code>
      <country>Belgium</country>
        </postal>
<!-- <phone/> -->
<!-- <facsimile/> -->
      <email>ayourtch@cisco.com</email>
<!-- <uri/> -->
      </address>
    </author>
    <date year="2014" />
<!-- <area/> -->
<!-- <workgroup/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
    <abstract>
      <t>
This document enumerates the practical issues observed with respect to Duplicate Address Detection.
      </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>
Duplicate Address Detection is a procedure in IPv6 performed before any address can be assigned to the interface.
On one hand, it is mandatory for all addresses. On the other hand, it is a "best effort" activity.
These somewhat counter-intuitive properties result in some issues that arise related to DAD. They are listed below.
      </t>
    </section>
    <section title="Duplicate L2 address detection">
      <t>
DAD does not detect duplicate L2 addresses in all cases. Depending on the medium, it may be impossible to detect a duplicate
L2 address - e.g. if this address itself is used as a determinant in order to establish the L2 connection.
      </t>
    </section>
    <section title="Interaction with delay in forwarding on the link">
      <t>
The DAD makes an assumption that if a link layer is up, the traffic can be immediately forwarded, 
which is frequently not the case in modern networks. Two prominent cases include the switches
running Spanning Tree Protocol (STP), and bridging modems.
      </t>
      <t>
When a port on an STP-enabled switch comes up, it goes through three phases of Listening then Learning then Forwarding.
The default is to keep it for 15 seconds in Listening and 15 seconds in Learning states. During this time no user traffic 
is forwarded by the switch from and to this port. Therefore, if a DAD process happens during this period it is guaranteed
to not detect any duplicates. This results in DAD being ineffective for link-local and otherwise pre configured 
addresses.
      </t>
      <t>
Similarly, a DSL or cable modem whose line status is invisible to IP stack either within the modem or to a host connected
on the Ethernet side, also renders the DAD ineffective - the delay before the connectivity is established can be much longer 
than any DAD wait.
      </t>
    </section>
    <section title="Behavior on links with unreliable multicast">
      <t>
DAD requires two multicast messages to pass through - the NS and NA. 
Thus it shows a noticeable failure rate on links 
that do not pass multicast reliably (e.g. the 802.11a/b/g/n series of technologies).
Author's ad-hoc experimentation at IETF90 revealed the success rate of detecting 
the duplicate address being about 4 in 5. This may violate the assumptions that other protocols make.
      </t>
    </section>
    <section title="Interaction with looped interfaces">
      <t>
<xref target="RFC4862"/> explicitly defines that the case of a physically looped back interface is not a failure: 
"If
the solicitation is from the node itself (because the node loops back
multicast packets), the solicitation does not indicate the presence
of a duplicate address."
      </t>
      <t>
However, the practical experiences show that the measures described in <xref target="RFC4862"/>
are either incomplete or incorrectly implemented: a loopback on the interface 
causes DAD failure.
      </t>
      <t>
<xref target="I-D.ietf-6man-enhanced-dad"/> discusses the solution to this issue.
      </t>
    </section>
    <section title="Delays before an address can be used">
      <t>
Section "5.4. Duplicate Address Detection" of <xref target="RFC4862"/> specifies that until the DAD procedure completes, 
the address remains in Tentative state. In this state, any traffic to this address other than that related
to DAD-related is dropped. This introduces delay between the interface getting connected to the network and
an address on this interface becoming usable. For fast-moving nodes it may be a problem.
      </t>
      <t>
<xref target="RFC4429"/> introduces "Optimistic DAD" process, which addresses this.
      </t>
    </section>
    <section title="Partition-join tolerance">
      <t>
<xref target="RFC4862"/> explicitly mentions this problem: "Note that the method for detecting duplicates
is not completely reliable, and it is possible that duplicate 
addresses will still exist (e.g., if the link was partitioned while
Duplicate Address Detection was performed)."
      </t>
      <t>
In contrast, IPv4 stacks typically implement the Address Conflict Detection (ACD) from <xref target="RFC5227"/>.
This disparity results in a less robust operation of IPv6 compared to IPv4 and is undesirable.
      </t>
    </section>
    <section title="Behavior on collision">
      <t>
<xref target="RFC4862"/> in its section "5.4.5. When Duplicate Address Detection Fails" is much more prescriptive than <xref target="RFC2462"/> that
it superceeds. However, it has been observed that some implementations may simply reset the network interface and
attempt the DAD process again. This behavior, while being more resilient in case the DAD failure is
happening erroneously, is different from what is recommended in the standard.
      </t>
    </section>
    <section title="Energy efficiency">
      <t>
If a node wants to "defend" its address using DAD, it has to be awake and listening on the solicited node multicast address in order to receive the DAD NS. In the low-power environments this may significantly impact the battery life of the devices.
      </t>
    </section>
    <section title="Wake-up and L2 events">
      <t>
In mobile environments, node may roam in different parts of the network and also take "naps". The specification
in <xref target="RFC4862"/> does not explicitly discuss this scenario, so there is a room for ambiguity in implementation. This may
either result in less robust DAD coverage (if the node does not perform the DAD again when an L2 event happens), or
an excessive amount of multicast packets (when a node performs the dad every time L2 event happens and there is a lot
of them moving within a segment).
      </t>
    </section>
    <section title="Usage of DAD to create state">
      <t>
<xref target="RFC4862"/> in section "5.4. Duplicate Address Detection" states that DAD must be performed on all addresses.
Given the potentially decentralized nature of address assignment in IPv6, this property is being used to prebuild
the state in the network about the host's addresses - e.g. for "First Come First Served" security as described in section "3.2.3. Processing of Local Traffic" of <xref target="RFC6620"/>.
      </t>
      <t>
If the delivery of the DAD_NS packets is unreliable or there are nodes on the segment which use the Optimistic DAD mechanism,
state created purely on DAD_NS packets might be also unreliable. The specific case of <xref target="RFC6620"/> solves the issue by triggering
the recreation of state based on data packets as well, however it might not be possible in some scenarios.
      </t>
    </section>
    <section title="Support of multi-link subnets">
      <t>
DAD doesn't support multi-link subnets: a multicast DAD_NS sent on one link will not be seen on the other.
      </t>
      <t>
<xref target="RFC6275"/> specifically provides one
way to construct a multi-link subnet (consisting of a broadcast link and a collection of point to point tunnels).
It explicitly defines the procedures for making DAD work in that topology. 
      </t>
      <t>
<xref target="RFC4903"/> discusses the issues related to multi-link subnets - and given the multi-link subnets might be created
in many ways, it might be prudent to keep enhancements to DAD whose sole purpose is related to multi-link subnets,
to be out of scope.
      </t>
    </section>
    <section title="Anycast Addresses and Duplicate Address Detection">
      <t>
Section 5.4 "Duplicate Address Detection" of <xref target="RFC4862"/> specifies that Duplicate Address Detection MUST NOT be performed on anycast
addresses. This, stems from the fact that the anycast addresses are syntactically indistinguishable from unicast addresses. One can argue that this
allows for misconfiguration if an address deemed to be anycast already exist on the network.
      </t>
    </section>
    <section title="Implementations doing DAD once per IID">
      <t>
Section 5.4 of <xref target="RFC4862"/> mentions the implementations performing a single DAD per interface identifier, and discourages
that "optimization". As the practice is emerging in the industry is to move away from the fixed interface identifiers anywhere,
the necessity to perform a DAD on a per-address basis might be useful to elevate to a requirement status.
      </t>
    </section>
    <section title="Backwards compatibility and presence of the DAD proxies">
      <t>
While not being an issue as such, this is a reminder that the operation of DAD has to remain backwards compatible, both to remain cooperative with 
the existing hosts, and the potentially present DAD proxies as described in <xref target="RFC6957"/>.
      </t>
    </section>
    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
Thanks to Ole Troan for creating and curating the original list. Thanks a lot to Suresh Krishnan and Erik Nordmark for the reviews and useful suggestions.
      </t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>
None.
      </t>
    </section>
    <section anchor="Security" title="Security Considerations">
      <t>
There are no additional security considerations as this document only outlines the issues observed with the current Duplicate Address Detection protocol.
      </t>
    </section>
  </middle>
  <back>
    <references title="Informative References">
      &I-D.ietf-6man-enhanced-dad;
    </references>
    <references title="Normative References">
      &RFC2119;
      &RFC2462;
      &RFC4862;
      &RFC4429;
      &RFC4903;
      &RFC5227;
      &RFC6275;
      &RFC6620;
      &RFC6957;
    </references>
  </back>
</rfc>