Network Working Group                                           R. Asati
Internet-Draft                                                  H. Singh
Updates: 4862, 4861, 3971 4429 (if approved)                        W. Beebee
Intended status: Standards Track                            C. Pignataro
Expires: May 17, July 18, 2015                               Cisco Systems, Inc.
                                                                 E. Dart
                                   Lawrence Berkeley National Laboratory
                                                               W. George
                                                       Time Warner Cable
                                                       November 13, 2014
                                                        January 14, 2015

                  Enhanced Duplicate Address Detection
                    draft-ietf-6man-enhanced-dad-10
                    draft-ietf-6man-enhanced-dad-11

Abstract

   IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are
   discussed in Appendix A of RFC4862.  That specification mentions a
   hardware-assisted mechanism to detect looped back DAD messages.  If
   hardware cannot suppress looped back DAD messages, a software
   solution is required.  Several service provider communities have
   expressed a need for automated detection of looped backed back Neighbor
   Discovery (ND) messages used by DAD.  This document includes
   mitigation techniques and outlines the Enhanced DAD algorithm to
   automate the detection of looped back IPv6 ND messages used by DAD.
   For network loopback tests, the Enhanced DAD algorithm allows IPv6 to
   self-heal after a loopback is placed and removed.  Further, for
   certain access networks the document automates resolving a specific
   duplicate address conflict.  This document updates RFC4861, RFC4862,
   and RFC3971.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 17, July 18, 2015.

Copyright Notice

   Copyright (c) 2014 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Two Deployment Problems  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Problem Statement . . . .   4
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   3.  Operational Mitigation Options  . . . . . . . . . . . . . . .   5   4
     3.1.  Disable DAD on an Interface . . . . . . . . . . . . . . .   5   4
     3.2.  Dynamic Disable/Enable of DAD Using Layer-2 Protocol  . .   5
     3.3.  Operational Considerations  . . . . . . . . . . . . . . .   6   5
   4.  The Enhanced DAD Algorithm  . . . . . . . . . . . . . . . . .   6
     4.1.  Processing Rules for Senders  . . . . . . . . . . . . . .   7   6
     4.2.  Processing Rules for Receivers  . . . . . . . . . . . . .   7
     4.3.  Impact on SEND  . . . . . . . . . . . . . . . . . . . . .   8
     4.4.  Changes to RFC 4862 . . . . . . . . . . . . . . . . . . .   8
     4.5.  Changes to RFC 4861 . . . . . . . . . . . . . . . . . . .   8
     4.6.  Changes to RFC 3971 . . . . . . . . . . . . . . . . . . .   9   7
   5.  Actions to Perform on Detecting a Genuine Duplicate . . . . .   9   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10   8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10   8
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  10   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11   9

1.  Introduction

   IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are
   discussed in Appendix A of [RFC4862].  That specification mentions a
   hardware-assisted mechanism to detect looped back DAD messages.  If
   hardware cannot suppress looped back DAD messages, a software
   solution is required.  One specific DAD message is the Neighbor
   Solicitation (NS), specified in [RFC4861].  The NS is issued by the
   network interface of an IPv6 node for DAD.  Another message involved
   in DAD is the Neighbor Advertisement (NA).  The Enhanced DAD
   algorithm specified in this document focuses on detecting an NS
   looped back to the transmitting interface during the DAD operation.

   Detecting a looped back NA does not solve the looped back DAD
   problem.  Detection of any other looped back ND messages during the
   DAD operation is outside the scope of this document.  This document
   also includes a section on Mitigation that discusses means already
   available to mitigate the DAD loopback problem.  This document
   updates RFC4861, RFC4862, and RFC3971.

