One document matched: draft-yourtchenko-6man-dad-issues-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2462 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2462.xml">
<!ENTITY RFC2491 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2491.xml">
<!ENTITY RFC4429 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4429.xml">
<!ENTITY RFC4861 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4862 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC4903 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4903.xml">
<!ENTITY RFC5227 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5227.xml">
<!ENTITY RFC6059 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6059.xml">
<!ENTITY RFC6275 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6275.xml">
<!ENTITY RFC6620 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6620.xml">
<!ENTITY RFC6957 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6957.xml">
<!ENTITY RESILIENT-RS SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-resilient-rs.xml">
<!ENTITY ENHANCED-DAD SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-enhanced-dad.xml">
<!ENTITY MCAST-NOT-EFFICIENT PUBLIC '' 
'http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.vyncke-6man-mcast-not-efficient.xml'>
<!ENTITY MCAST-WIFI-POWER PUBLIC '' 
'http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.desmouceaux-ipv6-mcast-wifi-power-usage.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://xml2rfc.ietf.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-01" 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>
    <author initials="E" surname="Nordmark" fullname="Erik Nordmark">
      <organization>Arista Networks</organization>
      <address>
	<postal>
	  <street></street>
	  <city>Santa Clara, CA</city>
	  <country>USA</country>
	</postal>
	<email>nordmark@arista.com</email>
      </address>
    </author>
    <date month="February" year="2015" />
<!-- <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 (DAD) is a procedure in IPv6 performed on an address before it can be assigned to an interface <xref target="RFC2462"/>. By default it consists of sending a single multicast Neighbor Soliciation message and waiting for a response for one second. If no response is received, the address is declared to not be a duplicate. Once the address has been tested once, there is no further attempts to check for duplicates (unless the interface is re-initialized).</t>
<t>
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. The issues have been grouped to facilitate discussing them.
      </t>
    </section>
    <section title="Open Issues">
      <t>Whether it is due to the assumptions made in 1995, or changes in how networks are built or deployed, there are many reasons why DAD would fail to detect a duplicate even when one exists. From a historical perspective it is important to keep in mind that when DAD was designed we had two forms of IPv6 addresses; those derived from EUI-64 and statically assigned. Since the IETF has developed additional methods for address assignment like DHCPv6 and addresses that improve privacy by reducing linkability.</t>

      <section title="Robustness: Interaction with delay in forwarding">
	<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 modem-like device 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>
      <t>
Some of the link types, notably cable modems, have link-specific standards to address this issue
by requiring a new DAD each time the RF-side interface bounces, as well as bouncing the LAN interface
triggered by the bounce of the RF interface.
      </t>
      <t>Note that <xref target="I-D.ietf-6man-resilient-rs"/> makes the router solicitation resilent to the above cases, but there is no counterpart to make DAD robust.</t>
      </section>
      <section title="Robustness: 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. See <xref target="I-D.vyncke-6man-mcast-not-efficient"/> for more information.
	</t>
	<t>
The author's ad-hoc experimentation at IETF90 revealed the success rate of detecting 
the duplicate address on the IETF WiFi network being about 4 in 5. This may violate the assumptions that other protocols make.
	</t>
      </section>
      <section title="Robustness: 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>
	<t>Note that solutions along the lines of ACD, while improving robustness, might result in more resource usage in on the links and nodes by multicasting more ND packets.</t>
      </section>
      <section title="Robustness: 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>
	<t>
TBD: Do the other RFCs for address allocation require some retry behavior?
	</t>
      </section>
      <section title="Energy Efficiency">
	<t>
The use of multicast messages for DAD results in some inefficiencies for both the network, in particular when multicast uses more layer 2 resources than unicast, and also has efficiency implications for hosts. Potential techniques for making DAD reliably detect and recover from duplicates might result in reduced efficiency. The impact for WiFi is shown in <xref target="I-D.desmouceaux-ipv6-mcast-wifi-power-usage"/>.
	</t>
	<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, nor does DNA <xref target="RFC6059"/>, 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>
	<t>
Thus this item could be categorized as being either in the robustness or efficiency group of items.
	</t>
      </section>
    </section>
    <section title="Solved Issues">
      <t>Some issues have been or are in the process of being solved.</t>
      <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"/> provides 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. That document has some notes about potentially causing TCP RST when there is a duplicate, which can reset an existing TCP connection for the existing user of the IPv6 address. That has some overall impact on the robustness of the network and implicitly assumes that all application protocols will always retry in order to handle such an event.
	</t>
      </section>
    </section>
    <section title="Observations">
      <t>Some issues we can't do much about in that they are more observations of what can be done.</t>

      <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="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="No 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>
        <t>
One may also argue that since <xref target="RFC4861"/> defers the clarifications on IPv6 operation
on NBMA networks to <xref target="RFC2491"/>, it is unreasonable to expect <xref target="RFC4862"/>
describe the operation of DAD on NBMA type links, and it is up to a link-specific document 
to describe such operation. (An example is cable industry, where the cable standards define it).
	</t>
        <t>
However, it is then unclear where to address the frequently used scenario of WiFi with blocked direct
communication between the stations - whether it is supposed to be an IEEE document or IETF document ?
And is there enough fundamental differences between the different NBMA models to warrant the link-specific
approaches to DAD ?
	</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 anyhow,
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>
	<t>
There are also various forms of sleep proxies [ECMA-393] [http://en.wikipedia.org/wiki/Bonjour_Sleep_Proxy] which perform handoffs of Neighbor Discovery protocol processing that need to be considered.
	</t>
      </section>
    </section>
    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
Thanks to Ole Troan for creating and curating the original list. Thanks a lot to Lorenzo Colitti, Suresh Krishnan, Hemant Singh, Hesham Soliman, Eric Vyncke, and James Woodyatt 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="Normative References">
      &RFC2119;
      &RFC2462;
      &RFC2491;
      &RFC4861;
      &RFC4862;
      &RFC4429;
      &RFC4903;
      &RFC5227;
      &RFC6059;
      &RFC6275;
      &RFC6620;
      &RFC6957;
    </references>
    <references title="Informative References">
      &ENHANCED-DAD;
      &RESILIENT-RS;
      &MCAST-NOT-EFFICIENT;
      &MCAST-WIFI-POWER;
    </references>
  </back>
</rfc>