Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4861

Neighbor Discovery for IP version 6 (IPv6)

Pages: 97
Draft Standard
Errata
Obsoletes:  2461
Updated by:  594269807048752775598028831984259131
Part 4 of 5 – Pages 59 to 73
First   Prev   Next

Top   ToC   RFC4861 - Page 59   prevText

7. Address Resolution and Neighbor Unreachability Detection

This section describes the functions related to Neighbor Solicitation and Neighbor Advertisement messages and includes descriptions of address resolution and the Neighbor Unreachability Detection algorithm. Neighbor Solicitation and Advertisement messages are also used for Duplicate Address Detection as specified by [ADDRCONF]. In particular, Duplicate Address Detection sends Neighbor Solicitation messages with an unspecified source address targeting its own "tentative" address. Such messages trigger nodes already using the address to respond with a multicast Neighbor Advertisement indicating that the address is in use.

7.1. Message Validation

7.1.1. Validation of Neighbor Solicitations

A node MUST silently discard any received Neighbor Solicitation messages that do not satisfy all of the following validity checks: - The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router. - ICMP Checksum is valid. - ICMP Code is 0. - ICMP length (derived from the IP length) is 24 or more octets. - Target Address is not a multicast address. - All included options have a length that is greater than zero. - If the IP source address is the unspecified address, the IP destination address is a solicited-node multicast address. - If the IP source address is the unspecified address, there is no source link-layer address option in the message. The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values.
Top   ToC   RFC4861 - Page 60
   The contents of any defined options that are not specified to be used
   with Neighbor Solicitation messages MUST be ignored and the packet
   processed as normal.  The only defined option that may appear is the
   Source Link-Layer Address option.

   A Neighbor Solicitation that passes the validity checks is called a
   "valid solicitation".

7.1.2. Validation of Neighbor Advertisements

A node MUST silently discard any received Neighbor Advertisement messages that do not satisfy all of the following validity checks: - The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router. - ICMP Checksum is valid. - ICMP Code is 0. - ICMP length (derived from the IP length) is 24 or more octets. - Target Address is not a multicast address. - If the IP Destination Address is a multicast address the Solicited flag is zero. - All included options have a length that is greater than zero. The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values. The contents of any defined options that are not specified to be used with Neighbor Advertisement messages MUST be ignored and the packet processed as normal. The only defined option that may appear is the Target Link-Layer Address option. A Neighbor Advertisements that passes the validity checks is called a "valid advertisement".

7.2. Address Resolution

Address resolution is the process through which a node determines the link-layer address of a neighbor given only its IP address. Address resolution is performed only on addresses that are determined to be on-link and for which the sender does not know the corresponding
Top   ToC   RFC4861 - Page 61
   link-layer address (see Section 5.2).  Address resolution is never
   performed on multicast addresses.

   It is possible that a host may receive a solicitation, a router
   advertisement, or a Redirect message without a link-layer address
   option included.  These messages MUST NOT create or update neighbor
   cache entries, except with respect to the IsRouter flag as specified
   in Sections 6.3.4 and 7.2.5.  If a Neighbor Cache entry does not
   exist for the source of such a message, Address Resolution will be
   required before unicast communications with that address can begin.
   This is particularly relevant for unicast responses to solicitations
   where an additional packet exchange is required for advertisement
   delivery.

7.2.1. Interface Initialization

When a multicast-capable interface becomes enabled, the node MUST join the all-nodes multicast address on that interface, as well as the solicited-node multicast address corresponding to each of the IP addresses assigned to the interface. The set of addresses assigned to an interface may change over time. New addresses might be added and old addresses might be removed [ADDRCONF]. In such cases the node MUST join and leave the solicited-node multicast address corresponding to the new and old addresses, respectively. Joining the solicited-node multicast address is done using a Multicast Listener Discovery such as [MLD] or [MLDv2] protocols. Note that multiple unicast addresses may map into the same solicited-node multicast address; a node MUST NOT leave the solicited-node multicast group until all assigned addresses corresponding to that multicast address have been removed.