1.1.  Two Deployment Problems

   In each problem articulated below, the IPv6 link-local address  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2.  Terminology

   o  DAD-failed state - Duplication Address Detection failure as
      specified in [RFC4862].  Note even Optimistic DAD
   operation fails as specified in
      [RFC4429] can fail due to a looped back DAD probe.  However, the  This document
      covers looped back DAD probe exists detection for any IPv6 address type including global
   addresses.

   Recently, service providers have reported a problem with Optimistic DAD that is
   caused by looped as well.

   o  Looped back NS messages.  The following is message - also referred to as a description of
   the circumstances under which reflected message.
      The message sent by the problem arises.  Loopback testing
   for troubleshooting purposes sender is underway on a circuit connected received by the sender due to
      the network or an
   interface on a router.  The interface Upper Layer Protocol on the router is enabled sender looping the
      message back.

   o  Loopback - A function in which the router's layer-3 interface (or
      the circuit to which the router's interface is connected) is
      looped back or connected to itself.  Loopback causes packets sent
      by the interface to be received by the interface and results in
      interface unavailability for regular data traffic forwarding.  See
      more details in section 9.1 of [RFC2328].  The Loopback function
      is commonly used in an interface context to gain information on
      the quality of the interface, by employing mechanisms such as
      ICMPv6 pings and bit-error tests.  In a circuit context, this
      function is used in wide area environments including optical Dense
      Wave Division Multiplexing (DWDM) and SONET/SDH for fault
      isolation (e.g. by placing a loopback at different geographic
      locations along the path of a wide area circuit to help locate a
      circuit fault).  The Loopback function may be employed locally or
      remotely.

   o  NS(DAD) - shorthand notation to denote an Neighbor Solicitation
      (NS) (as specified in [RFC4861]) with unspecified IPv6 source-
      address issued during DAD.

2.  Problem Statement

   Recently, service providers have reported a problem with DAD that
   arises under the following sets of circumstances: In the first,
   loopback testing for
   IPv6. 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 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  In the second scenario, two broadband
   modems are other conditions which will also trigger similar problems
   with DAD Loopback.  While served by the following example is not a common
   configuration, it has occurred in a large same service provider network.
   It is necessary and terminate 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 an IPv6-enabled access concentrator.  The two modems have  In
   this case, the two modems' Ethernet ports of each modem interfaces are also connected to
   a common local network hub. (collision domain).  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. address of its
   layer-3 interface.  The NS message reaches one modem first and this
   modem sends the message to the
   network hub which sends the message to local network, where the second modem which
   forwards
   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 up to a hundred thousand thousands of broadband modems causing
   modems, and all the modems (and hosts behind the modems) to fail to get would have their IPv6
   online on connectivity affected until the access network.
   DAD-failed state is cleared.  Additionally, it may be tedious difficult for
   the user of the access concentrator to find out which determine the source of the hundred
   thousand or more homes
   looped back the DAD message.  Clearly  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.

2.  Terminology

   o  DAD-failed state - Duplication Address Detection failure as
      specified in [RFC4862].  Note even Optimistic

   Note: In both examples above, the IPv6 link-local address DAD as specified in
      [RFC4429] can fail
   operation fails due to a looped back DAD probe.  This document
      covers  However, the problem
   of a looped back detection for Optimistic DAD as well.

   o  Looped back message - also referred to as a reflected message.
      The message sent by the sender is received by the sender due probe exists for any IPv6 address type including
   global addresses.

3.  Operational Mitigation Options

   Two mitigation options are described below that do not require any
   change to
      the network or existing implementations.

3.1.  Disable DAD on an Upper Layer Protocol Interface

   One can disable DAD on an interface so that there are no NS(DAD)
   messages issued.  While this mitigation may be the sender looping the
      message back.

   o  Loopback - A function in which simplest, the router's layer-3 interface (or
      the circuit to which the router's interface is connected) is
      looped back or connected to itself.  Loopback causes packets sent
      by the interface to be received by the interface and results in
      interface unavailability for regular data traffic forwarding.  See
      more details in section 9.1 of [RFC2328].  The Loopback function
      is commonly used in an interface context to gain information on
      the quality of the interface, by employing mechanisms such as
      ICMPv6 pings and bit-error tests.  In a circuit context, this
      function is used in wide area environments including optical Dense
      Wave Division Multiplexing (DWDM) and SONET/SDH for fault
      isolation (e.g. by placing a loopback at different geographic
      locations along the path of a wide area circuit to help locate a
      circuit fault).  The Loopback function may be employed locally or
      remotely.

   o  NS(DAD) - shorthand notation to denote an Neighbor Solicitation
      (NS) (as specified in [RFC4861]) with unspecified IPv6 source-
      address issued during DAD.

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Operational Mitigation Options

   Two mitigation options are described below.  The mechanisms do not
   require any change to existing implementations.

