tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 1970

 
 
 

Neighbor Discovery for IP Version 6 (IPv6)

Part 3 of 3, p. 55 to 82
Prev RFC Part

 


prevText      Top      Up      ToC       Page 55 
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.

   - If the message includes an IP Authentication Header, the message
     authenticates correctly.

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

   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;

Top      Up      ToC       Page 56 
   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.

   - If the message includes an IP Authentication Header, the message
     authenticates correctly.

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

Top      Up      ToC       Page 57 
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.  Address resolution is never performed on
   multicast addresses.

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

Top      Up      ToC       Page 58 
   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.

   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 where the Target Address is not a
   unicast or anycast address assigned to the receiving interface, and
   the Target Address is not a "tentative" address on which Duplicate
   Address Detection is being performed [ADDRCONF] MUST be silently
   ignored.  If the Target Address is tentative, the Neighbor
   Solicitation should be processed as described in [ADDRCONF].

   Upon receipt of a valid Neighbor Solicitation targeted at the node,
   the recipient SHOULD update the Neighbor Cache entry for the IP
   Source Address of the solicitation if the Source Address is not the
   unspecified address.  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 a cache entry already exists and is
   updated with a different link-layer address its reachability state
   MUST be set to STALE.  If the solicitation contains a Source Link-
   Layer Address option, the entry's cached link-layer address should be
   replaced with the one in the solicitation.

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

Top      Up      ToC       Page 59 
   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
   a unicast or anycast address, the Target Link-Layer Address option
   SHOULD NOT be included; 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
   solicited-node multicast address, the Target Link-Layer option MUST
   be included in the advertisement.  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 in the outgoing
   advertisement, the Override flag SHOULD be set to zero.  Otherwise,
   it SHOULD be set to one.  Proper setting of the Override flag insures
   that nodes give preference to non-proxy advertisements, even when
   received after proxy advertisements, but 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.

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 in this case, 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 and the flags in the advertisement.  If the entry is in an
   INCOMPLETE state (i.e., no link-layer address is cached for the

Top      Up      ToC       Page 60 
   target) the received advertisement updates the entry.  If a cached
   link-layer address is already present, however, a node might choose
   to ignore the received advertisement and continue using the cached
   link-layer address.

   If the target's Neighbor Cache entry is in the INCOMPLETE state, the
   receiving node records the link-layer address in the Neighbor Cache
   entry and sends any packets queued for the neighbor awaiting address
   resolution.  If the Solicited flag is set, the reachability state for
   the neighbor MUST be set to REACHABLE; otherwise it MUST be set to
   STALE. (A more detailed explanation of reachability state is
   described in Section 7.3.3).  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 advertisement's
   Override flag's setting determines whether the Target Link-Layer
   Address option (if present) replaces the cached address.  If the
   Override flag is set, the receiving node MUST install the link-layer
   address in its cache; if the flag is zero, the receiving node MUST
   NOT install the link-layer address in its cache.  An advertisement's
   sender sets the Override flag when it wants its Target Link-Layer
   Address option to replace the cached value in Neighbor Cache entries,
   regardless of their current contents.

   If the target's Neighbor Cache entry is in any state other than
   INCOMPLETE when the advertisement is received, the advertisement's
   Solicited flag setting determines what the entry's new state should
   be.  If the Solicited flag is set, the entry's state MUST be set to
   REACHABLE; if the flag is zero, the entry's state MUST be set to
   STALE.  An advertisement's Solicited flag should only be set if the
   advertisement is a response to a Neighbor Solicitation.  Because
   Neighbor Unreachability Solicitations are sent to the cached link-
   layer address, a receipt of a solicited advertisement indicates that
   the forward path is working.  Receipt of an unsolicited
   advertisement, however, suggests that a neighbor has urgent
   information to announce (e.g., a changed link-layer address).
   Regardless of whether or not the new link-layer address is installed
   in the cache, a node should verify the reachability of the path it is
   currently using when it sends the next packet, so that it quickly
   finds a working path if the existing path has failed (e.g., as would
   be the case if the unsolicited Neighbor Advertisement is sent to
   announce a link-layer address change).

   In those cases where the cached link-layer address is updated, the
   receiving node MUST examine the Router flag in the received
   advertisement and update the IsRouter flag in the Neighbor Cache
   entry to reflect whether the node is a host or router.  In those

