idnits 2.17.1 draft-yourtchenko-6man-dad-issues-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3462 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-6man-enhanced-dad-07 ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Yourtchenko 3 Internet-Draft cisco 4 Intended status: Informational October 27, 2014 5 Expires: April 30, 2015 7 A survey of issues related to IPv6 Duplicate Address Detection 8 draft-yourtchenko-6man-dad-issues-00 10 Abstract 12 This document enumerates the practical issues observed with respect 13 to Duplicate Address Detection. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on April 30, 2015. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Duplicate L2 address detection . . . . . . . . . . . . . . . 2 51 3. Interaction with delay in forwarding on the link . . . . . . 3 52 4. Behavior on links with unreliable multicast . . . . . . . . . 3 53 5. Interaction with looped interfaces . . . . . . . . . . . . . 3 54 6. Delays before an address can be used . . . . . . . . . . . . 3 55 7. Partition-join tolerance . . . . . . . . . . . . . . . . . . 4 56 8. Behavior on collision . . . . . . . . . . . . . . . . . . . . 4 57 9. Energy efficiency . . . . . . . . . . . . . . . . . . . . . . 4 58 10. Wake-up and L2 events . . . . . . . . . . . . . . . . . . . . 4 59 11. Usage of DAD to create state . . . . . . . . . . . . . . . . 5 60 12. Support of multi-link subnets . . . . . . . . . . . . . . . . 5 61 13. Anycast Addresses and Duplicate Address Detection . . . . . . 5 62 14. Implementations doing DAD once per IID . . . . . . . . . . . 5 63 15. Backwards compatibility and presence of the DAD proxies . . . 6 64 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 18. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 19.1. Informative References . . . . . . . . . . . . . . . . . 6 69 19.2. Normative References . . . . . . . . . . . . . . . . . . 6 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 Duplicate Address Detection is a procedure in IPv6 performed before 79 any address can be assigned to the interface. On one hand, it is 80 mandatory for all addresses. On the other hand, it is a "best 81 effort" activity. These somewhat counter-intuitive properties result 82 in some issues that arise related to DAD. They are listed below. 84 2. Duplicate L2 address detection 86 DAD does not detect duplicate L2 addresses in all cases. Depending 87 on the medium, it may be impossible to detect a duplicate L2 address 88 - e.g. if this address itself is used as a determinant in order to 89 establish the L2 connection. 91 3. Interaction with delay in forwarding on the link 93 The DAD makes an assumption that if a link layer is up, the traffic 94 can be immediately forwarded, which is frequently not the case in 95 modern networks. Two prominent cases include the switches running 96 Spanning Tree Protocol (STP), and bridging modems. 98 When a port on an STP-enabled switch comes up, it goes through three 99 phases of Listening then Learning then Forwarding. The default is to 100 keep it for 15 seconds in Listening and 15 seconds in Learning 101 states. During this time no user traffic is forwarded by the switch 102 from and to this port. Therefore, if a DAD process happens during 103 this period it is guaranteed to not detect any duplicates. This 104 results in DAD being ineffective for link-local and otherwise pre 105 configured addresses. 107 Similarly, a DSL or cable modem whose line status is invisible to IP 108 stack either within the modem or to a host connected on the Ethernet 109 side, also renders the DAD ineffective - the delay before the 110 connectivity is established can be much longer than any DAD wait. 112 4. Behavior on links with unreliable multicast 114 DAD requires two multicast messages to pass through - the NS and NA. 115 Thus it shows a noticeable failure rate on links that do not pass 116 multicast reliably (e.g. the 802.11a/b/g/n series of technologies). 117 Author's ad-hoc experimentation at IETF90 revealed the success rate 118 of detecting the duplicate address being about 4 in 5. This may 119 violate the assumptions that other protocols make. 121 5. Interaction with looped interfaces 123 [RFC4862] explicitly defines that the case of a physically looped 124 back interface is not a failure: "If the solicitation is from the 125 node itself (because the node loops back multicast packets), the 126 solicitation does not indicate the presence of a duplicate address." 128 However, the practical experiences show that the measures described 129 in [RFC4862] are either incomplete or incorrectly implemented: a 130 loopback on the interface causes DAD failure. 132 [I-D.ietf-6man-enhanced-dad] discusses the solution to this issue. 134 6. Delays before an address can be used 136 Section "5.4. Duplicate Address Detection" of [RFC4862] specifies 137 that until the DAD procedure completes, the address remains in 138 Tentative state. In this state, any traffic to this address other 139 than that related to DAD-related is dropped. This introduces delay 140 between the interface getting connected to the network and an address 141 on this interface becoming usable. For fast-moving nodes it may be a 142 problem. 144 [RFC4429] introduces "Optimistic DAD" process, which addresses this. 146 7. Partition-join tolerance 148 [RFC4862] explicitly mentions this problem: "Note that the method for 149 detecting duplicates is not completely reliable, and it is possible 150 that duplicate addresses will still exist (e.g., if the link was 151 partitioned while Duplicate Address Detection was performed)." 153 In contrast, IPv4 stacks typically implement the Address Conflict 154 Detection (ACD) from [RFC5227]. This disparity results in a less 155 robust operation of IPv6 compared to IPv4 and is undesirable. 157 8. Behavior on collision 159 [RFC4862] in its section "5.4.5. When Duplicate Address Detection 160 Fails" is much more prescriptive than [RFC2462] that it superceeds. 161 However, it has been observed that some implementations may simply 162 reset the network interface and attempt the DAD process again. This 163 behavior, while being more resilient in case the DAD failure is 164 happening erroneously, is different from what is recommended in the 165 standard. 167 9. Energy efficiency 169 If a node wants to "defend" its address using DAD, it has to be awake 170 and listening on the solicited node multicast address in order to 171 receive the DAD NS. In the low-power environments this may 172 significantly impact the battery life of the devices. 174 10. Wake-up and L2 events 176 In mobile environments, node may roam in different parts of the 177 network and also take "naps". The specification in [RFC4862] does 178 not explicitly discuss this scenario, so there is a room for 179 ambiguity in implementation. This may either result in less robust 180 DAD coverage (if the node does not perform the DAD again when an L2 181 event happens), or an excessive amount of multicast packets (when a 182 node performs the dad every time L2 event happens and there is a lot 183 of them moving within a segment). 185 11. Usage of DAD to create state 187 [RFC4862] in section "5.4. Duplicate Address Detection" states that 188 DAD must be performed on all addresses. Given the potentially 189 decentralized nature of address assignment in IPv6, this property is 190 being used to prebuild the state in the network about the host's 191 addresses - e.g. for "First Come First Served" security as described 192 in section "3.2.3. Processing of Local Traffic" of [RFC6620]. 194 If the delivery of the DAD_NS packets is unreliable or there are 195 nodes on the segment which use the Optimistic DAD mechanism, state 196 created purely on DAD_NS packets might be also unreliable. The 197 specific case of [RFC6620] solves the issue by triggering the 198 recreation of state based on data packets as well, however it might 199 not be possible in some scenarios. 201 12. Support of multi-link subnets 203 DAD doesn't support multi-link subnets: a multicast DAD_NS sent on 204 one link will not be seen on the other. 206 [RFC6275] specifically provides one way to construct a multi-link 207 subnet (consisting of a broadcast link and a collection of point to 208 point tunnels). It explicitly defines the procedures for making DAD 209 work in that topology. 211 [RFC4903] discusses the issues related to multi-link subnets - and 212 given the multi-link subnets might be created in many ways, it might 213 be prudent to keep enhancements to DAD whose sole purpose is related 214 to multi-link subnets, to be out of scope. 216 13. Anycast Addresses and Duplicate Address Detection 218 Section 5.4 "Duplicate Address Detection" of [RFC4862] specifies that 219 Duplicate Address Detection MUST NOT be performed on anycast 220 addresses. This, stems from the fact that the anycast addresses are 221 syntactically indistinguishable from unicast addresses. One can 222 argue that this allows for misconfiguration if an address deemed to 223 be anycast already exist on the network. 225 14. Implementations doing DAD once per IID 227 Section 5.4 of [RFC4862] mentions the implementations performing a 228 single DAD per interface identifier, and discourages that 229 "optimization". As the practice is emerging in the industry is to 230 move away from the fixed interface identifiers anywhere, the 231 necessity to perform a DAD on a per-address basis might be useful to 232 elevate to a requirement status. 234 15. Backwards compatibility and presence of the DAD proxies 236 While not being an issue as such, this is a reminder that the 237 operation of DAD has to remain backwards compatible, both to remain 238 cooperative with the existing hosts, and the potentially present DAD 239 proxies as described in [RFC6957]. 241 16. Acknowledgements 243 Thanks to Ole Troan for creating and curating the original list. 244 Thanks a lot to Suresh Krishnan and Erik Nordmark for the reviews and 245 useful suggestions. 247 17. IANA Considerations 249 None. 251 18. Security Considerations 253 There are no additional security considerations as this document only 254 outlines the issues observed with the current Duplicate Address 255 Detection protocol. 257 19. References 259 19.1. Informative References 261 [I-D.ietf-6man-enhanced-dad] 262 Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., 263 and W. George, "Enhanced Duplicate Address Detection", 264 draft-ietf-6man-enhanced-dad-07 (work in progress), 265 October 2014. 267 19.2. Normative References 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, March 1997. 272 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 273 Autoconfiguration", RFC 2462, December 1998. 275 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 276 for IPv6", RFC 4429, April 2006. 278 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 279 Address Autoconfiguration", RFC 4862, September 2007. 281 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 282 2007. 284 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 285 July 2008. 287 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 288 in IPv6", RFC 6275, July 2011. 290 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 291 SAVI: First-Come, First-Served Source Address Validation 292 Improvement for Locally Assigned IPv6 Addresses", RFC 293 6620, May 2012. 295 [RFC6957] Costa, F., Combes, J-M., Pougnard, X., and H. Li, 296 "Duplicate Address Detection Proxy", RFC 6957, June 2013. 298 Author's Address 300 Andrew Yourtchenko 301 cisco 302 6b de Kleetlaan 303 Diegem 1831 304 Belgium 306 Email: ayourtch@cisco.com