draft-ietf-6man-enhanced-dad-03.txt   draft-ietf-6man-enhanced-dad-04.txt 
Network Working Group R. Asati Network Working Group R. Asati
Internet-Draft H. Singh Internet-Draft H. Singh
Updates: 4862, 4861 (if approved) W. Beebee Updates: 4862, 4861 (if approved) W. Beebee
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: November 25, 2013 E. Dart Expires: May 08, 2014 E. Dart
Lawrence Berkeley National Laboratory Lawrence Berkeley National Laboratory
W. George W. George
Time Warner Cable Time Warner Cable
C. Pignataro C. Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
May 24, 2013 November 04, 2013
Enhanced Duplicate Address Detection Enhanced Duplicate Address Detection
draft-ietf-6man-enhanced-dad-03 draft-ietf-6man-enhanced-dad-04
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 48 skipping to change at page 1, line 48
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 November 25, 2013. This Internet-Draft will expire on May 08, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . 8 4.4. Impact on SEND . . . . . . . . . . . . . . . . . . . . . 8
4.5. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . 8 4.5. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . 8
4.6. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 8 4.6. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 9
5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 9 5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . 10 9. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 16 skipping to change at page 3, line 16
circuit to which the router's interface is connected) is looped circuit to which the router's interface is connected) is looped
back or connected to itself. Loopback causes packets sent by the back or connected to itself. Loopback causes packets sent by the
interface to be received by the interface, and results in interface to be received by the interface, and results in
interface unavailability for regular data traffic forwarding. See interface unavailability for regular data traffic forwarding. See
more details in section 9.1 of [RFC1247]. The Loopback function more details in section 9.1 of [RFC1247]. The Loopback function
is commonly used in an interface context to gain information on is commonly used in an interface context to gain information on
the quality of the interface, by employing mechanisms such as the quality of the interface, by employing mechanisms such as
ICMPv6 pings, bit-error tests, etc. In a circuit context, it is ICMPv6 pings, bit-error tests, etc. In a circuit context, it is
used in wide area environments including optical dense wave used in wide area environments including optical dense wave
division multiplexing (DWDM) and SONET/SDH for fault isolation division multiplexing (DWDM) and SONET/SDH for fault isolation
(e.g. by placing a loopback at different geographic locations (e.g. by placing a loopback at different geographic locations
along the path of a wide area circuit to help locate a circuit along the path of a wide area circuit to help locate a circuit
fault). The Loopback function may be employed locally or 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) with unspecified IPv6 source-address issued during DAD. (NS) with unspecified IPv6 source-address issued during DAD.
2. Introduction 2. Introduction
Appendix A of [RFC4862] discusses Loopback Suppression and Duplicate Appendix A of [RFC4862] discusses Loopback Suppression and Duplicate
skipping to change at page 5, line 43 skipping to change at page 5, line 43
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. The mitigation options discussed in this document are negotiation. The mitigation options discussed in this document are
effective for unidirectional circuit or interface loopback (i.e. the effective for unidirectional circuit or interface loopback (i.e. the
the loopback is placed in one direction on the circuit, rendering the the loopback is placed in one direction on the circuit, rendering the
other direction non-operational). 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
loopback. Hence, it is expected that an operator would resort to loopback. Hence, it is expected that an operator would resort to
manual intervention for the devices not compliant with this document, manual intervention for the devices not compliant with this document,
as usual. as usual.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
is used only once, DAD for each IPv6 address of an interface uses a is used only once, DAD for each IPv6 address of an interface uses a
different nonce. different nonce.
The interface follows [RFC4862] behavior by issuing The interface follows [RFC4862] behavior by issuing
DupAddrDetectTransmits (see [RFC4862]) probes spaced RetransTimer DupAddrDetectTransmits (see [RFC4862]) probes spaced RetransTimer
(see [RFC4861]) apart. When the IPv6 network interface issues a (see [RFC4861]) apart. When the IPv6 network interface issues a
NS(DAD) message, the interface includes the Nonce Option in the NS(DAD) message, the interface includes the Nonce Option in the
NS(DAD) message and saves the nonce in local store. Subsequently if NS(DAD) message and saves the nonce in local store. Subsequently if
the interface receives an identical NS(DAD) message, the interface the interface receives an identical NS(DAD) message, the interface
logs a system management message, updates any statistics counter, logs a system management message, updates any statistics counter,
drops the looped back NS(DAD), and moves the Target Address to drops the looped back NS(DAD). If any probe is looped back within
assigned state. If any probe is looped back within RetransTimer RetransTimer milliseconds after having sent DupAddrDetectTransmits
milliseconds after having sent DupAddrDetectTransmits NS(DAD) NS(DAD) messages, the interface continues with another
messages, the interface continues with another MAX_MULTICAST_SOLICIT MAX_MULTICAST_SOLICIT number of NS(DAD) messages spaced RetransTimer
number of NS(DAD) messages spaced RetransTimer apart. If no probe is apart. If no probe is looped back within RetransTimer milliseconds
looped back within RetransTimer milliseconds after after MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, the probing
MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, the probing stops stops else a new MAX_MULTICAST_SOLICIT number of NS(DAD) messages
else a new MAX_MULTICAST_SOLICIT number of NS(DAD) messages sequence sequence is initiated. The MAX_MULTICAST_SOLICIT number of NS(DAD)
is initiated. The MAX_MULTICAST_SOLICIT number of NS(DAD) messages messages sequence continues until the stop condition is reached. The
sequence continues until the stop condition is reached. The
RetransTimer may be overidden by a link-specific document if a node RetransTimer may be overidden by a link-specific document if a node
supports the Enhanced DAD algorithm. Note supports the Enhanced DAD algorithm. Note
[I-D.ietf-6man-impatient-nud] has intentions to change probe behavior [I-D.ietf-6man-impatient-nud] has intentions to change probe behavior
of [RFC4861]. The RetransTimer value may be overridden by a link- of [RFC4861].
type specific document.
If the interface receives a NS(DAD) message with a different nonce If the interface receives a NS(DAD) message with a different nonce
but the Target Address matches a tentative or optimistic address on but the Target Address matches a tentative or optimistic address on
the interface, the interface logs a DAD-failed system management the interface, the interface logs a DAD-failed system management
message, updates any statistics, and behaves identical to the message, updates any statistics, and behaves identical to the
behavior specified in [RFC4862] for DAD failure. 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 that are using the
random nonce (that are using the same Target Address in their same Target Address in their NS(DAD) generated the same random nonce,
NS(DAD)), then the algorithm will incorrectly detect a looped back then the algorithm will incorrectly detect a looped back NS(DAD) when
NS(DAD) when the NS(DAD) was issued to signal a genuine duplicate. a genuine address collision has occurred. Since each looped back
Since each looped back NS(DAD) event is logged to system management, NS(DAD) event is logged to system management, the administrator of
the administrator of the network will have to intervene manually. the network will have access to the information necessary to
intervene manually. Also, because the nodes will have detected what
appear to be looped back NS(DAD) messages, they will continue to
probe and it is unlikely that they will choose the same nonce the
second time (assuming quality random number generators).
The algorithm is capable of detecting any ND solicitation (NS and The algorithm is capable of detecting any ND solicitation (NS and
Router Solicitation) or advertisement (NA and Router Advertisement) Router Solicitation) or advertisement (NA and Router Advertisement)
that is looped back. However, saving a nonce and nonce related data that is looped back. However, saving a nonce and nonce related data
for all ND messages has impact on memory of the node and also adds for all ND messages has impact on memory of the node and also adds
the algorithm state to a substantially larger number of ND messages. the algorithm state to a substantially larger number of ND messages.
Therefore this document does not recommend using the algorithm Therefore this document does not recommend using the algorithm
outside of the DAD operation by an interface on a node. outside of the DAD operation by an interface on a node.
4.1. General Rules 4.1. General Rules
skipping to change at page 7, line 33 skipping to change at page 7, line 33
If an IPv6 node implements the Enhanced DAD algorithm, the node MUST If an IPv6 node implements the Enhanced DAD algorithm, the node MUST
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 any probe is looped back within Option included in the NS(DAD). If the interface does not receive
RetransTimer milliseconds after having sent DupAddrDetectTransmits any DAD failure indications within RetransTimer milliseconds after
NS(DAD) messages, the interface continues with another having sent DupAddrDetectTransmits Neighbor Solicitations, the
MAX_MULTICAST_SOLICIT number of NS(DAD) messages spaced RetransTimer interface moves the Target Address to assigned state. If any probe
apart. If no probe is looped back within RetransTimer milliseconds is looped back within RetransTimer milliseconds after having sent
after MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, the probing DupAddrDetectTransmits NS(DAD) messages, the interface continues with
stops else a new MAX_MULTICAST_SOLICIT number of NS(DAD) messages another MAX_MULTICAST_SOLICIT number of NS(DAD) messages spaced
sequence is initiated. The MAX_MULTICAST_SOLICIT number of NS(DAD) RetransTimer apart. If no probe is looped back within RetransTimer
messages sequence continues until the stop condition is reached. milliseconds after MAX_MULTICAST_SOLICIT NS(DAD) messages are sent,
the probing stops else a new MAX_MULTICAST_SOLICIT number of NS(DAD)
messages sequence is initiated. The MAX_MULTICAST_SOLICIT number of
NS(DAD) messages sequence continues until the stop condition is
reached.
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 where the an interface on the node receives any NS(DAD) message where the
Target Address matches the interface address (in tentative or Target Address matches the interface address (in tentative or
optimistic state), the receiver compares the nonce, if any, is optimistic state), the receiver compares the nonce, if any, is
included in the message with any saved nonce on the receiving included in the message with any saved nonce on the receiving
interface. If a match is found, the node SHOULD log a system interface. If a match is found, the node SHOULD log a system
management message, SHOULD update any statistics counter, MUST drop management message, SHOULD update any statistics counter, MUST drop
the received message, and move the Target Address to assigned state. the received message. If the received NS(DAD) message includes a
nonce and no match is found with any saved nonce, the node SHOULD log
If the received NS(DAD) message includes a nonce and no match is a system management message for DAD-failed and SHOULD update any
found with any saved nonce, the node SHOULD log a system management statistics counter. If the interface does not receive any DAD
message for DAD-failed and SHOULD update any statistics counter. failure indications within RetransTimer milliseconds after having
sent DupAddrDetectTransmits Neighbor Solicitations, the interface
moves the Target Address to assigned state.
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 10, line 12 skipping to change at page 10, line 32
Troan, Ray Hunter, Suresh Krishnan, and Tassos Chatzithomaoglou for Troan, Ray Hunter, Suresh Krishnan, and Tassos Chatzithomaoglou for
their guidance and review of the document. Thanks to Thomas Narten their guidance and review of the document. Thanks to Thomas Narten
for encouraging this work. Thanks to Steinar Haug and Scott Beuker for encouraging this work. Thanks to Steinar Haug and Scott Beuker
for describing the use cases. for describing the use cases.
9. Normative References 9. Normative References
[I-D.ietf-6man-impatient-nud] [I-D.ietf-6man-impatient-nud]
Nordmark, E. and I. Gashinsky, "Neighbor Unreachability Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
Detection is too impatient", draft-ietf-6man-impatient- Detection is too impatient", draft-ietf-6man-impatient-
nud-06 (work in progress), April 2013. nud-07 (work in progress), October 2013.
[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
 End of changes. 17 change blocks. 
46 lines changed or deleted 54 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/