idnits 2.17.1 draft-yourtchenko-6man-dad-issues-01.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 (February 28, 2015) is 3344 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ECMA-393' is mentioned on line 322, but not defined ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) == Outdated reference: A later version (-15) exists of draft-ietf-6man-enhanced-dad-13 == Outdated reference: A later version (-06) exists of draft-ietf-6man-resilient-rs-04 Summary: 1 error (**), 0 flaws (~~), 4 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 E. Nordmark 5 Expires: September 1, 2015 Arista Networks 6 February 28, 2015 8 A survey of issues related to IPv6 Duplicate Address Detection 9 draft-yourtchenko-6man-dad-issues-01 11 Abstract 13 This document enumerates the practical issues observed with respect 14 to Duplicate Address Detection. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 1, 2015. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Robustness: Interaction with delay in forwarding . . . . . 3 53 2.2. Robustness: Behavior on links with unreliable multicast . 4 54 2.3. Robustness: Partition-join tolerance . . . . . . . . . . . 4 55 2.4. Robustness: Behavior on collision . . . . . . . . . . . . 4 56 2.5. Energy Efficiency . . . . . . . . . . . . . . . . . . . . 5 57 2.6. Wake-up and L2 events . . . . . . . . . . . . . . . . . . 5 58 3. Solved Issues . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Interaction with looped interfaces . . . . . . . . . . . . 5 60 3.2. Delays before an address can be used . . . . . . . . . . . 6 61 4. Observations . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. Duplicate L2 address detection . . . . . . . . . . . . . . 6 63 4.2. Usage of DAD to create state . . . . . . . . . . . . . . . 6 64 4.3. No support of multi-link subnets . . . . . . . . . . . . . 7 65 4.4. Anycast Addresses and Duplicate Address Detection . . . . 7 66 4.5. Implementations doing DAD once per IID . . . . . . . . . . 7 67 4.6. Backwards compatibility and presence of the DAD proxies . 8 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 Duplicate Address Detection (DAD) is a procedure in IPv6 performed on 83 an address before it can be assigned to an interface [RFC2462]. By 84 default it consists of sending a single multicast Neighbor 85 Soliciation message and waiting for a response for one second. If no 86 response is received, the address is declared to not be a duplicate. 87 Once the address has been tested once, there is no further attempts 88 to check for duplicates (unless the interface is re-initialized). 90 On one hand, it is mandatory for all addresses. On the other hand, 91 it is a "best effort" activity. These somewhat counter-intuitive 92 properties result in some issues that arise related to DAD. They are 93 listed below. The issues have been grouped to facilitate discussing 94 them. 96 2. Open Issues 98 Whether it is due to the assumptions made in 1995, or changes in how 99 networks are built or deployed, there are many reasons why DAD would 100 fail to detect a duplicate even when one exists. From a historical 101 perspective it is important to keep in mind that when DAD was 102 designed we had two forms of IPv6 addresses; those derived from 103 EUI-64 and statically assigned. Since the IETF has developed 104 additional methods for address assignment like DHCPv6 and addresses 105 that improve privacy by reducing linkability. 107 2.1. Robustness: Interaction with delay in forwarding 109 The DAD makes an assumption that if a link layer is up, the traffic 110 can be immediately forwarded, which is frequently not the case in 111 modern networks. Two prominent cases include the switches running 112 Spanning Tree Protocol (STP), and bridging modems. 114 When a port on an STP-enabled switch comes up, it goes through three 115 phases of Listening then Learning then Forwarding. The default is to 116 keep it for 15 seconds in Listening and 15 seconds in Learning 117 states. During this time no user traffic is forwarded by the switch 118 from and to this port. Therefore, if a DAD process happens during 119 this period it is guaranteed to not detect any duplicates. This 120 results in DAD being ineffective for link-local and otherwise pre 121 configured addresses. 123 Similarly, a modem-like device whose line status is invisible to IP 124 stack either within the modem or to a host connected on the Ethernet 125 side, also renders the DAD ineffective - the delay before the 126 connectivity is established can be much longer than any DAD wait. 128 Some of the link types, notably cable modems, have link-specific 129 standards to address this issue by requiring a new DAD each time the 130 RF-side interface bounces, as well as bouncing the LAN interface 131 triggered by the bounce of the RF interface. 133 Note that [I-D.ietf-6man-resilient-rs] makes the router solicitation 134 resilent to the above cases, but there is no counterpart to make DAD 135 robust. 137 2.2. Robustness: Behavior on links with unreliable multicast 139 DAD requires two multicast messages to pass through - the NS and NA. 140 Thus it shows a noticeable failure rate on links that do not pass 141 multicast reliably e.g. the 802.11a/b/g/n series of technologies. 142 See [I-D.vyncke-6man-mcast-not-efficient] for more information. 144 The author's ad-hoc experimentation at IETF90 revealed the success 145 rate of detecting the duplicate address on the IETF WiFi network 146 being about 4 in 5. This may violate the assumptions that other 147 protocols make. 149 2.3. Robustness: Partition-join tolerance 151 [RFC4862] explicitly mentions this problem: "Note that the method for 152 detecting duplicates is not completely reliable, and it is possible 153 that duplicate addresses will still exist (e.g., if the link was 154 partitioned while Duplicate Address Detection was performed)." 156 In contrast, IPv4 stacks typically implement the Address Conflict 157 Detection (ACD) from [RFC5227]. This disparity results in a less 158 robust operation of IPv6 compared to IPv4 and is undesirable. 160 Note that solutions along the lines of ACD, while improving 161 robustness, might result in more resource usage in on the links and 162 nodes by multicasting more ND packets. 164 2.4. Robustness: Behavior on collision 166 [RFC4862] in its section "5.4.5. When Duplicate Address Detection 167 Fails" is much more prescriptive than [RFC2462] that it superceeds. 168 However, it has been observed that some implementations may simply 169 reset the network interface and attempt the DAD process again. This 170 behavior, while being more resilient in case the DAD failure is 171 happening erroneously, is different from what is recommended in the 172 standard. 174 TBD: Do the other RFCs for address allocation require some retry 175 behavior? 177 2.5. Energy Efficiency 179 The use of multicast messages for DAD results in some inefficiencies 180 for both the network, in particular when multicast uses more layer 2 181 resources than unicast, and also has efficiency implications for 182 hosts. Potential techniques for making DAD reliably detect and 183 recover from duplicates might result in reduced efficiency. The 184 impact for WiFi is shown in 185 [I-D.desmouceaux-ipv6-mcast-wifi-power-usage]. 187 If a node wants to "defend" its address using DAD, it has to be awake 188 and listening on the solicited node multicast address in order to 189 receive the DAD NS. In the low-power environments this may 190 significantly impact the battery life of the devices. 192 2.6. Wake-up and L2 events 194 In mobile environments, node may roam in different parts of the 195 network and also take "naps". The specification in [RFC4862] does 196 not explicitly discuss this scenario, nor does DNA [RFC6059], so 197 there is a room for ambiguity in implementation. This may either 198 result in less robust DAD coverage (if the node does not perform the 199 DAD again when an L2 event happens), or an excessive amount of 200 multicast packets (when a node performs the dad every time L2 event 201 happens and there is a lot of them moving within a segment). 203 Thus this item could be categorized as being either in the robustness 204 or efficiency group of items. 206 3. Solved Issues 208 Some issues have been or are in the process of being solved. 210 3.1. Interaction with looped interfaces 212 [RFC4862] explicitly defines that the case of a physically looped 213 back interface is not a failure: "If the solicitation is from the 214 node itself (because the node loops back multicast packets), the 215 solicitation does not indicate the presence of a duplicate address." 217 However, the practical experiences show that the measures described 218 in [RFC4862] are either incomplete or incorrectly implemented: a 219 loopback on the interface causes DAD failure. 221 [I-D.ietf-6man-enhanced-dad] provides the solution to this issue. 223 3.2. Delays before an address can be used 225 Section "5.4. Duplicate Address Detection" of [RFC4862] specifies 226 that until the DAD procedure completes, the address remains in 227 Tentative state. In this state, any traffic to this address other 228 than that related to DAD-related is dropped. This introduces delay 229 between the interface getting connected to the network and an address 230 on this interface becoming usable. For fast-moving nodes it may be a 231 problem. 233 [RFC4429] introduces "Optimistic DAD" process, which addresses this. 234 That document has some notes about potentially causing TCP RST when 235 there is a duplicate, which can reset an existing TCP connection for 236 the existing user of the IPv6 address. That has some overall impact 237 on the robustness of the network and implicitly assumes that all 238 application protocols will always retry in order to handle such an 239 event. 241 4. Observations 243 Some issues we can't do much about in that they are more observations 244 of what can be done. 246 4.1. Duplicate L2 address detection 248 DAD does not detect duplicate L2 addresses in all cases. Depending 249 on the medium, it may be impossible to detect a duplicate L2 address 250 - e.g. if this address itself is used as a determinant in order to 251 establish the L2 connection. 253 4.2. Usage of DAD to create state 255 [RFC4862] in section "5.4. Duplicate Address Detection" states that 256 DAD must be performed on all addresses. Given the potentially 257 decentralized nature of address assignment in IPv6, this property is 258 being used to prebuild the state in the network about the host's 259 addresses - e.g. for "First Come First Served" security as described 260 in section "3.2.3. Processing of Local Traffic" of [RFC6620]. 262 If the delivery of the DAD_NS packets is unreliable or there are 263 nodes on the segment which use the Optimistic DAD mechanism, state 264 created purely on DAD_NS packets might be also unreliable. The 265 specific case of [RFC6620] solves the issue by triggering the 266 recreation of state based on data packets as well, however it might 267 not be possible in some scenarios. 269 4.3. No support of multi-link subnets 271 DAD doesn't support multi-link subnets: a multicast DAD_NS sent on 272 one link will not be seen on the other. 274 [RFC6275] specifically provides one way to construct a multi-link 275 subnet (consisting of a broadcast link and a collection of point to 276 point tunnels). It explicitly defines the procedures for making DAD 277 work in that topology. 279 [RFC4903] discusses the issues related to multi-link subnets - and 280 given the multi-link subnets might be created in many ways, it might 281 be prudent to keep enhancements to DAD whose sole purpose is related 282 to multi-link subnets, to be out of scope. 284 One may also argue that since [RFC4861] defers the clarifications on 285 IPv6 operation on NBMA networks to [RFC2491], it is unreasonable to 286 expect [RFC4862] describe the operation of DAD on NBMA type links, 287 and it is up to a link-specific document to describe such operation. 288 (An example is cable industry, where the cable standards define it). 290 However, it is then unclear where to address the frequently used 291 scenario of WiFi with blocked direct communication between the 292 stations - whether it is supposed to be an IEEE document or IETF 293 document ? And is there enough fundamental differences between the 294 different NBMA models to warrant the link-specific approaches to DAD 295 ? 297 4.4. Anycast Addresses and Duplicate Address Detection 299 Section 5.4 "Duplicate Address Detection" of [RFC4862] specifies that 300 Duplicate Address Detection MUST NOT be performed on anycast 301 addresses. This, stems from the fact that the anycast addresses are 302 syntactically indistinguishable from unicast addresses. One can 303 argue that this allows for misconfiguration if an address deemed to 304 be anycast already exist on the network. 306 4.5. Implementations doing DAD once per IID 308 Section 5.4 of [RFC4862] mentions the implementations performing a 309 single DAD per interface identifier, and discourages that 310 "optimization". As the practice is emerging in the industry is to 311 move away from the fixed interface identifiers anyhow, the necessity 312 to perform a DAD on a per-address basis might be useful to elevate to 313 a requirement status. 315 4.6. Backwards compatibility and presence of the DAD proxies 317 While not being an issue as such, this is a reminder that the 318 operation of DAD has to remain backwards compatible, both to remain 319 cooperative with the existing hosts, and the potentially present DAD 320 proxies as described in [RFC6957]. 322 There are also various forms of sleep proxies [ECMA-393] 323 [http://en.wikipedia.org/wiki/Bonjour_Sleep_Proxy] which perform 324 handoffs of Neighbor Discovery protocol processing that need to be 325 considered. 327 5. Acknowledgements 329 Thanks to Ole Troan for creating and curating the original list. 330 Thanks a lot to Lorenzo Colitti, Suresh Krishnan, Hemant Singh, 331 Hesham Soliman, Eric Vyncke, and James Woodyatt for the reviews and 332 useful suggestions. 334 6. IANA Considerations 336 None. 338 7. Security Considerations 340 There are no additional security considerations as this document only 341 outlines the issues observed with the current Duplicate Address 342 Detection protocol. 344 8. References 346 8.1. Normative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 352 Autoconfiguration", RFC 2462, December 1998. 354 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 355 over Non-Broadcast Multiple Access (NBMA) networks", 356 RFC 2491, January 1999. 358 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 359 for IPv6", RFC 4429, April 2006. 361 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 362 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 363 September 2007. 365 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 366 Address Autoconfiguration", RFC 4862, September 2007. 368 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 369 June 2007. 371 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 372 July 2008. 374 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 375 Detecting Network Attachment in IPv6", RFC 6059, 376 November 2010. 378 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 379 in IPv6", RFC 6275, July 2011. 381 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 382 SAVI: First-Come, First-Served Source Address Validation 383 Improvement for Locally Assigned IPv6 Addresses", 384 RFC 6620, May 2012. 386 [RFC6957] Costa, F., Combes, J-M., Pougnard, X., and H. Li, 387 "Duplicate Address Detection Proxy", RFC 6957, June 2013. 389 8.2. Informative References 391 [I-D.desmouceaux-ipv6-mcast-wifi-power-usage] 392 Desmouceaux, Y., "Power consumption due to IPv6 multicast 393 on WiFi devices", 394 draft-desmouceaux-ipv6-mcast-wifi-power-usage-01 (work in 395 progress), August 2014. 397 [I-D.ietf-6man-enhanced-dad] 398 Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., 399 and W. George, "Enhanced Duplicate Address Detection", 400 draft-ietf-6man-enhanced-dad-13 (work in progress), 401 February 2015. 403 [I-D.ietf-6man-resilient-rs] 404 Krishnan, S., Anipko, D., and D. Thaler, "Packet loss 405 resiliency for Router Solicitations", 406 draft-ietf-6man-resilient-rs-04 (work in progress), 407 October 2014. 409 [I-D.vyncke-6man-mcast-not-efficient] 410 Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. 411 Yourtchenko, "Why Network-Layer Multicast is Not Always 412 Efficient At Datalink Layer", 413 draft-vyncke-6man-mcast-not-efficient-01 (work in 414 progress), February 2014. 416 Authors' Addresses 418 Andrew Yourtchenko 419 cisco 420 6b de Kleetlaan 421 Diegem 1831 422 Belgium 424 Email: ayourtch@cisco.com 426 Erik Nordmark 427 Arista Networks 428 Santa Clara, CA 429 USA 431 Email: nordmark@arista.com