idnits 2.17.1 draft-nordmark-6man-dad-approaches-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 14, 2015) is 3270 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ECMA-393' is mentioned on line 170, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN E. Nordmark 3 Internet-Draft Arista Networks 4 Intended status: Informational May 14, 2015 5 Expires: November 15, 2015 7 Possible approaches to make DAD more robust and/or efficient 8 draft-nordmark-6man-dad-approaches-01 10 Abstract 12 This outlines possible approaches to solve the issues around IPv6 13 Duplicate Address Detection robustness and/or efficiency which are 14 specified in the "DAD issues" dradft. 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 November 15, 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. Robustness Solution Approaches . . . . . . . . . . . . . . . . 3 52 3. Approaches to efficiency . . . . . . . . . . . . . . . . . . . 5 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 54 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 55 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 57 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 1. Introduction 62 Duplicate Address Detection (DAD) is a procedure in IPv6 performed on 63 an address before it can be assigned to an interface [RFC4862]. By 64 default it consists of sending a single multicast Neighbor 65 Soliciation message and waiting for a response for one second. If no 66 response is received, the address is declared to not be a duplicate. 67 Once the address has been tested once, there is no further attempts 68 to check for duplicates (unless the interface is re-initialized). 70 The companion document [I-D.yourtchenko-6man-dad-issues] outlines a 71 set of issues around Duplicate Address Detection (DAD) which either 72 result in reduced robustness, or result in lower efficiency for 73 either the hosts wanting to sleep or the network handling more 74 multicast packets. 76 The reader is encourage to review the issues in that document. In 77 summary, the lack of robustness is due to only sending one or a few 78 DAD probe initially, and not having any positive acknowledgement that 79 "there are no duplicates". This implies that partioned links that 80 later heal can result in persistent undetected duplicate IPv6 81 addresses, including cases of "local partitions" such as the case of 82 a modem not having connected when the DAD probes are sent. The 83 inefficiences appears when there are low-powered devices on the link 84 that wish to sleep a significant amount of time. Such devices must 85 either be woken up by multicast Neighbor Soliciations sent to one of 86 their solicited-node multicast addresses, or they need to redo DAD 87 each time they wake up from sleep. Both drain the battery; the 88 second one results in sending a DAD probe and then waiting for a 89 second with the radion receiver enabled to see if a DAD message 90 indicates a duplicate. 92 2. Robustness Solution Approaches 94 IPv4 ARP robustness against partitions and joins is greately improved 95 by Address Conflict Detection (ACD) [RFC5227]. That approach is 96 leverages the fact that ARP requests are broadcast on the link and 97 also makes the ARP replies be broadcast on the link. That 98 combination means that a host can immediately detect when some other 99 host provides a different MAC address for what the host thinks is its 100 own IPv4 address. That is coupled with state machines and logic for 101 determining whether to try to reclaim the address or give up and let 102 the other host have it. When giving up the host will form a new IPv4 103 address. The ACD approach results in more broadcast traffic than 104 normal ARP [RFC0826] since the ARP replies are broadcast. 106 Applying the same approach to IPv6 would require sending the Neighbor 107 Solicitations and Neighbor Advertisements to the all-nodes multicast 108 address so that a host can see when a different host is claiming/ 109 using the same source IPv6 address. That would remove the efficiency 110 that Neighbor Discovery gets from "spreading" the resolution traffic 111 over 4 million multicast addresses. 113 One can envision variants on the theme of ACD that fit better with 114 the use of solicited-node multicast addresses. Suppose we have Host1 115 with IP1 that hashes to solicited-node multicast address SN1. And we 116 also have Host2 with IP2 and SN2.The link-layer addresses are MAC1 117 and MAC2, respectively. In [RFC4861] when Host1 wants to communicate 118 with Host2 we will see 119 1. Host1 multicasts a NS from IP1 to SN2. That include a claim for 120 IP1->MAC1 using the Source Link-layer Address option. 121 2. Host2 receives the NA and unicasts a NA from IP2 to IP1. That 122 includes a claim for IP2->MAC using the Taget Link-layer Address 123 option. 125 If we want other hosts which might think they own either IP1 or IP2 126 to see the NA or NS (and we don't want to send the NS and NA to all- 127 nodes), then we can add additional multicast packets which explicitly 128 send the claim and send it to the Solicited-node multicast address of 129 the address that is being claimed. Thus 130 1. Host1 multicasts a NS from IP1 to SN2. That include a claim for 131 IP1->MAC1 using the Source Link-layer Address option. 132 2. Host1 multicasts a NA from IP1 to SN1 explicitly claiming 133 IP1->MAC1 using the TLLAO. 134 3. Host2 receives the NA and unicasts a NA from IP2 to IP1. That 135 includes a claim for IP2->MAC using the Taget Link-layer Address 136 option. 137 4. Host2 multicasts a NA from IP2 to SN2 explicitly claiming 138 IP2->MAC2 using the TLLAO. 140 The above explicit claims can then trigger the state machine 141 described in ACD. The claims can probably be rate limited for any 142 given source address since there is no need to repeat the claim just 143 because a NS needs to be sent for a new IP3 etc. The impact of such 144 rate limitig on the ability to detect duplicates. 146 In the worst case the above approach turns one multicast and one 147 unicast into three multicasts and one unicast, but all the multicasts 148 are sent to solicited-node multicast addresss. Thus a host would not 149 need to process the additional multicast packets. 151 This ACD-multicast approach assumes that the multicast packets are 152 delivered with reasonable reliability, but does not assume perfect 153 delivery. If multicast reliability is lower than unicast it will 154 result in retransmitted multicast NS in [RFC4861]. However, the 155 above rate limiting idea might need care to ensure that claims are 156 re-transmitted when the NS is re-transmitted. 158 A slightly different approach to on-going DAD is what is implemented 159 in Solaris where the node sends a periodic NA annoucement for the 160 address it is using, plus the ACD behavior of detecting such an NA 161 with a conflicting address. Presumably the NA annoucement can be 162 sent to the solicited-node multicast address. It might make sense to 163 use the Nonce option used by [I-D.ietf-6man-enhanced-dad] to avoid 164 issues where a host would hear its own announcement. 166 3. Approaches to efficiency 168 There exists some form of sleep proxies 169 [ECMA-393][http://en.wikipedia.org/wiki/Bonjour_Sleep_Proxy] which 170 perform handover of Neighbor Discovery protocol processing. [ECMA- 171 393] does not specify the handover mechanism, and there is no know 172 dcumentation for the handover mechanism. Even though the details are 173 not specified, the approach seems to allow a host to sleep without 174 worrying about DAD; the sleep proxy will respond to DAD probes. This 175 seems to entail sending multicast NAs to all-nodes to hand-over the 176 IP address to the proxy's MAC address before going to sleep and then 177 again to hand it back to the host's MAC address when it wakes up. 179 It is not clear whether such sleep proxies provide protection against 180 Single Points of Failure i.e., whether the host can hand over things 181 to a pair of sleep proxies. 183 FCFS SAVI [RFC6620] builds up state in devices to be able to detect 184 and prevent when some host is trying to use an IPv6 address already 185 used by another host on the link. This binding is built and checked 186 for DAD packets, but also for data packets to ensure that an attacker 187 can not inject a data packet with somebody elses source address. 188 When FCFS SAVI detects a potential problem it checks whether the IPv6 189 address has merely moved to a different binding anchor (e.g., port on 190 the switch) by sending a probe to its old anchor. Thus it assumes 191 the host is always awake or can be awoken to answer that probe. 192 Futhermore, implementation of the data triggered aspects can run into 193 hardware limitations since it requires something like an ACL for 194 every IPv6 address which has been validated. 196 DAD proxies as specified in [RFC6957] was designed to handle split- 197 horizon forwarding which means that a host would never receive a 198 multicast DAD probe sent by another host. This approach maintains a 199 binding cache built up by DAD probes and checked when handling DAD 200 probes. However, just like SAVI in order to handle host mobility and 201 legitimate host MAC address change, it the case of a potential 202 conflict the proxy ends up verifying whether the IP address is still 203 present at its old port and MAC address. Hence the host can not 204 sleep. 206 One could explore something along the SAVI and DAD proxy approach 207 that uses timestamps to allow better sleep. In principle would could 208 start some fixed timer each time an IPv6 address is added or updated 209 in the binding cache, and during that time the proxy would respond to 210 DAD probes on behalf of the (potentially sleeping) host. To enable 211 movement between ports/anchors such an approach would have to compare 212 MAC address and assume that if the MAC address is the same it is the 213 same host. (Unclear whether that is a good idea if we end up with 214 random MAC addresses for better privacy.) And if a host would like 215 to change its MAC address it would need to wait for the timeout 216 before it can succeed in doing the change. Thus on one hand one 217 would want a long time (24 hours?) to facilitate for sleeping hosts, 218 and on the other hand a short time to allow for MAC address change 219 and movement. 221 In essence the above forms an implicit request for the proxy to 222 handle DAD on behalf of the host, with a fixed time limit. If the 223 host can instead make that time explicit, then the host can also 224 remove the proxy behavior (by passing a time of zero). Such a "proxy 225 for me" request can leverage the ARO option defined for 6LoWPan in 226 [RFC6775] but use it only for the purposes of DAD offload to the 227 proxy. That option can also carry an additional identifier which can 228 be used to distinguish between the same host aka same identifier 229 changing the MAC address. In the RFC that is an EUI-64 and in 230 [I-D.chakrabarti-nordmark-energy-aware-nd] in is a more generalized 231 identifier field. For redundancy the ARO can be sent to more than 232 one proxy. 234 4. Security Considerations 236 If the working group decides to pursue one of the outlined approaches 237 to improve the robustness and/or efficiency of DAD, then the security 238 issues for that partiticular approach will need to be studied. 240 In general DAD is subject to a Denial of Service attack since a 241 malicious host can claim all the IPv6 addresses [RFC4218]. 243 5. Acknowledgements 245 Sowmini Varadhan pointed out the Solaris approach to use periodic 246 annoucements to increase robustness. 248 6. References 250 6.1. Normative References 252 [I-D.yourtchenko-6man-dad-issues] 253 Yourtchenko, A. and E. Nordmark, "A survey of issues 254 related to IPv6 Duplicate Address Detection", 255 draft-yourtchenko-6man-dad-issues-01 (work in progress), 256 March 2015. 258 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 259 converting network protocol addresses to 48.bit Ethernet 260 address for transmission on Ethernet hardware", STD 37, 261 RFC 826, November 1982. 263 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 264 Multihoming Solutions", RFC 4218, October 2005. 266 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 267 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 268 September 2007. 270 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 271 Address Autoconfiguration", RFC 4862, September 2007. 273 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 274 July 2008. 276 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 277 SAVI: First-Come, First-Served Source Address Validation 278 Improvement for Locally Assigned IPv6 Addresses", 279 RFC 6620, May 2012. 281 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 282 "Neighbor Discovery Optimization for IPv6 over Low-Power 283 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 284 November 2012. 286 [RFC6957] Costa, F., Combes, J-M., Pougnard, X., and H. Li, 287 "Duplicate Address Detection Proxy", RFC 6957, June 2013. 289 6.2. Informative References 291 [I-D.chakrabarti-nordmark-energy-aware-nd] 292 Chakrabarti, S., Nordmark, E., and M. Wasserman, "Energy 293 Aware IPv6 Neighbor Discovery Optimizations", 294 draft-chakrabarti-nordmark-energy-aware-nd-02 (work in 295 progress), March 2012. 297 [I-D.ietf-6man-enhanced-dad] 298 Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., 299 and W. George, "Enhanced Duplicate Address Detection", 300 draft-ietf-6man-enhanced-dad-15 (work in progress), 301 March 2015. 303 Author's Address 305 Erik Nordmark 306 Arista Networks 307 Santa Clara, CA 308 USA 310 Email: nordmark@arista.com