draft-ietf-6man-enhanced-dad-01.txt   draft-ietf-6man-enhanced-dad-02.txt 
Network Working Group R. Asati Network Working Group R. Asati
Internet-Draft H. Singh Internet-Draft H. Singh
Updates: 4862 (if approved) W. Beebee Updates: 4862 (if approved) W. Beebee
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: March 10, 2013 E. Dart Expires: August 9, 2013 E. Dart
Lawrence Berkeley National Lawrence Berkeley National
Laboratory Laboratory
W. George W. George
Time Warner Cable Time Warner Cable
C. Pignataro C. Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
September 6, 2012 February 5, 2013
Enhanced Duplicate Address Detection Enhanced Duplicate Address Detection
draft-ietf-6man-enhanced-dad-01.txt draft-ietf-6man-enhanced-dad-02
Abstract Abstract
Appendix A of the IPv6 Duplicate Address Detection (DAD) document in Appendix A of the IPv6 Duplicate Address Detection (DAD) document in
RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862
does not settle on one specific automated means to detect loopback of does not settle on one specific automated means to detect loopback of
Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several
service provider communities have expressed a need for automated service provider communities have expressed a need for automated
detection of looped backed ND messages used by DAD. This document detection of looped backed ND messages used by DAD. This document
includes mitigation techniques and then outlines the Enhanced DAD includes mitigation techniques and then outlines the Enhanced DAD
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 March 10, 2013. This Internet-Draft will expire on August 9, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Operational Mitigation Options . . . . . . . . . . . . . . . . 4 3. Operational Mitigation Options . . . . . . . . . . . . . . . . 4
3.1. Disable DAD on Interface . . . . . . . . . . . . . . . . . 4 3.1. Disable DAD on Interface . . . . . . . . . . . . . . . . . 5
3.2. Dynamic Disable/Enable of DAD Using Layer 2 Protocol . . . 5 3.2. Dynamic Disable/Enable of DAD Using Layer 2 Protocol . . . 5
3.3. Operational Considerations . . . . . . . . . . . . . . . . 5 3.3. Operational Considerations . . . . . . . . . . . . . . . . 6
4. The Enhanced DAD Algorithm . . . . . . . . . . . . . . . . . . 6 4. The Enhanced DAD Algorithm . . . . . . . . . . . . . . . . . . 6
4.1. General Rules . . . . . . . . . . . . . . . . . . . . . . 7 4.1. General Rules . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Processing Rules for Senders . . . . . . . . . . . . . . . 7 4.2. Processing Rules for Senders . . . . . . . . . . . . . . . 7
4.3. Processing Rules for Receivers . . . . . . . . . . . . . . 7 4.3. Processing Rules for Receivers . . . . . . . . . . . . . . 8
4.4. Impact on SEND . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Impact on SEND . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . 8 4.5. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . 8
5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 8 5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Changes from the -01 version . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Terminology 1. Terminology
o DAD-failed state - Duplication Address Detection failure as o DAD-failed state - Duplication Address Detection failure as
specified in [RFC4862]. Failure also includes if the Target specified in [RFC4862]. Failure also includes if the Target
Address is optimistic. Optimistic DAD is specified in [RFC4429]. Address is optimistic. Optimistic DAD is specified in [RFC4429].
o Looped back message - also referred to as a reflected message. o Looped back message - also referred to as a reflected message.
The message sent by the sender is received by the sender due to The message sent by the sender is received by the sender due to
the network or a Upper Layer Protocol on the sender looping the the network or a Upper Layer Protocol on the sender looping the
skipping to change at page 3, line 47 skipping to change at page 3, line 47
Appendix A of [RFC4862] discusses Loopback Suppression and Duplicate Appendix A of [RFC4862] discusses Loopback Suppression and Duplicate
Address Detection (DAD). However, [RFC4862] does not settle on one Address Detection (DAD). However, [RFC4862] does not settle on one
specific automated means to detect loopback of ND messages used by specific automated means to detect loopback of ND messages used by
DAD. One specific DAD message is a Neighbor Solicitation (NS), DAD. One specific DAD message is a Neighbor Solicitation (NS),
specified in [RFC4861]. The NS is issued by the network interface of specified in [RFC4861]. The NS is issued by the network interface of
an IPv6 node for DAD. Another message involved in DAD is a Neighbor an IPv6 node for DAD. Another message involved in DAD is a Neighbor
Advertisement (NA). The Enhanced DAD algorithm proposed in this Advertisement (NA). The Enhanced DAD algorithm proposed in this
document focuses on detecting an NS looped back to the transmitting document focuses on detecting an NS looped back to the transmitting
interface during the DAD operation. Detecting a looped back NA is of interface during the DAD operation. Detecting a looped back NA is of
no use because no problems with DAD will occur if a node receives a no use because no problems with DAD will occur if a node receives a
looped back NA. Detecting of any other looped back ND messages looped back NA. Detection of any other looped back ND messages
outside of the DAD operation is not critical and thus this document outside of the DAD operation is not critical and thus this document
does not cover such detection. The document also includes a does not cover such detection. The document also includes a
Mitigation section that discusses means already available to mitigate Mitigation section that discusses means already available to mitigate
the loopback problem. the loopback problem.
Recently service providers have reported a DAD loopback problem. Recently, service providers have reported a problem with DAD that is
Loopback testing is underway on a circuit connected to an interface caused by looped back NS messages. The following is a description of
on a router. The interface on the router is enabled for IPv6. The the circumstances under which the problem arises. Loopback testing
interface issues a NS for the IPv6 link-local address DAD. The NS is for troubleshooting purposes is underway on a circuit connected to an
reflected back to the router interface due to the loopback condition interface on a router. The interface on the router is enabled for
of the circuit, and the router interface enters a DAD-failed state. IPv6. The interface issues a NS for the IPv6 link-local address DAD.
In contrast to IPv4, IPv6 will not return to operation on the The NS is reflected back to the router interface due to the loopback
interface when the loopback condition is cleared without manual condition of the circuit, and the router interface enters a DAD-
intervention. failed state. After the circuit troubleshooting has concluded and
the loopback condition is removed, IPv4 will return to operation
without further manual intervention. However, IPv6 will remain in
DAD-failed state until manual intervention on the router restores
IPv6 to operation.
There are other conditions which will also trigger similar problems There are other conditions which will also trigger similar problems
with DAD Loopback. While the following example is not a common with DAD Loopback. While the following example is not a common
configuration, it has occurred in a large service provider network. configuration, it has occurred in a large service provider network.
It is necessary to address it in the proposed solution because the It is necessary to address it in the proposed solution because the
trigger scenario has the potential to cause significant IPv6 service trigger scenario has the potential to cause significant IPv6 service
outages when it does occur. Two broadband modems in the same outages when it does occur. Two broadband modems in the same
location are served by the same service provider and both modems are location are served by the same service provider and both modems are
served by one access concentrator and one layer 3 interface on the served by one access concentrator and one layer 3 interface on the
access concentrator. The two modems have the Ethernet ports of each access concentrator. The two modems have the Ethernet ports of each
skipping to change at page 5, line 37 skipping to change at page 5, line 42
(re-)enable DAD on that interface. (re-)enable DAD on that interface.
This solution requires no protocol changes. This solution SHOULD be This solution requires no protocol changes. This solution SHOULD be
enabled by default, and MUST be a configurable option. enabled by default, and MUST be a configurable option.
This mitigation has several benefits. They are This mitigation has several benefits. They are
1. It leverages layer 2 protocol's built-in loopback detection 1. It leverages layer 2 protocol's built-in loopback detection
capability, if available. capability, if available.
2. It scales better (since it relies on an event-driven), requires 2. It scales better since it relies on an event-driven model which
no additional state, timer etc. This may be a significant requires no additional state or timer. This may be a significant
scaling consideration on devices with hundreds or thousands of scaling consideration on devices with hundreds or thousands of
interfaces that may be in loopback for long periods of time (such interfaces that may be in loopback for long periods of time (such
as while awaiting turn-up or during long-duration intrusive bit as while awaiting turn-up or during long-duration intrusive bit
error rate tests). error rate tests).
3.3. Operational Considerations 3.3. Operational Considerations
The mitigation options discussed in the document do not require the The mitigation options discussed in the document do not require the
devices on both ends of the circuit to support the mitigation devices on both ends of the circuit to support the mitigation
functionality simultaneously, and do not propose any capability functionality simultaneously, and do not propose any capability
negotiation. Suffice to say that the mitigation options are well negotiation. The mitigation options discussed in this document are
effective for the unidirectional loopback. effective for unidirectional circuit or interface loopback (i.e. the
the loopback is placed in one direction on the circuit, rendering the
other direction non-operational).
The mitigation options may not be effective for the bidirectional The mitigation options may not be effective for the bidirectional
loopback (i.e. the loopback is placed in both directions of the loopback (i.e. the loopback is placed in both directions of the
circuit interface, so as to identify the faulty segment) if only one circuit interface, so as to identify the faulty segment) if only one
device followed a mitigation option specified in this document, since device followed a mitigation option specified in this document, since
the other device would follow current behavior and disable IPv6 on the other device would follow current behavior and disable IPv6 on
that interface due to DAD until manual intervention restores it. that interface due to DAD until manual intervention restores it.
This is nothing different from what happens today (without the This is nothing different from what happens today (without the
solutions proposed by this document) in case of unidirectional solutions proposed by this document) in case of unidirectional
skipping to change at page 6, line 26 skipping to change at page 6, line 36
as usual. as usual.
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 the Nonce Option specified in message. The document proposes use of the Nonce Option specified in
the SEND document of [RFC3971]. The nonce is a random number as the SEND document of [RFC3971]. The nonce is a random number as
specified in [RFC3971]. If SEND is enabled on the router and the specified in [RFC3971]. If SEND is enabled on the router and the
router also supports the Enhanced DAD algorithm (specified in this router also supports the Enhanced DAD algorithm (specified in this
document), there is integration with the Enhanced DAD algorithm and document), there is integration with the Enhanced DAD algorithm and
SEND. See more details in the Impact on SEND section. SEND. See more details in the Impact on SEND section. Since a nonce
is used only once, DAD for each IPv6 address of an interface uses a
different nonce.
When the IPv6 network interface issues a NS(DAD) message, the When the IPv6 network interface issues a NS(DAD) message, the
interface includes the Nonce Option in the NS(DAD) message and saves interface includes the Nonce Option in the NS(DAD) message and saves
the nonce in local store. Subsequently if the interface receives an the nonce in local store. Subsequently if the interface receives an
identical NS(DAD) message, the interface logs a system management identical NS(DAD) message, the interface logs a system management
message, updates any statistics counter, and drops the looped back message, updates any statistics counter, and drops the looped back
NS(DAD). If the DupAddrDetectTransmits variable for the interface is NS(DAD). Additionally the interface continues to issue subsequent
greater than one, subsequent NS(DAD) messages for the same Target probes until a termination condition (to be defined) is detected.
Address should be suppressed. If the interface receives a NS(DAD) The DupAddrDetectTransmits value is ignored by the algorithm on
message with a different nonce but TargetAddress matches a tentative detection of a looped back NS(DAD). Note [RFC4861] already
or optimistic address on the interface, the interface logs a DAD- randomizes issuing the first probe and issues up to three probes;
failed system management message, updates any statistics, and behaves note [I-D.ietf-6man-impatient-nud] has intentions to change probe
identical to the behavior specified in [RFC4862] for DAD failure. behavior of [RFC4861]. Additionally, certain networks take a few
minutes to loop back a packet to a sender. Hence a variable is
needed to help the interface decide how long to wait for the DAD
process to complete. For example, [RFC4862] waits for two seconds to
see if any message is received to signal a DAD failure, and if not,
DAD is completed. This document defines a new variable in
WAIT_TIME_LOOPBACK. For example, WAIT_TIME_LOOPBACK is two seconds
for [RFC4862] behavior and five minutes for another network. The
interface also uses an exponentially backoff algorithm (pick one of
several available) to issue probes.
If the interface receives a NS(DAD) message with a different nonce
but TargetAddress matches a tentative or optimistic address on the
interface, the interface logs a DAD-failed system management message,
updates any statistics, and behaves identical to the behavior
specified in [RFC4862] for DAD failure.
Six bytes of random nonce is sufficiently large for nonce collisions. Six bytes of random nonce is sufficiently large for nonce collisions.
However if there is a collision because two nodes generated the same However if there is a collision because two nodes generated the same
random nonce (that are using the same Target address in their random nonce (that are using the same Target address in their
NS(DAD)), then the algorithm will incorrectly detect a looped back NS(DAD)), then the algorithm will incorrectly detect a looped back
NS(DAD) when the NS(DAD) was issued to signal a genuine duplicate. NS(DAD) when the NS(DAD) was issued to signal a genuine duplicate.
Since each looped back NS(DAD) event is logged to system management, Since each looped back NS(DAD) event is logged to system management,
the administrator of the network will have to intervene manually. the administrator of the network will have to intervene manually.
The algorithm is capable of detecting any ND solicitation (NS and The algorithm is capable of detecting any ND solicitation (NS and
skipping to change at page 7, line 22 skipping to change at page 7, line 49
implement detection of looped back NS(DAD) messages during DAD for an implement detection of looped back NS(DAD) messages during DAD for an
interface address. interface address.
4.2. Processing Rules for Senders 4.2. Processing Rules for Senders
If a node has been configured to use the Enhanced DAD algorithm, when If a node has been configured to use the Enhanced DAD algorithm, when
sending a NS(DAD) for a tentative or optimistic interface address the sending a NS(DAD) for a tentative or optimistic interface address the
sender MUST generate a random nonce associated with the interface sender MUST generate a random nonce associated with the interface
address, MUST save the nonce, and MUST include the nonce in the Nonce address, MUST save the nonce, and MUST include the nonce in the Nonce
Option included in the NS(DAD). If a looped back NS(DAD) is detected Option included in the NS(DAD). If a looped back NS(DAD) is detected
by the interface, and if the DupAddrDetectTransmits variable for the by the interface, the interface ignores the DupAddrDetectTransmits
interface is greater than one, subsequent NS(DAD) messages for the and issues subsequent probes forever in an exponential backoff
same Target Address SHOULD be suppressed. transmission until a termination condition is detected.
4.3. Processing Rules for Receivers 4.3. Processing Rules for Receivers
If the node has been configured to use the Enhanced DAD algorithm and If the node has been configured to use the Enhanced DAD algorithm and
an interface on the node receives any NS(DAD) message that matches an interface on the node receives any NS(DAD) message where the
the interface address (in tentative or optimistic state), the target address matches the interface address (in tentative or
receiver compares the nonce in the message with the saved nonce. If optimistic state), the receiver compares the nonce, if any, is
a match is found, the node SHOULD log a system management message, included in the message with any saved nonce on the receiving
SHOULD update any statistics counter, and MUST drop the received interface. If a match is found, the node SHOULD log a system
message. If the received NS(DAD) message includes a nonce and no management message, SHOULD update any statistics counter, and MUST
match is found with the saved nonce, the node SHOULD log a system drop the received message. If the received NS(DAD) message includes
management message for DAD-failed and SHOULD update any statistics a nonce and no match is found with any saved nonce, the node SHOULD
counter. log a system management message for DAD-failed and SHOULD update any
statistics counter. TODO: Define termination condition.
4.4. Impact on SEND 4.4. Impact on SEND
The SEND document uses the Nonce Option in the context of matching an The SEND document uses the Nonce Option in the context of matching an
NA with an NS. However, no text in SEND has an explicit mention of NA with an NS. However, no text in SEND has an explicit mention of
detecting looped back ND messages. If this document updates detecting looped back ND messages. If this document updates
[RFC4862], SEND should be updated to integrate with the Enhanced DAD [RFC4862], SEND should be updated to integrate with the Enhanced DAD
algorithm. A minor update to SEND would be to explicitly mention algorithm. A minor update to SEND would be to explicitly mention
that the nonce in SEND is also used by SEND to detect looped back NS that the nonce in SEND is also used by SEND to detect looped back NS
messages during DAD operations by the node. In a mixed SEND messages during DAD operations by the node. In a mixed SEND
skipping to change at page 9, line 25 skipping to change at page 10, line 4
security issue before a remote node on the link can issue reflected security issue before a remote node on the link can issue reflected
NS(DAD) messages. Again, SEND is recommended for this exploit. NS(DAD) messages. Again, SEND is recommended for this exploit.
7. IANA Considerations 7. IANA Considerations
None. None.
8. Acknowledgements 8. Acknowledgements
Thanks (in alphabetical order by first name) to Dmitry Anipko, Eric Thanks (in alphabetical order by first name) to Dmitry Anipko, Eric
Levy-Abegnoli, Erik Nordmark, Fred Templin, Suresh Krishnan, and Levy-Abegnoli, Erik Nordmark, Fred Templin, Michael Sinatra, Ray
Tassos Chatzithomaoglou for their guidance and review of the Hunter, Suresh Krishnan, and Tassos Chatzithomaoglou for their
document. Thanks to Thomas Narten for encouraging this work. Thanks guidance and review of the document. Thanks to Thomas Narten for
to Steinar Haug and Scott Beuker for describing the use cases. encouraging this work. Thanks to Steinar Haug and Scott Beuker for
describing the use cases.
9. Normative References 9. Normative References
[I-D.ietf-6man-impatient-nud]
Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
Detection is too impatient",
draft-ietf-6man-impatient-nud-05 (work in progress),
October 2012.
[RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991. [RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991.
[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.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
skipping to change at page 10, line 9 skipping to change at page 10, line 39
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, April 2006. for IPv6", RFC 4429, April 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
Appendix A. Changes from the -01 version
1. Changed the algorithm in section 4 and other sections to not
suppress subsequent probes and instead probe forever subject to a
termination condition.
2. Minor edits were made for more clarified text.
Authors' Addresses Authors' Addresses
Rajiv Asati Rajiv Asati
Cisco Systems, Inc. Cisco Systems, Inc.
7025 Kit Creek road 7025 Kit Creek road
Research Triangle Park, NC 27709-4987 Research Triangle Park, NC 27709-4987
USA USA
Email: rajiva@cisco.com Email: rajiva@cisco.com
URI: http://www.cisco.com/ URI: http://www.cisco.com/
 End of changes. 21 change blocks. 
50 lines changed or deleted 90 lines changed or added

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