Top      Up      ToC       Page 61 
   cases where the neighbor was previously used as a router, but the
   advertisement's Router flag is now set to zero, 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.

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.

   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.

Top      Up      ToC       Page 62 
   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 identical
   to 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.

   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

Top      Up      ToC       Page 63 
   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.

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.

Top      Up      ToC       Page 64 
   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)
   acknowledgement indicates that previously sent data reached the peer.
   Likewise, the arrival of new (non-duplicate) data indicates that
   earlier acknowledgements 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 confirm 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 the 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

Top      Up      ToC       Page 65 
               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
               insures 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.

Top      Up      ToC       Page 66 
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 insures 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 a 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 performs address resolution again.

Top      Up      ToC       Page 67 
   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.

Top      Up      ToC       Page 68 
8.  REDIRECT FUNCTION

   This section describes the functions related to the sending and
   processing of Redirect messages.

   Redirect messages are sent by routers to redirect a host to a better
   first-hop router for a specific destination or to inform hosts that a
   destination is in fact a neighbor (i.e., on-link).  The latter is
   accomplished by having the ICMP Target Address be equal to the ICMP
   Destination Address.

   A router MUST be able to determine the link-local address for each of
   its neighboring routers in order to ensure that the target address in
   a Redirect message identifies the neighbor router by its link-local
   address.  For static routing this requirement implies that the next-
   hop router's address should be specified using the link-local address
   of the router.  For dynamic routing this requirement implies that all
   IPv6 routing protocols must somehow exchange the link-local addresses
   of neighboring routers.

8.1.  Validation of Redirect Messages

   A host MUST silently discard any received Redirect message that does
   not satisfy all of the following validity checks:

   - IP Source Address is a link-local address.  Routers must use their
     link-local address as the source for Router Advertisement and
     Redirect messages so that hosts can uniquely identify routers.

   - The IP Hop Limit field has a value of 255, i.e., the packet could
     not possibly have been forwarded by a router.

   - If the message includes an IP Authentication Header, the message
     authenticates correctly.

   - ICMP Checksum is valid.

   - ICMP Code is 0.

   - ICMP length (derived from the IP length) is 40 or more octets.

   - The IP source address of the Redirect is the same as the current
     first-hop router for the specified ICMP Destination Address.

   - The ICMP Destination Address field in the redirect message does not
     contain a multicast address.

Top      Up      ToC       Page 69 
   - The ICMP Target Address is either a link-local address (when
     redirected to a router) or the same as the ICMP Destination Address
     (when redirected to the on-link destination).

   - 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 Redirect messages MUST be ignored and the packet processed as
   normal.  The only defined options that may appear are the Target
   Link-Layer Address option and the Redirected Header option.

   A host MUST NOT consider a redirect invalid just because the Target
   Address of the redirect is not covered under one of the link's
   prefixes.  Part of the semantics of the Redirect message is that the
   Target Address is on-link.

   A redirect that passes the validity checks is called a "valid
   redirect".

8.2.  Router Specification

   A router SHOULD send a redirect message, subject to rate limiting,
   whenever it forwards a packet that is not explicitly addressed to
   itself (i.e. a packet that is not source routed through the router)
   in which:

   - the Source Address field of the packet identifies a neighbor, and

   - the router determines that a better first-hop node resides on the
     same link as the sending node for the Destination Address of the
     packet being forwarded, and

   - the Destination Address of the packet is not a multicast address,
     and

   The transmitted redirect packet contains, consistent with the message
   format given in Section 4.5:

   - In the Target Address field: the address to which subsequent
     packets for the destination SHOULD be sent.  If the target is a
     router, that router's link-local address MUST be used.  If the
     target is a host the target address field MUST be set to the same
     value as the Destination Address field.

Top      Up      ToC       Page 70 
   - In the Destination Address field: the destination address of the
     invoking IP packet.

   - In the options:

        o Target Link-Layer Address option: link-layer address of the
          target, if known.

        o Redirected Header: as much of the forwarded packet as can fit
          without the redirect packet exceeding 576 octets in size.

   A router MUST limit the rate at which Redirect messages are sent, in
   order to limit the bandwidth and processing costs incurred by the
   Redirect messages when the source does not correctly respond to the
   Redirects, or the source chooses to ignore unauthenticated Redirect
   messages.  More details on the rate-limiting of ICMP error messages
   can be found in [ICMPv6].

   A router MUST NOT update its routing tables upon receipt of a
   Redirect.