7.2.2. Sending Neighbor Solicitations

When a node has a unicast packet to send to a neighbor, but does not know the neighbor's link-layer address, it performs address resolution. For multicast-capable interfaces, this entails creating a Neighbor Cache entry in the INCOMPLETE state and transmitting a Neighbor Solicitation message targeted at the neighbor. The solicitation is sent to the solicited-node multicast address corresponding to the target address. If the source address of the packet prompting the solicitation is the same as one of the addresses assigned to the outgoing interface, that address SHOULD be placed in the IP Source Address of the outgoing solicitation. Otherwise, any one of the addresses assigned to the interface should be used. Using the prompting packet's source address when possible ensures that the recipient of the Neighbor
Top   ToC   RFC4861 - Page 62
   Solicitation installs in its Neighbor Cache the IP address that is
   highly likely to be used in subsequent return traffic belonging to
   the prompting packet's "connection".

   If the solicitation is being sent to a solicited-node multicast
   address, the sender MUST include its link-layer address (if it has
   one) as a Source Link-Layer Address option.  Otherwise, the sender
   SHOULD include its link-layer address (if it has one) as a Source
   Link-Layer Address option.  Including the source link-layer address
   in a multicast solicitation is required to give the target an address
   to which it can send the Neighbor Advertisement.  On unicast
   solicitations, an implementation MAY omit the Source Link-Layer
   Address option.  The assumption here is that if the sender has a
   peer's link-layer address in its cache, there is a high probability
   that the peer will also have an entry in its cache for the sender.
   Consequently, it need not be sent.

   While waiting for address resolution to complete, the sender MUST,
   for each neighbor, retain a small queue of packets waiting for
   address resolution to complete.  The queue MUST hold at least one
   packet, and MAY contain more.  However, the number of queued packets
   per neighbor SHOULD be limited to some small value.  When a queue
   overflows, the new arrival SHOULD replace the oldest entry.  Once
   address resolution completes, the node transmits any queued packets.

   While awaiting a response, the sender SHOULD retransmit Neighbor
   Solicitation messages approximately every RetransTimer milliseconds,
   even in the absence of additional traffic to the neighbor.
   Retransmissions MUST be rate-limited to at most one solicitation per
   neighbor every RetransTimer milliseconds.

   If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT
   solicitations, address resolution has failed.  The sender MUST return
   ICMP destination unreachable indications with code 3 (Address
   Unreachable) for each packet queued awaiting address resolution.

7.2.3. Receipt of Neighbor Solicitations

A valid Neighbor Solicitation that does not meet any of the following requirements MUST be silently discarded: - The Target Address is a "valid" unicast or anycast address assigned to the receiving interface [ADDRCONF], - The Target Address is a unicast or anycast address for which the node is offering proxy service, or
Top   ToC   RFC4861 - Page 63
    - The Target Address is a "tentative" address on which Duplicate
      Address Detection is being performed [ADDRCONF].

   If the Target Address is tentative, the Neighbor Solicitation should
   be processed as described in [ADDRCONF].  Otherwise, the following
   description applies.  If the Source Address is not the unspecified
   address and, on link layers that have addresses, the solicitation
   includes a Source Link-Layer Address option, then the recipient
   SHOULD create or update the Neighbor Cache entry for the IP Source
   Address of the solicitation.  If an entry does not already exist, the
   node SHOULD create a new one and set its reachability state to STALE
   as specified in Section 7.3.3.  If an entry already exists, and the
   cached link-layer address differs from the one in the received Source
   Link-Layer option, the cached address should be replaced by the
   received address, and the entry's reachability state MUST be set to
   STALE.

   If a Neighbor Cache entry is created, the IsRouter flag SHOULD be set
   to FALSE.  This will be the case even if the Neighbor Solicitation is
   sent by a router since the Neighbor Solicitation messages do not
   contain an indication of whether or not the sender is a router.  In
   the event that the sender is a router, subsequent Neighbor
   Advertisement or Router Advertisement messages will set the correct
   IsRouter value.  If a Neighbor Cache entry already exists, its
   IsRouter flag MUST NOT be modified.

   If the Source Address is the unspecified address, the node MUST NOT
   create or update the Neighbor Cache entry.

   After any updates to the Neighbor Cache, the node sends a Neighbor
   Advertisement response as described in the next section.

