draft-ietf-6man-enhanced-dad-07.txt   draft-ietf-6man-enhanced-dad-08.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: April 26, 2015 Cisco Systems, Inc. Expires: May 14, 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
October 23, 2014 November 10, 2014
Enhanced Duplicate Address Detection Enhanced Duplicate Address Detection
draft-ietf-6man-enhanced-dad-07 draft-ietf-6man-enhanced-dad-08
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 backed Neighbor
Discovery (ND) messages used by DAD. This document includes Discovery (ND) messages used by DAD. This document includes
skipping to change at page 1, line 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 April 26, 2015. This Internet-Draft will expire on May 14, 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 31 skipping to change at page 2, line 31
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 an 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. Processing Rules for Senders . . . . . . . . . . . . . . 7
4.2. Processing Rules for Senders . . . . . . . . . . . . . . 7 4.2. Processing Rules for Receivers . . . . . . . . . . . . . 7
4.3. Processing Rules for Receivers . . . . . . . . . . . . . 7 4.3. Impact on SEND . . . . . . . . . . . . . . . . . . . . . 8
4.4. Impact on SEND . . . . . . . . . . . . . . . . . . . . . 8 4.4. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . 8
4.5. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . 8 4.5. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 8
4.6. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 9 4.6. 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
IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are
skipping to change at page 3, line 40 skipping to change at page 3, line 39
the loopback condition is removed, IPv4 will return to operation the loopback condition is removed, IPv4 will return to operation
without further manual intervention. However, IPv6 will remain in without further manual intervention. However, IPv6 will remain in
DAD-failed state until manual intervention on the router restores DAD-failed state until manual intervention on the router restores
IPv6 to operation. IPv6 to operation.
There are other conditions which will also trigger similar problems There are other conditions which will also trigger similar problems
with DAD Loopback. While the following example is not a common with DAD Loopback. While the following example is not a common
configuration, it has occurred in a large service provider network. configuration, it has occurred in a large service provider network.
It is necessary to address it in the proposed solution because the It is necessary to address it in the proposed solution because the
trigger scenario has the potential to cause significant IPv6 service trigger scenario has the potential to cause significant IPv6 service
outages when it does occur. Two broadband modems in the same home outages when it does occur. In this scenario, two broadband modems
are served by the same service provider and both modems are served by in the same home are served by the same service provider and both
one access concentrator and one layer-3 interface on the access modems are served by one access concentrator and one layer-3
concentrator. The two modems have the Ethernet ports of each modem interface on the access concentrator. The two modems have the
connected to a network hub. The access concentrator serving the Ethernet ports of each modem connected to a network hub. The access
modems is the first-hop IPv6 router for the modems. The network concentrator serving the modems is the first-hop IPv6 router for the
interface of the access concentrator serving the two broadband modems modems. The network interface of the access concentrator serving the
is enabled for IPv6 and the interface issues a NS(DAD) message for two broadband modems is enabled for IPv6 and the interface issues a
the IPv6 link-local address. The NS message reaches one modem first NS(DAD) message for the IPv6 link-local address. The NS message
and this modem sends the message to the network hub which sends the reaches one modem first and this modem sends the message to the
message to the second modem which forwards the message back to the network hub which sends the message to the second modem which
access concentrator. The looped back NS message causes the network forwards the message back to the access concentrator. The looped
interface on the access concentrator to be in a DAD-failed state. back NS message causes the network interface on the access
Such a network interface typically serves up to a hundred thousand concentrator to be in a DAD-failed state. Such a network interface
broadband modems causing all the modems (and hosts behind the modems) typically serves up to a hundred thousand broadband modems causing
to fail to get IPv6 online on the access network. Additionally, it all the modems (and hosts behind the modems) to fail to get IPv6
may be tedious for the access concentrator to find out which of the online on the access network. Additionally, it may be tedious for
hundred thousand or more homes looped back the DAD message. Clearly the access concentrator to find out which of the hundred thousand or
there is a need for automated detection of looped back NS messages more homes looped back the DAD message. Clearly there is a need for
during DAD operations by a node. automated detection of looped back NS messages 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
skipping to change at page 5, line 29 skipping to change at page 5, line 29
configuration on each of such interfaces, and more importantly, configuration on each of such interfaces, and more importantly,
genuine duplicates in the link 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
One or more layer-2 protocols MAY include provisions to detect the One or more layer-2 protocols MAY include provisions to detect the
existence of a loopback on an interface circuit, usually by comparing existence of a loopback on an interface circuit, usually by comparing
protocol data sent and received. For example, PPP uses magic number protocol data sent and received. For example, the Point-to-Point
(section 6.4 of [RFC1661]) to detect a loopback on an interface. Protocol (PPP) uses a magic number (section 6.4 of [RFC1661]) to
detect a 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 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
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 section 4.4.) SEND. (See more details in the Impact on SEND section 4.3.) Since a
Since a nonce is used only once, The NS(DAD) for each IPv6 address of nonce is used only once, The NS(DAD) for each IPv6 address of an
an interface uses a different nonce. Additional details of the 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 to minimize Six bytes of random nonce is sufficiently large to minimize
collisions. However, if there is a collision because two nodes that collisions. However, if there is a collision because two nodes using
are using the same Target Address in their NS(DAD) and generated the the same Target Address in their NS(DAD) and generated the same
same random nonce, then the algorithm will incorrectly detect a random nonce, then the algorithm will incorrectly detect a looped
looped back NS(DAD) when a genuine address collision has occurred. back NS(DAD) when a genuine address collision has occurred. Since
Since each looped back NS(DAD) event is logged to system management, each looped back NS(DAD) event is logged to system management, the
the administrator of the network will have access to the information administrator of the network will have access to the information
necessary to intervene manually. Also, because the nodes will have necessary to intervene manually. Also, because the nodes will have
detected what appear to be looped back NS(DAD) messages, they will 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 continue to probe, and it is unlikely that they will choose the same
nonce the 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, for a sender to store a nonce and
for all ND messages has impact on memory requirements of the node and nonce related state for all ND messages has impact on memory and
also adds the algorithm state to a substantially larger number of ND causes more complexity for the sender node. Therefore, this document
messages. Therefore, this document does not recommend using the does not recommend using the algorithm outside of the DAD operation
algorithm outside of the DAD operation by an interface on a node. by an interface on a node.
4.1. General Rules
If an IPv6 node implements the Enhanced DAD algorithm, the node MUST
implement detection of looped back NS(DAD) messages during DAD for an
interface address.
4.2. 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 save the nonce, and MUST include the nonce in the Nonce address, MUST store the nonce internally, and MUST include the nonce
Option included in the NS(DAD). If the interface does not receive in the Nonce Option included in the NS(DAD). If the interface does
any DAD failure indications within RetransTimer milliseconds (see not receive any DAD failure indications within RetransTimer
[RFC4861]) after having sent DupAddrDetectTransmits Neighbor milliseconds (see [RFC4861]) after having sent DupAddrDetectTransmits
Solicitations, the interface moves the Target Address to the assigned Neighbor Solicitations, the interface moves the Target Address to the
state. assigned 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 milliseconds apart. Section 2 of
looped back within RetransTimer milliseconds after [RFC3971] defines a single-use nonce, so each Enhanced DAD probe uses
MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, the probing stops. a different nonce. If no probe is looped back within RetransTimer
The probing MAY be stopped via manual intervention. When probing is milliseconds after MAX_MULTICAST_SOLICIT NS(DAD) messages are sent,
stopped, the interface moves the Target Address to the assigned the probing stops. The probing MAY be stopped via manual
state. intervention. When probing is stopped, the interface moves the
Target Address to the assigned state.
4.3. Processing Rules for Receivers 4.2. 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, with any saved nonce on the receiving interface. If a match message, with any stored nonce on the receiving interface. If a
is found, the node SHOULD log a system management message, SHOULD match is found, the node SHOULD log a system management message,
update any statistics counter, and MUST drop the received message. SHOULD update any statistics counter, and MUST drop the received
message. If the received NS(DAD) message includes a nonce and no
If the received NS(DAD) message includes a nonce and no match is match is found with any stored nonce, the node SHOULD log a system
found with any saved nonce, the node SHOULD log a system management management message for a DAD-failed state, and SHOULD update any
message for a DAD-failed state, and SHOULD update any statistics statistics counter.
counter. If the interface does not receive any DAD failure
indications within RetransTimer milliseconds after having sent
DupAddrDetectTransmits Neighbor Solicitations, the interface moves
the Target Address to the assigned state.
4.4. Impact on SEND 4.3. 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. As 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 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 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.4. 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
a hundred thousand 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 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 thousand 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
skipping to change at page 9, line 9 skipping to change at page 8, line 47
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.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.7. Changes to RFC 3971 4.6. 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.
The 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
skipping to change at page 10, line 5 skipping to change at page 9, line 45
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 networks such as an access network,
if 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 recommended. actions are recommended.
One access network is a cable broadband deployment where the access One example of a type of access network is cable broadband deployment
concentrator is the first-hop IPv6 router to several hundred thousand where the access concentrator is the first-hop IPv6 router to several
broadband modems. The router also supports proxying of DAD messages. hundred thousand broadband modems. The router also supports proxying
The network interface on the access concentrator initiates DAD for an of DAD messages. The network interface on the access concentrator
IPv6 address and detects a genuine duplicate due to receiving an initiates DAD for an IPv6 address and detects a genuine duplicate due
NS(DAD) or an NA message. On detecting such a duplicate, the access to receiving an NS(DAD) or an NA message. On detecting such a
concentrator logs a system management message, drops the received ND duplicate, the access concentrator logs a system management message,
message, and blocks the modem on whose layer-2 service identifier the drops the received ND message, and blocks the modem on whose layer-2
NS(DAD) or NA message was received on. service identifier the 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 duplicated by a trusted router has a tentative or optimistic address duplicated by a
host. Any other network that follows the same trust model MAY use host. Any other network that follows the same trust model MAY use
the automated actions proposed in this section. the automated actions proposed in this section.
6. Security Considerations 6. Security Considerations
The nonce can be exploited by a rogue deliberately changing the nonce This document does not improve nor reduce the security posture of
to fail the looped back detection specified by the Enhanced DAD [RFC4862]. The nonce can be exploited by a rogue deliberately
algorithm. SEND is recommended to circumvent this exploit. changing the nonce to fail the looped back detection specified by the
Additionally, the nonce does not protect against the DoS caused by a Enhanced DAD algorithm. SEND is recommended to circumvent this
rogue node replying by a fake NA to all DAD probes. SEND is exploit. Additionally, the nonce does not protect against the DoS
recommended to circumvent this exploit also. Disabling DAD has an 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
obvious security issue before a remote node on the link can issue obvious security issue before a remote node on the link can issue
reflected NS(DAD) messages. Again, SEND is recommended for this reflected NS(DAD) messages. Again, SEND is recommended for this
exploit. exploit. Source Address Validation Improvement (SAVI) [RFC6620] also
protects against various attacks by on-link rogues.
7. IANA Considerations 7. IANA Considerations
None. None.
8. Acknowledgements 8. Acknowledgements
Thanks (in alphabetical order by first name) to Bernie Volz, Dmitry Thanks (in alphabetical order by first name) to Bernie Volz, Dmitry
Anipko, Eric Levy-Abegnoli, Eric Vyncke, Erik Nordmark, Fred Templin, Anipko, Eric Levy-Abegnoli, Eric Vyncke, Erik Nordmark, Fred Templin,
Jouni Korhonen, Michael Sinatra, Ole Troan, Ray Hunter, Suresh Jouni Korhonen, Michael Sinatra, Ole Troan, Pascal Thubert, Ray
Krishnan, and Tassos Chatzithomaoglou for their guidance and review Hunter, Suresh Krishnan, and Tassos Chatzithomaoglou for their
of the document. Thanks to Thomas Narten for encouraging this work. guidance and review of the document. Thanks to Thomas Narten for
Thanks to Steinar Haug and Scott Beuker for describing the use cases. encouraging this work. Thanks to Steinar Haug and Scott Beuker for
describing the use cases.
9. Normative References 9. Normative References
[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.
skipping to change at page 11, line 21 skipping to change at page 11, line 18
[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.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses", RFC
6620, May 2012.
Authors' Addresses Authors' Addresses
Rajiv Asati Rajiv Asati
Cisco Systems, Inc. Cisco Systems, Inc.
7025 Kit Creek road 7025 Kit Creek road
Research Triangle Park, NC 27709-4987 Research Triangle Park, NC 27709-4987
USA USA
Email: rajiva@cisco.com Email: rajiva@cisco.com
URI: http://www.cisco.com/ URI: http://www.cisco.com/
 End of changes. 26 change blocks. 
104 lines changed or deleted 104 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/