idnits 2.17.1 draft-hsingh-6man-enhanced-dad-04.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 draft header indicates that this document updates RFC4862, but the abstract doesn't seem to directly say this. It does mention RFC4862 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC4862, updated by this document, for RFC5378 checks: 2004-02-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 5, 2012) is 4494 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 403, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1247 (Obsoleted by RFC 1583) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Asati 3 Internet-Draft H. Singh 4 Updates: 4862 (if approved) W. Beebee 5 Intended status: Standards Track Cisco Systems, Inc. 6 Expires: July 8, 2012 E. Dart 7 Lawrence Berkeley National 8 Laboratory 9 W. George 10 Time Warner Cable 11 C. Pignataro 12 Cisco Systems, Inc. 13 January 5, 2012 15 Enhanced Duplicate Address Detection 16 draft-hsingh-6man-enhanced-dad-04.txt 18 Abstract 20 Appendix A of the IPv6 Duplicate Address Detection (DAD) document in 21 RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 22 does not settle on one specific automated means to detect loopback of 23 Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several 24 service provider communities have expressed a need for automated 25 detection of looped backed ND messages used by DAD. This document 26 includes mitigation techniques and then outlines the Enhanced DAD 27 algorithm to automate detection of looped back IPv6 ND messages used 28 by DAD. For network loopback tests, the Enhanced DAD algorithm 29 allows IPv6 to self-heal after a loopback is placed and removed. 30 Further, for certain access networks the document automates resolving 31 a specific duplicate address conflict. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 8, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Operational Mitigation Options . . . . . . . . . . . . . . . . 4 70 3.1. Disable DAD on Interface . . . . . . . . . . . . . . . . . 4 71 3.2. Dynamic Disable/Enable of DAD Using Layer 2 Protocol . . . 5 72 3.3. Operational Considerations . . . . . . . . . . . . . . . . 5 73 4. The Enhanced DAD Algorithm . . . . . . . . . . . . . . . . . . 6 74 4.1. General Rules . . . . . . . . . . . . . . . . . . . . . . 7 75 4.2. Processing Rules for Senders . . . . . . . . . . . . . . . 7 76 4.3. Processing Rules for Receivers . . . . . . . . . . . . . . 7 77 4.4. Impact on SEND . . . . . . . . . . . . . . . . . . . . . . 7 78 4.5. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . 8 79 5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 8 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 83 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 84 Appendix A. Changes between the -03 and the -04 versions . . . . 10 85 Appendix B. Changes between the -02 and the -03 versions . . . . 10 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 88 1. Terminology 90 o DAD-failed state - Duplication Address Detection failure as 91 specified in [RFC4862]. Failure also includes if the Target 92 Address is optimistic. Optimistic DAD is specified in [RFC4429]. 94 o Looped back message - also referred to as a reflected message. 95 The message sent by the sender is received by the sender due to 96 the network or a Upper Layer Protocol on the sender looping the 97 message back. 99 o Loopback - A function in which the router's interface (or the 100 circuit to which the router's interface is connected) is looped 101 back or connected to itself. Loopback causes packets sent by the 102 interface to be received by the interface, and results in 103 interface unavailability for regular data traffic forwarding. See 104 more details in section 9.1 of [RFC1247]. The Loopback function 105 is commonly used in an interface context to gain information on 106 the quality of the interface, by employing mechanisms such as 107 ICMPv6 pings, bit-error tests, etc. In a circuit context, it is 108 used in wide area environments including optical dense wave 109 division multiplexing (DWDM) and SONET/SDH for fault isolation 110 (e.g. by placing a loopback at different geographic locations 111 along the path of a wide area circuit to help locate a circuit 112 fault). The Loopback function may be employed locally or 113 remotely. 115 o NS(DAD) - shorthand notation to denote an NS with unspecified IPv6 116 source-address issued during DAD. 118 2. Introduction 120 Appendix A of [RFC4862] discusses Loopback Suppression and Duplicate 121 Address Detection (DAD). However, [RFC4862] does not settle on one 122 specific automated means to detect loopback of ND messages used by 123 DAD. One specific DAD message is a Neighbor Solicitation (NS), 124 specified in [RFC4861]. The NS is issued by the network interface of 125 an IPv6 node for DAD. Another message involved in DAD is a Neighbor 126 Advertisement (NA). The Enhanced DAD algorithm proposed in this 127 document focuses on detecting an NS looped back to the transmitting 128 interface during the DAD operation. Detecting a looped back NA is of 129 no use because no problems with DAD will occur if a node receives a 130 looped back NA. Detecting of any other looped back ND messages 131 outside of the DAD operation is not critical and thus this document 132 does not cover such detection. The document also includes a 133 Mitigation section that discusses means already available to mitigate 134 the loopback problem. 136 Recently service providers have reported a DAD loopback problem. 137 Loopback testing is underway on a circuit connected to an interface 138 on a router. The interface on the router is enabled for IPv6. The 139 interface issues a NS for the IPv6 link-local address DAD. The NS is 140 reflected back to the router interface due to the loopback condition 141 of the circuit, and the router interface enters a DAD-failed state. 142 In contrast to IPv4, IPv6 will not return to operation on the 143 interface when the loopback condition is cleared without manual 144 intervention. 146 There are other conditions which will also trigger similar problems 147 with DAD Loopback. While the following example is not a common 148 configuration, it has occurred in a large service provider network. 149 It is necessary to address it in the proposed solution because the 150 trigger scenario has the potential to cause significant IPv6 service 151 outages when it does occur. Two broadband modems in the same 152 location are served by the same service provider and both modems are 153 served by one access concentrator and one layer 3 interface on the 154 access concentrator. The two modems have the Ethernet ports of each 155 modem connected to a network hub. The access concentrator serving 156 the modems is the first-hop IPv6 router for the modems. The access 157 concentrator also supports proxying of DAD messages. Each modem is 158 enabled for at least data services. The network interface of the 159 access concentrator serving the two broadband modems is enabled for 160 IPv6 and the interface issues a NS(DAD) message for the IPv6 link- 161 local address. The NS message reaches one modem first and this modem 162 sends the message to the network hub which sends the message to the 163 second modem which forwards the message back to the access 164 concentrator. The looped back NS message causes the network 165 interface on the access concentrator to be in a DAD-failed state. 166 Such a network interface typically serves up to 100 thousand 167 broadband modems causing all the modems (and hosts behind the modems) 168 to fail to get IPv6 online on the access network. Additionally, it 169 may be tedious for the access concentrator to find out which of the 170 six thousand or more homes looped back the DAD message. Clearly 171 there is a need for automated detection of looped back NS messages 172 during DAD operations by a node. 174 3. Operational Mitigation Options 176 Two mitigation options are described below. The mechanisms do not 177 require any change to existing implementations. 179 3.1. Disable DAD on Interface 181 One can disable DAD on an interface and then there is no NS(DAD) 182 issued to be looped back. DAD is disabled by setting the interface's 183 DupAddrDetectTransmits variable to zero. While this mitigation may 184 be the simplest the mitigation has three drawbacks. 186 It would likely require careful analysis of configuration on such 187 point-to-point interfaces, a one-time manual configuration on each of 188 such interfaces, and more importantly, genuine duplicates in the link 189 will not be detected. 191 A network operator MAY use this mitigation. 193 3.2. Dynamic Disable/Enable of DAD Using Layer 2 Protocol 195 It is possible that one or more layer 2 protocols include provisions 196 to detect the existence of a loopback on an interface circuit, 197 usually by comparing protocol data sent and received. For example, 198 PPP uses magic number (section 6.4 of [RFC1661]) to detect a loopback 199 on an interface. 201 When a layer 2 protocol detects that a loopback is present on an 202 interface circuit, the device MUST temporarily disable DAD on the 203 interface, and when the protocol detects that a loopback is no longer 204 present (or the interface state has changed), the device MUST 205 (re-)enable DAD on that interface. 207 This solution requires no protocol changes. This solution SHOULD be 208 enabled by default, and MUST be a configurable option. 210 This mitigation has several benefits. They are 212 1. It leverages layer 2 protocol's built-in loopback detection 213 capability, if available. 215 2. It scales better (since it relies on an event-driven), requires 216 no additional state, timer etc. This may be a significant 217 scaling consideration on devices with hundreds or thousands of 218 interfaces that may be in loopback for long periods of time (such 219 as while awaiting turn-up or during long-duration intrusive bit 220 error rate tests). 222 3.3. Operational Considerations 224 The mitigation options discussed in the document do not require the 225 devices on both ends of the circuit to support the mitigation 226 functionality simultaneously, and do not propose any capability 227 negotiation. Suffice to say that the mitigation options are well 228 effective for the unidirectional loopback. 230 The mitigation options may not be effective for the bidirectional 231 loopback (i.e. the loopback is placed in both directions of the 232 circuit interface, so as to identify the faulty segment) if only one 233 device followed a mitigation option specified in this document, since 234 the other device would follow current behavior and disable IPv6 on 235 that interface due to DAD until manual intervention restores it. 237 This is nothing different from what happens today (without the 238 solutions proposed by this document) in case of unidirectional 239 loopback. Hence, it is expected that an operator would resort to 240 manual intervention for the devices not compliant with this document, 241 as usual. 243 4. The Enhanced DAD Algorithm 245 The Enhanced DAD algorithm covers detection of a looped back NS(DAD) 246 message. The document proposes use of the Nonce Option specified in 247 the SEND document of [RFC3971]. The nonce is a random number as 248 specified in [RFC3971]. If SEND is enabled on the router and the 249 router also supports the Enhanced DAD algorithm (specified in this 250 document), there is integration with the Enhanced DAD algorithm and 251 SEND. See more details in the Impact on SEND section. 253 When the IPv6 network interface issues a NS(DAD) message, the 254 interface includes the Nonce Option in the NS(DAD) message and saves 255 the nonce in local store. Subsequently if the interface receives an 256 identical NS(DAD) message, the interface logs a system management 257 message, updates any statistics counter, and drops the looped back 258 NS(DAD). If the DupAddrDetectTransmits variable for the interface is 259 greater than one, subsequent NS(DAD) messages for the same Target 260 Address should be suppressed. If the interface receives a NS(DAD) 261 message with a different nonce but TargetAddress matches a tentative 262 or optimistic address on the interface, the interface logs a DAD- 263 failed system management message, updates any statistics, and behaves 264 identical to the behavior specified in [RFC4862] for DAD failure. 266 Six bytes of random nonce is sufficiently large for nonce collisions. 267 However if there is a collision because two nodes generated the same 268 random nonce (that are using the same Target address in their 269 NS(DAD)), then the algorithm will incorrectly detect a looped back 270 NS(DAD) when the NS(DAD) was issued to signal a genuine duplicate. 271 Since each looped back NS(DAD) event is logged to system management, 272 the administrator of the network will have to intervene manually. 274 The algorithm is capable of detecting any ND solicitation (NS and 275 Router Solicitation) or advertisement (NA and Router Advertisement) 276 that is looped back. However, saving a nonce and nonce related data 277 for all ND messages has impact on memory of the node and also adds 278 the algorithm state to a substantially larger number of ND messages. 279 Therefore this document does not recommend using the algorithm 280 outside of the DAD operation by an interface on a node. 282 4.1. General Rules 284 A node MUST implement detection of looped back NS(DAD) messages 285 during DAD for an interface address. 287 4.2. Processing Rules for Senders 289 If a node has been configured to use the Enhanced DAD algorithm, when 290 sending a NS(DAD) for a tentative or optimistic interface address the 291 sender MUST generate a random nonce associated with the interface 292 address, MUST save the nonce, and MUST include the nonce in the Nonce 293 Option included in the NS(DAD). If a looped back NS(DAD) is detected 294 by the interface, and if the DupAddrDetectTransmits variable for the 295 interface is greater than one, subsequent NS(DAD) messages for the 296 same Target Address SHOULD be suppressed. 298 4.3. Processing Rules for Receivers 300 If the node has been configured to use the Enhanced DAD algorithm and 301 an interface on the node receives any NS(DAD) message that matches 302 the interface address (in tentative or optimistic state), the 303 receiver compares the nonce in the message with the saved nonce. If 304 a match is found, the node SHOULD log a system management message, 305 SHOULD update any statistics counter, and MUST drop the received 306 message. If the received NS(DAD) message includes a nonce and no 307 match is found with the saved nonce, the node SHOULD log a system 308 management message for DAD-failed and SHOULD update any statistics 309 counter. 311 4.4. Impact on SEND 313 The SEND document uses the Nonce Option in the context of matching an 314 NA with an NS. However, no text in SEND has an explicit mention of 315 detecting looped back ND messages. If this document updates 316 [RFC4862], SEND should be updated to integrate with the Enhanced DAD 317 algorithm. A minor update to SEND would be to explicitly mention 318 that the nonce in SEND is also used by SEND to detect looped back NS 319 messages during DAD operations by the node. In a mixed SEND 320 environment with SEND and unsecured nodes, the lengths of the nonce 321 used by SEND and unsecured nodes MUST be identical. 323 4.5. Changes to RFC 4862 325 The following text is added to [RFC4862]. 327 A network interface of an IPv6 node SHOULD implement the Enhanced DAD 328 algorithm. For example, if the interface on an IPv6 node is 329 connected to a circuit that supports loopback testing, then the node 330 should implement the Enhanced DAD algorithm that allows the IPv6 331 interface to self-heal after loopback testing is ended on the 332 circuit. Another example is when the IPv6 interface resides on an 333 access concentrator running DAD Proxy. The interface supports up to 334 100 thousand IPv6 clients (broadband modems) connected to the 335 interface. If the interface performs DAD for its IPv6 link-local 336 address and if the DAD probe is reflected back to the interface, the 337 interface is stuck in DAD failed state and IPv6 services to the 100 338 thousand clients is denied. Disabling DAD for such an IPv6 interface 339 on an access concentrator is not an option because the network also 340 needs to detect genuine duplicates in the interface downstream 341 network. The Enhanced DAD algorithm also facilitates detecting a 342 genuine duplicate for the interface on the access concentrator. See 343 the Actions to Perform on Detecting a Genuine Duplicate section of 344 the Enhanced DAD document. 346 5. Actions to Perform on Detecting a Genuine Duplicate 348 As described in paragraphs above the nonce can also serve to detect 349 genuine duplicates even when the network has potential for looping 350 back ND messages. When a genuine duplicate is detected, the node 351 follows the manual intervention specified in section 5.4.5 of 352 [RFC4862]. However, in certain networks such as an access network if 353 the genuine duplicate matches the tentative or optimistic IPv6 354 address of a network interface of the access concentrator, automated 355 actions are proposed. 357 One access network is a cable broadband deployment where the access 358 concentrator is the first-hop IPv6 router to several thousand 359 broadband modems. The router also supports proxying of DAD messages. 360 The network interface on the access concentrator initiates DAD for an 361 IPv6 address and detects a genuine duplicate due to receiving an 362 NS(DAD) or an NA message. On detecting such a duplicate the access 363 concentrator logs a system management message, drops the received ND 364 message, and blocks the modem on whose layer 2 service identifier the 365 NS(DAD) or NA message was received on. 367 The network described above follows a trust model where a trusted 368 router serves un-trusted IPv6 host nodes. Operators of such networks 369 have a desire to take automated action if a network interface of the 370 trusted router has a tentative or optimistic address duplicate with a 371 host served by trusted router interface. Any other network that 372 follows the same trust model MAY use the automated actions proposed 373 in this section. 375 6. Security Considerations 377 The nonce can be exploited by a rogue deliberately changing the nonce 378 to fail the looped back detection specified by the Enhanced DAD 379 algorithm. SEND is recommended for this exploit. For any mitigation 380 suggested in the document such as disabling DAD has an obvious 381 security issue before a remote node on the link can issue reflected 382 NS(DAD) messages. Again, SEND is recommended for this exploit. 384 7. IANA Considerations 386 None. 388 8. Acknowledgements 390 Thanks (in alphabetical order by first name) to Dmitry Anipko, Eric 391 Levy-Abegnoli, Erik Nordmark, Fred Templin, Suresh Krishnan, and 392 Tassos Chatzithomaoglou for their guidance and review of the 393 document. Thanks to Thomas Narten for encouraging this work. Thanks 394 to Steinar Haug and Scott Beuker for describing the use cases. 396 9. Normative References 398 [RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991. 400 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 401 RFC 1661, July 1994. 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, March 1997. 406 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 407 Neighbor Discovery (SEND)", RFC 3971, March 2005. 409 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 410 for IPv6", RFC 4429, April 2006. 412 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 413 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 414 September 2007. 416 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 417 Address Autoconfiguration", RFC 4862, September 2007. 419 Appendix A. Changes between the -03 and the -04 versions 421 1. Modified text in the Introduction section for the second DAD 422 Loopback cable broadband problem with some editorial changes. 424 Appendix B. Changes between the -02 and the -03 versions 426 1. Added more precise definition of the Loopback function in a 427 circuit network to the Terminology section. 429 2. Added more clarification to the cable broadband example in the 430 Introduction section. 432 3. Changed the Changes to RFC 4862 section for the requirement to 433 support the Enhanced DAD algorithm from MUST to SHOULD. Also 434 changed the requirement to apply to a network interface for IPv6 435 rather than a router or host. Since the requirement changed from 436 a MUST to a SHOULD, a guidance paragraph was added to explain the 437 SHOULD. 439 4. Fixed some typos. 441 Authors' Addresses 443 Rajiv Asati 444 Cisco Systems, Inc. 445 7025 Kit Creek road 446 Research Triangle Park, NC 27709-4987 447 USA 449 Email: rajiva@cisco.com 450 URI: http://www.cisco.com/ 451 Hemant Singh 452 Cisco Systems, Inc. 453 1414 Massachusetts Ave. 454 Boxborough, MA 01719 455 USA 457 Phone: +1 978 936 1622 458 Email: shemant@cisco.com 459 URI: http://www.cisco.com/ 461 Wes Beebee 462 Cisco Systems, Inc. 463 1414 Massachusetts Ave. 464 Boxborough, MA 01719 465 USA 467 Phone: +1 978 936 2030 468 Email: wbeebee@cisco.com 469 URI: http://www.cisco.com/ 471 Eli Dart 472 Lawrence Berkeley National Laboratory 473 1 Cyclotron Road, Berkeley, CA 94720 474 USA 476 Email: dart@es.net 477 URI: http://www.es.net/ 479 Wes George 480 Time Warner Cable 481 13820 Sunrise Valley Drive 482 Herndon, VA 20171 483 USA 485 Email: wesley.george@twcable.com 486 Carlos Pignataro 487 Cisco Systems, Inc. 488 7200-12 Kit Creek Road 489 Research Triangle Park, NC 27709 490 USA 492 Email: cpignata@cisco.com 493 URI: http://www.cisco.com/