7.2.4. Sending Solicited Neighbor Advertisements

A node sends a Neighbor Advertisement in response to a valid Neighbor Solicitation targeting one of the node's assigned addresses. The Target Address of the advertisement is copied from the Target Address of the solicitation. If the solicitation's IP Destination Address is not a multicast address, the Target Link-Layer Address option MAY be omitted; the neighboring node's cached value must already be current in order for the solicitation to have been received. If the solicitation's IP Destination Address is a multicast address, the Target Link-Layer option MUST be included in the advertisement. Furthermore, if the node is a router, it MUST set the Router flag to one; otherwise, it MUST set the flag to zero.
Top   ToC   RFC4861 - Page 64
   If the Target Address is either an anycast address or a unicast
   address for which the node is providing proxy service, or the Target
   Link-Layer Address option is not included, the Override flag SHOULD
   be set to zero.  Otherwise, the Override flag SHOULD be set to one.
   Proper setting of the Override flag ensures that nodes give
   preference to non-proxy advertisements, even when received after
   proxy advertisements, and also ensures that the first advertisement
   for an anycast address "wins".

   If the source of the solicitation is the unspecified address, the
   node MUST set the Solicited flag to zero and multicast the
   advertisement to the all-nodes address.  Otherwise, the node MUST set
   the Solicited flag to one and unicast the advertisement to the Source
   Address of the solicitation.

   If the Target Address is an anycast address, the sender SHOULD delay
   sending a response for a random time between 0 and
   MAX_ANYCAST_DELAY_TIME seconds.

   Because unicast Neighbor Solicitations are not required to include a
   Source Link-Layer Address, it is possible that a node sending a
   solicited Neighbor Advertisement does not have a corresponding link-
   layer address for its neighbor in its Neighbor Cache.  In such
   situations, a node will first have to use Neighbor Discovery to
   determine the link-layer address of its neighbor (i.e., send out a
   multicast Neighbor Solicitation).

7.2.5. Receipt of Neighbor Advertisements

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. Once the appropriate Neighbor Cache entry has been located, the specific actions taken depend on the state of the Neighbor Cache entry, the flags in the advertisement, and the actual link-layer address supplied. If the target's Neighbor Cache entry is in the INCOMPLETE state when the advertisement is received, one of two things happens. If the link layer has addresses and no Target Link-Layer Address option is included, the receiving node SHOULD silently discard the received advertisement. Otherwise, the receiving node performs the following steps:
Top   ToC   RFC4861 - Page 65
   - It records the link-layer address in the Neighbor Cache entry.

   - If the advertisement's Solicited flag is set, the state of the
     entry is set to REACHABLE; otherwise, it is set to STALE.

   - It sets the IsRouter flag in the cache entry based on the Router
     flag in the received advertisement.

   - It sends any packets queued for the neighbor awaiting address
     resolution.

   Note that the Override flag is ignored if the entry is in the
   INCOMPLETE state.

   If the target's Neighbor Cache entry is in any state other than
   INCOMPLETE when the advertisement is received, the following actions
   take place:

   I.  If the Override flag is clear and the supplied link-layer address
       differs from that in the cache, then one of two actions takes
       place:
       a. If the state of the entry is REACHABLE, set it to STALE, but
          do not update the entry in any other way.
       b. Otherwise, the received advertisement should be ignored and
          MUST NOT update the cache.

   II. If the Override flag is set, or the supplied link-layer address
       is the same as that in the cache, or no Target Link-Layer Address
       option was supplied, the received advertisement MUST update the
       Neighbor Cache entry as follows:

       - The link-layer address in the Target Link-Layer Address option
         MUST be inserted in the cache (if one is supplied and differs
         from the already recorded address).

       - If the Solicited flag is set, the state of the entry MUST be
         set to REACHABLE.  If the Solicited flag is zero and the link-
         layer address was updated with a different address, the state
         MUST be set to STALE.  Otherwise, the entry's state remains
         unchanged.

         An advertisement's Solicited flag should only be set if the
         advertisement is a response to a Neighbor Solicitation.
         Because Neighbor Unreachability Detection Solicitations are
         sent to the cached link-layer address, receipt of a solicited
         advertisement indicates that the forward path is working.
         Receipt of an unsolicited advertisement, however, may indicate
         that a neighbor has urgent information to announce (e.g., a
Top   ToC   RFC4861 - Page 66
         changed link-layer address).  If the urgent information
         indicates a change from what a node is currently using, the
         node should verify the reachability of the (new) path when it
         sends the next packet.  There is no need to update the state
         for unsolicited advertisements that do not change the contents
         of the cache.

       - The IsRouter flag in the cache entry MUST be set based on the
         Router flag in the received advertisement.  In those cases
         where the IsRouter flag changes from TRUE to FALSE as a result
         of this update, the node MUST remove that router from the
         Default Router List and update the Destination Cache entries
         for all destinations using that neighbor as a router as
         specified in Section 7.3.3.  This is needed to detect when a
         node that is used as a router stops forwarding packets due to
         being configured as a host.

   The above rules ensure that the cache is updated either when the
   Neighbor Advertisement takes precedence (i.e., the Override flag is
   set) or when the Neighbor Advertisement refers to the same link-layer
   address that is currently recorded in the cache.  If none of the
   above apply, the advertisement prompts future Neighbor Unreachability
   Detection (if it is not already in progress) by changing the state in
   the cache entry.