3.1.  Disable DAD on an Interface

   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
   DupAddrDetectTransmits variable to zero.  While this mitigation may
   be the simplest, the mitigation has three drawbacks.

   This mitigation would likely require careful analysis of
   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
   core router, SHOULD support this mitigation strategy.

3.2.  Dynamic Disable/Enable of DAD Using Layer-2 Protocol

   One or more layer-2 protocols MAY include provisions to detect the
   existence of a loopback on an interface circuit, usually by comparing
   protocol data sent and received.  For example, the Point-to-Point
   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
   interface circuit, the device MUST temporarily disable DAD on the
   interface.  When the protocol detects that a loopback is no longer
   present (or the interface state has changed), the device MUST
   (re-)enable DAD on that interface.

   This solution requires no protocol changes.  This solution SHOULD be
   enabled by default, and MUST be a configurable option if the layer-2
   technology provides means for detecting loopback messages on an
   interface circuit.

   This mitigation has several benefits.  They are

   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
       requires no additional state or timer.  This may be a significant
       scaling consideration on devices with hundreds or thousands of
       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

   The mitigation options discussed in the document do not require the
   devices on both ends of the circuit to support the mitigation
   functionality simultaneously, and do not propose any capability
   negotiation.  The
   mitigation options discussed in this document are
   effective for unidirectional circuit or interface loopback (i.e. the
   the loopback has three drawbacks: 1) care is placed in one direction needed when making such
   configuration changes on the circuit, rendering the
   other direction non-operational).

   The mitigation options may not be effective for the bidirectional
   loopback (i.e. the loopback point-to-point interfaces, 2) this is placed in both directions of the
   circuit interface, so as to identify the faulty segment) if only one
   device followed a mitigation option specified in this document, since
   the other device would follow current behavior one-
   time manual configuration on each interface, and disable IPv6 3) genuine
   duplicates 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 link will not compliant with this document,
   as usual.

4.  The Enhanced DAD Algorithm

   The Enhanced DAD algorithm covers detection of a looped back NS(DAD)
   message.  The document proposes use of the Nonce Option specified in
   the SEND document of [RFC3971].  The nonce is a random number be detected.

   A Service Provider router, such as
   specified in [RFC3971].  If SEND is enabled on the router and the
   router also supports the Enhanced DAD algorithm (specified in an access concentrator, or network
   core router, SHOULD support this
   document), there is integration with the Enhanced mitigation strategy.

3.2.  Dynamic Disable/Enable of DAD algorithm and
   SEND.  (See more details in Using Layer-2 Protocol

   Some layer-2 protocols include provisions to detect the Impact on SEND section 4.3.)  Since a
   nonce is used only once, The NS(DAD) for each IPv6 address existence of
   a loopback on an interface circuit, usually by comparing protocol
   data sent and received.  For example, the Point-to-Point Protocol
   (PPP) uses a different nonce.  Additional details of the
   algorithm are included in section 4.2.

   Six bytes magic number (section 6.4 of random nonce is sufficiently large [RFC1661]) to minimize
   collisions.  However, if there is a collision because two nodes using
   the same Target Address in their NS(DAD) and generated the same
   random nonce, then the algorithm will incorrectly detect a looped
   back NS(DAD) when
   loopback on an interface.

   When a genuine address collision has occurred.  Since
   each looped back NS(DAD) event layer-2 protocol detects that a loopback is logged to system management, the
   administrator of present on an
   interface circuit, the network will have access to device MUST temporarily disable DAD on the information
   necessary to intervene manually.  Also, because
   interface.  When the nodes will have
   detected what appear to be looped back NS(DAD) messages, they will
   continue to probe, and it is unlikely protocol detects that they will choose a loopback is no longer
   present (or the same
   nonce interface state has changed), the second time (assuming quality random number generators).

   The algorithm is capable of detecting any ND solicitation (NS and
   Router Solicitation) device MUST
   (re-)enable DAD on that interface.

   This mitigation has several benefits.  It leverages the layer-2
   protocol's built-in loopback detection capability, if available.  It
   scales better since it relies on an event-driven model which requires
   no additional state or advertisement (NA and Router Advertisement) timer.  This may be significant on devices
   with hundreds or thousands of interfaces that is looped back.  However, may be in loopback for a sender to store a nonce
   long periods of time (e.g., awaiting turn-up).

   This solution SHOULD be enabled by default, and
   nonce related state MUST be a
   configurable option if the layer-2 technology provides means for all ND
   detecting loopback messages has impact on memory and
   causes more complexity for the sender node.  Therefore, this document
   does an interface circuit.