8.3.  Host Specification

   A host receiving a valid redirect SHOULD update its Destination Cache
   accordingly so that subsequent traffic goes to the specified target.
   If no Destination Cache entry exists for the destination, an
   implementation SHOULD create such an entry.

   If the redirect contains a Target Link-Layer Address option the host
   either creates or updates the Neighbor Cache entry for the target.
   In both cases the cached link-layer address is copied from the Target
   Link-Layer Address option.  If a Neighbor Cache entry is created for
   the target its reachability state MUST be set to STALE as specified
   in Section 7.3.3.  If a cache entry already existed and it is updated
   with a different link-layer address its reachability state MUST also
   be set to STALE.

   In addition, if the Target Address is the same as the Destination
   Address, the host MUST treat the destination as on-link and set the
   IsRouter field in the corresponding Neighbor Cache entry to FALSE.
   Otherwise it MUST set IsRouter to true.

   Redirect messages apply to all flows that are being sent to a given
   destination.  That is, upon receipt of a Redirect for a Destination
   Address, all Destination Cache entries to that address should be
   updated to use the specified next-hop, regardless of the contents of
   the Flow Label field that appears in the Redirected Header option.

Top      Up      ToC       Page 71 
   A host MAY have a configuration switch that can be set to make it
   ignore a Redirect message that does not have an IP Authentication
   header.

   A host MUST NOT send Redirect messages.

9.  EXTENSIBILITY - OPTION PROCESSING

   Options provide a mechanism for encoding variable length fields,
   fields that may appear multiple times in the same packet, or
   information that may not appear in all packets.  Options can also be
   used to add additional functionality to future versions of ND.

   In order to ensure that future extensions properly coexist with
   current implementations, all nodes MUST silently ignore any options
   they do not recognize in received ND packets and continue processing
   the packet.  All options specified in this document MUST be
   recognized.  A node MUST NOT ignore valid options just because the ND
   message contains unrecognized ones.

   The current set of options is defined in such a way that receivers
   can process multiple options in the same packet independently of each
   other.  In order to maintain these properties future options SHOULD
   follow the simple rule:

      The option MUST NOT depend on the presence or absence of any other
      options.  The semantics of an option should depend only on the
      information in the fixed part of the ND packet and on the
      information contained in the option itself.

   Adhering to the above rule has the following benefits:

  1) Receivers can process options independently of one another.  For
     example, an implementation can choose to process the Prefix
     Information option contained in a Router Advertisement message in a
     user-space process while the link-layer address option in the same
     message is processed by routines in the kernel.

  2) Should the number of options cause a packet to exceed a link's MTU,
     multiple packets can carry subsets of the options without any
     change in semantics.

  3) Senders MAY send a subset of options in different packets.  For
     instance, if a prefix's Valid and Preferred Lifetime are high
     enough, it might not be necessary to include the Prefix Information
     option in every Router Advertisement.  In addition, different
     routers might send different sets of options.  Thus, a receiver
     MUST NOT associate any action with the absence of an option in a

Top      Up      ToC       Page 72 
     particular packet.  This protocol specifies that receivers should
     only act on the expiration of timers and on the information that is
     received in the packets.

   Options in Neighbor Discovery packets can appear in any order;
   receivers MUST be prepared to process them independently of their
   order.  There can also be multiple instances of the same option in a
   message (e.g., Prefix Information options).

   If the number of included options in a Router Advertisement causes
   the advertisement's size to exceed the link MTU, the router can send
   multiple separate advertisements each containing a subset of the
   options.

   The amount of data to include in the Redirected Header option MUST be
   limited so that the entire redirect packet does not exceed 576
   octets.

   All options are a multiple of 8 octets of length, ensuring
   appropriate alignment without any "pad" options.  The fields in the
   options (as well as the fields in ND packets) are defined to align on
   their natural boundaries (e.g., a 16-bit field is aligned on a 16-bit
   boundary) with the exception of the 128-bit IP addresses/prefixes,
   which are aligned on a 64-bit boundary.  The link-layer address field
   contains an uninterpreted octet string; it is aligned on an 8-bit
   boundary.

   The size of an ND packet including the IP header is limited to the
   link MTU (which is at least 576 octets).  When adding options to an
   ND packet a node MUST NOT exceed the link MTU.

   Future versions of this protocol may define new option types.
   Receivers MUST silently ignore any options they do not recognize and
   continue processing the message.

