draft-ietf-6man-enhanced-dad-14.txt   draft-ietf-6man-enhanced-dad-15.txt 
Network Working Group R. Asati Network Working Group R. Asati
Internet-Draft H. Singh Internet-Draft H. Singh
Updates: 4862, 4861, 4429 (if approved) W. Beebee Updates: 4862, 4861, 4429 (if approved) W. Beebee
Intended status: Standards Track C. Pignataro Intended status: Standards Track C. Pignataro
Expires: September 4, 2015 Cisco Systems, Inc. Expires: September 6, 2015 Cisco Systems, Inc.
E. Dart E. Dart
Lawrence Berkeley National Laboratory Lawrence Berkeley National Laboratory
W. George W. George
Time Warner Cable Time Warner Cable
March 3, 2015 March 5, 2015
Enhanced Duplicate Address Detection Enhanced Duplicate Address Detection
draft-ietf-6man-enhanced-dad-14 draft-ietf-6man-enhanced-dad-15
Abstract Abstract
IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are
discussed in Appendix A of RFC4862. That specification mentions a discussed in Appendix A of RFC4862. That specification mentions a
hardware-assisted mechanism to detect looped back DAD messages. If hardware-assisted mechanism to detect looped back DAD messages. If
hardware cannot suppress looped back DAD messages, a software hardware cannot suppress looped back DAD messages, a software
solution is required. Several service provider communities have solution is required. Several service provider communities have
expressed a need for automated detection of looped back Neighbor expressed a need for automated detection of looped back Neighbor
Discovery (ND) messages used by DAD. This document includes Discovery (ND) messages used by DAD. This document includes
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
network interface of an IPv6 node for DAD. Another message involved network interface of an IPv6 node for DAD. Another message involved
in DAD is the Neighbor Advertisement (NA). The Enhanced DAD in DAD is the Neighbor Advertisement (NA). The Enhanced DAD
algorithm specified in this document focuses on detecting an NS algorithm specified in this document focuses on detecting an NS
looped back to the transmitting interface during the DAD operation. looped back to the transmitting interface during the DAD operation.
Detecting a looped back NA does not solve the looped back DAD Detecting a looped back NA does not solve the looped back DAD
problem. Detection of any other looped back ND messages during the problem. Detection of any other looped back ND messages during the
DAD operation is outside the scope of this document. This document DAD operation is outside the scope of this document. This document
also includes a section on Mitigation that discusses means already also includes a section on Mitigation that discusses means already
available to mitigate the DAD loopback problem. This document available to mitigate the DAD loopback problem. This document
updates RFC4861, RFC4862, and RFC4429. This document updates RFC updates RFC4861, RFC4862, and RFC4429. It updates RFC 4862 and RFC
4862 and RFC 4429 to use the enhanced-dad algorithm to detect looped 4429 to use the enhanced-dad algorithm to detect looped back DAD
back DAD probes. The Changes to RFC 4861 section includes an update probes, and RFC4861 as described in Section 4.3 below.
to RFC 4861.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
o DAD-failed state - Duplication Address Detection failure as o DAD-failed state - Duplication Address Detection failure as
skipping to change at page 4, line 7 skipping to change at page 4, line 7
locations along the path of a wide area circuit to help locate a locations along the path of a wide area circuit to help locate a
circuit fault). The Loopback function may be employed locally or circuit fault). The Loopback function may be employed locally or
remotely. remotely.
o NS(DAD) - shorthand notation to denote an Neighbor Solicitation o NS(DAD) - shorthand notation to denote an Neighbor Solicitation
(NS) (as specified in [RFC4861]) with unspecified IPv6 source- (NS) (as specified in [RFC4861]) with unspecified IPv6 source-
address issued during DAD. address issued during DAD.
2. Problem Statement 2. Problem Statement
Recently, service providers have reported a problem with DAD that Service providers have reported a problem with DAD that arises in a
arises under the following sets of circumstances: In the first, few scenarios. In the first scenario, loopback testing for
loopback testing for troubleshooting purposes is underway on a troubleshooting purposes is underway on a circuit connected to an
circuit connected to an IPv6-enabled interface on a router. The IPv6-enabled interface on a router. The interface issues a NS for
interface issues a NS for the IPv6 link-local address DAD. The NS is the IPv6 link-local address DAD. The NS is reflected back to the
reflected back to the router interface due to the loopback condition router interface due to the loopback condition of the circuit, and
of the circuit, and the router interface enters a DAD-failed state. the router interface enters a DAD-failed state. After the loopback
After the loopback condition is removed, IPv4 will return to condition is removed, IPv4 will return to operation without further
operation without further manual intervention. However, IPv6 will manual intervention. However, IPv6 will remain in DAD-failed state
remain in DAD-failed state until manual intervention on the router until manual intervention on the router restores IPv6 to operation.
restores IPv6 to operation. In the second scenario, two broadband
modems are served by the same service provider and terminate to the In the second scenario, two broadband modems are served by the same
same layer-3 interface on an IPv6-enabled access concentrator. In service provider and terminate to the same layer-3 interface on an
this case, the two modems' Ethernet interfaces are also connected to IPv6-enabled access concentrator. In this case, the two modems'
a common local network (collision domain). The access concentrator Ethernet interfaces are also connected to a common local network
serving the modems is the first-hop IPv6 router for the modems and (collision domain). The access concentrator serving the modems is
issues a NS(DAD) message for the IPv6 link-local address of its the first-hop IPv6 router for the modems and issues a NS(DAD) message
layer-3 interface. The NS message reaches one modem first and this for the IPv6 link-local address of its layer-3 interface. The NS
modem sends the message to the local network, where the second modem message reaches one modem first and this modem sends the message to
receives the message and then forwards it back to the access the local network, where the second modem receives the message and
concentrator. The looped back NS message causes the network then forwards it back to the access concentrator. The looped back NS
interface on the access concentrator to be in a DAD-failed state. message causes the network interface on the access concentrator to be
Such a network interface typically serves thousands of broadband in a DAD-failed state. Such a network interface typically serves
modems, and all would have their IPv6 connectivity affected until the thousands of broadband modems, and all would have their IPv6
DAD-failed state is cleared. Additionally, it may be difficult for connectivity affected until the DAD-failed state is cleared.
the user of the access concentrator to determine the source of the Additionally, it may be difficult for the user of the access
looped back DAD message. Thus in order to avoid IPv6 outages that concentrator to determine the source of the looped back DAD message.
can potentially affect multiple users, there is a need for automated Thus in order to avoid IPv6 outages that can potentially affect
detection of looped back NS messages during DAD operations by a node. 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 Note: In both examples above, the IPv6 link-local address DAD
operation fails due to a looped back DAD probe. However, the problem 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 of a looped back DAD probe exists for any IPv6 address type including
global addresses. global addresses.
3. Operational Mitigation Options 3. Operational Mitigation Options
Two mitigation options are described below that do not require any Two mitigation options are described below that do not require any
change to existing implementations. change to existing implementations.
skipping to change at page 5, line 8 skipping to change at page 5, line 9
3.1. Disable DAD on an Interface 3.1. Disable DAD on an Interface
One can disable DAD on an interface so that there are no NS(DAD) One can disable DAD on an interface so that there are no NS(DAD)
messages issued. While this mitigation may be the simplest, the messages issued. While this mitigation may be the simplest, the
mitigation has three drawbacks: 1) care is needed when making such mitigation has three drawbacks: 1) care is needed when making such
configuration changes on point-to-point interfaces, 2) this is a one- configuration changes on point-to-point interfaces, 2) this is a one-
time manual configuration on each interface, and 3) genuine time manual configuration on each interface, and 3) genuine
duplicates on the link will not be detected. duplicates on the link will not be detected.
A Service Provider router, such as an access concentrator, or network 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 3.2. Dynamic Disable/Enable of DAD Using Layer-2 Protocol
Some layer-2 protocols include provisions to detect the existence of Some layer-2 protocols include provisions to detect the existence of
a loopback on an interface circuit, usually by comparing protocol a loopback on an interface circuit, usually by comparing protocol
data sent and received. For example, the Point-to-Point 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 (PPP) uses a magic number (section 6.4 of [RFC1661]) to detect a
loopback on an interface. loopback on an interface.
When a layer-2 protocol detects that a loopback is present on an When a layer-2 protocol detects that a loopback is present on an
skipping to change at page 5, line 31 skipping to change at page 5, line 32
present (or the interface state has changed), the device MUST present (or the interface state has changed), the device MUST
(re-)enable DAD on that interface. (re-)enable DAD on that interface.
This mitigation has several benefits. It leverages the layer-2 This mitigation has several benefits. It leverages the layer-2
protocol's built-in loopback detection capability, if available. It protocol's built-in loopback detection capability, if available. It
scales better since it relies on an event-driven model which requires scales better since it relies on an event-driven model which requires
no additional state or timer. This may be significant on devices no additional state or timer. This may be significant on devices
with hundreds or thousands of interfaces that may be in loopback for with hundreds or thousands of interfaces that may be in loopback for
long periods of time (e.g., awaiting turn-up). long periods of time (e.g., awaiting turn-up).
This solution SHOULD be enabled by default, and MUST be a Detecting looped back DAD messages using a layer-2 protocol SHOULD be
configurable option if the layer-2 technology provides means for enabled by default, and MUST be a configurable option if the layer-2
detecting loopback messages on an interface circuit. technology provides means for detecting loopback messages on an
interface circuit.
3.3. Operational Considerations 3.3. Operational Considerations
The mitigation options discussed above do not require the devices on The mitigation options discussed above do not require the devices on
both ends of the circuit to support the mitigation functionality both ends of the circuit to support the mitigation functionality
simultaneously, and do not propose any capability negotiation. They simultaneously, and do not propose any capability negotiation. They
are effective for unidirectional circuit or interface loopback (i.e. are effective for unidirectional circuit or interface loopback (i.e.
the the loopback is placed in one direction on the circuit, rendering the loopback is placed in one direction on the circuit, rendering the
the other direction non-operational), but they may not be effective other direction non-operational), but they may not be effective for a
for a bidirectional loopback (i.e. the loopback is placed in both bidirectional loopback (i.e. the loopback is placed in both
directions of the circuit interface, so as to identify the faulty directions of the circuit interface, so as to identify the faulty
segment). This is because unless both ends followed a mitigation segment). This is because unless both ends followed a mitigation
option specified in this document, the non-compliant device would option specified in this document, the non-compliant device would
follow current behavior and disable IPv6 on that interface due to DAD follow current behavior and disable IPv6 on that interface due to DAD
until manual intervention restores it. until manual intervention restores it.
4. The Enhanced DAD Algorithm 4. The Enhanced DAD Algorithm
The Enhanced DAD algorithm covers detection of a looped back NS(DAD) The Enhanced DAD algorithm covers detection of a looped back NS(DAD)
message. The document proposes use of a random number in the Nonce message. The document proposes use of a random number in the Nonce
skipping to change at page 8, line 38 skipping to change at page 8, line 38
reflected NS(DAD) messages. Again, SEND is recommended for this reflected NS(DAD) messages. Again, SEND is recommended for this
exploit. Source Address Validation Improvement (SAVI) [RFC6620] also exploit. Source Address Validation Improvement (SAVI) [RFC6620] also
protects against various attacks by on-link rogues. protects against various attacks by on-link rogues.
7. IANA Considerations 7. IANA Considerations
None. None.
8. Acknowledgements 8. Acknowledgements
Thanks (in alphabetical order by first name) to Bernie Volz, Brian Thanks (in alphabetical order by first name) to Adrian Farrel, Benoit
Haberman, Dmitry Anipko, Eric Levy-Abegnoli, Eric Vyncke, Erik Claise, Bernie Volz, Brian Haberman, Dmitry Anipko, Eric Levy-
Nordmark, Fred Templin, Hilarie Orman, Jouni Korhonen, Michael Abegnoli, Eric Vyncke, Erik Nordmark, Fred Templin, Hilarie Orman,
Sinatra, Ole Troan, Pascal Thubert, Ray Hunter, Suresh Krishnan, and Jouni Korhonen, Michael Sinatra, Ole Troan, Pascal Thubert, Ray
Tassos Chatzithomaoglou for their guidance and review of the Hunter, Suresh Krishnan, Tassos Chatzithomaoglou, and Tim Chown for
document. Thanks to Thomas Narten for encouraging this work. Thanks their guidance and review of the document. Thanks to Thomas Narten
to Steinar Haug and Scott Beuker for describing the use cases. for encouraging this work. Thanks to Steinar Haug and Scott Beuker
for describing some of the use cases.
9. Normative References 9. Normative References
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
 End of changes. 10 change blocks. 
51 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/