draft-ietf-6man-enhanced-dad-10.txt   draft-ietf-6man-enhanced-dad-11.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, 4429 (if approved) W. Beebee
Intended status: Standards Track C. Pignataro Intended status: Standards Track C. Pignataro
Expires: May 17, 2015 Cisco Systems, Inc. Expires: July 18, 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
November 13, 2014 January 14, 2015
Enhanced Duplicate Address Detection Enhanced Duplicate Address Detection
draft-ietf-6man-enhanced-dad-10 draft-ietf-6man-enhanced-dad-11
Abstract Abstract
IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are
discussed in Appendix A of RFC4862. That specification mentions a discussed in Appendix A of RFC4862. That specification mentions a
hardware-assisted mechanism to detect looped back DAD messages. If hardware-assisted mechanism to detect looped back DAD messages. If
hardware cannot suppress looped back DAD messages, a software hardware cannot suppress looped back DAD messages, a software
solution is required. Several service provider communities have solution is required. Several service provider communities have
expressed a need for automated detection of looped backed Neighbor expressed a need for automated detection of looped back Neighbor
Discovery (ND) messages used by DAD. This document includes Discovery (ND) messages used by DAD. This document includes
mitigation techniques and outlines the Enhanced DAD algorithm to mitigation techniques and outlines the Enhanced DAD algorithm to
automate the detection of looped back IPv6 ND messages used by DAD. automate the detection of looped back IPv6 ND messages used by DAD.
For network loopback tests, the Enhanced DAD algorithm allows IPv6 to For network loopback tests, the Enhanced DAD algorithm allows IPv6 to
self-heal after a loopback is placed and removed. Further, for self-heal after a loopback is placed and removed. Further, for
certain access networks the document automates resolving a specific certain access networks the document automates resolving a specific
duplicate address conflict. This document updates RFC4861, RFC4862, duplicate address conflict. This document updates RFC4861, RFC4862,
and RFC3971. and RFC3971.
Status of This Memo Status of This Memo
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 May 17, 2015. This Internet-Draft will expire on July 18, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Two Deployment Problems . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Operational Mitigation Options . . . . . . . . . . . . . . . 5 3. Operational Mitigation Options . . . . . . . . . . . . . . . 4
3.1. Disable DAD on an Interface . . . . . . . . . . . . . . . 5 3.1. Disable DAD on an 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 . . . . . . . . . . . . . . . 6 3.3. Operational Considerations . . . . . . . . . . . . . . . 5
4. The Enhanced DAD Algorithm . . . . . . . . . . . . . . . . . 6 4. The Enhanced DAD Algorithm . . . . . . . . . . . . . . . . . 6
4.1. Processing Rules for Senders . . . . . . . . . . . . . . 7 4.1. Processing Rules for Senders . . . . . . . . . . . . . . 6
4.2. Processing Rules for Receivers . . . . . . . . . . . . . 7 4.2. Processing Rules for Receivers . . . . . . . . . . . . . 7
4.3. Impact on SEND . . . . . . . . . . . . . . . . . . . . . 8 4.3. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 7
4.4. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . 8 5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 7
4.5. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4.6. Changes to RFC 3971 . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Normative References . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are
discussed in Appendix A of [RFC4862]. That specification mentions a discussed in Appendix A of [RFC4862]. That specification mentions a
hardware-assisted mechanism to detect looped back DAD messages. If hardware-assisted mechanism to detect looped back DAD messages. If
hardware cannot suppress looped back DAD messages, a software hardware cannot suppress looped back DAD messages, a software
solution is required. One specific DAD message is the Neighbor solution is required. One specific DAD message is the Neighbor
Solicitation (NS), specified in [RFC4861]. The NS is issued by the Solicitation (NS), specified in [RFC4861]. The NS is issued by the
network interface of an IPv6 node for DAD. Another message involved network interface of an IPv6 node for DAD. Another message involved
skipping to change at page 3, line 7 skipping to change at page 3, line 4
IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are
discussed in Appendix A of [RFC4862]. That specification mentions a discussed in Appendix A of [RFC4862]. That specification mentions a
hardware-assisted mechanism to detect looped back DAD messages. If hardware-assisted mechanism to detect looped back DAD messages. If
hardware cannot suppress looped back DAD messages, a software hardware cannot suppress looped back DAD messages, a software
solution is required. One specific DAD message is the Neighbor solution is required. One specific DAD message is the Neighbor
Solicitation (NS), specified in [RFC4861]. The NS is issued by the Solicitation (NS), specified in [RFC4861]. The NS is issued by the
network interface of an IPv6 node for DAD. Another message involved network interface of an IPv6 node for DAD. Another message involved
in DAD is the Neighbor Advertisement (NA). The Enhanced DAD in DAD is the Neighbor Advertisement (NA). The Enhanced DAD
algorithm specified in this document focuses on detecting an NS algorithm specified in this document focuses on detecting an NS
looped back to the transmitting interface during the DAD operation. looped back to the transmitting interface during the DAD operation.
Detecting a looped back NA does not solve the looped back DAD Detecting a looped back NA does not solve the looped back DAD
problem. Detection of any other looped back ND messages during the problem. Detection of any other looped back ND messages during the
DAD operation is outside the scope of this document. This document DAD operation is outside the scope of this document. This document
also includes a section on Mitigation that discusses means already also includes a section on Mitigation that discusses means already
available to mitigate the DAD loopback problem. This document available to mitigate the DAD loopback problem. This document
updates RFC4861, RFC4862, and RFC3971. updates RFC4861, RFC4862, and RFC3971.
1.1. Two Deployment Problems 1.1. Requirements Language
In each problem articulated below, the IPv6 link-local address DAD
operation fails due to a looped back DAD probe. However, the looped
back DAD probe exists for any IPv6 address type including global
addresses.
Recently, service providers have reported a problem with DAD that is
caused by looped back NS messages. The following is a description of
the circumstances under which the problem arises. Loopback testing
for troubleshooting purposes is underway on a circuit connected to an
interface on a router. The interface on the router is enabled for
IPv6. The interface issues a NS for the IPv6 link-local address DAD.
The NS is reflected back to the router interface due to the loopback
condition of the circuit, and the router interface enters a DAD-
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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
with DAD Loopback. While the following example is not a common "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
configuration, it has occurred in a large service provider network. document are to be interpreted as described in [RFC2119].
It is necessary to address it in the proposed solution because the
trigger scenario has the potential to cause significant IPv6 service
outages when it does occur. In this scenario, two broadband modems
in the same home are served by the same service provider and both
modems are served by one access concentrator and one layer-3
interface on the access concentrator. The two modems have the
Ethernet ports of each modem connected to a network hub. The access
concentrator serving the modems is the first-hop IPv6 router for the
modems. The network interface of the access concentrator serving the
two broadband modems 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 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 access concentrator. The looped
back NS message causes the network interface on the access
concentrator to be in a DAD-failed state. Such a network interface
typically serves up to a hundred thousand broadband modems causing
all the modems (and hosts behind the modems) to fail to get IPv6
online on the access network. Additionally, it may be tedious for
the user of the access concentrator to find out which of the hundred
thousand or more homes looped back the DAD message. Clearly there is
a need for automated detection of looped back NS messages during DAD
operations by a node.
2. Terminology 1.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 an Upper Layer Protocol on the sender looping the the network or an Upper Layer Protocol on the sender looping the
message back. message back.
skipping to change at page 4, line 46 skipping to change at page 4, line 5
Wave Division Multiplexing (DWDM) and SONET/SDH for fault Wave Division Multiplexing (DWDM) and SONET/SDH for fault
isolation (e.g. by placing a loopback at different geographic isolation (e.g. by placing a loopback at different geographic
locations along the path of a wide area circuit to help locate a locations along the path of a wide area circuit to help locate a
circuit fault). The Loopback function may be employed locally or circuit fault). The Loopback function may be employed locally or
remotely. remotely.
o NS(DAD) - shorthand notation to denote an Neighbor Solicitation o NS(DAD) - shorthand notation to denote an Neighbor Solicitation
(NS) (as specified in [RFC4861]) with unspecified IPv6 source- (NS) (as specified in [RFC4861]) with unspecified IPv6 source-
address issued during DAD. address issued during DAD.
2.1. Requirements Language 2. Problem Statement
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Recently, service providers have reported a problem with DAD that
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this arises under the following sets of circumstances: In the first,
document are to be interpreted as described in [RFC2119]. loopback testing for troubleshooting purposes is underway on a
circuit connected to an IPv6-enabled interface on a router. The
interface issues a NS for the IPv6 link-local address DAD. The NS is
reflected back to the router interface due to the loopback condition
of the circuit, and the router interface enters a DAD-failed state.
After 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. In the second scenario, two broadband
modems are served by the same service provider and terminate to the
same layer-3 interface on an IPv6-enabled access concentrator. In
this case, the two modems' Ethernet interfaces are also connected to
a common local network (collision domain). The access concentrator
serving the modems is the first-hop IPv6 router for the modems and
issues a NS(DAD) message for the IPv6 link-local address of its
layer-3 interface. The NS message reaches one modem first and this
modem sends the message to the local network, where the second modem
receives the message and then forwards it back to the access
concentrator. The looped back NS message causes the network
interface on the access concentrator to be in a DAD-failed state.
Such a network interface typically serves thousands of broadband
modems, and all would have their IPv6 connectivity affected until the
DAD-failed state is cleared. Additionally, it may be difficult for
the user of the access concentrator to determine the source of the
looped back DAD message. Thus in order to avoid IPv6 outages that
can potentially affect multiple users, there is a need for automated
detection of looped back NS messages during DAD operations by a node.
Note: In both examples above, the IPv6 link-local address DAD
operation fails due to a looped back DAD probe. However, the problem
of a looped back DAD probe exists for any IPv6 address type including
global addresses.
3. Operational Mitigation Options 3. Operational Mitigation Options
Two mitigation options are described below. The mechanisms do not Two mitigation options are described below that do not require any
require any change to existing implementations. change to existing implementations.
3.1. Disable DAD on an Interface 3.1. Disable DAD on an Interface
One can disable DAD on an interface so that there is no NS(DAD) One can disable DAD on an interface so that there are no NS(DAD)
issued to be looped back. DAD is disabled by setting the interface's messages issued. While this mitigation may be the simplest, the
DupAddrDetectTransmits variable to zero. While this mitigation may mitigation has three drawbacks: 1) care is needed when making such
be the simplest, the mitigation has three drawbacks. configuration changes on point-to-point interfaces, 2) this is a one-
time manual configuration on each interface, and 3) genuine
This mitigation would likely require careful analysis of duplicates on the link will not be detected.
configuration on such point-to-point interfaces, a one-time manual
configuration on each of such interfaces, and more importantly,
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
One or more layer-2 protocols MAY include provisions to detect the Some layer-2 protocols include provisions to detect the existence of
existence of a loopback on an interface circuit, usually by comparing a loopback on an interface circuit, usually by comparing protocol
protocol data sent and received. For example, the Point-to-Point data sent and received. For example, the Point-to-Point Protocol
Protocol (PPP) uses a magic number (section 6.4 of [RFC1661]) to (PPP) uses a magic number (section 6.4 of [RFC1661]) to detect a
detect a loopback on an interface. loopback on an interface.
When a layer-2 protocol detects that a loopback is present on an When a layer-2 protocol detects that a loopback is present on an
interface circuit, the device MUST temporarily disable DAD on the interface circuit, the device MUST temporarily disable DAD on the
interface. 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 mitigation has several benefits. It leverages the layer-2
enabled by default, and MUST be a configurable option if the layer-2 protocol's built-in loopback detection capability, if available. It
technology provides means for detecting loopback messages on an scales better since it relies on an event-driven model which requires
interface circuit. no additional state or timer. This may be significant on devices
with hundreds or thousands of interfaces that may be in loopback for
This mitigation has several benefits. They are long periods of time (e.g., awaiting turn-up).
1. It leverages layer-2 protocol's built-in loopback detection
capability, if available.
2. It scales better since it relies on an event-driven model which This solution SHOULD be enabled by default, and MUST be a
requires no additional state or timer. This may be a significant configurable option if the layer-2 technology provides means for
scaling consideration on devices with hundreds or thousands of detecting loopback messages on an interface circuit.
interfaces that may be in loopback for long periods of time (such
as while awaiting turn-up or during long-duration intrusive bit
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 above do not require the devices on
devices on both ends of the circuit to support the mitigation both ends of the circuit to support the mitigation functionality
functionality simultaneously, and do not propose any capability simultaneously, and do not propose any capability negotiation. They
negotiation. The mitigation options discussed in this document are are effective for unidirectional circuit or interface loopback (i.e.
effective for unidirectional circuit or interface loopback (i.e. the the the loopback is placed in one direction on the circuit, rendering
the loopback is placed in one direction on the circuit, rendering the the other direction non-operational), but they may not be effective
other direction non-operational). for a bidirectional loopback (i.e. the loopback is placed in both
directions of the circuit interface, so as to identify the faulty
The mitigation options may not be effective for the bidirectional segment). This is because unless both ends followed a mitigation
loopback (i.e. the loopback is placed in both directions of the option specified in this document, the non-compliant device would
circuit interface, so as to identify the faulty segment) if only one follow current behavior and disable IPv6 on that interface due to DAD
device followed a mitigation option specified in this document, since until manual intervention restores it.
the other device would follow current behavior and disable IPv6 on
that interface due to DAD until manual intervention restores it.
This is nothing different from what happens today (without the
solutions proposed by this document) in case of unidirectional
loopback. Hence, it is expected that an operator would resort to
manual intervention for the devices not compliant with this document,
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 a random number in the Nonce
the SEND document of [RFC3971]. The nonce is a random number as Option specified in SEND [RFC3971]. Note [RFC3971] does not provide
specified in [RFC3971]. If SEND is enabled on the router and the a recommendation for pseudo-random functions. Pseudo-random
router also supports the Enhanced DAD algorithm (specified in this functions are covered in [RFC4086]. Since a nonce is used only once,
document), there is integration with the Enhanced DAD algorithm and the NS(DAD) for each IPv6 address of an interface uses a different
SEND. (See more details in the Impact on SEND section 4.3.) Since a nonce. Additional details of the algorithm are included in section
nonce is used only once, The NS(DAD) for each IPv6 address of an 4.2.
interface uses a different nonce. Additional details of the
algorithm are included in section 4.2.
Six bytes of random nonce is sufficiently large to minimize If there is a collision because two nodes using the same Target
collisions. However, if there is a collision because two nodes using Address in their NS(DAD) and generated the same random nonce, then
the same Target Address in their NS(DAD) and generated the same the algorithm will incorrectly detect a looped back NS(DAD) when a
random nonce, then the algorithm will incorrectly detect a looped genuine address collision has occurred. Since each looped back
back NS(DAD) when a genuine address collision has occurred. Since NS(DAD) event is logged to system management, the administrator of
each looped back NS(DAD) event is logged to system management, the the network will have access to the information necessary to
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, for a sender to store a nonce and that is looped back. However, there may be increased implementation
nonce related state for all ND messages has impact on memory and complexity and memory usage for the sender node to store a nonce and
causes more complexity for the sender node. Therefore, this document nonce related state for all ND messages. Therefore, this document
does not recommend using the algorithm outside of the DAD operation does not recommend using the algorithm outside of the DAD operation
by an interface on a node. by an interface on a node.
4.1. Processing Rules for Senders 4.1. 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 an NS(DAD) for a tentative or optimistic interface address sending an NS(DAD) for a tentative or optimistic interface address
the sender MUST generate a random nonce associated with the interface the sender MUST generate a random nonce associated with the interface
address, MUST store the nonce internally, and MUST include the nonce address, MUST store the nonce internally, and MUST include the nonce
in the Nonce Option included in the NS(DAD). If the interface does in the Nonce Option included in the NS(DAD). If the interface does
skipping to change at page 8, line 5 skipping to change at page 7, line 23
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, with any stored nonce on the receiving interface. If a message, with any stored nonce on the receiving interface. If a
match is found, the node SHOULD log a system management message, match is found, the node SHOULD log a system management message,
SHOULD update any statistics counter, and MUST drop the received SHOULD update any statistics counter, and MUST drop the received
message. If the received NS(DAD) message includes a nonce and no message. If the received NS(DAD) message includes a nonce and no
match is found with any stored nonce, the node SHOULD log a system match is found with any stored nonce, the node SHOULD log a system
management message for a DAD-failed state, and SHOULD update any management message for a DAD-failed state, and SHOULD update any
statistics counter. statistics counter.
4.3. Impact on SEND 4.3. Changes to RFC 4861
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
detecting looped back ND messages. As this document updates
[RFC4862], SEND should be updated to integrate with the Enhanced DAD
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(DAD) messages during DAD operations by the node. In a mixed SEND
environment with SEND and unsecured nodes, the lengths of the nonce
used by SEND and unsecured nodes MUST be identical.
4.4. Changes to RFC 4862
The following text is added to the end of the Introduction section of
[RFC4862].
A network interface of an IPv6 node should implement the Enhanced DAD
algorithm. For example, if the interface on an IPv6 node is
connected to a circuit that supports loopback testing, then the node
should implement the Enhanced DAD algorithm that allows the IPv6
interface to self-heal after loopback testing is ended on the
circuit. Another example is when the IPv6 interface resides on an
access concentrator running DAD Proxy. The interface supports up to
a hundred thousand IPv6 clients (broadband modems) connected to the
interface. If the interface performs DAD for its IPv6 link-local
address and the DAD probe is reflected back to the interface, the
interface is stuck in DAD-failed state and IPv6 services to the
hundred thousand clients is denied. Disabling DAD for such an IPv6
interface on an access concentrator is less desirable than
implementing the algorithm because the network also needs to detect
genuine duplicates in the interface downstream network. The Enhanced
DAD algorithm also facilitates detecting a genuine duplicate for the
interface on the access concentrator. (See the Actions to Perform on
Detecting a Genuine Duplicate section of the Enhanced DAD document.)
The following text is added to the end of Appendix A of [RFC4862].
The Enhanced DAD algorithm from draft-ietf-6man-enhanced-dad is
designed to detect looped back DAD probes. A network interface of an
IPv6 node SHOULD implement the Enhanced DAD algorithm.
4.5. 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.6. Changes to RFC 3971
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
is a fresh response to a solicitation sent earlier by the node.
The new text is included below:
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
nonce is also used to detect looped back NS messages when the network
interface performs DAD [RFC4862]. Detecting looped back DAD messages
is covered by the Enhanced DAD algorithm as specified in draft-ietf-
6man-enhanced-dad. In a mixed SEND environment with SEND and
unsecured nodes, the lengths of the nonce used by SEND and unsecured
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 the paragraphs above, the nonce can also serve to As described in the paragraphs above, the nonce can also serve to
detect genuine duplicates even when the network has potential for detect genuine duplicates even when the network has potential for
looping back ND messages. When a genuine duplicate is detected, the looping back ND messages. When a genuine duplicate is detected, the
node 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, [RFC4862]. However, in certain cases, if the genuine duplicate
if the genuine duplicate matches the tentative or optimistic IPv6 matches the tentative or optimistic IPv6 address of a network
address of a network interface of the access concentrator, automated interface of the access concentrator, additional automated actions
actions are recommended. are recommended.
One example of a type of access network is cable broadband deployment
where the access concentrator is the first-hop IPv6 router to several
hundred thousand broadband modems. The router also supports proxying
of DAD messages. The network interface on the access concentrator
initiates DAD for 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 concentrator logs a system management message,
drops the received ND message, and blocks the modem on whose layer-2
service identifier the NS(DAD) or NA message was received on.
The network described above follows a trust model where a trusted Some networks follow a trust model where a trusted router serves un-
router serves un-trusted IPv6 host nodes. Operators of such networks trusted IPv6 host nodes. Operators of such networks have a desire to
have a desire to take automated action if a network interface of the take automated action if a network interface of the trusted router
trusted router has a tentative or optimistic address duplicated by a has a tentative or optimistic address duplicated by a host. One
host. Any other network that follows the same trust model MAY use example of a type of access network is cable broadband deployment
the automated actions proposed in this section. where the access concentrator is the first-hop IPv6 router to
multiple broadband modems and supports proxying of DAD messages. The
network interface on the access concentrator initiates DAD for 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
concentrator SHOULD log a system management message, drop the
received ND message, and block the modem on whose layer-2 service
identifier the duplicate NS(DAD) or NA message was received on. Any
other network that follows the same trust model MAY use the automated
actions proposed in this section.
6. Security Considerations 6. Security Considerations
This document does not improve nor reduce the security posture of This document does not improve nor reduce the security posture of
[RFC4862]. The nonce can be exploited by a rogue deliberately [RFC4862]. The nonce can be exploited by a rogue deliberately
changing the nonce to fail the looped back detection specified by the changing the nonce to fail the looped back detection specified by the
Enhanced DAD algorithm. SEND is recommended to circumvent this Enhanced DAD algorithm. SEND is recommended to circumvent this
exploit. Additionally, the nonce does not protect against the DoS exploit. Additionally, the nonce does not protect against the DoS
caused by a rogue node replying by a fake NA to all DAD probes. SEND caused by a rogue node replying by a fake NA to all DAD probes. SEND
is recommended to circumvent this exploit also. Disabling DAD has an is recommended to circumvent this exploit also. Disabling DAD has an
skipping to change at page 11, line 8 skipping to change at page 9, line 13
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[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.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[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.
skipping to change at page 12, line 31 skipping to change at page 10, line 31
URI: http://www.cisco.com/ URI: http://www.cisco.com/
Eli Dart Eli Dart
Lawrence Berkeley National Laboratory Lawrence Berkeley National Laboratory
1 Cyclotron Road, Berkeley, CA 94720 1 Cyclotron Road, Berkeley, CA 94720
USA USA
Email: dart@es.net Email: dart@es.net
URI: http://www.es.net/ URI: http://www.es.net/
Wes George Wesley George
Time Warner Cable Time Warner Cable
13820 Sunrise Valley Drive 13820 Sunrise Valley Drive
Herndon, VA 20171 Herndon, VA 20171
USA USA
Email: wesley.george@twcable.com Email: wesley.george@twcable.com
 End of changes. 33 change blocks. 
232 lines changed or deleted 141 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/