7.2.6. Sending Unsolicited Neighbor Advertisements

In some cases, a node may be able to determine that its link-layer address has changed (e.g., hot-swap of an interface card) and may wish to inform its neighbors of the new link-layer address quickly. In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited Neighbor Advertisement messages to the all-nodes multicast address. These advertisements MUST be separated by at least RetransTimer seconds. The Target Address field in the unsolicited advertisement is set to an IP address of the interface, and the Target Link-Layer Address option is filled with the new link-layer address. The Solicited flag MUST be set to zero, in order to avoid confusing the Neighbor Unreachability Detection algorithm. If the node is a router, it MUST set the Router flag to one; otherwise, it MUST set it to zero. The Override flag MAY be set to either zero or one. In either case, neighboring nodes will immediately change the state of their Neighbor Cache entries for the Target Address to STALE, prompting them to verify the path for reachability. If the Override flag is set to one, neighboring nodes will install the new link-layer address in their caches. Otherwise, they will ignore the new link-layer address, choosing instead to probe the cached address.
Top   ToC   RFC4861 - Page 67
   A node that has multiple IP addresses assigned to an interface MAY
   multicast a separate Neighbor Advertisement for each address.  In
   such a case, the node SHOULD introduce a small delay between the
   sending of each advertisement to reduce the probability of the
   advertisements being lost due to congestion.

   A proxy MAY multicast Neighbor Advertisements when its link-layer
   address changes or when it is configured (by system management or
   other mechanisms) to proxy for an address.  If there are multiple
   nodes that are providing proxy services for the same set of
   addresses, the proxies should provide a mechanism that prevents
   multiple proxies from multicasting advertisements for any one
   address, in order to reduce the risk of excessive multicast traffic.
   This is a requirement on other protocols that need to use proxies for
   Neighbor Advertisements.  An example of a node that performs proxy
   advertisements is the Home Agent specified in [MIPv6].

   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.

   Note that because unsolicited Neighbor Advertisements do not reliably
   update caches in all nodes (the advertisements might not be received
   by all nodes), they should only be viewed as a performance
   optimization to quickly update the caches in most neighbors.  The
   Neighbor Unreachability Detection algorithm ensures that all nodes
   obtain a reachable link-layer address, though the delay may be
   slightly longer.

7.2.7. Anycast Neighbor Advertisements

