Internet DRAFT - draft-yourtchenko-chown-rupik-v6ops-dad-3x
draft-yourtchenko-chown-rupik-v6ops-dad-3x
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
Abstract
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.
Status of This Memo
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 Notice
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
Yourtchenko, et al. Expires January 5, 2015 [Page 1]
Internet-Draft DAD And Packet Triplication July 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Observed Effects of Multicast Triplication . . . . . . . . . 2
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
6. Security Considerations . . . . . . . . . . . . . . . . . . . 3
7. Normative References . . . . . . . . . . . . . . . . . . . . 3
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
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.
2. Observed Effects of Multicast Triplication
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
Yourtchenko, et al. Expires January 5, 2015 [Page 2]
Internet-Draft DAD And Packet Triplication July 2014
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.
3. Discussion
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.
4. Acknowledgements
5. IANA Considerations
None.
6. Security Considerations
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.
7. Normative References
[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.
Yourtchenko, et al. Expires January 5, 2015 [Page 3]
Internet-Draft DAD And Packet Triplication July 2014
Authors' Addresses
Andrew Yourtchenko
cisco
7a de Kleetlaan
Diegem 1831
Belgium
Phone: +32 2 704 5494
Email: ayourtch@cisco.com
Tim Chown
University of Southampton
Southampton, Hampshire SO17 1BJ
United Kingdom
Email: tjc@ecs.soton.ac.uk
Seb Rupik
University of Southampton
Southampton, Hampshire SO17 1BJ
United Kingdom
Email: snr@ecs.soton.ac.uk
Yourtchenko, et al. Expires January 5, 2015 [Page 4]