10.  PROTOCOL CONSTANTS

Router constants:

         MAX_INITIAL_RTR_ADVERT_INTERVAL  16 seconds

         MAX_INITIAL_RTR_ADVERTISEMENTS    3 transmissions

         MAX_FINAL_RTR_ADVERTISEMENTS      3 transmissions

         MIN_DELAY_BETWEEN_RAS             3 seconds

         MAX_RA_DELAY_TIME                 .5 seconds

Top      Up      ToC       Page 73 
Host constants:

         MAX_RTR_SOLICITATION_DELAY        1 second

         RTR_SOLICITATION_INTERVAL         4 seconds

         MAX_RTR_SOLICITATIONS             3 transmissions

Node constants:

         MAX_MULTICAST_SOLICIT             3 transmissions

         MAX_UNICAST_SOLICIT               3 transmissions

         MAX_ANYCAST_DELAY_TIME            1 second

         MAX_NEIGHBOR_ADVERTISEMENT        3 transmissions

         REACHABLE_TIME               30,000 milliseconds

         RETRANS_TIMER                 1,000 milliseconds

         DELAY_FIRST_PROBE_TIME            5 seconds

         MIN_RANDOM_FACTOR                 .5

         MAX_RANDOM_FACTOR                 1.5

   Additional protocol constants are defined with the message formats in
   Section 4.

   All protocol constants are subject to change in future revisions of
   the protocol.

   The constants in this specification may be overridden by specific
   documents that describe how IPv6 operates over different link layers.
   This rule allows Neighbor Discovery to operate over links with widely
   varying performance characteristics.

11.  SECURITY CONSIDERATIONS

   Neighbor Discovery is subject to attacks that cause IP packets to
   flow to unexpected places.  Such attacks can be used to cause denial
   of service but also allow nodes to intercept and optionally modify
   packets destined for other nodes.

   The protocol reduces the exposure to such threats in the absence of
   authentication by ignoring ND packets received from off-link senders.

Top      Up      ToC       Page 74 
   The Hop Limit field of all received packets is verified to contain
   255, the maximum legal value.  Because routers decrement the Hop
   Limit on all packets they forward, received packets containing a Hop
   Limit of 255 must have originated from a neighbor.

   The trust model for redirects is the same as in IPv4.  A redirect is
   accepted only if received from the same router that is currently
   being used for that destination.  It is natural to trust the routers
   on the link.  If a host has been redirected to another node (i.e.,
   the destination is on-link) there is no way to prevent the target
   from issuing another redirect to some other destination.  However,
   this exposure is no worse than it was; the target host, once
   subverted, could always act as a hidden router to forward traffic
   elsewhere.

   The protocol contains no mechanism to determine which neighbors are
   authorized to send a particular type of message e.g.  Router
   Advertisements; any neighbor, presumably even in the presence of
   authentication, can send Router Advertisement messages thereby being
   able to cause denial of service.  Furthermore, any neighbor can send
   proxy Neighbor Advertisements as well as unsolicited Neighbor
   Advertisements as a potential denial of service attack.

   Neighbor Discovery protocol packet exchanges can be authenticated
   using the IP Authentication Header [IPv6-AUTH].  A node SHOULD
   include an Authentication Header when sending Neighbor Discovery
   packets if a security association for use with the IP Authentication
   Header exists for the destination address.  The security associations
   may have been created through manual configuration or through the
   operation of some key management protocol.

   Received Authentication Headers in Neighbor Discovery packets MUST be
   verified for correctness and packets with incorrect authentication
   MUST be ignored.

   It SHOULD be possible for the system administrator to configure a
   node to ignore any Neighbor Discovery messages that are not
   authenticated using either the Authentication Header or Encapsulating
   Security Payload.  The configuration technique for this MUST be
   documented.  Such a switch SHOULD default to allowing unauthenticated
   messages.

   Confidentiality issues are addressed by the IP Security Architecture
   and the IP Encapsulating Security Payload documents [IPv6-SA, IPv6-
   ESP].

