1 - 2 - 3 - 6 - 8 - A - B - C - D - E - F - G - H - I - J - K - L - M - N - O - P - Q - R - S - T - U - V - W - X
reachability
Click on the red underlined text to get to the source
... prefix is the one that matches.
reachability
- whether or not the one-way "forward" path to a
...
... IP layer. For
neighboring routers, reachability means that packets
sent by a node's IP layer ...
... - a link where non-reflexive and/or non-transitive
reachability is part of normal operation. (Non-
reflexive reachability means packets from A reach B
...
... reachability is part of normal operation. (Non-
reflexive reachability means packets from A reach B
but packets from B don't reach A. Non-transitive
reachability ...
... reachability means packets from A reach B
but packets from B don't reach A. Non-transitive
reachability means packets from A reach B, and
packets from B reach C, but packets from A don't
reach C.) Many radio links ...
... Neighbor Solicitation messages that solicit Neighbor
Advertisements as reachability confirmation from the next hop. To
reduce unnecessary network traffic ...
... - Neighbor Discovery detects the absence of
symmetric reachability; a node avoids paths to a
neighbor ...
... node assumes a neighbor is
reachable after having received a reachability
confirmation. Used by the Neighbor Unreachability
Detection algorithm ...
... Destination address.
The S-bit is used as a reachability confirmation
for Neighbor Unreachability Detection. It MUST NOT
...
... Neighbor Unreachability Detection
algorithm, including the reachability state, the
number of unanswered probes ...
... default router favors routers known to be reachable
over those whose reachability is suspect. Each
entry also has an associated invalidation timer
...
... algorithm. A key piece of information is a
neighbor's reachability state, which is one of five possible values.
The following definitions are informal; precise definitions can be
...
... traffic is sent to the neighbor, no attempt
should be made to verify its reachability.
DELAY The neighbor ...
... link-layer address SHOULD be updated in the appropriate
Neighbor Cache entry, and its reachability state MUST also be set to
STALE. If there is no existing Neighbor Cache ...
... layer address and sets its reachability state to STALE as specified
in Section 7.3.3. Whether or not a Source Link-Layer Address option ...
... neighbor is considered reachable after
receiving a reachability confirmation.
This value should be a uniformly-distributed
...
... created
for the router its reachability state MUST be set to STALE as
specified in Section 7.3.3. If a cache ...
... cache entry already exists and is
updated with a different link-layer address the reachability state
MUST also be set to STALE.
...
... 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 ...
... node keeps track of a neighbor's reachability state are covered in
Section 7.3. The algorithm ...
... 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 ...
... 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
...
... address should be replaced by the
received address and the entry's reachability state MUST be set to
STALE.
...
... 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 ...
... 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 ...
... has failed, recovery may be possible. Thus, a node actively tracks
the reachability "state" for the neighbors to which it is sending
packets ...
... Reachability Confirmation ...
... routers forwarding
packets to hosts) such reachability information may not be readily
available from upper-layer protocols. When no hints ...
... 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.
...
... 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 ...
... 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
...
... perspective of Neighbor Unreachability Detection, only the
reachability of the forward path is of interest.
...
... the cached link-layer address. Receipt of such a
message does not confirm reachability, and entering
the STALE state insures reachability ...
... reachability, and entering
the STALE state insures reachability is verified
quickly if the entry is actually being used. However,
reachability ...
... reachability is verified
quickly if the entry is actually being used. However,
reachability is not actually verified until the entry
is actually used.
...
... 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
...
... 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 ...
... the subsequent three-way handshake would provide a
reachability confirmation almost immediately.
PROBE ...
...
PROBE A reachability confirmation is actively sought by
retransmitting Neighbor Solicitations every
...
... retransmitting Neighbor Solicitations every
RetransTimer milliseconds until a reachability
confirmation is received.
...
... neighbor. While reasserting a neighbor's
reachability, a node continues sending packets to that neighbor ...
...
When a reachability confirmation is received (either through upper-
layer advice or a solicited Neighbor Advertisement ...
...
When ReachableTime milliseconds have passed since receipt of the last
reachability confirmation for a neighbor, the Neighbor Cache entry's
...
... state changes to
PROBE. If reachability confirmation is received, the entry's state
changes to REACHABLE.
...
... 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 ...
... 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 ...
... so. However, link-specific information MUST NOT be used to confirm
the reachability of a neighbor; such information does not provide
end-to-end ...
... created for
the target its reachability state MUST be set to STALE as specified
in Section 7.3.3. If a cache ...
... 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 ...
... Adding additional procedures for links where asymmetric and non-
transitive reachability is part of normal operations. Such
procedures might allow hosts and routers ...
...
!INCOMPLETE upper-layer reachability - REACHABLE
confirmation
...
... REACHABLE timeout, more than - STALE
N seconds since
reachability confirm.
STALE Sending packet ...
... Appendix E.1: Reachability confirmations ...
... TCP and IP layers, an implementation may wish to rate-
limit the reachability confirmations its sends IP. One possibility
is to process reachability ...
... reachability confirmations its sends IP. One possibility
is to process reachability only every few packets. For example, one
might update reachability ...
... 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 ...
... 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
...
... 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
...
... 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
...