3.3.  Operational Considerations

   The mitigation options discussed above do not recommend using require the algorithm outside devices on
   both ends of the DAD operation
   by an interface on a node.

4.1.  Processing Rules for Senders

   If a node has been configured circuit to use support the Enhanced DAD algorithm, when
   sending an NS(DAD) mitigation functionality
   simultaneously, and do not propose any capability negotiation.  They
   are effective for a tentative unidirectional circuit or optimistic interface address
   the sender MUST generate a random nonce associated with the interface
   address, MUST store the nonce internally, and MUST include loopback (i.e.
   the nonce
   in the Nonce Option included loopback is placed in one direction on the NS(DAD).  If circuit, rendering
   the interface does other direction non-operational), but they may not receive any DAD failure indications within RetransTimer
   milliseconds (see [RFC4861]) after having sent DupAddrDetectTransmits
   Neighbor Solicitations, be effective
   for a bidirectional loopback (i.e. the interface moves loopback is placed in both
   directions of the Target Address circuit interface, so as to identify the
   assigned state.

   If any probe faulty
   segment).  This is looped back within RetransTimer milliseconds after
   having sent DupAddrDetectTransmits NS(DAD) messages, because unless both ends followed a mitigation
   option specified in this document, the non-compliant device would
   follow current behavior and disable IPv6 on that interface
   continues with another MAX_MULTICAST_SOLICIT number due to DAD
   until manual intervention restores it.

4.  The Enhanced DAD Algorithm

   The Enhanced DAD algorithm covers detection of a looped back NS(DAD)
   messages transmitted RetransTimer milliseconds apart.  Section 2
   message.  The document proposes use of a random number in the Nonce
   Option specified in SEND [RFC3971].  Note [RFC3971] defines does not provide
   a single-use nonce, so recommendation for pseudo-random functions.  Pseudo-random
   functions are covered in [RFC4086].  Since a nonce is used only once,
   the NS(DAD) for each Enhanced DAD probe IPv6 address of an interface uses a different
   nonce.  If no probe is looped back within RetransTimer
   milliseconds after MAX_MULTICAST_SOLICIT NS(DAD) messages are sent,  Additional details of the probing stops.  The probing MAY be stopped via manual
   intervention.  When probing algorithm are included in section
   4.2.

   If there is stopped, the interface moves a collision because two nodes using the same Target
   Address to the assigned state.

4.2.  Processing Rules for Receivers

   If in their NS(DAD) and generated the node has been configured to use same random nonce, then
   the Enhanced DAD algorithm and
   an interface on the node receives any will incorrectly detect a looped back NS(DAD) message where when a
   genuine address collision has occurred.  Since each looped back
   NS(DAD) event is logged to system management, the
   Target Address matches administrator of
   the interface address (in tentative or
   optimistic state), network will have access to the receiver compares information necessary to
   intervene manually.  Also, because the nonce included in nodes will have detected what
   appear to be looped back NS(DAD) messages, they will continue to
   probe, and it is unlikely that they will choose the
   message, with any stored same nonce on the receiving interface.  If a
   match
   second time (assuming quality random number generators).

   The algorithm is found, the node SHOULD log a system management message,
   SHOULD update capable of detecting any statistics counter, ND solicitation (NS and MUST drop the received
   message.  If the received NS(DAD) message includes a nonce
   Router Solicitation) or advertisement (NA and no
   match Router Advertisement)
   that is found with any stored nonce, looped back.  However, there may be increased implementation
   complexity and memory usage for the sender node SHOULD log a system
   management message for to store a DAD-failed state, nonce and SHOULD update any
   statistics counter.