Top      Up      ToC       Page 75 
REFERENCES

  [ADDRCONF] Thomson, S., and T. Narten, "IPv6 Address
          Autoconfiguration", RFC 1971, August 1996.

  [ADDR-ARCH] Deering, S., and R. Hinden, Editors, "IP Version 6
          Addressing Architecture", RFC 1884, January 1996.

  [ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host
          Anycasting Service", RFC 1546, November 1993.

  [ARP] Plummer, D., "An Ethernet Address Resolution Protocol", STD
          37, RFC 826, November 1982.

  [HR-CL] Braden, R., Editor, "Requirements for Internet Hosts --
          Communication Layers", STD 3, RFC 1122, October 1989.

  [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC
          792, September 1981.

  [ICMPv6] Conta, A., and S. Deering, "Internet Control Message
          Protocol (ICMPv6) for the Internet Protocol Version 6
          (IPv6)", RFC 1885, January 1996.

  [IPv6] Deering, S., and R. Hinden, Editors, "Internet Protocol,
          Version 6 (IPv6) Specification", RFC 1883, January, 1996.

  [IPv6-ETHER] Crawford, M., "A Method for the Transmission of IPv6
          Packets over Ethernet Networks", RFC 1972, August 1996.

  [IPv6-SA] Atkinson, R., "Security Architecture for the Internet
          Protocol", RFC 1825, August 1995.

  [IPv6-AUTH] Atkinson, R., "IP Authentication Header", RFC 1826,
          August 1995.

  [IPv6-ESP] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
          RFC 1827, August 1995.

  [RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
          September 1991.

  [SH-MEDIA] Braden, R., Postel, J., and Y. Rekhter, "Internet
          Architecture Extensions for Shared Media", RFC 1620, May
          1994.

  [ASSIGNED] Reynolds, J., and J. Postel, "ASSIGNED NUMBERS", STD 2,
          RFC 1700, October 1994.

Top      Up      ToC       Page 76 
  [SYNC] S. Floyd, V. Jacobsen, "The Synchronization of Periodic Routing
          Messages", IEEE/ACM Transactions on Networking, April 1994.
          ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z

AUTHORS' ADDRESSES

     Erik Nordmark                Thomas Narten
     Sun Microsystems, Inc.       IBM Corporation
     2550 Garcia Ave              P.O. Box 12195
     Mt. View, CA 94041           Research Triangle Park, NC 27709-2195
     USA                          USA

     Phone: +1 415 786 5166       Phone: +1 919 254 7798
     Fax:   +1 415 786 5896       Fax:   +1 919 254 4027
     EMail: nordmark@sun.com      EMail: narten@vnet.ibm.com


     William Allen Simpson
     Daydreamer
     Computer Systems Consulting Services
     1384 Fontaine
     Madison Heights, Michigan  48071
     USA

     EMail: Bill.Simpson@um.cc.umich.edu
            bsimpson@MorningStar.com

Top      Up      ToC       Page 77 
APPENDIX A: MULTIHOMED HOSTS

   There are a number of complicating issues that arise when Neighbor
   Discovery is used by hosts that have multiple interfaces.  This
   section does not attempt to define the proper operation of multihomed
   hosts with regard to Neighbor Discovery.  Rather, it identifies
   issues that require further study.  Implementors are encouraged to
   experiment with various approaches to making Neighbor Discovery work
   on multihomed hosts and to report their experiences.

   If a multihomed host receives Router Advertisements on all of its
   interfaces, it will (probably) have learned on-link prefixes for the
   addresses residing on each link.  When a packet must be sent through
   a router, however, selecting the "wrong" router can result in a
   suboptimal or non-functioning path.  There are number of issues to
   consider:

  1) In order for a router to send a redirect, it must determine that
     the packet it is forwarding originates from a neighbor.  The
     standard test for this case is to compare the source address of the
     packet to the list of on-link prefixes associated with the
     interface on which the packet was received.  If the originating
     host is multihomed, however, the source address it uses may belong
     to an interface other than the interface from which it was sent.
     In such cases, a router will not send redirects, and suboptimal
     routing is likely.  In order to be redirected, the sending host
     must always send packets out the interface corresponding to the
     outgoing packet's source address.  Note that this issue never
     arises with non-multihomed hosts; they only have one interface.

  2) If the selected first-hop router does not have a route at all for
     the destination, it will be unable to deliver the packet.  However,
     the destination may be reachable through a router on one of the
     other interfaces.  Neighbor Discovery does not address this
     scenario; it does not arise in the non-multihomed case.

  3) Even if the first-hop router does have a route for a destination,
     there may be a better route via another interface.  No mechanism
     exists for the multihomed host to detect this situation.

   If a multihomed host fails to receive Router Advertisements on one or
   more of its interfaces, it will not know (in the absence of
   configured information) which destinations are on-link on the
   affected interface(s).  This leads to a number of problems:

  1) If no Router Advertisement is received on any interfaces, a
     multihomed host will have no way of knowing which interface to send
     packets out on, even for on-link destinations.  Under similar

