| Network Working Group | A. Yourtchenko |
| Internet-Draft | cisco |
| Intended status: Informational | T. Chown |
| Expires: January 5, 2015 | S. Rupik |
| University of Southampton | |
| July 4, 2014 |
DAD And Packet Triplication
draft-yourtchenko-chown-rupik-v6ops-dad-3x-00
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 [RFC2119].
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.
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.
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.
The reason for IPv6 DAD failing in this case is encoded in [RFC4862], section 5.4.3, which instructs the hosts to treat the replication of more than 2x to be the sign of a collision:
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.
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.
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.
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.
None.
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC4862] | Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. |