component eliminates the possibility Neighbor Unreachability
Detection messages synchronize with each other.
In most cases, the advertised Reachable Time value will be the same
in consecutive Router Advertisements and a host's BaseReachableTime
rarely changes. In such cases, an implementation SHOULD insure that
a new random value gets recomputed at least once every few hours.
The RetransTimer variable SHOULD be copied from the Retrans Timer
field, if the received value is non-zero.
After extracting information from the fixed part of the Router
Advertisement message, the advertisement is scanned for valid
options. If the advertisement contains a Source Link-Layer Address
option the link-layer address SHOULD be recorded in the Neighbor
Cache entry for the router (creating an entry if necessary) and the
IsRouter flag in the Neighbor Cache entry MUST be set to TRUE. If no
Source Link-Layer Address is included, but a corresponding Neighbor
Cache entry exists, its IsRouter flag MUST be set to TRUE. The
IsRouter flag is used by Neighbor Unreachability Detection to
determine when a router changes to being a host (i.e., no longer
capable of forwarding packets). If a Neighbor Cache entry is created
for the router its reachability state MUST be set to STALE as
specified in Section 7.3.3. If a cache entry already exists and is
updated with a different link-layer address the reachability state
MUST also be set to STALE.
If the MTU option is present, hosts SHOULD copy the option's value
into LinkMTU so long as the value is greater than or equal to the
minimum link MTU [IPv6] and does not exceed the default LinkMTU value
specified in the link type specific document (e.g., [IPv6-ETHER]).
Prefix Information options that have the "on-link" (L) flag set
indicate a prefix identifying a range of addresses that should be
considered on-link. Note, however, that a Prefix Information option
with the on-link flag set to zero conveys no information concerning
on-link determination and MUST NOT be interpreted to mean that
addresses covered by the prefix are off-link. The only way to cancel
a previous on-link indication is to advertise that prefix with the
L-bit set and the Lifetime set to zero. The default behavior (see
Section 5.2) when sending a packet to an address for which no
information is known about the on-link status of the address is to
forward the packet to a default router; the reception of a Prefix
Information option with the "on-link " (L) flag set to zero does not
change this behavior. The reasons for an address being treated as
on-link is specified in the definition of "on-link" in Section 2.1.
Prefixes with the on-link flag set to zero would normally have the
autonomous flag set and be used by [ADDRCONF].
For each Prefix Information option with the on-link flag set, a host
does the following:
- If the prefix is the link-local prefix, silently ignore the
Prefix Information option.
- If the prefix is not already present in the Prefix List, and the
Prefix Information option's Valid Lifetime field is non-zero,
create a new entry for the prefix and initialize its
invalidation timer to the Valid Lifetime value in the Prefix
Information option.
- If the prefix is already present in the host's Prefix List as
the result of a previously-received advertisement, reset its
invalidation timer to the Valid Lifetime value in the Prefix
Information option. If the new Lifetime value is zero, time-out
the prefix immediately (see Section 6.3.5).
- If the Prefix Information option's Valid Lifetime field is zero,
and the prefix is not present in the host's Prefix List,
silently ignore the option.
Stateless address autoconfiguration [ADDRCONF] may in some
circumstances increase the Valid Lifetime of a prefix or ignore it
completely in order to prevent a particular denial of service attack.
However, since the effect of the same denial of service targeted at
the on-link prefix list is not catastrophic (hosts would send packets
to a default router and receive a redirect rather than sending
packets directly to a neighbor) the Neighbor Discovery protocol does
not impose such a check on the prefix lifetime values.
Note: Implementations can choose to process the on-link aspects of
the prefixes separately from the address autoconfiguration aspects
of the prefixes by, e.g., passing a copy of each valid Router
Advertisement message to both an "on-link" and an "addrconf"
function. Each function can then operate independently on the
prefixes that have the appropriate flag set.
6.3.5. Timing out Prefixes and Default Routers
Whenever the invalidation timer expires for a Prefix List entry, that
entry is discarded. No existing Destination Cache entries need be
updated, however. Should a reachability problem arise with an
existing Neighbor Cache entry, Neighbor Unreachability Detection will
perform any needed recovery.
Whenever the Lifetime of an entry in the Default Router List expires,
that entry is discarded. When removing a router from the Default
Router list, the node MUST update the Destination Cache in such a way
that all entries using the router perform next-hop determination
again rather than continue sending traffic to the (deleted) router.
6.3.6. Default Router Selection
The algorithm for selecting a router depends in part on whether or
not a router is known to be reachable. The exact details of how a
node keeps track of a neighbor's reachability state are covered in
Section 7.3. The algorithm for selecting a default router is invoked
during next-hop determination when no Destination Cache entry exists
for an off-link destination or when communication through an existing
router appears to be failing. Under normal conditions, a router
would be selected the first time traffic is sent to a destination,
with subsequent traffic for that destination using the same router as
indicated in the Destination Cache modulo any changes to the
Destination Cache caused by Redirect messages.
The policy for selecting routers from the Default Router List is as
follows:
1) Routers that are reachable or probably reachable (i.e., in any
state other than INCOMPLETE) SHOULD be preferred over routers
whose reachability is unknown or suspect (i.e., in the
INCOMPLETE state, or for which no Neighbor Cache entry exists).
An implementation may choose to always return the same router or
cycle through the router list in a round-robin fashion as long
as it always returns a reachable or a probably reachable router
when one is available.
2) When no routers on the list are known to be reachable or
probably reachable, routers SHOULD be selected in a round-robin
fashion, so that subsequent requests for a default router do not
return the same router until all other routers have been
selected.
Cycling through the router list in this case ensures that all
available routers are actively probed by the Neighbor
Unreachability Detection algorithm. A request for a default
router is made in conjunction with the sending of a packet to a
router, and the selected router will be probed for reachability
as a side effect.
3) If the Default Router List is empty, assume that all
destinations are on-link as specified in Section 5.2.
6.3.7. Sending Router Solicitations
When an interface becomes enabled, a host may be unwilling to wait
for the next unsolicited Router Advertisement to locate default
routers or learn prefixes. To obtain Router Advertisements quickly,
a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router
Solicitation messages each separated by at least
RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent
after any of the following events:
- The interface is initialized at system startup time.
- The interface is reinitialized after a temporary interface
failure or after being temporarily disabled by system
management.
- The system changes from being a router to being a host, by
having its IP forwarding capability turned off by system
management.
- The host attaches to a link for the first time.
- The host re-attaches to a link after being detached for some
time.
A host sends Router Solicitations to the All-Routers multicast
address. The IP source address is set to either one of the
interface's unicast addresses or the unspecified address. The Source
Link-Layer Address option SHOULD be set to the host's link-layer
address, if the IP source address is not the unspecified address.
Before a host sends an initial solicitation, it SHOULD delay the
transmission for a random amount of time between 0 and
MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when
many hosts start up on a link at the same time, such as might happen
after recovery from a power failure. If a host has already performed
a random delay since the interface became (re)enabled (e.g., as part
of Duplicate Address Detection [ADDRCONF]) there is no need to delay
again before sending the first Router Solicitation message.
Once the host sends a Router Solicitation, and receives a valid
Router Advertisement with a non-zero Router Lifetime, the host MUST
desist from sending additional solicitations on that interface, until
the next time one of the above events occurs. Moreover, a host
SHOULD send at least one solicitation in the case where an
advertisement is received prior to having sent a solicitation.
Unsolicited Router Advertisements may be incomplete (see Section
6.2.3); solicited advertisements are expected to contain complete
information.
If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no
Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY
seconds after sending the last solicitation, the host concludes that
there are no routers on the link for the purpose of [ADDRCONF].
However, the host continues to receive and process Router
Advertisements messages in the event that routers appear on the link.
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.
- 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.
- 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".
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
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 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 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, processing becomes
quite a bit more complex. 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: if the state of the entry is REACHABLE,
set it to STALE, but do not update the entry in any other way;
otherwise, the received advertisement should be ignored and MUST NOT
update the cache. If the Override flag is set, both the Override
flag is clear and 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 is different
than 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, suggests 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.
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 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
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.
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 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.
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.
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.
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.
- 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.
- 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 1280 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. If the link-layer address is the same as that
already in the cache, the cache entry's state remains unchanged.