--- 1/draft-ietf-6man-enhanced-dad-14.txt 2015-03-05 11:14:35.481651654 -0800 +++ 2/draft-ietf-6man-enhanced-dad-15.txt 2015-03-05 11:14:35.505652246 -0800 @@ -1,24 +1,24 @@ Network Working Group R. Asati Internet-Draft H. Singh Updates: 4862, 4861, 4429 (if approved) W. Beebee Intended status: Standards Track C. Pignataro -Expires: September 4, 2015 Cisco Systems, Inc. +Expires: September 6, 2015 Cisco Systems, Inc. E. Dart Lawrence Berkeley National Laboratory W. George Time Warner Cable - March 3, 2015 + March 5, 2015 Enhanced Duplicate Address Detection - draft-ietf-6man-enhanced-dad-14 + draft-ietf-6man-enhanced-dad-15 Abstract 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. Several service provider communities have expressed a need for automated detection of looped back Neighbor Discovery (ND) messages used by DAD. This document includes @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 4, 2015. + This Internet-Draft will expire on September 6, 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 @@ -94,24 +94,23 @@ 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 RFC4861, RFC4862, and RFC4429. This document updates RFC - 4862 and RFC 4429 to use the enhanced-dad algorithm to detect looped - back DAD probes. The Changes to RFC 4861 section includes an update - to RFC 4861. + updates RFC4861, RFC4862, and RFC4429. It updates RFC 4862 and RFC + 4429 to use the enhanced-dad algorithm to detect looped back DAD + probes, and RFC4861 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 @@ -139,49 +138,50 @@ 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 an Neighbor Solicitation (NS) (as specified in [RFC4861]) with unspecified IPv6 source- address issued during DAD. 2. Problem Statement - Recently, service providers have reported a problem with DAD that - arises under the following sets of circumstances: In the first, - loopback testing for troubleshooting purposes is underway on a - circuit connected to an IPv6-enabled interface on a router. The - interface issues a 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. + 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 a 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. @@ -189,21 +189,21 @@ 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 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 this mitigation strategy. + 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 @@ -212,33 +212,34 @@ 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 loopback detection capability, if available. It scales better since it relies on an event-driven model which 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). - This solution SHOULD be enabled by default, and MUST be a - configurable option if the layer-2 technology provides means for - detecting loopback messages on an interface circuit. + Detecting looped back DAD messages using a layer-2 protocol SHOULD be + enabled by default, and 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 the loopback is placed in one direction on the circuit, rendering - the other direction non-operational), but they may not be effective - for a bidirectional loopback (i.e. the loopback is placed in both + the loopback is placed in one direction on the circuit, rendering the + other direction non-operational), 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 option specified in this document, the non-compliant 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. The document proposes use of a random number in the Nonce @@ -361,27 +362,28 @@ 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. IANA Considerations None. 8. Acknowledgements - Thanks (in alphabetical order by first name) to 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, and - Tassos Chatzithomaoglou 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 the use cases. + 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. 9. Normative References [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.