One document matched: draft-nordmark-6man-dad-approaches-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0826 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0826.xml">
<!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 RFC4218 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4218.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 RFC6775 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6775.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'>
<!ENTITY ENERGY-AWARE PUBLIC '' 
'http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.chakrabarti-nordmark-energy-aware-nd.xml'>
<!ENTITY DAD-ISSUES PUBLIC '' 
'http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.yourtchenko-6man-dad-issues.xml'>]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?> <!-- do not start each main section on a new page -->
<?rfc subcompact="yes" ?> <!-- keep one blank line between list items -->
<rfc  category="info" docName="draft-nordmark-6man-dad-approaches-01" ipr="trust200902">
  <front>
    <title abbrev="DAD approaches">Possible approaches to make DAD more robust and/or efficient</title>
    <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="May" year="2015" />
    <area>INT</area>
    <workgroup>6MAN</workgroup>
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
    <abstract>
      <t>
This outlines possible approaches to solve the issues around IPv6 Duplicate Address Detection robustness and/or efficiency which are specified in the "DAD issues" dradft.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
      <t>
Duplicate Address Detection (DAD) is a procedure in IPv6 performed on an address before it can be assigned to an interface <xref target="RFC4862"/>. 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>
The companion document <xref target="I-D.yourtchenko-6man-dad-issues"/> outlines a set of issues around Duplicate Address Detection (DAD) which either result in reduced robustness, or result in lower efficiency for either the hosts wanting to sleep or the network handling more multicast packets.
      </t>
      <t>
The reader is encourage to review the issues in that document. In summary, the lack of robustness is due to only sending one or a few DAD probe initially, and not having any positive acknowledgement that "there are no duplicates". This implies that partioned links that later heal can result in persistent undetected duplicate IPv6 addresses, including cases of "local partitions" such as the case of a modem not having connected when the DAD probes are sent. The inefficiences appears when there are low-powered devices on the link that wish to sleep a significant amount of time. Such devices must either be woken up by multicast Neighbor Soliciations sent to one of their solicited-node multicast addresses, or they need to redo DAD each time they wake up from sleep. Both drain the battery; the second one results in sending a DAD probe and then waiting for a second with the radion receiver enabled to see if a DAD message indicates a duplicate.
    </t>
    </section>
    <section title="Robustness Solution Approaches">
      <t>
IPv4 ARP robustness against partitions and joins is greately improved by Address Conflict Detection (ACD) <xref target="RFC5227"/>. That approach is leverages the fact that ARP requests are broadcast on the link and also makes the ARP replies be broadcast on the link. That combination means that a host can immediately detect when some other host provides a different MAC address for what the host thinks is its own IPv4 address. That is coupled with state machines and logic for determining whether to try to reclaim the address or give up and let the other host have it. When giving up the host will form a new IPv4 address.
The ACD approach results in more broadcast traffic than normal ARP <xref target="RFC0826"/> since the ARP replies are broadcast.
      </t>
      <t>
Applying the same approach to IPv6 would require sending the Neighbor Solicitations and Neighbor Advertisements to the all-nodes multicast address so that a host can see when a different host is claiming/using the same source IPv6 address. That would remove the efficiency that Neighbor Discovery gets from "spreading" the resolution traffic over 4 million multicast addresses.
      </t>
      <t>
One can envision variants on the theme of ACD that fit better with the use of solicited-node multicast addresses. Suppose we have Host1 with IP1 that hashes to solicited-node multicast address SN1. And we also have Host2 with IP2 and SN2.The link-layer addresses are MAC1 and MAC2, respectively. In <xref target="RFC4861"/> when Host1 wants to communicate with Host2 we will see
<list style='numbers'>
  <t>Host1 multicasts a NS from IP1 to SN2. That include a claim for IP1->MAC1 using the Source Link-layer Address option.</t>
  <t>Host2 receives the NA and unicasts a NA from IP2 to IP1. That includes a claim for IP2->MAC using the Taget Link-layer Address option.</t>
</list>
      </t>
      <t>
