V6ops Working Group Rajiv Asati Internet Draft Cisco Intended status: Standards Track (Updates RFC4862) Expires: April 4, 2012 Eli Dart ESnet Wesley George Time Warner Cable Carlos Pignataro Cisco October 4, 2011 IPv6 DAD Enhancements for handling Layer1 Loopbacks draft-asati-v6ops-dad-loopback-01 Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 March 4, 2012. Copyright Notice Copyright (c) 2011 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 Asati, et. al Expires April 4, 2012 [Page 1] Internet-Draft draft-asati-v6ops-dad-loopback October 4, 2011 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. Abstract It is a common practice to install a (soft or hard) loopback on a circuit interface for various purposes (e.g. circuit turn-up test). However, this practice results in disabling IPv6 on an interface even after the loopback is removed, due to the way IPv6 duplicate address detection is performed. This document describes a mechanism to allow IPv6 to self-heal after such a loopback is placed & removed. Table of Contents 1. Introduction...................................................3 2. Specification Language.........................................3 3. DAD Loopback Solution..........................................4 3.1. Solution 1 - Static Configuration.........................4 3.2. Solution 2 - Dynamic Logic - Protocol Modification........5 3.3. Solution 3 - Dynamic Logic - Implementation Specific Modification...................................................6 4. IANA Considerations............................................6 5. Security Considerations........................................6 6. Acknowledgments................................................6 7. Appendix.......................................................7 7.1. Use Case #1...............................................7 7.2. Use Case #2...............................................7 8. References.....................................................7 8.1. Normative References......................................7 8.2. Informative References....................................8 Author's Addresses................................................8 Asati, et. al Expires April 4, 2012 [Page 2] Internet-Draft draft-asati-v6ops-dad-loopback October 4, 2011 1. Introduction One of the common fault-isolation practices in network operations is to install a (soft or hard) loopback on a circuit interface for troubleshooting physical/transport layer (layer1) issues. However, this practice may jeopardize IPv6 [RFC4291] functionality of an interface (corresponding to the circuit being looped) after the loopback is removed. This is because the loopback results in the router to receive the messages such as the ones relating to IPv6 Duplicate Address Detection [RFC4862], and consequently disable IPv6 on that interface, due to DAD check failure per [RFC4862] section 5.4.5. When the (soft) loopback is removed (note that removing soft loop, unlike hard loop, does not result in the interface status changes), the interface stays UP, and IPv6 functionality stays disabled. The only way to fix this is by the manual intervention (e.g. manually assign an IPv6 link-local address on that interface and then remove it, resulting in DAD to be triggered and enabling IPv6 on that interface). On the other hand, IPv4 continues to function fine after the loopback is removed (partly because IPv4 does not have DAD like procedure) with or without the 'warning' about duplicate IPv4 address when the loopback existed. This problem is built-into IPv6 DAD and needs to be fixed so as to simplify IPv6-provisioned interfaces turn-up and maintenance afterwards. This document describes a mechanism to allow IPv6 to self-heal after the physical/transport layer looping of the interface. The fix is intended to be a simple extension to the ND/DAD logic itself without requiring any new messages. This document is intended to update RFC4862. 2. Specification 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]. It uses the following abbreviations: Asati, et. al Expires April 4, 2012 [Page 3] Internet-Draft draft-asati-v6ops-dad-loopback October 4, 2011 DAD - Duplicate Address Detection ND - Neighbor Discovery NS - Neighbor Solicitation Loopback - A function in which the router's interface to the network is looped back, resulting in interface unavailablity for regular data traffic forwarding. This definition is in with that of [RFC1247]. Loopback function is commonly used to gain information on the quality of this interface, by employing mechanisms such as ICMP pings, bit-error test etc. Loopback function may be done locally or remotely. Loop - Same as Loopback. Soft loopback - Loopback function may be done in software. This doesn't result in interface line protocol going down. Hard loopback - Loopback function may be done in hardware. This does result in interface line protocol going down. This document uses 'loop' and 'loopback' terms interchangeably to mean 'loopback' function. 3. DAD Loopback Solution There are three options for solving the issue described in section 1. 3.1. Solution 1 - Static Configuration One may simply disable DAD on an interface and avoid the problem described in section 1 altogether. One way to disable DAD is set interface's DupAddrDetectTransmits variable to zero, as described in section 5.1 of [RFC4862]. Asati, et. al Expires April 4, 2012 [Page 4] Internet-Draft draft-asati-v6ops-dad-loopback October 4, 2011 While this Solution may be the simplest and well suited for certain point-to-point interfaces, it has three drawbacks - 1. Classification of such point-to-point interfaces, 2. A one-time manual configuration on each of such interfaces, and 3. More importantly, potential IPv6 brokenness if the other side of the router got misconfigured with the same IPv6 address (since there wouldn't be any DAD to catch such errors). Nonetheless, an implementation may still provide this solution. 3.2. Solution 2 - Dynamic Logic - Protocol Modification This solution option expands DAD with a logic (enabled by default) to make IPv6 self-healing after the loopback is removed, without requiring any manual intervention. If an IPv6 node receives an IPv6 NS message, corresponding to DAD [RFC4862], having the same source link-layer address and same IPv6 address (in Target Address field) as the one (to be) assigned to the receiving interface, then the IPv6 node must execute the following logic: 1. Log the duplicate IP address & the interface 2. Send another NS message (for DAD) with a Nonce option (section 5.3.2 of [RFC3971]), and fire up the timer 3. If the same NS message (as the one transmitted) is received, then keep IPv6 enabled on that interface 4. If the timer expires, then go back to step 2 5. If the same NS message (as the one transmitted) is not received (upon timer expiry), then enforce DAD criteria as per [RFC4862] for keeping IPv6 enabled (or disabled) on that interface The timer value is 60 seconds by default, but an implementation may allow a configurable option to override the default value. If the interface state goes DOWN in between any steps, then the logic is exited and IPv6 is re-initialized on that interface for DAD. Please note that the Nonce option is included in the NS message just to detect the NS message being looped (e.g. there is a loopback on the interface). If the remote router happens to receive such an NS message, then it MUST silently ignore the Nonce option. The Nonce value MUST be unique in each NS message being sent in the logic above. Asati, et. al Expires April 4, 2012 [Page 5] Internet-Draft draft-asati-v6ops-dad-loopback October 4, 2011 This solution simply paves the way for re-running DAD after detecting the loopback has been removed, and ultimately enabling IPv6 on an interface. Suffice to say that this option is preferred and it requires no new message or option. 3.3. Solution 3 - Dynamic Logic - Implementation Specific Modification It is possible that an implementation could somehow detect the existence of a (hard or soft) loopback on an interface. It is also possible that a layer2 protocol such as PPP using magic number (section 6.4 of [RFC1661]) may be capable of detecting the loopback on an interface. This solution option suggests that any implementation, upon detecting that loopback being installed on an interface, disable DAD on that interface, and upon detecting that the loopback being removed, enable DAD on that interface. One way to disable DAD is set interface's DupAddrDetectTransmits variable to zero, as described in section 5.1 of [RFC4862]. This solution is specific i.e. internal to any implementation, hence, requires no protocol changes. 4. IANA Considerations None. 5. Security Considerations None. 6. Acknowledgments This document was produced based on the active discussion on v6ops mailing list. Thanks to Thomas Marten for encouraging us to write this draft. Thanks to Steinar Haug and Scott Beuker for describing the use cases, and to Fred Templin for suggesting the reusage of Nonce option. Asati, et. al Expires April 4, 2012 [Page 6] Internet-Draft draft-asati-v6ops-dad-loopback October 4, 2011 Thanks to George Wesley, and Hemant Singh for providing constructive feedback. This document was prepared using 2-Word-v2.0.template.dot. 7. Appendix 7.1. Use Case #1 A network operator turns up the circuit (i.e. interface) for the 1st time. And it installs the loopback on that interface for initial checks and removes it afterwards. This results in IPv4 working fine, but IPv6 staying disabled (as described in section 1). 7.2. Use Case #2 A network operator installs a loopback on a working circuit (i.e. interface) for layer1 troubleshooting and removes it afterwards. This results in IPv4 working fine, but IPv6 staying disabled (as described in section 1). 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 4291, February 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and Soliman, H., "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and Jinmei, T., "IPv6 Stateless Address Architecture", RFC 4862, September 2007. Asati, et. al Expires April 4, 2012 [Page 7] Internet-Draft draft-asati-v6ops-dad-loopback October 4, 2011 8.2. Informative References [RFC4941] Narten, T., Draves, R., and Krishnan, S., "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1661, July 1994. [RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991. Author's Addresses Rajiv Asati Cisco Systems, Inc. 7025 Kit Creek Road Research Triangle Park, NC 27709-4987 Email: rajiva@cisco.com Eli Dart ESnet Network Engineering Group Lawrence Berkeley National Laboratory ??????? Email: dart@es.net Asati, et. al Expires April 4, 2012 [Page 8]