A survey of issues related to IPv6 Duplicate Address Detection
draft-yourtchenko-6man-dad-issues-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Andrew Yourtchenko | ||
| Last updated | 2014-10-27 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yourtchenko-6man-dad-issues-00
Network Working Group A. Yourtchenko
Internet-Draft cisco
Intended status: Informational October 27, 2014
Expires: April 30, 2015
A survey of issues related to IPv6 Duplicate Address Detection
draft-yourtchenko-6man-dad-issues-00
Abstract
This document enumerates the practical issues observed with respect
to Duplicate Address Detection.
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 April 30, 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Yourtchenko Expires April 30, 2015 [Page 1]
Internet-Draft DAD issues October 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Duplicate L2 address detection . . . . . . . . . . . . . . . 2
3. Interaction with delay in forwarding on the link . . . . . . 3
4. Behavior on links with unreliable multicast . . . . . . . . . 3
5. Interaction with looped interfaces . . . . . . . . . . . . . 3
6. Delays before an address can be used . . . . . . . . . . . . 3
7. Partition-join tolerance . . . . . . . . . . . . . . . . . . 4
8. Behavior on collision . . . . . . . . . . . . . . . . . . . . 4
9. Energy efficiency . . . . . . . . . . . . . . . . . . . . . . 4
10. Wake-up and L2 events . . . . . . . . . . . . . . . . . . . . 4
11. Usage of DAD to create state . . . . . . . . . . . . . . . . 5
12. Support of multi-link subnets . . . . . . . . . . . . . . . . 5
13. Anycast Addresses and Duplicate Address Detection . . . . . . 5
14. Implementations doing DAD once per IID . . . . . . . . . . . 5
15. Backwards compatibility and presence of the DAD proxies . . . 6
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
18. Security Considerations . . . . . . . . . . . . . . . . . . . 6
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
19.1. Informative References . . . . . . . . . . . . . . . . . 6
19.2. Normative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
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].
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.
2. Duplicate L2 address detection
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.
Yourtchenko Expires April 30, 2015 [Page 2]
Internet-Draft DAD issues October 2014
3. Interaction with delay in forwarding on the link
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.
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.
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.
4. Behavior on links with unreliable multicast
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.
5. Interaction with looped interfaces
[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."
However, the practical experiences show that the measures described
in [RFC4862] are either incomplete or incorrectly implemented: a
loopback on the interface causes DAD failure.
[I-D.ietf-6man-enhanced-dad] discusses the solution to this issue.
6. Delays before an address can be used
Section "5.4. Duplicate Address Detection" of [RFC4862] specifies
that until the DAD procedure completes, the address remains in
Tentative state. In this state, any traffic to this address other
Yourtchenko Expires April 30, 2015 [Page 3]
Internet-Draft DAD issues October 2014
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.
[RFC4429] introduces "Optimistic DAD" process, which addresses this.
7. Partition-join tolerance
[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)."
In contrast, IPv4 stacks typically implement the Address Conflict
Detection (ACD) from [RFC5227]. This disparity results in a less
robust operation of IPv6 compared to IPv4 and is undesirable.
8. Behavior on collision
[RFC4862] in its section "5.4.5. When Duplicate Address Detection
Fails" is much more prescriptive than [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.
9. Energy efficiency
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.
10. Wake-up and L2 events
In mobile environments, node may roam in different parts of the
network and also take "naps". The specification in [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).
Yourtchenko Expires April 30, 2015 [Page 4]
Internet-Draft DAD issues October 2014
11. Usage of DAD to create state
[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 [RFC6620].
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 [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.
12. Support of multi-link subnets
DAD doesn't support multi-link subnets: a multicast DAD_NS sent on
one link will not be seen on the other.
[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.
[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.
13. Anycast Addresses and Duplicate Address Detection
Section 5.4 "Duplicate Address Detection" of [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.
14. Implementations doing DAD once per IID
Section 5.4 of [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.
Yourtchenko Expires April 30, 2015 [Page 5]
Internet-Draft DAD issues October 2014
15. Backwards compatibility and presence of the DAD proxies
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 [RFC6957].
16. Acknowledgements
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.
17. IANA Considerations
None.
18. Security Considerations
There are no additional security considerations as this document only
outlines the issues observed with the current Duplicate Address
Detection protocol.
19. References
19.1. Informative References
[I-D.ietf-6man-enhanced-dad]
Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E.,
and W. George, "Enhanced Duplicate Address Detection",
draft-ietf-6man-enhanced-dad-07 (work in progress),
October 2014.
19.2. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, April 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
Yourtchenko Expires April 30, 2015 [Page 6]
Internet-Draft DAD issues October 2014
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June
2007.
[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227,
July 2008.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses", RFC
6620, May 2012.
[RFC6957] Costa, F., Combes, J-M., Pougnard, X., and H. Li,
"Duplicate Address Detection Proxy", RFC 6957, June 2013.
Author's Address
Andrew Yourtchenko
cisco
6b de Kleetlaan
Diegem 1831
Belgium
Email: ayourtch@cisco.com
Yourtchenko Expires April 30, 2015 [Page 7]