Internet Engineering Task Force (IETF) R. Asati Request for Comments: 7527 H. Singh Updates: 4429, 4861, 4862 W. Beebee Category: Standards Track C. Pignataro ISSN: 2070-1721 Cisco Systems, Inc. E. Dart Lawrence Berkeley National Laboratory W. George Time Warner Cable April 2015 Enhanced Duplicate Address Detection
AbstractIPv6 Loopback Suppression and Duplicate Address Detection (DAD) are discussed in Appendix A of RFC 4862. That specification mentions a hardware-assisted mechanism to detect looped back DAD messages. If hardware cannot suppress looped back DAD messages, a software solution is required. Several service provider communities have expressed a need for automated detection of looped back Neighbor Discovery (ND) messages used by DAD. This document includes mitigation techniques and outlines the Enhanced DAD algorithm to automate the detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks, this document automates resolving a specific duplicate address conflict. This document updates RFCs 4429, 4861, and 4862. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7527.
Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Operational Mitigation Options . . . . . . . . . . . . . . . 4 3.1. Disable DAD on an Interface . . . . . . . . . . . . . . . 4 3.2. Dynamic Disable/Enable of DAD Using Layer 2 Protocol . . 5 3.3. Operational Considerations . . . . . . . . . . . . . . . 5 4. The Enhanced DAD Algorithm . . . . . . . . . . . . . . . . . 6 4.1. Processing Rules for Senders . . . . . . . . . . . . . . 6 4.2. Processing Rules for Receivers . . . . . . . . . . . . . 7 4.3. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 7 5. Action to Perform on Detecting a Genuine Duplicate . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A of [RFC4862]. That specification mentions a hardware-assisted mechanism to detect looped back DAD messages. If hardware cannot suppress looped back DAD messages, a software solution is required. One specific DAD message is the Neighbor Solicitation (NS), specified in [RFC4861]. The NS is issued by the network interface of an IPv6 node for DAD. Another message involved in DAD is the Neighbor Advertisement (NA). The Enhanced DAD algorithm specified in this document focuses on detecting an NS looped back to the transmitting interface during the DAD operation. Detecting a looped back NA does not solve the looped back DAD
problem. Detection of any other looped back ND messages during the DAD operation is outside the scope of this document. This document also includes a section on mitigation that discusses means already available to mitigate the DAD loopback problem. This document updates RFCs 4429, 4861, and 4862. It updates RFCs 4429 and 4862 to use the Enhanced DAD algorithm to detect looped back DAD probes, and it updates RFC 4861 as described in Section 4.3 below. RFC2119]. RFC4862]. Note even Optimistic DAD as specified in [RFC4429] can fail due to a looped back DAD probe. This document covers looped back detection for Optimistic DAD as well. o Looped back message - also referred to as a reflected message. The message sent by the sender is received by the sender due to the network or an upper-layer protocol on the sender looping the message back. o Loopback - A function in which the router's Layer 3 interface (or the circuit to which the router's interface is connected) is looped back or connected to itself. Loopback causes packets sent by the interface to be received by the interface and results in interface unavailability for regular data traffic forwarding. See more details in Section 9.1 of [RFC2328]. The Loopback function is commonly used in an interface context to gain information on the quality of the interface, by employing mechanisms such as ICMPv6 pings and bit-error tests. In a circuit context, this function is used in wide-area environments including optical Dense Wavelength Division Multiplexing (DWDM) and Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) for fault isolation (e.g., by placing a loopback at different geographic locations along the path of a wide-area circuit to help locate a circuit fault). The Loopback function may be employed locally or remotely. o NS(DAD) - shorthand notation to denote a Neighbor Solicitation (NS) (as specified in [RFC4861]) that has an unspecified IPv6 source address and was issued during DAD.
configuration changes on point-to-point interfaces, 2) this is a one- time manual configuration on each interface, and 3) genuine duplicates on the link will not be detected. A service provider router, such as an access concentrator, or network core router, SHOULD support the DAD deactivation per interface. Section 6.4 of [RFC1661]) to detect a loopback on an interface. When a Layer 2 protocol detects that a loopback is present on an interface circuit, the device MUST temporarily disable DAD on the interface. When the protocol detects that a loopback is no longer present (or the interface state has changed), the device MUST (re-)enable DAD on that interface. This mitigation has several benefits. It leverages the Layer 2 protocol's built-in hardware loopback detection capability, if available. Being a hardware solution, it scales better than the software solution proposed in this document. This mitigation also scales better since it relies on an event-driven model that requires no additional state or timer. This may be significant on devices with hundreds or thousands of interfaces that may be in loopback for long periods of time (e.g., awaiting turn-up). Detecting looped back DAD messages using a Layer 2 protocol SHOULD be enabled by default, and it MUST be a configurable option if the Layer 2 technology provides means for detecting loopback messages on an interface circuit.
option specified in this document, the noncompliant device would follow current behavior and disable IPv6 on that interface due to DAD until manual intervention restores it. RFC3971]. Note [RFC3971] does not provide a recommendation for pseudorandom functions. Pseudorandom functions are covered in [RFC4086]. Since a nonce is used only once, the NS(DAD) for each IPv6 address of an interface uses a different nonce. Additional details of the algorithm are included in Section 4.1. If there is a collision because two nodes used the same Target Address in their NS(DAD) and generated the same random nonce, then the algorithm will incorrectly detect a looped back NS(DAD) when a genuine address collision has occurred. Since each looped back NS(DAD) event is logged to system management, the administrator of the network will have access to the information necessary to intervene manually. Also, because the nodes will have detected what appear to be looped back NS(DAD) messages, they will continue to probe, and it is unlikely that they will choose the same nonce the second time (assuming quality random number generators). The algorithm is capable of detecting any ND solicitation (NS and Router Solicitation) or advertisement (NA and Router Advertisement) that is looped back. However, there may be increased implementation complexity and memory usage for the sender node to store a nonce and nonce-related state for all ND messages. Therefore, this document does not recommend using the algorithm outside of the DAD operation by an interface on a node. RFC4861]) after having sent DupAddrDetectTransmits Neighbor Solicitations, the interface moves the Target Address to the assigned state.
If any probe is looped back within RetransTimer milliseconds after having sent DupAddrDetectTransmits NS(DAD) messages, the interface continues with another MAX_MULTICAST_SOLICIT number of NS(DAD) messages transmitted RetransTimer milliseconds apart. Section 2 of [RFC3971] defines a single-use nonce, so each Enhanced DAD probe uses a different nonce. If no probe is looped back within RetransTimer milliseconds after MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, the probing stops. The probing MAY be stopped via manual intervention. When probing is stopped, the interface moves the Target Address to the assigned state. Section 4.3 of [RFC4861]: If a node has been configured to use the Enhanced DAD algorithm, an NS with an unspecified source address adds the Nonce option to the message and implements the state machine of the Enhanced DAD algorithm. The following text is appended to the RetransTimer variable description in Section 6.3.2 of [RFC4861]: The RetransTimer MAY be overridden by a link-specific document if a node supports the Enhanced DAD algorithm. Section 5.4.5 of [RFC4862]. However, in certain cases, if the genuine duplicate
matches the tentative or optimistic IPv6 address of a network interface of the access concentrator, additional automated action is recommended. Some networks follow a trust model where a trusted router serves untrusted IPv6 host nodes. Operators of such networks have a desire to take automated action if a network interface of the trusted router has a tentative or optimistic address duplicated by a host. One example of a type of access network is cable broadband deployment where the access concentrator is the first-hop IPv6 router to multiple broadband modems and supports proxying of DAD messages. The network interface on the access concentrator initiates DAD for an IPv6 address and detects a genuine duplicate due to receiving an NS(DAD) or an NA message. On detecting such a duplicate, the access concentrator SHOULD log a system management message, drop the received ND message, and block the modem on whose Layer 2 service identifier the duplicate NS(DAD) or NA message was received. Any other network that follows the same trust model MAY use the automated action proposed in this section. RFC4862]. The nonce can be exploited by a rogue deliberately changing the nonce to fail the looped back detection specified by the Enhanced DAD algorithm. SEND is recommended to circumvent this exploit. Additionally, the nonce does not protect against the DoS caused by a rogue node replying by a fake NA to all DAD probes. SEND is recommended to circumvent this exploit also. Disabling DAD has an obvious security issue before a remote node on the link can issue reflected NS(DAD) messages. Again, SEND is recommended for this exploit. Source Address Validation Improvement (SAVI) [RFC6620] also protects against various attacks by on-link rogues. [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994, <http://www.rfc-editor.org/info/rfc1661>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005, <http://www.rfc-editor.org/info/rfc3971>. [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>. [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006, <http://www.rfc-editor.org/info/rfc4429>. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>. [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, May 2012, <http://www.rfc-editor.org/info/rfc6620>.
http://www.cisco.com/ Hemant Singh Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 United States Phone: +1 978 936 1622 EMail: firstname.lastname@example.org URI: http://www.cisco.com/ Wes Beebee Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 United States Phone: +1 978 936 2030 EMail: email@example.com URI: http://www.cisco.com/ Carlos Pignataro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States EMail: firstname.lastname@example.org URI: http://www.cisco.com/