From the perspective of Neighbor Discovery, anycast addresses are treated just like unicast addresses in most cases. Because an anycast address is syntactically the same as a unicast address, nodes performing address resolution or Neighbor Unreachability Detection on an anycast address treat it as if it were a unicast address. No special processing takes place. Nodes that have an anycast address assigned to an interface treat them exactly the same as if they were unicast addresses with two exceptions. First, Neighbor Advertisements sent in response to a Neighbor Solicitation SHOULD be delayed by a random time between 0 and MAX_ANYCAST_DELAY_TIME to reduce the probability of network congestion. Second, the Override flag in Neighbor Advertisements SHOULD be set to 0, so that when multiple advertisements are received, the first received advertisement is used rather than the most recently received advertisement.
Top   ToC   RFC4861 - Page 68
   As with unicast addresses, Neighbor Unreachability Detection ensures
   that a node quickly detects when the current binding for an anycast
   address becomes invalid.

7.2.8. Proxy Neighbor Advertisements

Under limited circumstances, a router MAY proxy for one or more other nodes, that is, through Neighbor Advertisements indicate that it is willing to accept packets not explicitly addressed to itself. For example, a router might accept packets on behalf of a mobile node that has moved off-link. The mechanisms used by proxy are essentially the same as the mechanisms used with anycast addresses. A proxy MUST join the solicited-node multicast address(es) that correspond to the IP address(es) assigned to the node for which it is proxying. This SHOULD be done using a multicast listener discovery protocol such as [MLD] or [MLDv2]. All solicited proxy Neighbor Advertisement messages MUST have the Override flag set to zero. This ensures that if the node itself is present on the link, its Neighbor Advertisement (with the Override flag set to one) will take precedence of any advertisement received from a proxy. A proxy MAY send unsolicited advertisements with the Override flag set to one as specified in Section 7.2.6, but doing so may cause the proxy advertisement to override a valid entry created by the node itself. Finally, when sending a proxy advertisement in response to a Neighbor Solicitation, the sender should delay its response by a random time between 0 and MAX_ANYCAST_DELAY_TIME seconds to avoid collisions due to multiple responses sent by several proxies. However, in some cases (e.g., Mobile IPv6) where only one proxy is present, such delay is not necessary.

7.3. Neighbor Unreachability Detection

Communication to or through a neighbor may fail for numerous reasons at any time, including hardware failure, hot-swap of an interface card, etc. If the destination has failed, no recovery is possible and communication fails. On the other hand, if it is the path that has failed, recovery may be possible. Thus, a node actively tracks the reachability "state" for the neighbors to which it is sending packets. Neighbor Unreachability Detection is used for all paths between hosts and neighboring nodes, including host-to-host, host-to-router, and router-to-host communication. Neighbor Unreachability Detection may also be used between routers, but is not required if an equivalent
Top   ToC   RFC4861 - Page 69
   mechanism is available, for example, as part of the routing
   protocols.

   When a path to a neighbor appears to be failing, the specific
   recovery procedure depends on how the neighbor is being used.  If the
   neighbor is the ultimate destination, for example, address resolution
   should be performed again.  If the neighbor is a router, however,
   attempting to switch to another router would be appropriate.  The
   specific recovery that takes place is covered under next-hop
   determination; Neighbor Unreachability Detection signals the need for
   next-hop determination by deleting a Neighbor Cache entry.

   Neighbor Unreachability Detection is performed only for neighbors to
   which unicast packets are sent; it is not used when sending to
   multicast addresses.

7.3.1. Reachability Confirmation

