V6ops Working Group Rajiv Asati Internet Draft Cisco Intended status: Standards Track (Updates RFC4862) Expires: February 24, 2012 Eli Dart ESnet August 24, 2011 IPv6 DAD Enhancements for handling Layer1 Loopbacks draft-asati-v6ops-dad-loopback-00 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 February 24, 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 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. Asati, et. al Expires February 24, 2012 [Page 1] Internet-Draft draft-asati-v6ops-dad-loopback August 24, 2011 Abstract It is a common practice to install a (soft or hard) loop 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 loop 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 loop is placed & removed. Table of Contents 1. Introduction...................................................2 2. Specification Language.........................................3 3. Solution.......................................................4 3.1. Solution 1 - Static Configuration.........................4 3.2. Solution 2 - Dynamic Logic................................4 4. IANA Considerations............................................5 5. Security Considerations........................................5 6. Acknowledgments................................................5 7. Appendix.......................................................6 7.1. Use Case #1...............................................6 7.2. Use Case #2...............................................6 8. References.....................................................6 8.1. Normative References......................................6 8.2. Informative References....................................6 Author's Addresses................................................7 1. Introduction One of the common fault-isolation practices in network operations is to install a (soft or hard) loop on a circuit interface for troubleshooting physical/transport layer (layer1) issues. Asati, et. al Expires February 24, 2012 [Page 2] Internet-Draft draft-asati-v6ops-dad-loopback August 24, 2011 However, this practice may jeopardize IPv6 [RFC4291] functionality of an interface (corresponding to the circuit being looped) after the loop is removed. This is because the loop 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) loop 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 loop is removed (partly because IPv4 does not have DAD like procedure) with or without the 'warning' about duplicate IPv4 address when the loop 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]. Abbreviations: DAD - Duplicate Address Detection ND - Neighbor Discovery NS - Neighbor Solicitation Asati, et. al Expires February 24, 2012 [Page 3] Internet-Draft draft-asati-v6ops-dad-loopback August 24, 2011 3. Solution There are two methods for solving this issue. 3.1. Solution 1 - Static Configuration One may simply disable DAD on an interface and avoid the problem described in section 1 altogether. While this Solution may be the simplest and well suited for certain point-to-point interfaces, it has three drawbacks - 1. it would likely require carefully figuring out such point-to- point interfaces, 2. a one-time manual configuration on each of such interfaces, and 3. more importantly, it would likely result in 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 as the lowest hanging fruit. 3.2. Solution 2 - Dynamic Logic This solution option expands DAD with a logic (that will stay enabled by default) to make IPv6 self-healing without requiring any manual configuration. In this, If an IPv6 node receives an IPv6 NS message corresponding to DAD [RFC4862] and having the same source link-layer address and same IPv6 address (in Target Address field) as the ones (to be) assigned to the receiving interface, then the IPv6 node must do the following: 1. Log the duplicate address & the interface (or generate a warning) 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 Asati, et. al Expires February 24, 2012 [Page 4] Internet-Draft draft-asati-v6ops-dad-loopback August 24, 2011 5. If the same NS message (as the one transmitted) is not received (upon timer expiry), then enforce DAD criteria [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. Please note that the Nonce option is included in the NS message just to detect the NS message being looped. If the remote router happens to receive such an NS message, then it MUST silently ignore the Nonce option. This solution simply paves the way for re-running DAD after detecting the loop 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. 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 this draft. Thanks to Steinar Haug and Scott Beuker for describing the use cases. This document was prepared using 2-Word-v2.0.template.dot. Asati, et. al Expires February 24, 2012 [Page 5] Internet-Draft draft-asati-v6ops-dad-loopback August 24, 2011 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 loop 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 loop 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. 8.2. Informative References [RFC4941] Narten, T., Draves, R., and Krishnan, S., "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. Asati, et. al Expires February 24, 2012 [Page 6] Internet-Draft draft-asati-v6ops-dad-loopback August 24, 2011 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 February 24, 2012 [Page 7]