If we want other hosts which might think they own either IP1 or IP2 to see the NA or NS (and we don't want to send the NS and NA to all-nodes), then we can add additional multicast packets which explicitly send the claim and send it to the Solicited-node multicast address of the address that is being claimed. Thus
<list style='numbers'>
  <t>Host1 multicasts a NS from IP1 to SN2. That include a claim for IP1->MAC1 using the Source Link-layer Address option.</t>
  <t>Host1 multicasts a NA from IP1 to SN1 explicitly claiming IP1->MAC1 using the TLLAO.</t>
  <t>Host2 receives the NA and unicasts a NA from IP2 to IP1. That includes a claim for IP2->MAC using the Taget Link-layer Address option.</t>
  <t>Host2 multicasts a NA from IP2 to SN2 explicitly claiming IP2->MAC2 using the TLLAO.</t>
</list>
      </t>
      <t>
The above explicit claims can then trigger the state machine described in ACD. The claims can probably be rate limited for any given source address since there is no need to repeat the claim just because a NS needs to be sent for a new IP3 etc. The impact of such rate limitig on the ability to detect duplicates.
      </t>
      <t>
In the worst case the above approach turns one multicast and one unicast into three multicasts and one unicast, but all the multicasts are sent to solicited-node multicast addresss. Thus a host would not need to process the additional multicast packets.
      </t>
      <t>
This ACD-multicast approach assumes that the multicast packets are delivered with reasonable reliability, but does not assume perfect delivery. If multicast reliability is lower than unicast it will result in retransmitted multicast NS in <xref target="RFC4861"/>. However, the above rate limiting idea might need care to ensure that claims are re-transmitted when the NS is re-transmitted.</t>
<t>
A slightly different approach to on-going DAD is what is implemented in Solaris where the node sends a periodic NA annoucement for the address it is using, plus the ACD behavior of detecting such an NA with a conflicting address. Presumably the NA annoucement can be sent to the solicited-node multicast address. It might make sense to use the Nonce option used by <xref target="I-D.ietf-6man-enhanced-dad"/> to avoid issues where a host would hear its own announcement.
</t>
    </section>
    <section title="Approaches to efficiency">
      <t>
There exists some form of sleep proxies [ECMA-393][http://en.wikipedia.org/wiki/Bonjour_Sleep_Proxy] which perform handover of Neighbor Discovery protocol processing. [ECMA-393] does not specify the handover mechanism, and there is no know dcumentation for the handover mechanism. Even though the details are not specified, the approach seems to allow a host to sleep without worrying about DAD; the sleep proxy will respond to DAD probes. This seems to entail sending multicast NAs to all-nodes to hand-over the IP address to the proxy's MAC address before going to sleep and then again to hand it back to the host's MAC address when it wakes up.
      </t>
      <t>
It is not clear whether such sleep proxies provide protection against Single Points of Failure i.e., whether the host can hand over things to a pair of sleep proxies.
      </t>
      <t>
FCFS SAVI <xref target="RFC6620"/> builds up state in devices to be able to detect and prevent when some host is trying to use an IPv6 address already used by another host on the link. This binding is built and checked for DAD packets, but also for data packets to ensure that an attacker can not inject a data packet with somebody elses source address. When FCFS SAVI detects a potential problem it checks whether the IPv6 address has merely moved to a different binding anchor (e.g., port on the switch) by sending a probe to its old anchor. Thus it assumes the host is always awake or can be awoken to answer that probe. Futhermore, implementation of the data triggered aspects can run into hardware limitations since it requires something like an ACL for every IPv6 address which has been validated.
      </t>
      <t>
DAD proxies as specified in <xref target="RFC6957"/> was designed to handle split-horizon forwarding which means that a host would never receive a multicast DAD probe sent by another host. This approach maintains a binding cache built up by DAD probes and checked when handling DAD probes. However, just like SAVI in order to handle host mobility and legitimate host MAC address change, it the case of a potential conflict the proxy ends up verifying whether the IP address is still present at its old port and MAC address. Hence the host can not sleep.
      </t>
      <t>
One could explore something along the SAVI and DAD proxy approach that uses timestamps to allow better sleep. In principle would could start some fixed timer each time an IPv6 address is added or updated in the binding cache, and during that time the proxy would respond to DAD probes on behalf of the (potentially sleeping) host. To enable movement between ports/anchors such an approach would have to compare MAC address and assume that if the MAC address is the same it is the same host. (Unclear whether that is a good idea if we end up with random MAC addresses for better privacy.) And if a host would like to change its MAC address it would need to wait for the timeout before it can succeed in doing the change. Thus on one hand one would want a long time (24 hours?) to facilitate for sleeping hosts, and on the other hand a short time to allow for MAC address change and movement.
      </t>
      <t>
In essence the above forms an implicit request for the proxy to handle DAD on behalf of the host, with a fixed time limit. If the host can instead make that time explicit, then the host can also remove the proxy behavior (by passing a time of zero). Such a "proxy for me" request can leverage the ARO option defined for 6LoWPan in <xref target="RFC6775"/> but use it only for the purposes of DAD offload to the proxy. That option can also carry an additional identifier which can be used to distinguish between the same host aka same identifier changing the MAC address. In the RFC that is an EUI-64 and in <xref target="I-D.chakrabarti-nordmark-energy-aware-nd"/> in is a more generalized identifier field. For redundancy the ARO can be sent to more than one proxy.
      </t>
    </section>
    <section anchor="Security" title="Security Considerations">
      <t>
If the working group decides to pursue one of the outlined approaches to improve the robustness and/or efficiency of DAD, then the security issues for that partiticular approach will need to be studied.
      </t>
      <t>
In general DAD is subject to a Denial of Service attack since a malicious host can claim all the IPv6 addresses <xref target="RFC4218"/>.
      </t>
    </section>
    <section title="Acknowledgements">
      <t>
Sowmini Varadhan pointed out the Solaris approach to use periodic NA annoucements to increase robustness.
      </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      &DAD-ISSUES;
      &RFC0826;
      &RFC4861;
      &RFC4862;
      &RFC4218;
      &RFC5227;
      &RFC6620;
      &RFC6775;
      &RFC6957;
    </references>
    <references title="Informative References">
      &ENHANCED-DAD;
      &ENERGY-AWARE;
    </references>
  </back>
</rfc>