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]