summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7527.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7527.txt')
-rw-r--r--doc/rfc/rfc7527.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc7527.txt b/doc/rfc/rfc7527.txt
new file mode 100644
index 0000000..65cc14a
--- /dev/null
+++ b/doc/rfc/rfc7527.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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
+
+Abstract
+
+ IPv6 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.
+
+
+
+
+
+
+
+Asati, et al. Standards Track [Page 1]
+
+RFC 7527 Enhanced DAD April 2015
+
+
+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.
+
+Table of Contents
+
+ 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
+
+1. Introduction
+
+ IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are
+ discussed in 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
+
+
+
+Asati, et al. Standards Track [Page 2]
+
+RFC 7527 Enhanced DAD April 2015
+
+
+ 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.
+
+1.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+1.2. Terminology
+
+ o DAD-failed state - Duplication Address Detection failure as
+ specified in [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.
+
+
+
+
+
+Asati, et al. Standards Track [Page 3]
+
+RFC 7527 Enhanced DAD April 2015
+
+
+2. Problem Statement
+
+ Service providers have reported a problem with DAD that arises in a
+ few scenarios. In the first scenario, loopback testing for
+ troubleshooting purposes is underway on a circuit connected to an
+ IPv6-enabled interface on a router. The interface issues an NS for
+ the IPv6 link-local address DAD. The NS is reflected back to the
+ router interface due to the loopback condition of the circuit, and
+ the router interface enters a DAD-failed state. After the loopback
+ condition is removed, IPv4 will return to operation without further
+ manual intervention. However, IPv6 will remain in DAD-failed state
+ until manual intervention on the router restores IPv6 to operation.
+
+ In the second scenario, two broadband modems are served by the same
+ service provider and terminate to the same Layer 3 interface on an
+ IPv6-enabled access concentrator. In this case, the two modems'
+ Ethernet interfaces are also connected to a common local network
+ (collision domain). The access concentrator serving the modems is
+ the first-hop IPv6 router for the modems and issues a NS(DAD) message
+ for the IPv6 link-local address of its Layer 3 interface. The NS
+ message reaches one modem first, and this modem sends the message to
+ the local network, where the second modem receives the message and
+ then forwards it back to the access concentrator. The looped back NS
+ message causes the network interface on the access concentrator to be
+ in a DAD-failed state. Such a network interface typically serves
+ thousands of broadband modems, and all would have their IPv6
+ connectivity affected until the DAD-failed state is cleared.
+ Additionally, it may be difficult for the user of the access
+ concentrator to determine the source of the looped back DAD message.
+ Thus, in order to avoid IPv6 outages that can potentially affect
+ multiple users, there is a need for automated detection of looped
+ back NS messages during DAD operations by a node.
+
+ Note: In both examples above, the IPv6 link-local address DAD
+ operation fails due to a looped back DAD probe. However, the problem
+ of a looped back DAD probe exists for any IPv6 address type including
+ global addresses.
+
+3. Operational Mitigation Options
+
+ Two mitigation options are described below that do not require any
+ change to existing implementations.
+
+3.1. Disable DAD on an Interface
+
+ One can disable DAD on an interface so that there are no NS(DAD)
+ messages issued. While this mitigation may be the simplest, the
+ mitigation has three drawbacks: 1) care is needed when making such
+
+
+
+Asati, et al. Standards Track [Page 4]
+
+RFC 7527 Enhanced DAD April 2015
+
+
+ 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.
+
+3.2. Dynamic Disable/Enable of DAD Using Layer 2 Protocol
+
+ Some Layer 2 protocols include provisions to detect the existence of
+ a loopback on an interface circuit, usually by comparing protocol
+ data sent and received. For example, the Point-to-Point Protocol
+ (PPP) uses a magic number (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.
+
+3.3. Operational Considerations
+
+ The mitigation options discussed above do not require the devices on
+ both ends of the circuit to support the mitigation functionality
+ simultaneously and do not propose any capability negotiation. They
+ are effective for unidirectional circuit or interface loopback (i.e.
+ the loopback is placed in one direction on the circuit, rendering the
+ other direction nonoperational), but they may not be effective for a
+ bidirectional loopback (i.e., the loopback is placed in both
+ directions of the circuit interface, so as to identify the faulty
+ segment). This is because, unless both ends followed a mitigation
+
+
+
+
+
+Asati, et al. Standards Track [Page 5]
+
+RFC 7527 Enhanced DAD April 2015
+
+
+ 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.
+
+4. The Enhanced DAD Algorithm
+
+ The Enhanced DAD algorithm covers detection of a looped back NS(DAD)
+ message. This document proposes use of a random number in the Nonce
+ Option specified in SEcure Neighbor Discovery (SEND) [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.
+
+4.1. Processing Rules for Senders
+
+ If a node has been configured to use the Enhanced DAD algorithm, when
+ sending an NS(DAD) for a tentative or optimistic interface address,
+ the sender MUST generate a random nonce associated with the interface
+ address, MUST store the nonce internally, and MUST include the nonce
+ in the Nonce option included in the NS(DAD). If the interface does
+ not receive any DAD failure indications within RetransTimer
+ milliseconds (see [RFC4861]) after having sent DupAddrDetectTransmits
+ Neighbor Solicitations, the interface moves the Target Address to the
+ assigned state.
+
+
+
+
+
+
+Asati, et al. Standards Track [Page 6]
+
+RFC 7527 Enhanced DAD April 2015
+
+
+ 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.
+
+4.2. Processing Rules for Receivers
+
+ If the node has been configured to use the Enhanced DAD algorithm and
+ an interface on the node receives any NS(DAD) message where the
+ Target Address matches the interface address (in tentative or
+ optimistic state), the receiver compares the nonce included in the
+ message, with any stored nonce on the receiving interface. If a
+ match is found, the node SHOULD log a system management message,
+ SHOULD update any statistics counter, and MUST drop the received
+ message. If the received NS(DAD) message includes a nonce and no
+ match is found with any stored nonce, the node SHOULD log a system
+ management message for a DAD-failed state and SHOULD update any
+ statistics counter.
+
+4.3. Changes to RFC 4861
+
+ The following text is appended to the Source Address definition in
+ 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.
+
+5. Action to Perform on Detecting a Genuine Duplicate
+
+ As described in the paragraphs above, the nonce can also serve to
+ detect genuine duplicates even when the network has potential for
+ looping back ND messages. When a genuine duplicate is detected, the
+ node follows the manual intervention specified in Section 5.4.5 of
+ [RFC4862]. However, in certain cases, if the genuine duplicate
+
+
+
+Asati, et al. Standards Track [Page 7]
+
+RFC 7527 Enhanced DAD April 2015
+
+
+ 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.
+
+6. Security Considerations
+
+ This document does not improve or reduce the security posture of
+ [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.
+
+7. Normative References
+
+ [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>.
+
+
+
+
+
+Asati, et al. Standards Track [Page 8]
+
+RFC 7527 Enhanced DAD April 2015
+
+
+ [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>.
+
+Acknowledgements
+
+ Thanks (in alphabetical order by first name) to Adrian Farrel, Benoit
+ Claise, Bernie Volz, Brian Haberman, Dmitry Anipko, Eric Levy-
+ Abegnoli, Eric Vyncke, Erik Nordmark, Fred Templin, Hilarie Orman,
+ Jouni Korhonen, Michael Sinatra, Ole Troan, Pascal Thubert, Ray
+ Hunter, Suresh Krishnan, Tassos Chatzithomaoglou, and Tim Chown for
+ their guidance and review of the document. Thanks to Thomas Narten
+ for encouraging this work. Thanks to Steinar Haug and Scott Beuker
+ for describing some of the use cases.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Asati, et al. Standards Track [Page 9]
+
+RFC 7527 Enhanced DAD April 2015
+
+
+Authors' Addresses
+
+ Rajiv Asati
+ Cisco Systems, Inc.
+ 7025 Kit Creek road
+ Research Triangle Park, NC 27709-4987
+ United States
+
+ EMail: rajiva@cisco.com
+ URI: http://www.cisco.com/
+
+
+ Hemant Singh
+ Cisco Systems, Inc.
+ 1414 Massachusetts Ave.
+ Boxborough, MA 01719
+ United States
+
+ Phone: +1 978 936 1622
+ EMail: shemant@cisco.com
+ URI: http://www.cisco.com/
+
+
+ Wes Beebee
+ Cisco Systems, Inc.
+ 1414 Massachusetts Ave.
+ Boxborough, MA 01719
+ United States
+
+ Phone: +1 978 936 2030
+ EMail: wbeebee@cisco.com
+ URI: http://www.cisco.com/
+
+
+ Carlos Pignataro
+ Cisco Systems, Inc.
+ 7200-12 Kit Creek Road
+ Research Triangle Park, NC 27709
+ United States
+
+ EMail: cpignata@cisco.com
+ URI: http://www.cisco.com/
+
+
+
+
+
+
+
+
+
+Asati, et al. Standards Track [Page 10]
+
+RFC 7527 Enhanced DAD April 2015
+
+
+ Eli Dart
+ Lawrence Berkeley National Laboratory
+ 1 Cyclotron Road, Berkeley, CA 94720
+ United States
+
+ EMail: dart@es.net
+ URI: http://www.es.net/
+
+
+ Wesley George
+ Time Warner Cable
+ 13820 Sunrise Valley Drive
+ Herndon, VA 20171
+ United States
+
+ EMail: wesley.george@twcable.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Asati, et al. Standards Track [Page 11]
+