A neighbor is considered reachable if the node has recently received a confirmation that packets sent recently to the neighbor were received by its IP layer. Positive confirmation can be gathered in two ways: hints from upper-layer protocols that indicate a connection is making "forward progress", or receipt of a Neighbor Advertisement message that is a response to a Neighbor Solicitation message. A connection makes "forward progress" if the packets received from a remote peer can only be arriving if recent packets sent to that peer are actually reaching it. In TCP, for example, receipt of a (new) acknowledgment indicates that previously sent data reached the peer. Likewise, the arrival of new (non-duplicate) data indicates that earlier acknowledgments are being delivered to the remote peer. If packets are reaching the peer, they must also be reaching the sender's next-hop neighbor; thus, "forward progress" is a confirmation that the next-hop neighbor is reachable. For off-link destinations, forward progress implies that the first-hop router is reachable. When available, this upper-layer information SHOULD be used. In some cases (e.g., UDP-based protocols and routers forwarding packets to hosts), such reachability information may not be readily available from upper-layer protocols. When no hints are available and a node is sending packets to a neighbor, the node actively probes the neighbor using unicast Neighbor Solicitation messages to verify that the forward path is still working. The receipt of a solicited Neighbor Advertisement serves as reachability confirmation, since advertisements with the Solicited flag set to one are sent only in response to a Neighbor Solicitation.
Top   ToC   RFC4861 - Page 70
   Receipt of other Neighbor Discovery messages, such as Router
   Advertisements and Neighbor Advertisement with the Solicited flag set
   to zero, MUST NOT be treated as a reachability confirmation.  Receipt
   of unsolicited messages only confirms the one-way path from the
   sender to the recipient node.  In contrast, Neighbor Unreachability
   Detection requires that a node keep track of the reachability of the
   forward path to a neighbor from its perspective, not the neighbor's
   perspective.  Note that receipt of a solicited advertisement
   indicates that a path is working in both directions.  The
   solicitation must have reached the neighbor, prompting it to generate
   an advertisement.  Likewise, receipt of an advertisement indicates
   that the path from the sender to the recipient is working.  However,
   the latter fact is known only to the recipient; the advertisement's
   sender has no direct way of knowing that the advertisement it sent
   actually reached a neighbor.  From the perspective of Neighbor
   Unreachability Detection, only the reachability of the forward path
   is of interest.

7.3.2. Neighbor Cache Entry States

A Neighbor Cache entry can be in one of five states: INCOMPLETE Address resolution is being performed on the entry. Specifically, a Neighbor Solicitation has been sent to the solicited-node multicast address of the target, but the corresponding Neighbor Advertisement has not yet been received. REACHABLE Positive confirmation was received within the last ReachableTime milliseconds that the forward path to the neighbor was functioning properly. While REACHABLE, no special action takes place as packets are sent. STALE More than ReachableTime milliseconds have elapsed since the last positive confirmation was received that the forward path was functioning properly. While stale, no action takes place until a packet is sent. The STALE state is entered upon receiving an unsolicited Neighbor Discovery message that updates the cached link-layer address. Receipt of such a message does not confirm reachability, and entering the STALE state ensures reachability is verified quickly if the entry is actually being used. However, reachability is not actually verified until the entry is actually used.
Top   ToC   RFC4861 - Page 71
      DELAY       More than ReachableTime milliseconds have elapsed
                  since the last positive confirmation was received that
                  the forward path was functioning properly, and a
                  packet was sent within the last DELAY_FIRST_PROBE_TIME
                  seconds.  If no reachability confirmation is received
                  within DELAY_FIRST_PROBE_TIME seconds of entering the
                  DELAY state, send a Neighbor Solicitation and change
                  the state to PROBE.

                  The DELAY state is an optimization that gives upper-
                  layer protocols additional time to provide
                  reachability confirmation in those cases where
                  ReachableTime milliseconds have passed since the last
                  confirmation due to lack of recent traffic.  Without
                  this optimization, the opening of a TCP connection
                  after a traffic lull would initiate probes even though
                  the subsequent three-way handshake would provide a
                  reachability confirmation almost immediately.

      PROBE       A reachability confirmation is actively sought by
                  retransmitting Neighbor Solicitations every
                  RetransTimer milliseconds until a reachability
                  confirmation is received.

7.3.3. Node Behavior