4.3.  Impact on SEND

   The SEND
   nonce related state for all ND messages.  Therefore, this document uses the Nonce Option in
   does not recommend using the context algorithm outside of matching an
   NA with the DAD operation
   by an NS.  However, no text in SEND interface on a node.

4.1.  Processing Rules for Senders

   If a node has an explicit mention of
   detecting looped back ND messages.  As this document updates
   [RFC4862], SEND should be updated been configured to integrate with use 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 algorithm, when
   sending an NS(DAD) messages during DAD operations by for a tentative or optimistic interface address
   the node.  In sender MUST generate a mixed SEND
   environment random nonce associated with SEND and unsecured nodes, the lengths of interface
   address, MUST store the nonce
   used by SEND internally, and unsecured nodes MUST be identical.

4.4.  Changes to RFC 4862

   The following text is added to include the end of nonce
   in the Introduction section of
   [RFC4862].

   A network interface of an IPv6 node should implement Nonce Option included in the Enhanced DAD
   algorithm.  For example, if NS(DAD).  If the interface on an IPv6 node is
   connected to a circuit that supports loopback testing, then the node
   should implement the Enhanced does
   not receive any DAD algorithm that allows failure indications within RetransTimer
   milliseconds (see [RFC4861]) after having sent DupAddrDetectTransmits
   Neighbor Solicitations, the IPv6 interface moves the Target Address to self-heal after loopback testing is ended on the
   circuit.  Another example
   assigned state.

   If any probe is when looped back within RetransTimer milliseconds after
   having sent DupAddrDetectTransmits NS(DAD) messages, the IPv6 interface resides on an
   access concentrator running
   continues with another MAX_MULTICAST_SOLICIT number of NS(DAD)
   messages transmitted RetransTimer milliseconds apart.  Section 2 of
   [RFC3971] defines a single-use nonce, so each Enhanced DAD Proxy.  The interface supports up to probe uses
   a hundred thousand IPv6 clients (broadband modems) connected to the
   interface. different nonce.  If the interface performs DAD for its IPv6 link-local
   address and the DAD no probe is reflected looped back to within RetransTimer
   milliseconds after MAX_MULTICAST_SOLICIT NS(DAD) messages are sent,
   the interface, probing stops.  The probing MAY be stopped via manual
   intervention.  When probing is stopped, the interface is stuck in DAD-failed state and IPv6 services moves the
   Target Address to the
   hundred thousand clients is denied.  Disabling DAD assigned state.

4.2.  Processing Rules for such an IPv6
   interface on an access concentrator is less desirable than
   implementing the algorithm because Receivers

   If the network also needs node has been configured to detect
   genuine duplicates in use the interface downstream network.  The Enhanced DAD algorithm also facilitates detecting a genuine duplicate for the and
   an interface on the access concentrator.  (See node receives any NS(DAD) message where the Actions to Perform
   Target Address matches the interface address (in tentative or
   optimistic state), the receiver compares the nonce included in the
   message, with any stored nonce on
   Detecting a Genuine Duplicate section of the Enhanced DAD document.)

   The following text receiving interface.  If a
   match is added to found, the end of Appendix A of [RFC4862].

   The Enhanced DAD algorithm from draft-ietf-6man-enhanced-dad node SHOULD log a system management message,
   SHOULD update any statistics counter, and MUST drop the received
   message.  If the received NS(DAD) message includes a nonce and no
   match is
   designed to detect looped back DAD probes.  A network interface of an
   IPv6 found with any stored nonce, the node SHOULD implement the Enhanced DAD algorithm.

4.5. log a system
   management message for a DAD-failed state, and SHOULD update any
   statistics counter.

