Internet DRAFT - draft-asati-v6ops-dad-loopback

draft-asati-v6ops-dad-loopback



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]