doc: Add RFC documents

1 files changed, 1104 insertions, 0 deletions

diff --git a/doc/rfc/rfc9131.txt b/doc/rfc/rfc9131.txt
new file mode 100644
index 0000000..8c6816c
--- /dev/null
+++ b/doc/rfc/rfc9131.txt
@@ -0,0 +1,1104 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        J. Linkova
+Request for Comments: 9131                                        Google
+Updates: 4861                                               October 2021
+Category: Standards Track                                               
+ISSN: 2070-1721
+
+
+   Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on
+                           First-Hop Routers
+
+Abstract
+
+   Neighbor Discovery (RFC 4861) is used by IPv6 nodes to determine the
+   link-layer addresses of neighboring nodes as well as to discover and
+   maintain reachability information.  This document updates RFC 4861 to
+   allow routers to proactively create a Neighbor Cache entry when a new
+   IPv6 address is assigned to a node.  It also updates RFC 4861 and
+   recommends that nodes send unsolicited Neighbor Advertisements upon
+   assigning a new IPv6 address.  These changes will minimize the delay
+   and packet loss when a node initiates connections to an off-link
+   destination from a new IPv6 address.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9131.
+
+Copyright Notice
+
+   Copyright (c) 2021 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
+   (https://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
+     1.1.  Requirements Language
+     1.2.  Terminology
+   2.  Problem Statement
+   3.  Solution Requirements
+   4.  Changes to Neighbor Discovery
+     4.1.  Nodes Sending Gratuitous Neighbor Advertisements
+     4.2.  Routers Creating Cache Entries upon Receiving Unsolicited
+           Neighbor Advertisements
+   5.  Avoiding Disruption
+     5.1.  Neighbor Cache Entry Exists in Any State Other Than
+           INCOMPLETE
+     5.2.  Neighbor Cache Entry Is in INCOMPLETE State
+     5.3.  Neighbor Cache Entry Does Not Exist
+       5.3.1.  The Rightful Owner Is Not Sending Packets from the
+               Address
+       5.3.2.  The Rightful Owner Has Started Sending Packets from the
+               Address
+   6.  Modifications to RFC-Mandated Behavior
+     6.1.  Modification to RFC 4861 (Neighbor Discovery for IP version
+           6 (IPv6))
+       6.1.1.  Modification to Section 7.2.5 of RFC 4861
+       6.1.2.  Modification to Section 7.2.6 of RFC 4861
+   7.  Solution Limitations
+   8.  Solutions Considered but Discarded
+     8.1.  Do Nothing
+     8.2.  Change to the Registration-Based Neighbor Discovery
+     8.3.  Host Sending NS to the Router Address from Its GUA
+     8.4.  Host Sending Router Solicitation from Its GUA
+     8.5.  Routers Populating Their Caches by Gleaning from Neighbor
+           Discovery Packets
+     8.6.  Initiating Host-to-Router Communication
+     8.7.  Making the Probing Logic on Hosts More Robust
+     8.8.  Increasing the Buffer Size on Routers
+     8.9.  Transit Data Plane Traffic from a New Address to Trigger
+           Address Resolution
+   9.  IANA Considerations
+   10. Security Considerations
+   11. References
+     11.1.  Normative References
+     11.2.  Informative References
+   Acknowledgements
+   Author's Address
+
+1.  Introduction
+
+   The Neighbor Discovery state machine defined in [RFC4861] assumes
+   that communications between IPv6 nodes are, in most cases,
+   bidirectional and if a node A is trying to communicate to its
+   neighbor, node B, the return traffic flows could be expected.  So,
+   when node A starts the address resolution process, the target node B
+   would also create an entry containing A's IPv6 and link-layer
+   addresses in its Neighbor Cache.  That entry will be used for sending
+   the return traffic to A.
+
+   In particular, Section 7.2.5 of [RFC4861] states:
+
+   |  When a valid Neighbor Advertisement is received (either solicited
+   |  or unsolicited), the Neighbor Cache is searched for the target's
+   |  entry.  If no entry exists, the advertisement SHOULD be silently
+   |  discarded.  There is no need to create an entry if none exists,
+   |  since the recipient has apparently not initiated any communication
+   |  with the target.
+
+   While this approach is perfectly suitable for host-to-host on-link
+   communications, it does not work so well when a host sends traffic to
+   off-link destinations.  After joining the network and receiving a
+   Router Advertisement, the host populates its Neighbor Cache with the
+   default router IPv6 and link-layer addresses and is able to send
+   traffic to off-link destinations.  At the same time, the router does
+   not have any cache entries for the host global addresses yet and only
+   starts address resolution upon receiving the first packet of the
+   return traffic flow.  While waiting for the resolution to complete,
+   routers only keep a very small number of packets in the queue, as
+   recommended in Section 7.2.2 of [RFC4861].  Any additional packets
+   arriving before the resolution process finishes are likely to result
+   in dropped packets.  It can cause packet loss and performance
+   degradation that can be visible to users.
+
+   This document updates the Neighbor Discovery protocol [RFC4861] to
+   avoid packet loss in the scenario described above.  Section 4
+   discusses the changes and analyzes the potential impact, while
+   normative changes to [RFC4861] are specified in Section 6.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+1.2.  Terminology
+
+   Node:  A device that implements IP [RFC4861].
+
+   Host:  Any node that is not a router [RFC4861].
+
+   ND:  Neighbor Discovery [RFC4861].
+
+   NC:  Neighbor Cache [RFC4861].  The Neighbor Cache entry can be in
+      one of five states, as described in Section 7.3.2 of [RFC4861]:
+      INCOMPLETE, REACHABLE, STALE, DELAY, or PROBE.
+
+   SLAAC:  IPv6 Stateless Address Autoconfiguration [RFC4862].
+
+   NS:  Neighbor Solicitation [RFC4861].
+
+   NA:  Neighbor Advertisement [RFC4861].
+
+   RS:  Router Solicitation [RFC4861].
+
+   RA:  Router Advertisement [RFC4861].
+
+   SLLAO:  Source Link-Layer Address Option.  An option in the ND
+      packets containing the link-layer address of the sender of the
+      packet [RFC4861].
+
+   TLLAO:  Target Link-Layer Address Option.  An option in the ND
+      packets containing the link-layer address of the target [RFC4861].
+
+   GUA:  Global Unicast Address [RFC4291].
+
+   DAD:  Duplicate Address Detection [RFC4862].
+
+   Preferred Address:  An address assigned to an interface whose
+      uniqueness has been verified using DAD and whose use by upper-
+      layer protocols is unrestricted [RFC4862].  Preferred addresses
+      may be used as the source address of packets sent from the
+      interface.
+
+   Optimistic DAD:  A modification of DAD [RFC4429].
+
+2.  Problem Statement
+
+   The most typical scenario when the problem described in this document
+   may arise is a host joining the network, forming a new address, and
+   using that address for accessing the Internet:
+
+   1.  A host joins the network and receives a Router Advertisement (RA)
+       packet from the first-hop router (either a periodic unsolicited
+       RA or a response to a Router Solicitation sent by the host).  The
+       RA contains information the host needs to perform SLAAC and to
+       configure its network stack.  The RA is sent from the router's
+       link-local address to a link-local destination address and may
+       contain the link-layer address of the router.  As a result, the
+       host can populate its Neighbor Cache with the router's link-local
+       and link-layer addresses.
+
+   2.  The host starts opening connections to off-link destinations.  A
+       very common use case is a mobile device sending probes to detect
+       Internet connectivity and/or the presence of a captive portal on
+       the network.  To speed up that process, many implementations use
+       Optimistic DAD, which allows them to send probes before the DAD
+       process is completed.  At that moment, the device's Neighbor
+       Cache contains all information required to send those probes
+       (such as the default router link-local and link-layer addresses).
+       The router's Neighbor Cache, however, might contain an entry for
+       the device's link-local address (if the device has been
+       performing address resolution for the router's link-local
+       address), but there are no entries for any of the device's global
+       addresses.
+
+   3.  Return traffic is received by the first-hop router.  As the
+       router does not have any cache entry for the host's global
+       address yet, the router starts the Neighbor Discovery process by
+       creating an INCOMPLETE cache entry and then sending a Neighbor
+       Solicitation to the solicited-node multicast address
+       (Section 7.3.2 of [RFC4861]).  As per Section 7.2.2 of [RFC4861],
+       routers MUST buffer at least one data packet and MAY buffer more,
+       while resolving the packet destination address.  However, most
+       router implementations limit the buffer size to a few packets
+       only, and some implementations are known to buffer just one
+       packet.  So, any subsequent packets arriving before the address
+       resolution process is completed cause packet loss by replacing
+       older packets in the buffer.
+
+   4.  If the host sends multiple probes in parallel, in the worst case,
+       it would consider all but one of them failed.  That leads to
+       user-visible delay in connecting to the network, especially if
+       the host implements some form of backoff mechanism and does not
+       retransmit the probes as soon as possible.
+
+   This scenario illustrates the problem occurring when the device
+   connects to the network for the first time or after an inactivity
+   period long enough for the device's address to be removed from the
+   router's Neighbor Cache.  However, the same sequence of events
+   happens when the host starts using a new global address previously
+   unseen by the router, such as a new privacy address [RFC8981] or if
+   the router's Neighbor Cache has been flushed.
+
+   While in dual-stack networks this problem might be hidden by Happy
+   Eyeballs [RFC8305], it manifests quite clearly in IPv6-only
+   environments, especially wireless environments, leading to poor user
+   experience and contributing to a negative perception of IPv6-only
+   solutions as unstable and non-deployable.
+
+3.  Solution Requirements
+
+   It would be highly desirable to improve the Neighbor Discovery
+   mechanics so routers have a usable cache entry for a host address by
+   the time the router receives the first packet for that address.  In
+   particular:
+
+   *  If the router does not have a Neighbor Cache entry for the
+      address, a STALE entry needs to be created proactively, prior to
+      arrival of the first packet intended for that address.
+
+   *  The solution needs to work for Optimistic Addresses as well.
+      Devices implementing Optimistic DAD usually attempt to minimize
+      the delay in connecting to the network and therefore are more
+      likely to be affected by the problem described in this document.
+
+   *  In the case of duplicate addresses present in the network, the
+      solution should not override the existing entry.
+
+   *  In topologies with multiple first-hop routers, the cache needs to
+      be updated on all of them, as traffic might be asymmetric:
+      outgoing flows leaving the network via one router while the return
+      traffic enters the segment via another one.
+
+   In addition, the solution must not exacerbate issues described in
+   [RFC6583] and needs to be compatible with the recommendations
+   provided in [RFC6583].
+
+4.  Changes to Neighbor Discovery
+
+   The following changes are required to minimize the delay in creating
+   new entries in a router's Neighbor Cache:
+
+   *  A node sends unsolicited NAs upon assigning a new IPv6 address to
+      its interface.
+
+   *  A router creates a new cache entry upon receiving an unsolicited
+      NA from a host.
+
+   The following sections discuss these changes in more detail.
+   Normative changes are specified in Section 6.
+
+4.1.  Nodes Sending Gratuitous Neighbor Advertisements
+
+   Section 7.2.6 of [RFC4861] discusses using unsolicited Neighbor
+   Advertisements to inform node neighbors of the new link-layer address
+   quickly.  The same mechanism could be used to notify the node
+   neighbors about the new network-layer address as well: the node can
+   send unsolicited Neighbor Advertisements upon assigning a new IPv6
+   address to its interface.
+
+   To minimize potential disruption in the case of duplicate addresses,
+   the node should not set the Override flag for a preferred address and
+   must not set the Override flag if the address is in the Optimistic
+   state [RFC4429].
+
+   As the main purpose of sending unsolicited NAs upon configuring a new
+   address is to proactively create a Neighbor Cache entry on the first-
+   hop routers, the gratuitous NAs are sent to the all-routers multicast
+   address (ff02::2).  Limiting the recipients to routers only would
+   help reduce the multicast noise level.  If the link-layer devices are
+   performing Multicast Listener Discovery (MLD) snooping [RFC4541],
+   then those unsolicited NAs will only be sent to routers on the given
+   network segment/link, instead of being flooded to all nodes.
+
+   It should be noted that the mechanism discussed here does not cause
+   any significant increase in multicast traffic.  The additional
+   multicast unsolicited NAs would proactively create a STALE cache
+   entry on the router, as discussed below.  When the router receives
+   the return traffic flows, it does not need to send multicast NSes to
+   the solicited-node multicast address but would send unicast NSes
+   instead.  Therefore, this procedure would only produce an increase in
+   the overall amount of multicast traffic if no return traffic arrives
+   for the address that sent the unsolicited NA or if the router does
+   not create a STALE entry upon receiving such an NA.  The increase
+   would be negligible, as that additional traffic is a few orders of
+   magnitude less than the usual level of Neighbor Discovery multicast
+   traffic.
+
+4.2.  Routers Creating Cache Entries upon Receiving Unsolicited Neighbor
+      Advertisements
+
+   Section 7.2.5 of [RFC4861] states:
+
+   |  When a valid Neighbor Advertisement is received (either solicited
+   |  or unsolicited), the Neighbor Cache is searched for the target's
+   |  entry.  If no entry exists, the advertisement SHOULD be silently
+   |  discarded.  There is no need to create an entry if none exists,
+   |  since the recipient has apparently not initiated any communication
+   |  with the target.
+
+   The reasoning behind dropping unsolicited Neighbor Advertisements
+   ("the recipient has apparently not initiated any communication with
+   the target") is valid for on-link host-to-host communication but, as
+   discussed in Section 1, it does not really apply to the scenario when
+   the host is announcing its address to routers.  Therefore, it would
+   be beneficial to allow routers to create new entries upon receiving
+   an unsolicited Neighbor Advertisement.
+
+   This document updates [RFC4861] so that routers create a new Neighbor
+   Cache entry upon receiving an unsolicited Neighbor Advertisement for
+   an address that does not already have a Neighbor Cache entry.  These
+   changes do not modify the router behavior specified in [RFC4861] for
+   the scenario when the corresponding Neighbor Cache entry already
+   exists.
+
+   The next section analyzes various scenarios of duplicate addresses
+   and discusses the potential impact of creating a STALE entry for a
+   duplicate IPv6 address.
+
+5.  Avoiding Disruption
+
+   If nodes following the recommendations in this document are using the
+   DAD mechanism defined in [RFC4862], they would send unsolicited NAs
+   as soon as the address changes state from tentative to preferred
+   (after its uniqueness has been verified).  However, nodes willing to
+   minimize network stack configuration delays might be using Optimistic
+   Addresses, which means there is a possibility of the address not
+   being unique on the link.  Section 2.2 of [RFC4429] discusses
+   measures to ensure that ND packets from the Optimistic Address do not
+   override any existing Neighbor Cache entries, as it would cause
+   interruption of the rightful address owner's traffic in the case of
+   an address conflict.  Nodes that are willing to speed up their
+   network stack configuration are most likely to be affected by the
+   problem outlined in this document; therefore, it seems reasonable for
+   such hosts to advertise their Optimistic Addresses by sending
+   unsolicited NAs.  The main question to consider is the potential risk
+   of overriding the cache entry for the rightful address owner if the
+   Optimistic Address happens to be a duplicate.
+
+   The following sections discuss the address collision scenario when a
+   node sends an unsolicited NA for an address in the Optimistic state,
+   while another node (the rightful owner) already has the same address
+   assigned.  This document uses the term "the rightful owner", as the
+   same terminology is used in [RFC4429].  The analysis assumes that the
+   host performs DAD, as Section 5.4 of [RFC4862] requires that DAD MUST
+   be performed on all unicast addresses prior to assigning them to an
+   interface.
+
+5.1.  Neighbor Cache Entry Exists in Any State Other Than INCOMPLETE
+
+   If the router's Neighbor Cache entry for the target address already
+   exists in any state other than INCOMPLETE, then as per Section 7.2.5
+   of [RFC4861], an unsolicited NA with the Override flag cleared would
+   change the entry state from REACHABLE to STALE but would not update
+   the entry in any other way.  Therefore, even if the host sends an
+   unsolicited NA from its Optimistic Address, the router's cache entry
+   would not be updated with the new link-layer address, and no impact
+   on the traffic for the rightful address owner is expected.
+
+   The return traffic intended for the host with the Optimistic Address
+   would be sent to the rightful owner.  However, this is unavoidable
+   with or without the unsolicited NA mechanism.
+
+5.2.  Neighbor Cache Entry Is in INCOMPLETE State
+
+   Another corner case is the INCOMPLETE cache entry for the address.
+
+   1.  The router receives a packet for the rightful owner of the
+       address.
+
+   2.  The router starts the address resolution process by creating an
+       INCOMPLETE entry and sends the multicast NS.
+
+   3.  More packets arrive at the router for the address in question.
+
+   4.  The host configures an Optimistic Address and sends an
+       unsolicited NA.
+
+   5.  The router creates a STALE entry and sends the buffered packet(s)
+       to the host (while at least some of those packets are actually
+       intended for the rightful owner).
+
+   6.  As the STALE entry was used to send packets, the router changes
+       the entry state to DELAY and waits up to DELAY_FIRST_PROBE_TIME
+       (5 seconds) [RFC4861] before sending a unicast NS.
+
+   7.  The rightful owner responds to the multicast NS sent at Step 2
+       with a solicited NA with the Override flag set.
+
+   8.  The router updates the entry with the TLLAO supplied (the
+       rightful owner's link-layer address) and sets the entry state to
+       REACHABLE (as the NA has the Solicited flag set).
+
+   As a result, some packets (packets in the buffer at Step 6 and all
+   packets arriving between Step 6 and Step 8) are delivered to the host
+   with the Optimistic Address, while some of them, if not all, are
+   intended for the rightful owner.  Without the unsolicited NA, one or
+   more packets that are in the buffer at Step 8 (usually just one
+   packet, but some routers may buffer a few) would have been delivered
+   to the rightful owner and the rest of the packets would have been
+   dropped.  However, the probability of such a scenario is rather low,
+   as it would require the following things to happen almost
+   simultaneously (within tens of milliseconds in most cases):
+
+   *  One host starts using a new IPv6 address and sending traffic
+      without sending an unsolicited NA first.
+
+   *  Another host configures the same IPv6 address in Optimistic mode
+      before the router completes the address resolution process for the
+      rightful owner.
+
+   It should be noted that in this scenario the rightful owner does not
+   send any unsolicited NAs before sending packets.  If the rightful
+   owner implements the functionality described in this document and
+   sends unsolicited NAs upon configuring its address, then the router
+   creates a STALE entry for the address, causing all packets to be
+   delivered to the rightful owner (see Section 5.1).  The rightful
+   owner would experience no disruption but might receive some packets
+   intended for the host with an Optimistic Address.
+
+   This section focuses on the scenario when the solicited NA from the
+   rightful owner arrives after the unsolicited one sent from the
+   Optimistic Address (Step 7 and Step 4, respectively).  If the
+   solicited NA arrives first, it changes the NC entry state from
+   INCOMPLETE to REACHABLE.  As discussed in Section 5.1, there will be
+   no disruption for the rightful owner if the router already has a
+   REACHABLE entry for the address when an unsolicited NA is received.
+
+5.3.  Neighbor Cache Entry Does Not Exist
+
+   There are two distinct scenarios that can lead to the situation when
+   the router does not have an NC entry for the IPv6 address:
+
+   1.  The rightful owner of the address has not been using it for off-
+       link communication recently or has never used it at all.
+
+   2.  The rightful owner just started sending packets from that
+       address, but the router has not received any return traffic yet.
+
+   The impact on the rightful owner's traffic flows would be different
+   in those cases.
+
+5.3.1.  The Rightful Owner Is Not Sending Packets from the Address
+
+   In this scenario, the following events are expected to happen:
+
+   1.  The host configures the address and sets its state to Optimistic.
+
+   2.  The host sends an unsolicited NA with the Override flag set to
+       zero and starts sending traffic from the Optimistic Address.
+
+   3.  The router creates a STALE entry for the address and the host
+       link-layer address.
+
+   4.  The host starts DAD and detects the address duplication.
+
+   5.  The router receives the return traffic for the duplicate address.
+       As the NC entry is STALE, it sends traffic using that entry,
+       changes it to DELAY, and waits up to DELAY_FIRST_PROBE_TIME
+       seconds [RFC4861].
+
+   6.  The router changes the NC entry state to PROBE and sends up to
+       MAX_UNICAST_SOLICIT unicast NSes [RFC4861] separated by
+       RetransTimer milliseconds [RFC4861] to the host link-layer
+       address.
+
+   7.  As the host has already detected the address conflict, it does
+       not respond to the unicast NSes.  (It is unlikely that the host
+       has not completed the DAD process at this stage, as
+       DELAY_FIRST_PROBE_TIME (5 seconds) is much higher than the DAD
+       duration (DupAddrDetectTransmits*RetransTimer*1000 +
+       MAX_RTR_SOLICITATION_DELAY seconds) (Section 5.4 of [RFC4862]).)
+       The default value for the DAD process would be 1*1*1000 + 1 = 2
+       seconds [RFC4861].  If the host has completed DAD but did not
+       detect the address conflict, then there are two hosts with the
+       same address in the preferred state and disruption is inevitable
+       anyway.
+
+   8.  As the router receives no response for the unicast NSes, it
+       deletes the NC entry.
+
+   9.  If return packets for communication initiated at Step 2 are still
+       arriving, the router buffers a small number of those packets and
+       starts the address resolution process again by sending a
+       multicast NS to the solicited-node multicast address.  The
+       rightful owner responds, and the router's NC entry is updated
+       with the rightful owner's link-local address.  The buffered
+       packet or packets are sent to that address.  Any packets still
+       arriving after the address resolution process has completed are
+       sent to the rightful address owner as well.
+
+   The rightful owner is not experiencing any disruption, as it does not
+   send any traffic.  It would only start receiving packets intended for
+   another host after Step 8 is completed and only if return packets for
+   the communication initiated at Step 2 are still arriving.
+
+   However, the same behavior would be observed if the changes specified
+   in this document are not implemented.  If the host starts sending
+   packets from its Optimistic Address but then detects that the address
+   is a duplicate, the first return packet would trigger the address
+   resolution process and would be buffered until the resolution is
+   completed.  The buffered packet(s) and any packets still arriving
+   after the address is resolved would be forwarded to the rightful
+   owner of the address.  So, the rightful owner might still receive one
+   or more packets from the flows intended for another host.  Therefore,
+   it's safe to conclude that the changes specified in this document do
+   not introduce any disruption for the rightful owner of the duplicated
+   address.
+
+5.3.2.  The Rightful Owner Has Started Sending Packets from the Address
+
+   In this scenario, the following events are happening:
+
+   1.   The rightful owner starts sending traffic from the address
+        (e.g., the address has just been configured or has not been
+        recently used).
+
+   2.   The host configures the address and sets its state to
+        Optimistic.
+
+   3.   The host sends an unsolicited NA with the Override flag set to
+        zero and starts sending traffic from the Optimistic Address.
+
+   4.   The router creates a STALE entry for the address and the host
+        link-layer address.
+
+   5.   The host starts DAD and detects the address duplication.
+
+   6.   The router receives the return traffic for the IPv6 address in
+        question.  Some flows are intended for the rightful owner of the
+        duplicate address, while some are for the new host.  As the NC
+        entry is STALE, it sends traffic using that entry, changes it to
+        DELAY, and waits up to DELAY_FIRST_PROBE_TIME seconds [RFC4861].
+
+   7.   The router changes the NC entry state to PROBE and sends up to
+        MAX_UNICAST_SOLICIT unicast NSes [RFC4861] separated by
+        RetransTimer milliseconds [RFC4861] to the host link-layer
+        address.
+
+   8.   As the host has already detected the address conflict, it does
+        not respond to the unicast NSes.
+
+   9.   As the router receives no response for the unicast NSes, it
+        deletes the NC entry.
+
+   10.  The next packet recreates the entry and triggers the resolution
+        process.  The router buffers the packet and sends a multicast NS
+        to the solicited-node multicast address.  The rightful owner
+        responds, and the router's NC entry is updated with the rightful
+        owner's link-local address.
+
+   As a result, the traffic for the address of the rightful owner would
+   be sent to the host with the duplicate address instead.  The duration
+   of the disruption can be estimated as DELAY_FIRST_PROBE_TIME*1000 +
+   (MAX_UNICAST_SOLICIT - 1)*RetransTimer milliseconds.  As per the
+   constants defined in Section 10 of [RFC4861], this interval is equal
+   to 5*1000 + (3 - 1)*1000 = 7000 milliseconds, or 7 seconds.
+
+   However, it should be noted that the probability of such a scenario
+   is rather low.  Similar to the scenario discussed in Section 5.2, it
+   would require the following things to happen almost simultaneously
+   (within tens of milliseconds in most cases):
+
+   *  One host starts using a new IPv6 address and sending traffic
+      without sending an unsolicited NA first.
+
+   *  Another host configures the same IPv6 address in Optimistic mode
+      before the router receives the return traffic for the first host.
+
+   As discussed in Section 5.2, the disruption for the rightful owner
+   can easily be prevented if that node implements the mechanism
+   described in this document.  Sending unsolicited NAs before
+   initiating off-link communication would create a STALE entry in the
+   router's NC and prevent any traffic to that address from being sent
+   to the host with the Optimistic Address (see Section 5.1).
+
+6.  Modifications to RFC-Mandated Behavior
+
+   All normative text in this memo is contained in this section.
+
+6.1.  Modification to RFC 4861 (Neighbor Discovery for IP version 6
+      (IPv6))
+
+6.1.1.  Modification to Section 7.2.5 of RFC 4861
+
+   This document makes the following changes to Section 7.2.5 of
+   [RFC4861]:
+
+   The text in RFC 4861 is as follows:
+
+   |  When a valid Neighbor Advertisement is received (either solicited
+   |  or unsolicited), the Neighbor Cache is searched for the target's
+   |  entry.  If no entry exists, the advertisement SHOULD be silently
+   |  discarded.  There is no need to create an entry if none exists,
+   |  since the recipient has apparently not initiated any communication
+   |  with the target.
+
+   This document updates the text as follows:
+
+   |  When a valid Neighbor Advertisement is received (either solicited
+   |  or unsolicited), the Neighbor Cache is searched for the target's
+   |  entry.  If no entry exists:
+   |  
+   |  *  Hosts SHOULD silently discard the advertisement.  There is no
+   |     need to create an entry if none exists, since the recipient has
+   |     apparently not initiated any communication with the target.
+   |  
+   |  *  Routers SHOULD create a new entry for the target address with
+   |     the link-layer address set to the Target Link-Layer Address
+   |     Option (if supplied).  The entry's reachability state MUST be
+   |     set to STALE.  If the received Neighbor Advertisement does not
+   |     contain the Target Link-Layer Address Option, the advertisement
+   |     SHOULD be silently discarded.
+
+6.1.2.  Modification to Section 7.2.6 of RFC 4861
+
+   This document makes the following changes to Section 7.2.6 of
+   [RFC4861]:
+
+   The text in RFC 4861 is as follows:
+
+   |  Also, a node belonging to an anycast address MAY multicast
+   |  unsolicited Neighbor Advertisements for the anycast address when
+   |  the node's link-layer address changes.
+
+   This document updates the text as follows:
+
+   |  Also, a node belonging to an anycast address MAY multicast
+   |  unsolicited Neighbor Advertisements for the anycast address when
+   |  the node's link-layer address changes.
+   |  
+   |  A node may also wish to notify its first-hop routers when it
+   |  configures a new global IPv6 address so the routers can
+   |  proactively populate their Neighbor Caches with the corresponding
+   |  entries.  In such cases, a node SHOULD send up to
+   |  MAX_NEIGHBOR_ADVERTISEMENT Neighbor Advertisement messages.  If
+   |  the address is preferred, then the Override flag SHOULD NOT be
+   |  set.  If the address is in the Optimistic state, then the Override
+   |  flag MUST NOT be set.  The destination address SHOULD be set to
+   |  the all-routers multicast address.  These advertisements MUST be
+   |  separated by at least RetransTimer seconds.  The first
+   |  advertisement SHOULD be sent as soon as one of the following
+   |  events happens:
+   |  If Optimistic DAD [RFC4429] is used:  A new Optimistic Address is
+   |     assigned to the node interface.
+   |  
+   |  If Optimistic DAD is not used:  An address changes the state from
+   |     tentative to preferred.
+
+7.  Solution Limitations
+
+   The solution described in this document provides some improvement for
+   a node configuring a new IPv6 address and starting to send traffic
+   from it.  However, that approach does not completely eliminate the
+   scenario when a router receives some transit traffic for an address
+   without the corresponding Neighbor Cache entry.  For example:
+
+   *  If the host starts using an already-configured IPv6 address after
+      a long period of inactivity, the router might not have the NC
+      entry for that address anymore, as old/expired entries are
+      deleted.
+
+   *  Clearing the router's Neighbor Cache would trigger packet loss for
+      all actively used addresses removed from the cache.
+
+8.  Solutions Considered but Discarded
+
+   There are other possible approaches to address the problem.  For
+   example:
+
+   *  Just do nothing.
+
+   *  Migrate from the "reactive" Neighbor Discovery [RFC4861] to the
+      registration-based mechanisms [RFC8505].
+
+   *  Create new entries in the router's Neighbor Cache by gleaning from
+      Neighbor Discovery DAD messages.
+
+   *  Initiate bidirectional communication from the host to the router
+      using the host GUA.
+
+   *  Make the probing logic on hosts more robust.
+
+   *  Increase the buffer size on routers.
+
+   *  Transit data plane traffic from an unknown address (an address
+      without the corresponding Neighbor Cache entry) to trigger an
+      address resolution process on the router.
+
+   It should be noted that some of those options are already implemented
+   by some vendors.  The following sections discuss those approaches and
+   the reasons they were discarded.
+
+8.1.  Do Nothing
+
+   One of the possible approaches might be to declare that everything is
+   working as intended and let the upper-layer protocols deal with
+   packet loss.  The obvious drawbacks include:
+
+   *  Unhappy users.
+
+   *  Many support tickets.
+
+   *  More resistance to deploying IPv6 and IPv6-only networks.
+
+8.2.  Change to the Registration-Based Neighbor Discovery
+
+   The most radical approach would be to move away from the reactive ND
+   as defined in [RFC4861] and expand the registration-based ND
+   [RFC6775] [RFC8505] used in IPv6 over Low-Power Wireless Personal
+   Area Networks (6LoWPANs) to the rest of the IPv6 deployments.  This
+   option requires some investigation and discussion.  However,
+   significant changes to the existing IPv6 implementations would be
+   needed, so an unclear adoption timeline makes this approach less
+   preferable than the approach specified in this document.
+
+8.3.  Host Sending NS to the Router Address from Its GUA
+
+   The host could force the creation of a STALE entry for its GUA in the
+   router's Neighbor Cache by sending the following Neighbor
+   Solicitation message:
+
+   *  The NS source address is the host GUA.
+
+   *  The destination address is the default router IPv6 address.
+
+   *  The Source Link-Layer Address Option contains the host link-layer
+      address.
+
+   *  The target address is the host's default router address (the
+      default router address the host received in the RA).
+
+   The main disadvantages of this approach are as follows:
+
+   *  It would not work for Optimistic Addresses, as Section 2.2 of
+      [RFC4429] explicitly prohibits sending Neighbor Solicitations from
+      an Optimistic Address.
+
+   *  If first-hop redundancy is deployed in the network, the NS would
+      reach the active router only, so all backup routers (or all active
+      routers except one) would not get their Neighbor Cache updated.
+
+   *  Some wireless devices are known to alter ND packets and perform
+      various nonobvious forms of ND proxy actions.  In some cases,
+      unsolicited NAs might not even reach the routers.
+
+8.4.  Host Sending Router Solicitation from Its GUA
+
+   The host could send a Router Solicitation message to the all-routers
+   multicast address, using its GUA as a source.  If the host link-layer
+   address is included in the Source Link-Layer Address Option, the
+   router would create a STALE entry for the host GUA as per
+   Section 6.2.6 of [RFC4861].  However, this approach cannot be used if
+   the GUA is in the Optimistic state: Section 2.2 of [RFC4429]
+   explicitly prohibits using an Optimistic Address as the source
+   address of a Router Solicitation with a SLLAO, as it might cause
+   disruption for the rightful owner of the address in the case of a
+   collision.  So, for the Optimistic Addresses, the host can send an RS
+   without a SLLAO included.  In that case, the router may respond with
+   either a multicast or unicast RA (only the latter would create a
+   cache entry).
+
+   This approach has the following drawbacks:
+
+   *  If the address is in the Optimistic state, the RS cannot contain a
+      SLLAO.  As a result, the router would only create a cache entry if
+      solicited RAs are sent as unicast.  Routers sending solicited RAs
+      as multicast would not create a new cache entry, as they do not
+      need to send a unicast packet back to the host.
+
+   *  There might be a random delay between receiving an RS and sending
+      a unicast RA back (and creating a cache entry), which might
+      undermine the idea of creating the cache entry proactively.
+
+   *  Some wireless devices are known to intercept ND packets and
+      perform various nonobvious forms of ND proxy actions.  In some
+      cases, the RS might not even reach the routers.
+
+8.5.  Routers Populating Their Caches by Gleaning from Neighbor
+      Discovery Packets
+
+   Routers may be able to learn about new addresses by gleaning from the
+   DAD Neighbor Solicitation messages.  The router could listen to all
+   solicited-node multicast address groups and, upon receiving a
+   Neighbor Solicitation from the unspecified address, search its
+   Neighbor Cache for the solicitation's target address.  If no entry
+   exists, the router may create an entry, set its reachability state to
+   INCOMPLETE, and start the address resolution process for that entry.
+
+   The same solution was proposed in [ND-ADDR-RES].  Some routing
+   vendors already support such optimization.  However, this approach
+   has a number of drawbacks and therefore should not be used as the
+   only solution:
+
+   *  Routers need to receive all multicast Neighbor Discovery packets;
+      this might negatively impact a router's CPU.
+
+   *  If the router starts the address resolution process as soon as it
+      receives the DAD Neighbor Solicitation, the host might still be
+      performing DAD and the target address might be tentative.  In that
+      case, the host SHOULD silently ignore the received Neighbor
+      Solicitation from the router as per Section 5.4.3 of [RFC4862].
+      As a result, the router might not be able to complete the address
+      resolution process before the return traffic arrives.
+
+8.6.  Initiating Host-to-Router Communication
+
+   The host may force the router to start address resolution by sending
+   a data packet such as ping or traceroute to its default router link-
+   local address, using the GUA as a source address.  As the RTT to the
+   default router is lower than the RTT to any off-link destinations,
+   it's quite likely that the router would start the Neighbor Discovery
+   process for the host GUA before the first packet of the returning
+   traffic arrives.
+
+   This approach has the following drawbacks:
+
+   *  Data packets to the router's link-local address could be blocked
+      by a security policy or control plane protection mechanism.
+
+   *  It introduces an additional overhead for the router's control
+      plane (in addition to processing ND packets, the data packet needs
+      to be processed as well).
+
+   *  Unless the data packet is sent to the all-routers ff02::2
+      multicast address, if the network provides a first-hop redundancy,
+      then only the active router would create a new cache entry.
+
+8.7.  Making the Probing Logic on Hosts More Robust
+
+   Theoretically, the probing logic on hosts might be modified to better
+   deal with initial packet loss.  For example, only one probe can be
+   sent, or probe retransmit intervals can be reduced.  However, this
+   approach has a number of drawbacks:
+
+   *  It would require updating all possible applications that perform
+      probing, while the solution described in this document is
+      implemented at the operating-system level.
+
+   *  Some implementations need to send multiple probes.  Examples
+      include but are not limited to:
+
+      -  Sending AAAA and A record DNS probes in parallel.
+
+      -  Detecting captive portals, which often requires sending
+         multiple packets.
+
+   *  While it would increase the probability that the probing will
+      complete successfully, there are multiple cases when packet loss
+      would still occur:
+
+      -  The probe response consists of multiple packets, so all but the
+         first one are dropped.
+
+      -  There are multiple applications on the same host sending
+         traffic, and return packets arrive simultaneously.
+
+      -  There are multiple first-hop routers in the network.  The first
+         probe packet creates the NC entry on one of them.  The
+         subsequent return traffic flows might cross other routers and
+         still experience the issue.
+
+   *  Reducing the probe retransmit interval unnecessarily increases
+      network utilization and might cause network congestion.
+
+8.8.  Increasing the Buffer Size on Routers
+
+   Increasing the buffer size and buffering more packets would
+   exacerbate issues described in [RFC6583] and make the router more
+   vulnerable to ND-based denial-of-service attacks.
+
+8.9.  Transit Data Plane Traffic from a New Address to Trigger Address
+      Resolution
+
+   When a router receives a transit packet sourced by an on-link
+   neighbor node, it might check for the presence of a Neighbor Cache
+   entry for the packet source address and, if the entry does not exist,
+   start the address resolution process.  This approach does ensure that
+   a Neighbor Cache entry is proactively created every time a new,
+   previously unseen GUA is used for sending off-link traffic.  However,
+   this approach has a number of limitations.  In particular:
+
+   *  If traffic flows are asymmetrical, the return traffic might not
+      transit the same router as the original traffic that triggered the
+      address resolution process.  So, the Neighbor Cache entry is
+      created on the "wrong" router, not the one that actually needs the
+      Neighbor Cache entry for the host address.
+
+   *  The functionality needs to be limited to explicitly configured
+      networks/interfaces, as the router needs to distinguish between
+      on-link addresses (addresses for which the router needs to have
+      Neighbor Cache entries) and the rest of the address space.  The
+      proactive address resolution process must only be triggered by
+      packets from the prefixes known to be on-link.  Otherwise, traffic
+      from spoofed source addresses or any transit traffic could lead to
+      Neighbor Cache exhaustion.
+
+   *  Implementing such functionality is much more complicated than all
+      other solutions, as it would involve complex interactions between
+      the data plane and the control plane.
+
+9.  IANA Considerations
+
+   This document has no IANA actions.
+
+10.  Security Considerations
+
+   One of the potential attack vectors to consider is cache spoofing,
+   where the attacker might try to install a cache entry for the
+   victim's IPv6 address and the attacker's link-layer address.
+   However, it should be noted that this document does not propose any
+   changes for the scenario when the Neighbor Cache for a given IPv6
+   address already exists.  Therefore, there are no new vectors for an
+   attacker to override an existing cache entry.
+
+   Section 5 describes some corner cases when a host with a duplicate
+   Optimistic Address might get some packets intended for the rightful
+   owner of the address.  However, such scenarios do not introduce any
+   new attack vectors: even without the changes discussed in this
+   document, an attacker can easily override the router's Neighbor Cache
+   and redirect the traffic by sending NAs with the Solicited flag set.
+   As discussed in Section 5.3.2, the worst-case scenario might cause a
+   disruption for up to 7 seconds.  Because this scenario is highly
+   unlikely, this risk of disruption is considered acceptable.  More
+   importantly, for all cases described in Section 5, the rightful owner
+   can prevent disruption caused by an accidental address duplication
+   just by implementing the mechanism described in this document.  If
+   the rightful owner sends unsolicited NAs before using the address,
+   the STALE entry would be created on the router's NC, and any
+   subsequent unsolicited NAs sent from the host with an Optimistic
+   Address would not override the NC entry.
+
+   A malicious host could attempt to exhaust the Neighbor Cache on the
+   router by creating a large number of STALE entries.  However, this
+   attack vector is not new, and the mechanism specified in this
+   document does not increase the risk of such an attack: the attacker
+   could do it, for example, by sending an NS or RS packet with a SLLAO
+   included.  All recommendations from [RFC6583] still apply.
+
+   Announcing a new address to the all-routers multicast address may
+   inform an on-link attacker about IPv6 addresses assigned to the host.
+   However, hiding information about the specific IPv6 address should
+   not be considered a security measure, as such information is usually
+   disclosed via DAD to all nodes anyway if MLD snooping is not enabled.
+   Network administrators can also mitigate this issue by enabling MLD
+   snooping on the link-layer devices to prevent IPv6 link-local
+   multicast packets from being flooded to all on-link nodes.  If peer-
+   to-peer on-link communications are not desirable for a given network
+   segment, they should be prevented by proper Layer 2 security
+   mechanisms.  Therefore, the risk of allowing hosts to send
+   unsolicited Neighbor Advertisements to the all-routers multicast
+   address is low.
+
+   It should be noted that the mechanism discussed in this document
+   allows hosts to proactively inform their routers about global IPv6
+   addresses existing on-link.  Routers could use that information to
+   distinguish between used and unused addresses to mitigate Neighbor
+   Cache exhaustion DoS attacks as described in Section 4.3.2 of
+   [RFC3756] and in [RFC6583].
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
+              2006, <https://www.rfc-editor.org/info/rfc4291>.
+
+   [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
+              for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
+              <https://www.rfc-editor.org/info/rfc4429>.
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              DOI 10.17487/RFC4861, September 2007,
+              <https://www.rfc-editor.org/info/rfc4861>.
+
+   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+              Address Autoconfiguration", RFC 4862,
+              DOI 10.17487/RFC4862, September 2007,
+              <https://www.rfc-editor.org/info/rfc4862>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+11.2.  Informative References
+
+   [ND-ADDR-RES]
+              Chen, I. and J. Halpern, "Triggering ND Address Resolution
+              on Receiving DAD-NS", Work in Progress, Internet-Draft,
+              draft-halpern-6man-nd-pre-resolve-addr-00, 10 January
+              2014, <https://datatracker.ietf.org/doc/html/draft-
+              halpern-6man-nd-pre-resolve-addr-00>.
+
+   [RFC3756]  Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
+              Neighbor Discovery (ND) Trust Models and Threats",
+              RFC 3756, DOI 10.17487/RFC3756, May 2004,
+              <https://www.rfc-editor.org/info/rfc3756>.
+
+   [RFC4541]  Christensen, M., Kimball, K., and F. Solensky,
+              "Considerations for Internet Group Management Protocol
+              (IGMP) and Multicast Listener Discovery (MLD) Snooping
+              Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
+              <https://www.rfc-editor.org/info/rfc4541>.
+
+   [RFC6583]  Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
+              Neighbor Discovery Problems", RFC 6583,
+              DOI 10.17487/RFC6583, March 2012,
+              <https://www.rfc-editor.org/info/rfc6583>.
+
+   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
+              Bormann, "Neighbor Discovery Optimization for IPv6 over
+              Low-Power Wireless Personal Area Networks (6LoWPANs)",
+              RFC 6775, DOI 10.17487/RFC6775, November 2012,
+              <https://www.rfc-editor.org/info/rfc6775>.
+
+   [RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
+              Better Connectivity Using Concurrency", RFC 8305,
+              DOI 10.17487/RFC8305, December 2017,
+              <https://www.rfc-editor.org/info/rfc8305>.
+
+   [RFC8505]  Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
+              Perkins, "Registration Extensions for IPv6 over Low-Power
+              Wireless Personal Area Network (6LoWPAN) Neighbor
+              Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
+              <https://www.rfc-editor.org/info/rfc8505>.
+
+   [RFC8981]  Gont, F., Krishnan, S., Narten, T., and R. Draves,
+              "Temporary Address Extensions for Stateless Address
+              Autoconfiguration in IPv6", RFC 8981,
+              DOI 10.17487/RFC8981, February 2021,
+              <https://www.rfc-editor.org/info/rfc8981>.
+
+Acknowledgements
+
+   Thanks to the following people (in alphabetical order) for their
+   comments, review, and feedback: Mikael Abrahamsson, Stewart Bryant,
+   Lorenzo Colitti, Roman Danyliw, Owen DeLong, Martin Duke, Igor
+   Gashinsky, Carles Gomez, Fernando Gont, Tatuya Jinmei, Benjamin
+   Kaduk, Scott Kelly, Erik Kline, Warren Kumari, Barry Leiba, Jordi
+   Palet Martinez, Erik Nordmark, Michael Richardson, Dan Romascanu,
+   Zaheduzzaman Sarker, Michael Scharf, John Scudder, Mark Smith, Dave
+   Thaler, Pascal Thubert, Loganaden Velvindron, and Éric Vyncke.
+
+Author's Address
+
+   Jen Linkova
+   Google
+   1 Darling Island Rd
+   Pyrmont NSW 2009
+   Australia
+
+   Email: furry@google.com