4.3.  Changes to RFC 4861

   The following text is appended to the RetransTimer variable
   description in section 6.3.2 of [RFC4861]:

   The RetransTimer may MAY be overridden by a link-specific document if a
   node supports the Enhanced DAD algorithm.

   The following text is appended to the Source Address definition in
   section 4.3 of [RFC4861]:

   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
   message and implements the state machine of the Enhanced DAD
   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

   As described in the paragraphs above, the nonce can also serve to
   detect genuine duplicates even when the network has potential for
   looping back ND messages.  When a genuine duplicate is detected, the
   node follows the manual intervention specified in section 5.4.5 of
   [RFC4862].  However, in certain networks such as an access network, cases, if the genuine duplicate
   matches the tentative or optimistic IPv6 address of a network
   interface of the access concentrator, additional automated actions
   are recommended.

   Some networks follow a trust model where a trusted router serves un-
   trusted IPv6 host nodes.  Operators of such networks have a desire to
   take automated action if a network interface of the trusted router
   has a tentative or optimistic address duplicated by a host.  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
   multiple broadband modems.  The router also 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 logs SHOULD log a system management message,
   drops drop the
   received ND message, and blocks block the modem on whose layer-2 service
   identifier the duplicate NS(DAD) or NA message was received on.

   The network described above follows a trust model where a trusted
   router serves un-trusted IPv6 host nodes.  Operators of such networks
   have a desire to take automated action if a network interface of the
   trusted router has a tentative or optimistic address duplicated by a
   host.  Any
   other network that follows the same trust model MAY use the automated
   actions proposed in this section.

6.  Security Considerations

   This document does not improve nor reduce the security posture of
   [RFC4862].  The nonce can be exploited by a rogue deliberately
   changing the nonce to fail the looped back detection specified by the
   Enhanced DAD algorithm.  SEND is recommended to circumvent this
   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
   is recommended to circumvent this exploit also.  Disabling DAD has an
   obvious security issue before a remote node on the link can issue
   reflected NS(DAD) messages.  Again, SEND is recommended for this
   exploit.  Source Address Validation Improvement (SAVI) [RFC6620] also
   protects against various attacks by on-link rogues.

7.  IANA Considerations

   None.

8.  Acknowledgements

   Thanks (in alphabetical order by first name) to Bernie Volz, Dmitry
   Anipko, Eric Levy-Abegnoli, Eric Vyncke, Erik Nordmark, Fred Templin,
   Jouni Korhonen, Michael Sinatra, Ole Troan, Pascal Thubert, Ray
   Hunter, Suresh Krishnan, and Tassos Chatzithomaoglou for their
   guidance and review of the document.  Thanks to Thomas Narten for
   encouraging this work.  Thanks to Steinar Haug and Scott Beuker for
   describing the use cases.

9.  Normative References

   [RFC1661]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
              RFC 1661, July 1994.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              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)
              for IPv6", RFC 4429, April 2006.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              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

   Rajiv Asati
   Cisco Systems, Inc.
   7025 Kit Creek road
   Research Triangle Park, NC  27709-4987
   USA

   Email: rajiva@cisco.com
   URI:   http://www.cisco.com/

   Hemant Singh
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough, MA  01719
   USA

   Phone: +1 978 936 1622
   Email: shemant@cisco.com
   URI:   http://www.cisco.com/
   Wes Beebee
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough, MA  01719
   USA

   Phone: +1 978 936 2030
   Email: wbeebee@cisco.com
   URI:   http://www.cisco.com/

   Carlos Pignataro
   Cisco Systems, Inc.
   7200-12 Kit Creek Road
   Research Triangle Park, NC  27709
   USA

   Email: cpignata@cisco.com
   URI:   http://www.cisco.com/

   Eli Dart
   Lawrence Berkeley National Laboratory
   1 Cyclotron Road, Berkeley, CA 94720
   USA

   Email: dart@es.net
   URI:   http://www.es.net/

   Wes

   Wesley George
   Time Warner Cable
   13820 Sunrise Valley Drive
   Herndon, VA  20171
   USA

   Email: wesley.george@twcable.com