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.

   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

   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

   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

    - 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.

   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:

   - 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

         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.

   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.

   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

   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.

   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.

      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).

   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.

   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.