Top      Up      ToC       Page 78 
     conditions in the non-multihomed host case, a node treats all
     destinations as residing on-link, and communication proceeds.  In
     the multihomed case, however, additional information is needed to
     select the proper outgoing interface.  Alternatively, a node could
     attempt to perform address resolution on all interfaces, a step
     involving significant complexity that is not present in the non-
     multihomed host case.

  2) If Router Advertisements are received on some, but not all
     interfaces, a multihomed host could choose to only send packets out
     on the interfaces on which it has received Router Advertisements.
     A key assumption made here, however, is that routers on those other
     interfaces will be able to route packets to the ultimate
     destination, even when those destinations reside on the subnet to
     which the sender connects, but has no on-link prefix information.
     Should the assumption be false, communication would fail.  Even if
     the assumption holds, packets will traverse a sub-optimal path.

APPENDIX B: FUTURE EXTENSIONS

Possible extensions for future study are:

 o Using dynamic timers to be able to adapt to links with widely varying
   delay.  Measuring round trip times, however, requires acknowledgments
   and sequence numbers in order to match received Neighbor
   Advertisements with the actual Neighbor Solicitation that triggered
   the advertisement.  Implementors wishing to experiment with such a
   facility could do so in a backwards-compatible way by defining a new
   option carrying the necessary information.  Nodes not understanding
   the option would simply ignore it.

 o Adding capabilities to facilitate the operation over links that
   currently require hosts to register with an address resolution
   server.  This could for instance enable routers to ask hosts to send
   them periodic unsolicited advertisements.  Once again this can be
   added using a new option sent in the Router Advertisements.

 o Adding additional procedures for links where asymmetric and non-
   transitive reachability is part of normal operations.  Such
   procedures might allow hosts and routers to find usable paths on,
   e.g., radio links.

APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE

   This appendix contains a summary of the rules specified in Sections
   7.2 and 7.3.  This document does not mandate that implementations
   adhere to this model as long as their external behavior is consistent
   with that described in this document.

Top      Up      ToC       Page 79 
   When performing address resolution and Neighbor Unreachability
   Detection the following state transitions apply using the conceptual
   model:

State           Event                   Action                New state

-               Packet to send.         Create entry.         INCOMPLETE
                                        Send multicast NS.
                                        Start retransmit timer

INCOMPLETE      Retransmit timeout,     Retransmit NS         INCOMPLETE
                less than N             Start retransmit timer
                retransmissions.

INCOMPLETE      Retransmit timeout,     Discard entry         -
                N or more               Send ICMP error
                retransmissions.

INCOMPLETE      NA, Solicited=0,        Record link-layer     STALE
                Override=any            address.  Send queued
                                        packets.

INCOMPLETE      NA, Solicited=1,        Record link-layer     REACHABLE
                Override=any            address.  Send queued
                                        packets.

!INCOMPLETE     NA, Solicited=1,        -                     REACHABLE
                Override=0

!INCOMPLETE     NA, Solicited=1,        Record link-layer     REACHABLE
                Override=1              address.

!INCOMPLETE     NA, Solicited=0,        -                     STALE
                Override=0

!INCOMPLETE     NA, Solicited=0,        Record link-layer     STALE
                Override=1              address.

!INCOMPLETE     upper-layer reachability  -                   REACHABLE
                confirmation

REACHABLE       timeout, more than      -                     STALE
                N seconds since
                reachability confirm.

