draft-ietf-6man-enhanced-dad-06.txt   draft-ietf-6man-enhanced-dad-07.txt 
Network Working Group R. Asati Network Working Group R. Asati
Internet-Draft H. Singh Internet-Draft H. Singh
Updates: 4862, 4861, 3971 (if approved) W. Beebee Updates: 4862, 4861, 3971 (if approved) W. Beebee
Intended status: Standards Track C. Pignataro Intended status: Standards Track C. Pignataro
Expires: January 22, 2015 Cisco Systems, Inc. Expires: April 26, 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
July 21, 2014 October 23, 2014
Enhanced Duplicate Address Detection Enhanced Duplicate Address Detection
draft-ietf-6man-enhanced-dad-06 draft-ietf-6man-enhanced-dad-07
Abstract Abstract
Appendix A of the IPv6 Duplicate Address Detection (DAD) document in IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are
RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 discussed in Appendix A of [RFC4862]. That specification mentions a
does not settle on one specific automated means to detect loopback of hardware-assisted mechanism to detect looped back DAD messages. If
Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several hardware cannot suppress looped back DAD messages, a software
service provider communities have expressed a need for automated solution is required. Several service provider communities have
detection of looped backed ND messages used by DAD. This document expressed a need for automated detection of looped backed Neighbor
includes mitigation techniques and then outlines the Enhanced DAD Discovery (ND) messages used by DAD. This document includes
algorithm to automate detection of looped back IPv6 ND messages used mitigation techniques and outlines the Enhanced DAD algorithm to
by DAD. For network loopback tests, the Enhanced DAD algorithm automate the detection of looped back IPv6 ND messages used by DAD.
allows IPv6 to self-heal after a loopback is placed and removed. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to
Further, for certain access networks the document automates resolving self-heal after a loopback is placed and removed. Further, for
a specific duplicate address conflict. certain access networks the document automates resolving a specific
duplicate address conflict.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 22, 2015. This Internet-Draft will expire on April 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 27 skipping to change at page 2, line 27
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Two Deployment Problems . . . . . . . . . . . . . . . . . 3 1.1. Two Deployment Problems . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Operational Mitigation Options . . . . . . . . . . . . . . . 5 3. Operational Mitigation Options . . . . . . . . . . . . . . . 5
3.1. Disable DAD on Interface . . . . . . . . . . . . . . . . 5 3.1. Disable DAD on an 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 . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . 9 4.6. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 9
4.7. Changes to RFC 3971 . . . . . . . . . . . . . . . . . . . 9 4.7. Changes to RFC 3971 . . . . . . . . . . . . . . . . . . . 9
5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 9 5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . 10 9. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Appendix A of [RFC4862] discusses Loopback Suppression and Duplicate IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are
Address Detection (DAD). However, [RFC4862] does not settle on one discussed in Appendix A of [RFC4862]. That specification mentions a
specific automated means to detect loopback of ND messages used by hardware-assisted mechanism to detect looped back DAD messages. If
DAD. One specific DAD message is a Neighbor Solicitation (NS), hardware cannot suppress looped back DAD messages, a software
specified in [RFC4861]. The NS is issued by the network interface of solution is required. One specific DAD message is the Neighbor
an IPv6 node for DAD. Another message involved in DAD is a Neighbor Solicitation (NS), specified in [RFC4861]. The NS is issued by the
Advertisement (NA). The Enhanced DAD algorithm proposed in this network interface of an IPv6 node for DAD. Another message involved
document focuses on detecting an NS looped back to the transmitting in DAD is the Neighbor Advertisement (NA). The Enhanced DAD
interface during the DAD operation. Detecting a looped back NA is of algorithm specified in this document focuses on detecting an NS
no use because no problems with DAD will occur if a node receives a looped back to the transmitting interface during the DAD operation.
looped back NA. Detection of any other looped back ND messages Detecting a looped back NA does not solve the looped back DAD
outside of the DAD operation is not critical and thus this document problem. Detection of any other looped back ND messages during the
does not cover such detection. The document also includes a DAD operation is outside the scope of this document. This document
Mitigation section that discusses means already available to mitigate also includes a section on Mitigation that discusses means already
the loopback problem. available to mitigate the DAD loopback problem.
1.1. Two Deployment Problems 1.1. Two Deployment Problems
In each problem articulated below, the IPv6 link-local address DAD In each problem articulated below, the IPv6 link-local address DAD
operation fails due to a looped back DAD probe. However, the looped operation fails due to a looped back DAD probe. However, the looped
back DAD probe exists for any IPv6 address type including global back DAD probe exists for any IPv6 address type including global
addresses. addresses.
Recently, service providers have reported a problem with DAD that is Recently, service providers have reported a problem with DAD that is
caused by looped back NS messages. The following is a description of caused by looped back NS messages. The following is a description of
skipping to change at page 4, line 5 skipping to change at page 4, line 5
concentrator. The two modems have the Ethernet ports of each modem concentrator. The two modems have the Ethernet ports of each modem
connected to a network hub. The access concentrator serving the connected to a network hub. The access concentrator serving the
modems is the first-hop IPv6 router for the modems. The network modems is the first-hop IPv6 router for the modems. The network
interface of the access concentrator serving the two broadband modems interface of the access concentrator serving the two broadband modems
is enabled for IPv6 and the interface issues a NS(DAD) message for is enabled for IPv6 and the interface issues a NS(DAD) message for
the IPv6 link-local address. The NS message reaches one modem first the IPv6 link-local address. The NS message reaches one modem first
and this modem sends the message to the network hub which sends the and this modem sends the message to the network hub which sends the
message to the second modem which forwards the message back to the message to the second modem which forwards the message back to the
access concentrator. The looped back NS message causes the network access concentrator. The looped back NS message causes the network
interface on the access concentrator to be in a DAD-failed state. interface on the access concentrator to be in a DAD-failed state.
Such a network interface typically serves up to hundred thousands Such a network interface typically serves up to a hundred thousand
broadband modems causing all the modems (and hosts behind the modems) broadband modems causing all the modems (and hosts behind the modems)
to fail to get IPv6 online on the access network. Additionally, it to fail to get IPv6 online on the access network. Additionally, it
may be tedious for the access concentrator to find out which of the may be tedious for the access concentrator to find out which of the
hundred thousand or more homes looped back the DAD message. Clearly hundred thousand or more homes looped back the DAD message. Clearly
there is a need for automated detection of looped back NS messages there is a need for automated detection of looped back NS messages
during DAD operations by a node. during DAD operations by a node.
2. Terminology 2. Terminology
o DAD-failed state - Duplication Address Detection failure as o DAD-failed state - Duplication Address Detection failure as
specified in [RFC4862]. Note even Optimistic DAD as specified in specified in [RFC4862]. Note even Optimistic DAD as specified in
[RFC4429] can fail due to a looped back DAD probe. This document [RFC4429] can fail due to a looped back DAD probe. This document
covers looped back detection for Optimistic DAD as well. covers looped back detection for Optimistic DAD as well.
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 an Upper Layer Protocol on the sender looping the
message back. message back.
o Loopback - A function in which the router's layer-3 interface (or o Loopback - A function in which the router's layer-3 interface (or
the circuit to which the router's interface is connected) is the circuit to which the router's interface is connected) is
looped back or connected to itself. Loopback causes packets sent looped back or connected to itself. Loopback causes packets sent
by the interface to be received by the interface, and results in by the 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 [RFC1583]. The Loopback function more details in section 9.1 of [RFC1583]. 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 and bit-error tests. In a circuit context, this
used in wide area environments including optical dense wave function is used in wide area environments including optical Dense
division multiplexing (DWDM) and SONET/SDH for fault isolation Wave Division Multiplexing (DWDM) and SONET/SDH for fault
(e.g. by placing a loopback at different geographic locations isolation (e.g. by placing a loopback at different geographic
along the path of a wide area circuit to help locate a circuit locations along the path of a wide area circuit to help locate a
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.1. Requirements Language 2.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].
3. Operational Mitigation Options 3. Operational Mitigation Options
Two mitigation options are described below. The mechanisms do not Two mitigation options are described below. The mechanisms do not
require any change to existing implementations. require any change to existing implementations.
3.1. Disable DAD on Interface 3.1. Disable DAD on an Interface
One can disable DAD on an interface and then there is no NS(DAD) One can disable DAD on an interface so that there is no NS(DAD)
issued to be looped back. DAD is disabled by setting the interface's issued to be looped back. DAD is disabled by setting the interface's
DupAddrDetectTransmits variable to zero. While this mitigation may DupAddrDetectTransmits variable to zero. While this mitigation may
be the simplest the mitigation has three drawbacks. be the simplest, the mitigation has three drawbacks.
It would likely require careful analysis of configuration on such This mitigation would likely require careful analysis of
point-to-point interfaces, a one-time manual configuration on each of configuration on such point-to-point interfaces, a one-time manual
such interfaces, and more importantly, genuine duplicates in the link configuration on each of such interfaces, and more importantly,
will not be detected. genuine duplicates in 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 this mitigation strategy.
3.2. Dynamic Disable/Enable of DAD Using Layer-2 Protocol 3.2. Dynamic Disable/Enable of DAD Using Layer-2 Protocol
It is possible that one or more layer-2 protocols include provisions One or more layer-2 protocols MAY include provisions to detect the
to detect the existence of a loopback on an interface circuit, existence of a loopback on an interface circuit, usually by comparing
usually by comparing protocol data sent and received. For example, protocol data sent and received. For example, PPP uses magic number
PPP uses magic number (section 6.4 of [RFC1661]) to detect a loopback (section 6.4 of [RFC1661]) to detect a loopback on an interface.
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
interface circuit, the device MUST temporarily disable DAD on the interface circuit, the device MUST temporarily disable DAD on the
interface, and when the protocol detects that a loopback is no longer interface. When the protocol detects that a loopback is no longer
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 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 if the layer-2 enabled by default, and MUST be a configurable option if the layer-2
technology provides means for detecting loopback messages on an technology provides means for detecting loopback messages on an
interface circuit. interface circuit.
This mitigation has several benefits. They are This mitigation has several benefits. They are
skipping to change at page 6, line 38 skipping to change at page 6, line 38
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 in section 4.4. SEND. (See more details in the Impact on SEND section section 4.4.)
Since a nonce is used only once, DAD for each IPv6 address of an Since a nonce is used only once, The NS(DAD) for each IPv6 address of
interface uses a different nonce. Additional details of the an interface uses a different nonce. Additional details of the
algorithm are included in section 4.2. algorithm are included in section 4.2.
Six bytes of random nonce is sufficiently large for collisions. Six bytes of random nonce is sufficiently large to minimize
However if there is a collision because two nodes that are using the collisions. However, if there is a collision because two nodes that
same Target Address in their NS(DAD) generated the same random nonce, are using the same Target Address in their NS(DAD) and generated the
then the algorithm will incorrectly detect a looped back NS(DAD) when same random nonce, then the algorithm will incorrectly detect a
a genuine address collision has occurred. Since each looped back looped back NS(DAD) when a genuine address collision has occurred.
NS(DAD) event is logged to system management, the administrator of Since each looped back NS(DAD) event is logged to system management,
the network will have access to the information necessary to the administrator of the network will have access to the information
intervene manually. Also, because the nodes will have detected what necessary to intervene manually. Also, because the nodes will have
appear to be looped back NS(DAD) messages, they will continue to detected what appear to be looped back NS(DAD) messages, they will
probe and it is unlikely that they will choose the same nonce the continue to probe, and it is unlikely that they will choose the same
second time (assuming quality random number generators). 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 requirements of the node and
the algorithm state to a substantially larger number of ND messages. also adds the algorithm state to a substantially larger number of ND
Therefore this document does not recommend using the algorithm messages. Therefore, this document does not recommend using the
outside of the DAD operation by an interface on a node. algorithm outside of the DAD operation by an interface on a node.
4.1. General Rules 4.1. General Rules
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 an NS(DAD) for a tentative or optimistic interface address
sender MUST generate a random nonce associated with the interface the 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 the interface does not receive Option included in the NS(DAD). If the interface does not receive
any DAD failure indications within RetransTimer milliseconds (see any DAD failure indications within RetransTimer milliseconds (see
[RFC4861]) after having sent DupAddrDetectTransmits Neighbor [RFC4861]) after having sent DupAddrDetectTransmits Neighbor
Solicitations, the interface moves the Target Address to assigned Solicitations, the interface moves the Target Address to the assigned
state. state.
If any probe is looped back within RetransTimer milliseconds after If any probe is looped back within RetransTimer milliseconds after
having sent DupAddrDetectTransmits NS(DAD) messages, the interface having sent DupAddrDetectTransmits NS(DAD) messages, the interface
continues with another MAX_MULTICAST_SOLICIT number of NS(DAD) continues with another MAX_MULTICAST_SOLICIT number of NS(DAD)
messages transmitted RetransTimer millseconds apart. If no probe is messages transmitted RetransTimer millseconds apart. If no probe is
looped back within RetransTimer milliseconds after looped back within RetransTimer milliseconds after
MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, the probing stops. MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, the probing stops.
The probing MAY be stopped via manual intervention. When probing is The probing MAY be stopped via manual intervention. When probing is
stopped, the interface moves the Target Address to assigned state. stopped, the interface moves the Target Address to the assigned
state.
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 included in the optimistic state), the receiver compares the nonce included in the
message, if any, with any saved nonce on the receiving interface. If message, with any saved nonce on the receiving interface. If a match
a match is found, the node SHOULD log a system management message, is found, the node SHOULD log a system management message, SHOULD
SHOULD update any statistics counter, MUST drop the received message. update any statistics counter, and MUST drop the received message.
If the received NS(DAD) message includes a nonce and no match is If the received NS(DAD) message includes a nonce and no match is
found with any saved nonce, the node SHOULD log a system management found with any saved nonce, the node SHOULD log a system management
message for DAD-failed and SHOULD update any statistics counter. If message for a DAD-failed state, and SHOULD update any statistics
the interface does not receive any DAD failure indications within counter. If the interface does not receive any DAD failure
RetransTimer milliseconds after having sent DupAddrDetectTransmits indications within RetransTimer milliseconds after having sent
Neighbor Solicitations, the interface moves the Target Address to DupAddrDetectTransmits Neighbor Solicitations, the interface moves
assigned state. the Target Address to the 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. As 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
messages during DAD operations by the node. In a mixed SEND NS(DAD) messages during DAD operations by the node. In a mixed SEND
environment with SEND and unsecured nodes, the lengths of the nonce environment with SEND and unsecured nodes, the lengths of the nonce
used by SEND and unsecured nodes MUST be identical. used by SEND and unsecured nodes MUST be identical.
4.5. Changes to RFC 4862 4.5. Changes to RFC 4862
The following text is added to the end of the Introduction section of The following text is added to the end of the Introduction section of
[RFC4862]. [RFC4862].
A network interface of an IPv6 node SHOULD implement the Enhanced DAD A network interface of an IPv6 node SHOULD implement the Enhanced DAD
algorithm. For example, if the interface on an IPv6 node is algorithm. For example, if the interface on an IPv6 node is
connected to a circuit that supports loopback testing, then the node connected to a circuit that supports loopback testing, then the node
should implement the Enhanced DAD algorithm that allows the IPv6 SHOULD implement the Enhanced DAD algorithm that allows the IPv6
interface to self-heal after loopback testing is ended on the interface to self-heal after loopback testing is ended on the
circuit. Another example is when the IPv6 interface resides on an circuit. Another example is when the IPv6 interface resides on an
access concentrator running DAD Proxy. The interface supports up to access concentrator running DAD Proxy. The interface supports up to
hundred thousands IPv6 clients (broadband modems) connected to the a hundred thousand IPv6 clients (broadband modems) connected to the
interface. If the interface performs DAD for its IPv6 link-local interface. If the interface performs DAD for its IPv6 link-local
address and if the DAD probe is reflected back to the interface, the address and the DAD probe is reflected back to the interface, the
interface is stuck in DAD failed state and IPv6 services to the interface is stuck in DAD-failed state and IPv6 services to the
hundred thousands clients is denied. Disabling DAD for such an IPv6 hundred thousand clients is denied. Disabling DAD for such an IPv6
interface on an access concentrator is less desirable than interface on an access concentrator is less desirable than
implementing the algorithm because the network also needs to detect implementing the algorithm because the network also needs to detect
genuine duplicates in the interface downstream network. The Enhanced genuine duplicates in the interface downstream network. The Enhanced
DAD algorithm also facilitates detecting a genuine duplicate for the DAD algorithm also facilitates detecting a genuine duplicate for the
interface on the access concentrator. See the Actions to Perform on interface on the access concentrator. (See the Actions to Perform on
Detecting a Genuine Duplicate section of the Enhanced DAD document. Detecting a Genuine Duplicate section of the Enhanced DAD document.)
The following text is added to the end of Appendix A of [RFC4862]. The following text is added to the end of Appendix A of [RFC4862].
The Enhanced DAD algorithm from draft-ietf-6man-enhanced-dad is The Enhanced DAD algorithm from draft-ietf-6man-enhanced-dad is
designed to detect looped back DAD probes. A network interface of an designed to detect looped back DAD probes. A network interface of an
IPv6 node SHOULD implement the Enhanced DAD algorithm. IPv6 node SHOULD implement the Enhanced DAD algorithm.
4.6. Changes to RFC 4861 4.6. Changes to RFC 4861
The following text is appended to the RetransTimer variable The following text is appended to the RetransTimer variable
description in section 6.3.2 of [RFC4861]. description in section 6.3.2 of [RFC4861]:
The RetransTimer may be overridden by a link-specific document if a The RetransTimer may be overridden by a link-specific document if a
node supports the Enhanced DAD algorithm. node supports the Enhanced DAD algorithm.
The following text is appended to the Source Address definition in The following text is appended to the Source Address definition in
section 4.3 of [RFC4861]. section 4.3 of [RFC4861]:
If a node has been configured to use the Enhanced DAD algorithm, an If a node has been configured to use the Enhanced DAD algorithm, an
NS with an unspecified source address adds the Nonce option to the NS with an unspecified source address adds the Nonce option to the
message and implements the state machine of the Enhanced DAD message and implements the state machine of the Enhanced DAD
algorithm. algorithm.
4.7. Changes to RFC 3971 4.7. Changes to RFC 3971
The following text is changed in section 5.3.2 of [RFC3971]. The following text is changed in section 5.3.2 of [RFC3971]:
The purpose of the Nonce option is to make sure that an advertisement The purpose of the Nonce option is to make sure that an advertisement
is a fresh response to a solicitation sent earlier by the node. is a fresh response to a solicitation sent earlier by the node.
New text is included below. The new text is included below:
The purpose of the Nonce option is to make sure that an advertisement The purpose of the Nonce option is to make sure that an advertisement
is a fresh response to a solicitation sent earlier by the node. The is a fresh response to a solicitation sent earlier by the node. The
nonce is also used to detect looped back NS messages when the network nonce is also used to detect looped back NS messages when the network
interface performs DAD [RFC4862]. Detecting looped back DAD messages interface performs DAD [RFC4862]. Detecting looped back DAD messages
is covered by the Enhanced DAD algorithm as specified in draft-ietf- is covered by the Enhanced DAD algorithm as specified in draft-ietf-
6man-enhanced-dad. In a mixed SEND environment with SEND and 6man-enhanced-dad. In a mixed SEND environment with SEND and
unsecured nodes, the lengths of the nonce used by SEND and unsecured unsecured nodes, the lengths of the nonce used by SEND and unsecured
nodes MUST be identical. nodes MUST be identical.
5. Actions to Perform on Detecting a Genuine Duplicate 5. Actions to Perform on Detecting a Genuine Duplicate
As described in paragraphs above the nonce can also serve to detect As described in the paragraphs above, the nonce can also serve to
genuine duplicates even when the network has potential for looping detect genuine duplicates even when the network has potential for
back ND messages. When a genuine duplicate is detected, the node looping back ND messages. When a genuine duplicate is detected, the
follows the manual intervention specified in section 5.4.5 of node follows the manual intervention specified in section 5.4.5 of
[RFC4862]. However, in certain networks such as an access network if [RFC4862]. However, in certain networks such as an access network,
the genuine duplicate matches the tentative or optimistic IPv6 if the genuine duplicate matches the tentative or optimistic IPv6
address of a network interface of the access concentrator, automated address of a network interface of the access concentrator, automated
actions are proposed. actions are recommended.
One access network is a cable broadband deployment where the access One access network is a cable broadband deployment where the access
concentrator is the first-hop IPv6 router to several thousand concentrator is the first-hop IPv6 router to several hundred thousand
broadband modems. The router also supports proxying of DAD messages. broadband modems. The router also supports proxying of DAD messages.
The network interface on the access concentrator initiates DAD for an The network interface on the access concentrator initiates DAD for an
IPv6 address and detects a genuine duplicate due to receiving an IPv6 address and detects a genuine duplicate due to receiving an
NS(DAD) or an NA message. On detecting such a duplicate the access NS(DAD) or an NA message. On detecting such a duplicate, the access
concentrator logs a system management message, drops the received ND concentrator logs a system management message, drops the received ND
message, and blocks the modem on whose layer-2 service identifier the message, and blocks the modem on whose layer-2 service identifier the
NS(DAD) or NA message was received on. NS(DAD) or NA message was received on.
The network described above follows a trust model where a trusted The network described above follows a trust model where a trusted
router serves un-trusted IPv6 host nodes. Operators of such networks router serves un-trusted IPv6 host nodes. Operators of such networks
have a desire to take automated action if a network interface of the have a desire to take automated action if a network interface of the
trusted router has a tentative or optimistic address duplicate with a trusted router has a tentative or optimistic address duplicated by a
host served by trusted router interface. Any other network that host. Any other network that follows the same trust model MAY use
follows the same trust model MAY use the automated actions proposed the automated actions proposed in this section.
in this section.
6. Security Considerations 6. Security Considerations
The nonce can be exploited by a rogue deliberately changing the nonce The nonce can be exploited by a rogue deliberately changing the nonce
to fail the looped back detection specified by the Enhanced DAD to fail the looped back detection specified by the Enhanced DAD
algorithm. SEND is recommended to circumvent this exploit. algorithm. SEND is recommended to circumvent this exploit.
Additionally, the nonce does not protect against the DoS caused by a Additionally, the nonce does not protect against the DoS caused by a
rogue node replying by fake NA to all DAD probes. SEND is rogue node replying by a fake NA to all DAD probes. SEND is
recommended to circumvent this exploit. For any mitigation suggested recommended to circumvent this exploit also. Disabling DAD has an
in the document such as disabling DAD has an obvious security issue obvious security issue before a remote node on the link can issue
before a remote node on the link can issue reflected NS(DAD) reflected NS(DAD) messages. Again, SEND is recommended for this
messages. Again, SEND is recommended for this exploit. 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 Bernie Volz, Dmitry
Levy-Abegnoli, Eric Vyncke, Erik Nordmark, Fred Templin, Jouni Anipko, Eric Levy-Abegnoli, Eric Vyncke, Erik Nordmark, Fred Templin,
Korhonen, Michael Sinatra, Ole Troan, Ray Hunter, Suresh Krishnan, Jouni Korhonen, Michael Sinatra, Ole Troan, Ray Hunter, Suresh
and Tassos Chatzithomaoglou for their guidance and review of the Krishnan, and Tassos Chatzithomaoglou for their guidance and review
document. Thanks to Thomas Narten for encouraging this work. Thanks of the document. Thanks to Thomas Narten for encouraging this work.
to Steinar Haug and Scott Beuker for describing the use cases. Thanks to Steinar Haug and Scott Beuker for describing the use cases.
9. Normative References 9. Normative References
[RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994. [RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
[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.
 End of changes. 44 change blocks. 
125 lines changed or deleted 125 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/