Neighbor Unreachability Detection operates in parallel with the sending of packets to a neighbor. While reasserting a neighbor's reachability, a node continues sending packets to that neighbor using the cached link-layer address. If no traffic is sent to a neighbor, no probes are sent. When a node needs to perform address resolution on a neighboring address, it creates an entry in the INCOMPLETE state and initiates address resolution as specified in Section 7.2. If address resolution fails, the entry SHOULD be deleted, so that subsequent traffic to that neighbor invokes the next-hop determination procedure again. Invoking next-hop determination at this point ensures that alternate default routers are tried. When a reachability confirmation is received (either through upper- layer advice or a solicited Neighbor Advertisement), an entry's state changes to REACHABLE. The one exception is that upper-layer advice has no effect on entries in the INCOMPLETE state (e.g., for which no link-layer address is cached).
Top   ToC   RFC4861 - Page 72
   When ReachableTime milliseconds have passed since receipt of the last
   reachability confirmation for a neighbor, the Neighbor Cache entry's
   state changes from REACHABLE to STALE.

      Note: An implementation may actually defer changing the state from
      REACHABLE to STALE until a packet is sent to the neighbor, i.e.,
      there need not be an explicit timeout event associated with the
      expiration of ReachableTime.

   The first time a node sends a packet to a neighbor whose entry is
   STALE, the sender changes the state to DELAY and sets a timer to
   expire in DELAY_FIRST_PROBE_TIME seconds.  If the entry is still in
   the DELAY state when the timer expires, the entry's state changes to
   PROBE.  If reachability confirmation is received, the entry's state
   changes to REACHABLE.

   Upon entering the PROBE state, a node sends a unicast Neighbor
   Solicitation message to the neighbor using the cached link-layer
   address.  While in the PROBE state, a node retransmits Neighbor
   Solicitation messages every RetransTimer milliseconds until
   reachability confirmation is obtained.  Probes are retransmitted even
   if no additional packets are sent to the neighbor.  If no response is
   received after waiting RetransTimer milliseconds after sending the
   MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the
   entry SHOULD be deleted.  Subsequent traffic to that neighbor will
   recreate the entry and perform address resolution again.

   Note that all Neighbor Solicitations are rate-limited on a per-
   neighbor basis.  A node MUST NOT send Neighbor Solicitations to the
   same neighbor more frequently than once every RetransTimer
   milliseconds.

   A Neighbor Cache entry enters the STALE state when created as a
   result of receiving packets other than solicited Neighbor
   Advertisements (i.e., Router Solicitations, Router Advertisements,
   Redirects, and Neighbor Solicitations).  These packets contain the
   link-layer address of either the sender or, in the case of Redirect,
   the redirection target.  However, receipt of these link-layer
   addresses does not confirm reachability of the forward-direction path
   to that node.  Placing a newly created Neighbor Cache entry for which
   the link-layer address is known in the STALE state provides assurance
   that path failures are detected quickly.  In addition, should a
   cached link-layer address be modified due to receiving one of the
   above messages, the state SHOULD also be set to STALE to provide
   prompt verification that the path to the new link-layer address is
   working.
Top   ToC   RFC4861 - Page 73
   To properly detect the case where a router switches from being a
   router to being a host (e.g., if its IP forwarding capability is
   turned off by system management), a node MUST compare the Router flag
   field in all received Neighbor Advertisement messages with the
   IsRouter flag recorded in the Neighbor Cache entry.  When a node
   detects that a neighbor has changed from being a router to being a
   host, the node MUST remove that router from the Default Router List
   and update the Destination Cache as described in Section 6.3.5.  Note
   that a router may not be listed in the Default Router List, even
   though a Destination Cache entry is using it (e.g., a host was
   redirected to it).  In such cases, all Destination Cache entries that
   reference the (former) router must perform next-hop determination
   again before using the entry.

   In some cases, link-specific information may indicate that a path to
   a neighbor has failed (e.g., the resetting of a virtual circuit).  In
   such cases, link-specific information may be used to purge Neighbor
   Cache entries before the Neighbor Unreachability Detection would do
   so.  However, link-specific information MUST NOT be used to confirm
   the reachability of a neighbor; such information does not provide
   end-to-end confirmation between neighboring IP layers.



(page 73 continued on part 5)

Next Section