idnits 2.17.1 draft-ietf-6man-enhanced-dad-15.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 RFC4429, but the abstract doesn't seem to directly say this. It does mention RFC4429 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 (Using the creation date from RFC4429, updated by this document, for RFC5378 checks: 2004-03-23) (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 (March 5, 2015) is 3312 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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, 4861, 4429 (if approved) W. Beebee 5 Intended status: Standards Track C. Pignataro 6 Expires: September 6, 2015 Cisco Systems, Inc. 7 E. Dart 8 Lawrence Berkeley National Laboratory 9 W. George 10 Time Warner Cable 11 March 5, 2015 13 Enhanced Duplicate Address Detection 14 draft-ietf-6man-enhanced-dad-15 16 Abstract 18 IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are 19 discussed in Appendix A of RFC4862. That specification mentions a 20 hardware-assisted mechanism to detect looped back DAD messages. If 21 hardware cannot suppress looped back DAD messages, a software 22 solution is required. Several service provider communities have 23 expressed a need for automated detection of looped back Neighbor 24 Discovery (ND) messages used by DAD. This document includes 25 mitigation techniques and outlines the Enhanced DAD algorithm to 26 automate the detection of looped back IPv6 ND messages used by DAD. 27 For network loopback tests, the Enhanced DAD algorithm allows IPv6 to 28 self-heal after a loopback is placed and removed. Further, for 29 certain access networks the document automates resolving a specific 30 duplicate address conflict. This document updates RFC4861, RFC4862, 31 and RFC4429. 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 September 6, 2015. 50 Copyright Notice 52 Copyright (c) 2015 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Operational Mitigation Options . . . . . . . . . . . . . . . 4 72 3.1. Disable DAD on an Interface . . . . . . . . . . . . . . . 4 73 3.2. Dynamic Disable/Enable of DAD Using Layer-2 Protocol . . 5 74 3.3. Operational Considerations . . . . . . . . . . . . . . . 5 75 4. The Enhanced DAD Algorithm . . . . . . . . . . . . . . . . . 6 76 4.1. Processing Rules for Senders . . . . . . . . . . . . . . 6 77 4.2. Processing Rules for Receivers . . . . . . . . . . . . . 7 78 4.3. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 7 79 5. Action to Perform on Detecting a Genuine Duplicate . . . . . 7 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 83 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 86 1. Introduction 88 IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are 89 discussed in Appendix A of [RFC4862]. That specification mentions a 90 hardware-assisted mechanism to detect looped back DAD messages. If 91 hardware cannot suppress looped back DAD messages, a software 92 solution is required. One specific DAD message is the Neighbor 93 Solicitation (NS), specified in [RFC4861]. The NS is issued by the 94 network interface of an IPv6 node for DAD. Another message involved 95 in DAD is the Neighbor Advertisement (NA). The Enhanced DAD 96 algorithm specified in this document focuses on detecting an NS 97 looped back to the transmitting interface during the DAD operation. 99 Detecting a looped back NA does not solve the looped back DAD 100 problem. Detection of any other looped back ND messages during the 101 DAD operation is outside the scope of this document. This document 102 also includes a section on Mitigation that discusses means already 103 available to mitigate the DAD loopback problem. This document 104 updates RFC4861, RFC4862, and RFC4429. It updates RFC 4862 and RFC 105 4429 to use the enhanced-dad algorithm to detect looped back DAD 106 probes, and RFC4861 as described in Section 4.3 below. 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 1.2. Terminology 116 o DAD-failed state - Duplication Address Detection failure as 117 specified in [RFC4862]. Note even Optimistic DAD as specified in 118 [RFC4429] can fail due to a looped back DAD probe. This document 119 covers looped back detection for Optimistic DAD as well. 121 o Looped back message - also referred to as a reflected message. 122 The message sent by the sender is received by the sender due to 123 the network or an Upper Layer Protocol on the sender looping the 124 message back. 126 o Loopback - A function in which the router's layer-3 interface (or 127 the circuit to which the router's interface is connected) is 128 looped back or connected to itself. Loopback causes packets sent 129 by the interface to be received by the interface and results in 130 interface unavailability for regular data traffic forwarding. See 131 more details in section 9.1 of [RFC2328]. The Loopback function 132 is commonly used in an interface context to gain information on 133 the quality of the interface, by employing mechanisms such as 134 ICMPv6 pings and bit-error tests. In a circuit context, this 135 function is used in wide area environments including optical Dense 136 Wave Division Multiplexing (DWDM) and SONET/SDH for fault 137 isolation (e.g. by placing a loopback at different geographic 138 locations along the path of a wide area circuit to help locate a 139 circuit fault). The Loopback function may be employed locally or 140 remotely. 142 o NS(DAD) - shorthand notation to denote an Neighbor Solicitation 143 (NS) (as specified in [RFC4861]) with unspecified IPv6 source- 144 address issued during DAD. 146 2. Problem Statement 148 Service providers have reported a problem with DAD that arises in a 149 few scenarios. In the first scenario, loopback testing for 150 troubleshooting purposes is underway on a circuit connected to an 151 IPv6-enabled interface on a router. The interface issues a NS for 152 the IPv6 link-local address DAD. The NS is reflected back to the 153 router interface due to the loopback condition of the circuit, and 154 the router interface enters a DAD-failed state. After the loopback 155 condition is removed, IPv4 will return to operation without further 156 manual intervention. However, IPv6 will remain in DAD-failed state 157 until manual intervention on the router restores IPv6 to operation. 159 In the second scenario, two broadband modems are served by the same 160 service provider and terminate to the same layer-3 interface on an 161 IPv6-enabled access concentrator. In this case, the two modems' 162 Ethernet interfaces are also connected to a common local network 163 (collision domain). The access concentrator serving the modems is 164 the first-hop IPv6 router for the modems and issues a NS(DAD) message 165 for the IPv6 link-local address of its layer-3 interface. The NS 166 message reaches one modem first and this modem sends the message to 167 the local network, where the second modem receives the message and 168 then forwards it back to the access concentrator. The looped back NS 169 message causes the network interface on the access concentrator to be 170 in a DAD-failed state. Such a network interface typically serves 171 thousands of broadband modems, and all would have their IPv6 172 connectivity affected until the DAD-failed state is cleared. 173 Additionally, it may be difficult for the user of the access 174 concentrator to determine the source of the looped back DAD message. 175 Thus in order to avoid IPv6 outages that can potentially affect 176 multiple users, there is a need for automated detection of looped 177 back NS messages during DAD operations by a node. 179 Note: In both examples above, the IPv6 link-local address DAD 180 operation fails due to a looped back DAD probe. However, the problem 181 of a looped back DAD probe exists for any IPv6 address type including 182 global addresses. 184 3. Operational Mitigation Options 186 Two mitigation options are described below that do not require any 187 change to existing implementations. 189 3.1. Disable DAD on an Interface 191 One can disable DAD on an interface so that there are no NS(DAD) 192 messages issued. While this mitigation may be the simplest, the 193 mitigation has three drawbacks: 1) care is needed when making such 194 configuration changes on point-to-point interfaces, 2) this is a one- 195 time manual configuration on each interface, and 3) genuine 196 duplicates on the link will not be detected. 198 A Service Provider router, such as an access concentrator, or network 199 core router, SHOULD support the DAD deactivation per interface. 201 3.2. Dynamic Disable/Enable of DAD Using Layer-2 Protocol 203 Some layer-2 protocols include provisions to detect the existence of 204 a loopback on an interface circuit, usually by comparing protocol 205 data sent and received. For example, the Point-to-Point Protocol 206 (PPP) uses a magic number (section 6.4 of [RFC1661]) to detect a 207 loopback on an interface. 209 When a layer-2 protocol detects that a loopback is present on an 210 interface circuit, the device MUST temporarily disable DAD on the 211 interface. When the protocol detects that a loopback is no longer 212 present (or the interface state has changed), the device MUST 213 (re-)enable DAD on that interface. 215 This mitigation has several benefits. It leverages the layer-2 216 protocol's built-in loopback detection capability, if available. It 217 scales better since it relies on an event-driven model which requires 218 no additional state or timer. This may be significant on devices 219 with hundreds or thousands of interfaces that may be in loopback for 220 long periods of time (e.g., awaiting turn-up). 222 Detecting looped back DAD messages using a layer-2 protocol SHOULD be 223 enabled by default, and MUST be a configurable option if the layer-2 224 technology provides means for detecting loopback messages on an 225 interface circuit. 227 3.3. Operational Considerations 229 The mitigation options discussed above do not require the devices on 230 both ends of the circuit to support the mitigation functionality 231 simultaneously, and do not propose any capability negotiation. They 232 are effective for unidirectional circuit or interface loopback (i.e. 233 the loopback is placed in one direction on the circuit, rendering the 234 other direction non-operational), but they may not be effective for a 235 bidirectional loopback (i.e. the loopback is placed in both 236 directions of the circuit interface, so as to identify the faulty 237 segment). This is because unless both ends followed a mitigation 238 option specified in this document, the non-compliant device would 239 follow current behavior and disable IPv6 on that interface due to DAD 240 until manual intervention restores it. 242 4. The Enhanced DAD Algorithm 244 The Enhanced DAD algorithm covers detection of a looped back NS(DAD) 245 message. The document proposes use of a random number in the Nonce 246 Option specified in SEND [RFC3971]. Note [RFC3971] does not provide 247 a recommendation for pseudo-random functions. Pseudo-random 248 functions are covered in [RFC4086]. Since a nonce is used only once, 249 the NS(DAD) for each IPv6 address of an interface uses a different 250 nonce. Additional details of the algorithm are included in section 251 4.2. 253 If there is a collision because two nodes used the same Target 254 Address in their NS(DAD) and generated the same random nonce, then 255 the algorithm will incorrectly detect a looped back NS(DAD) when a 256 genuine address collision has occurred. Since each looped back 257 NS(DAD) event is logged to system management, the administrator of 258 the network will have access to the information necessary to 259 intervene manually. Also, because the nodes will have detected what 260 appear to be looped back NS(DAD) messages, they will continue to 261 probe, and it is unlikely that they will choose the same nonce the 262 second time (assuming quality random number generators). 264 The algorithm is capable of detecting any ND solicitation (NS and 265 Router Solicitation) or advertisement (NA and Router Advertisement) 266 that is looped back. However, there may be increased implementation 267 complexity and memory usage for the sender node to store a nonce and 268 nonce related state for all ND messages. Therefore, this document 269 does not recommend using the algorithm outside of the DAD operation 270 by an interface on a node. 272 4.1. Processing Rules for Senders 274 If a node has been configured to use the Enhanced DAD algorithm, when 275 sending an NS(DAD) for a tentative or optimistic interface address 276 the sender MUST generate a random nonce associated with the interface 277 address, MUST store the nonce internally, and MUST include the nonce 278 in the Nonce Option included in the NS(DAD). If the interface does 279 not receive any DAD failure indications within RetransTimer 280 milliseconds (see [RFC4861]) after having sent DupAddrDetectTransmits 281 Neighbor Solicitations, the interface moves the Target Address to the 282 assigned state. 284 If any probe is looped back within RetransTimer milliseconds after 285 having sent DupAddrDetectTransmits NS(DAD) messages, the interface 286 continues with another MAX_MULTICAST_SOLICIT number of NS(DAD) 287 messages transmitted RetransTimer milliseconds apart. Section 2 of 288 [RFC3971] defines a single-use nonce, so each Enhanced DAD probe uses 289 a different nonce. If no probe is looped back within RetransTimer 290 milliseconds after MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, 291 the probing stops. The probing MAY be stopped via manual 292 intervention. When probing is stopped, the interface moves the 293 Target Address to the assigned state. 295 4.2. Processing Rules for Receivers 297 If the node has been configured to use the Enhanced DAD algorithm and 298 an interface on the node receives any NS(DAD) message where the 299 Target Address matches the interface address (in tentative or 300 optimistic state), the receiver compares the nonce included in the 301 message, with any stored nonce on the receiving interface. If a 302 match is found, the node SHOULD log a system management message, 303 SHOULD update any statistics counter, and MUST drop the received 304 message. If the received NS(DAD) message includes a nonce and no 305 match is found with any stored nonce, the node SHOULD log a system 306 management message for a DAD-failed state, and SHOULD update any 307 statistics counter. 309 4.3. Changes to RFC 4861 311 The following text is appended to the RetransTimer variable 312 description in section 6.3.2 of [RFC4861]: 314 The RetransTimer MAY be overridden by a link-specific document if a 315 node supports the Enhanced DAD algorithm. 317 The following text is appended to the Source Address definition in 318 section 4.3 of [RFC4861]: 320 If a node has been configured to use the Enhanced DAD algorithm, an 321 NS with an unspecified source address adds the Nonce option to the 322 message and implements the state machine of the Enhanced DAD 323 algorithm. 325 5. Action to Perform on Detecting a Genuine Duplicate 327 As described in the paragraphs above, the nonce can also serve to 328 detect genuine duplicates even when the network has potential for 329 looping back ND messages. When a genuine duplicate is detected, the 330 node follows the manual intervention specified in section 5.4.5 of 331 [RFC4862]. However, in certain cases, if the genuine duplicate 332 matches the tentative or optimistic IPv6 address of a network 333 interface of the access concentrator, additional automated action is 334 recommended. 336 Some networks follow a trust model where a trusted router serves un- 337 trusted IPv6 host nodes. Operators of such networks have a desire to 338 take automated action if a network interface of the trusted router 339 has a tentative or optimistic address duplicated by a host. One 340 example of a type of access network is cable broadband deployment 341 where the access concentrator is the first-hop IPv6 router to 342 multiple broadband modems and supports proxying of DAD messages. The 343 network interface on the access concentrator initiates DAD for an 344 IPv6 address and detects a genuine duplicate due to receiving an 345 NS(DAD) or an NA message. On detecting such a duplicate, the access 346 concentrator SHOULD log a system management message, drop the 347 received ND message, and block the modem on whose layer-2 service 348 identifier the duplicate NS(DAD) or NA message was received on. Any 349 other network that follows the same trust model MAY use the automated 350 action proposed in this section. 352 6. Security Considerations 354 This document does not improve nor reduce the security posture of 355 [RFC4862]. The nonce can be exploited by a rogue deliberately 356 changing the nonce to fail the looped back detection specified by the 357 Enhanced DAD algorithm. SEND is recommended to circumvent this 358 exploit. Additionally, the nonce does not protect against the DoS 359 caused by a rogue node replying by a fake NA to all DAD probes. SEND 360 is recommended to circumvent this exploit also. Disabling DAD has an 361 obvious security issue before a remote node on the link can issue 362 reflected NS(DAD) messages. Again, SEND is recommended for this 363 exploit. Source Address Validation Improvement (SAVI) [RFC6620] also 364 protects against various attacks by on-link rogues. 366 7. IANA Considerations 368 None. 370 8. Acknowledgements 372 Thanks (in alphabetical order by first name) to Adrian Farrel, Benoit 373 Claise, Bernie Volz, Brian Haberman, Dmitry Anipko, Eric Levy- 374 Abegnoli, Eric Vyncke, Erik Nordmark, Fred Templin, Hilarie Orman, 375 Jouni Korhonen, Michael Sinatra, Ole Troan, Pascal Thubert, Ray 376 Hunter, Suresh Krishnan, Tassos Chatzithomaoglou, and Tim Chown for 377 their guidance and review of the document. Thanks to Thomas Narten 378 for encouraging this work. Thanks to Steinar Haug and Scott Beuker 379 for describing some of the use cases. 381 9. Normative References 383 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 384 RFC 1661, July 1994. 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, March 1997. 389 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 391 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 392 Neighbor Discovery (SEND)", RFC 3971, March 2005. 394 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 395 Requirements for Security", BCP 106, RFC 4086, June 2005. 397 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 398 for IPv6", RFC 4429, April 2006. 400 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 401 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 402 September 2007. 404 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 405 Address Autoconfiguration", RFC 4862, September 2007. 407 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 408 SAVI: First-Come, First-Served Source Address Validation 409 Improvement for Locally Assigned IPv6 Addresses", RFC 410 6620, May 2012. 412 Authors' Addresses 414 Rajiv Asati 415 Cisco Systems, Inc. 416 7025 Kit Creek road 417 Research Triangle Park, NC 27709-4987 418 USA 420 Email: rajiva@cisco.com 421 URI: http://www.cisco.com/ 423 Hemant Singh 424 Cisco Systems, Inc. 425 1414 Massachusetts Ave. 426 Boxborough, MA 01719 427 USA 429 Phone: +1 978 936 1622 430 Email: shemant@cisco.com 431 URI: http://www.cisco.com/ 432 Wes Beebee 433 Cisco Systems, Inc. 434 1414 Massachusetts Ave. 435 Boxborough, MA 01719 436 USA 438 Phone: +1 978 936 2030 439 Email: wbeebee@cisco.com 440 URI: http://www.cisco.com/ 442 Carlos Pignataro 443 Cisco Systems, Inc. 444 7200-12 Kit Creek Road 445 Research Triangle Park, NC 27709 446 USA 448 Email: cpignata@cisco.com 449 URI: http://www.cisco.com/ 451 Eli Dart 452 Lawrence Berkeley National Laboratory 453 1 Cyclotron Road, Berkeley, CA 94720 454 USA 456 Email: dart@es.net 457 URI: http://www.es.net/ 459 Wesley George 460 Time Warner Cable 461 13820 Sunrise Valley Drive 462 Herndon, VA 20171 463 USA 465 Email: wesley.george@twcable.com