STALE           Sending packet          Start delay timer     DELAY

DELAY           Delay timeout           Send unicast NS probe PROBE

Top      Up      ToC       Page 80 
                                        Start retransmit timer

PROBE           Retransmit timeout,     Retransmit NS         PROBE
                less than N
                retransmissions.

PROBE           Retransmit timeout,     Discard entry         -
                N or more
                retransmissions.

   The state transitions for receiving unsolicited information other
   than Neighbor Advertisement messages apply to either the source of
   the packet (for Neighbor Solicitation, Router Solicitation, and
   Router Advertisement messages) or the target address (for Redirect
   messages) as follows:

State           Event                   Action                New state

-               NS, RS, RA, Redirect    Create entry.         STALE

INCOMPLETE      NS, RS, RA, Redirect    Record link-layer     STALE
                                        address.  Send queued
                                        packets.

!INCOMPLETE     NS, RS, RA, Redirect    Update link-layer     STALE
                Different link-layer    address
                address than cached.

!INCOMPLETE     NS, RS, RA, Redirect    -                     unchanged
                Same link-layer
                address as cached.

APPENDIX D: IMPLEMENTATION ISSUES

Appendix D.1: Reachability confirmations

   Neighbor Unreachability Detection requires explicit confirmation that
   a forward-path is functioning properly.  To avoid the need for
   Neighbor Solicitation probe messages, upper layer protocols should
   provide such an indication when the cost of doing so is small.
   Reliable connection-oriented protocols such as TCP are generally
   aware when the forward-path is working.  When TCP sends (or receives)
   data, for instance, it updates its window sequence numbers, sets and
   cancels retransmit timers, etc.  Specific scenarios that usually
   indicate a properly functioning forward-path include:

- Receipt of an acknowledgement that covers a sequence number (e.g.,
   data) not previously acknowledged indicates that the forward path was

Top      Up      ToC       Page 81 
   working at the time the data was sent.

- Completion of the initial three-way handshake is a special case of the
   previous rule; although no data is sent during the handshake, the SYN
   flags are counted as data from the sequence number perspective.  This
   applies to both the SYN+ACK for the active open the ACK of that
   packet on the passively opening peer.

- Receipt of new data (i.e., data not previously received) indicates
   that the forward-path was working at the time an acknowledgement was
   sent that advanced the peer's send window that allowed the new data
   to be sent.

   To minimize the cost of communicating reachability information
   between the TCP and IP layers, an implementation may wish to rate-
   limit the reachability confirmations its sends IP.  One possibility
   is to process reachability only every few packets.  For example, one
   might update reachability information once per round trip time, if an
   implementation only has one round trip timer per connection.  For
   those implementations that cache Destination Cache entries within
   control blocks, it may be possible to update the Neighbor Cache entry
   directly (i.e., without an expensive lookup) once the TCP packet has
   been demultiplexed to its corresponding control block.  For other
   implementation it may be possible to piggyback the reachability
   confirmation on the next packet submitted to IP assuming that the
   implementation guards against the piggybacked confirmation becoming
   stale when no packets are sent to IP for an extended period of time.

   TCP must also guard against thinking "stale" information indicates
   current reachability.  For example, new data received 30 minutes
   after a window has opened up does not constitute a confirmation that
   the path is currently working.  In merely indicates that 30 minutes
   ago the window update reached the peer i.e. the path was working at
   that point in time.  An implementation must also take into account
   TCP zero-window probes that are sent even if the path is broken and
   the window update did not reach the peer.

   For UDP based applications (RPC, DNS) it is relatively simple to make
   the client send reachability confirmations when the response packet
   is received.  It is more difficult and in some cases impossible for
   the server to generate such confirmations since there is no flow
   control, i.e., the server can not determine whether a received
   request indicates that a previous response reached the client.

   Note that an implementation can not use negative upper-layer advise
   as a replacement for the Neighbor Unreachability Detection algorithm.
   Negative advise (e.g. from TCP when there are excessive
   retransmissions) could serve as a hint that the forward path from the

Top      Up      ToC       Page 82 
   sender of the data might not be working.  But it would fail to detect
   when the path from the receiver of the data is not functioning
   causing, none of the acknowledgement packets to reach the
   dgement