RFC 4861
Neighbor Discovery for IP version 6 (IPv6)
Pages: 97
Draft Standard
→ Errata
Obsoletes: 2461
Updated by: 5942 6980 7048 7527 7559 8028 8319 8425 9131 9685
Draft Standard
→ Errata
Obsoletes: 2461
Updated by: 5942 6980 7048 7527 7559 8028 8319 8425 9131 9685
Part 2 of 5 – Pages 18 to 38
4. Message Formats
This section introduces message formats for all messages used in this specification.4.1. Router Solicitation Message Format
Hosts send Router Solicitations in order to prompt routers to generate Router Advertisements quickly. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address An IP address assigned to the sending interface, or the unspecified address if no address is assigned to the sending interface. Destination Address Typically the all-routers multicast address. Hop Limit 255
ICMP Fields:
Type 133
Code 0
Checksum The ICMP checksum. See [ICMPv6].
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Valid Options:
Source link-layer address The link-layer address of the sender, if
known. MUST NOT be included if the Source Address
is the unspecified address. Otherwise, it SHOULD
be included on link layers that have addresses.
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.
4.2. Router Advertisement Message Format
Routers send out Router Advertisement messages periodically, or in
response to Router Solicitations.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O| Reserved | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
MUST be the link-local address assigned to the
interface from which this message is sent.
Destination Address
Typically the Source Address of an invoking Router
Solicitation or the all-nodes multicast address.
Hop Limit 255
ICMP Fields:
Type 134
Code 0
Checksum The ICMP checksum. See [ICMPv6].
Cur Hop Limit 8-bit unsigned integer. The default value that
should be placed in the Hop Count field of the IP
header for outgoing IP packets. A value of zero
means unspecified (by this router).
M 1-bit "Managed address configuration" flag. When
set, it indicates that addresses are available via
Dynamic Host Configuration Protocol [DHCPv6].
If the M flag is set, the O flag is redundant and
can be ignored because DHCPv6 will return all
available configuration information.
O 1-bit "Other configuration" flag. When set, it
indicates that other configuration information is
available via DHCPv6. Examples of such information
are DNS-related information or information on other
servers within the network.
Note: If neither M nor O flags are set, this indicates that no
information is available via DHCPv6.
Reserved A 6-bit unused field. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Router Lifetime
16-bit unsigned integer. The lifetime associated
with the default router in units of seconds. The
field can contain values up to 65535 and receivers
should handle any value, while the sending rules in
Section 6 limit the lifetime to 9000 seconds. A
Lifetime of 0 indicates that the router is not a
default router and SHOULD NOT appear on the default
router list. The Router Lifetime applies only to
the router's usefulness as a default router; it
does not apply to information contained in other
message fields or options. Options that need time
limits for their information include their own
lifetime fields.
Reachable Time 32-bit unsigned integer. The time, in
milliseconds, that a node assumes a neighbor is
reachable after having received a reachability
confirmation. Used by the Neighbor Unreachability
Detection algorithm (see Section 7.3). A value of
zero means unspecified (by this router).
Retrans Timer 32-bit unsigned integer. The time, in
milliseconds, between retransmitted Neighbor
Solicitation messages. Used by address resolution
and the Neighbor Unreachability Detection algorithm
(see Sections 7.2 and 7.3). A value of zero means
unspecified (by this router).
Possible options:
Source link-layer address
The link-layer address of the interface from which
the Router Advertisement is sent. Only used on
link layers that have addresses. A router MAY omit
this option in order to enable inbound load sharing
across multiple link-layer addresses.
MTU SHOULD be sent on links that have a variable MTU
(as specified in the document that describes how to
run IP over the particular link type). MAY be sent
on other links.
Prefix Information
These options specify the prefixes that are on-link
and/or are used for stateless address
autoconfiguration. A router SHOULD include all its
on-link prefixes (except the link-local prefix) so
that multihomed hosts have complete prefix
information about on-link destinations for the
links to which they attach. If complete
information is lacking, a host with multiple
interfaces may not be able to choose the correct
outgoing interface when sending traffic to its
neighbors.
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.
4.3. Neighbor Solicitation Message Format
Nodes send Neighbor Solicitations to request the link-layer address
of a target node while also providing their own link-layer address to
the target. Neighbor Solicitations are multicast when the node needs
to resolve an address and unicast when the node seeks to verify the
reachability of a neighbor.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
Either an address assigned to the interface from
which this message is sent or (if Duplicate Address
Detection is in progress [ADDRCONF]) the
unspecified address.
Destination Address
Either the solicited-node multicast address
corresponding to the target address, or the target
address.
Hop Limit 255
ICMP Fields:
Type 135
Code 0
Checksum The ICMP checksum. See [ICMPv6].
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Target Address The IP address of the target of the solicitation.
It MUST NOT be a multicast address.
Possible options:
Source link-layer address
The link-layer address for the sender. MUST NOT be
included when the source IP address is the
unspecified address. Otherwise, on link layers
that have addresses this option MUST be included in
multicast solicitations and SHOULD be included in
unicast solicitations.
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.
4.4. Neighbor Advertisement Message Format
A node sends Neighbor Advertisements in response to Neighbor
Solicitations and sends unsolicited Neighbor Advertisements in order
to (unreliably) propagate new information quickly.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
An address assigned to the interface from which the
advertisement is sent.
Destination Address
For solicited advertisements, the Source Address of
an invoking Neighbor Solicitation or, if the
solicitation's Source Address is the unspecified
address, the all-nodes multicast address.
For unsolicited advertisements typically the all-
nodes multicast address.
Hop Limit 255
ICMP Fields:
Type 136
Code 0
Checksum The ICMP checksum. See [ICMPv6].
R Router flag. When set, the R-bit indicates that
the sender is a router. The R-bit is used by
Neighbor Unreachability Detection to detect a
router that changes to a host.
S Solicited flag. When set, the S-bit indicates that
the advertisement was sent in response to a
Neighbor Solicitation from the Destination address.
The S-bit is used as a reachability confirmation
for Neighbor Unreachability Detection. It MUST NOT
be set in multicast advertisements or in
unsolicited unicast advertisements.
O Override flag. When set, the O-bit indicates that
the advertisement should override an existing cache
entry and update the cached link-layer address.
When it is not set the advertisement will not
update a cached link-layer address though it will
update an existing Neighbor Cache entry for which
no link-layer address is known. It SHOULD NOT be
set in solicited advertisements for anycast
addresses and in solicited proxy advertisements.
It SHOULD be set in other solicited advertisements
and in unsolicited advertisements.
Reserved 29-bit unused field. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Target Address
For solicited advertisements, the Target Address
field in the Neighbor Solicitation message that
prompted this advertisement. For an unsolicited
advertisement, the address whose link-layer address
has changed. The Target Address MUST NOT be a
multicast address.
Possible options:
Target link-layer address
The link-layer address for the target, i.e., the
sender of the advertisement. This option MUST be
included on link layers that have addresses when
responding to multicast solicitations. When
responding to a unicast Neighbor Solicitation this
option SHOULD be included.
The option MUST be included for multicast
solicitations in order to avoid infinite Neighbor
Solicitation "recursion" when the peer node does
not have a cache entry to return a Neighbor
Advertisements message. When responding to unicast
solicitations, the option can be omitted since the
sender of the solicitation has the correct link-
layer address; otherwise, it would not be able to
send the unicast solicitation in the first place.
However, including the link-layer address in this
case adds little overhead and eliminates a
potential race condition where the sender deletes
the cached link-layer address prior to receiving a
response to a previous solicitation.
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.
4.5. Redirect Message Format
Routers send Redirect packets to inform a host of a better first-hop node on the path to a destination. Hosts can be redirected to a better first-hop router but can also be informed by a redirect that the destination is in fact a neighbor. The latter is accomplished by setting the ICMP Target Address equal to the ICMP Destination Address. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address MUST be the link-local address assigned to the interface from which this message is sent. Destination Address The Source Address of the packet that triggered the redirect. Hop Limit 255
ICMP Fields:
Type 137
Code 0
Checksum The ICMP checksum. See [ICMPv6].
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Target Address
An IP address that is a better first hop to use for
the ICMP Destination Address. When the target is
the actual endpoint of communication, i.e., the
destination is a neighbor, the Target Address field
MUST contain the same value as the ICMP Destination
Address field. Otherwise, the target is a better
first-hop router and the Target Address MUST be the
router's link-local address so that hosts can
uniquely identify routers.
Destination Address
The IP address of the destination that is
redirected to the target.
Possible options:
Target link-layer address
The link-layer address for the target. It SHOULD
be included (if known). Note that on NBMA links,
hosts may rely on the presence of the Target Link-
Layer Address option in Redirect messages as the
means for determining the link-layer addresses of
neighbors. In such cases, the option MUST be
included in Redirect messages.
Redirected Header
As much as possible of the IP packet that triggered
the sending of the Redirect without making the
redirect packet exceed the minimum MTU specified in
[IPv6].
4.6. Option Formats
Neighbor Discovery messages include zero or more options, some of which may appear multiple times in the same message. Options should be padded when necessary to ensure that they end on their natural 64-bit boundaries. All options are of the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type 8-bit identifier of the type of option. The options defined in this document are: Option Name Type Source Link-Layer Address 1 Target Link-Layer Address 2 Prefix Information 3 Redirected Header 4 MTU 5 Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. The value 0 is invalid. Nodes MUST silently discard an ND packet that contains an option with length zero.4.6.1. Source/Target Link-layer Address
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Link-Layer Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type 1 for Source Link-layer Address 2 for Target Link-layer Address
Length The length of the option (including the type and
length fields) in units of 8 octets. For example,
the length for IEEE 802 addresses is 1
[IPv6-ETHER].
Link-Layer Address
The variable length link-layer address.
The content and format of this field (including
byte and bit ordering) is expected to be specified
in specific documents that describe how IPv6
operates over different link layers. For instance,
[IPv6-ETHER].
Description
The Source Link-Layer Address option contains the
link-layer address of the sender of the packet. It
is used in the Neighbor Solicitation, Router
Solicitation, and Router Advertisement packets.
The Target Link-Layer Address option contains the
link-layer address of the target. It is used in
Neighbor Advertisement and Redirect packets.
These options MUST be silently ignored for other
Neighbor Discovery messages.
4.6.2. Prefix Information
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type 3
Length 4
Prefix Length 8-bit unsigned integer. The number of leading bits
in the Prefix that are valid. The value ranges
from 0 to 128. The prefix length field provides
necessary information for on-link determination
(when combined with the L flag in the prefix
information option). It also assists with address
autoconfiguration as specified in [ADDRCONF], for
which there may be more restrictions on the prefix
length.
L 1-bit on-link flag. When set, indicates that this
prefix can be used for on-link determination. When
not set the advertisement makes no statement about
on-link or off-link properties of the prefix. In
other words, if the L flag is not set a host MUST
NOT conclude that an address derived from the
prefix is off-link. That is, it MUST NOT update a
previous indication that the address is on-link.
A 1-bit autonomous address-configuration flag. When
set indicates that this prefix can be used for
stateless address configuration as specified in
[ADDRCONF].
Reserved1 6-bit unused field. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Valid Lifetime
32-bit unsigned integer. The length of time in
seconds (relative to the time the packet is sent)
that the prefix is valid for the purpose of on-link
determination. A value of all one bits
(0xffffffff) represents infinity. The Valid
Lifetime is also used by [ADDRCONF].
Preferred Lifetime
32-bit unsigned integer. The length of time in
seconds (relative to the time the packet is sent)
that addresses generated from the prefix via
stateless address autoconfiguration remain
preferred [ADDRCONF]. A value of all one bits
(0xffffffff) represents infinity. See [ADDRCONF].
Note that the value of this field MUST NOT exceed
the Valid Lifetime field to avoid preferring
addresses that are no longer valid.
Reserved2 This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Prefix An IP address or a prefix of an IP address. The
Prefix Length field contains the number of valid
leading bits in the prefix. The bits in the prefix
after the prefix length are reserved and MUST be
initialized to zero by the sender and ignored by
the receiver. A router SHOULD NOT send a prefix
option for the link-local prefix and a host SHOULD
ignore such a prefix option.
Description
The Prefix Information option provide hosts with
on-link prefixes and prefixes for Address
Autoconfiguration. The Prefix Information option
appears in Router Advertisement packets and MUST be
silently ignored for other messages.
4.6.3. Redirected Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IP header + data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type 4
Length The length of the option in units of 8 octets.
Reserved These fields are unused. They MUST be initialized
to zero by the sender and MUST be ignored by the
receiver.
IP header + data
The original packet truncated to ensure that the
size of the redirect message does not exceed the
minimum MTU required to support IPv6 as specified
in [IPv6].
Description
The Redirected Header option is used in Redirect
messages and contains all or part of the packet
that is being redirected.
This option MUST be silently ignored for other
Neighbor Discovery messages.
4.6.4. MTU
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type 5
Length 1
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
MTU 32-bit unsigned integer. The recommended MTU for
the link.
Description
The MTU option is used in Router Advertisement
messages to ensure that all nodes on a link use the
same MTU value in those cases where the link MTU is
not well known.
This option MUST be silently ignored for other
Neighbor Discovery messages.
In configurations in which heterogeneous
technologies are bridged together, the maximum
supported MTU may differ from one segment to
another. If the bridges do not generate ICMP
Packet Too Big messages, communicating nodes will
be unable to use Path MTU to dynamically determine
the appropriate MTU on a per-neighbor basis. In
such cases, routers can be configured to use the
MTU option to specify the maximum MTU value that is
supported by all segments.
5. Conceptual Model of a Host
This section describes a conceptual model of one possible data
structure organization that hosts (and, to some extent, routers) will
maintain in interacting with neighboring nodes. The described
organization is provided to facilitate the explanation of how the
Neighbor Discovery protocol should behave. 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.
This model is only concerned with the aspects of host behavior
directly related to Neighbor Discovery. In particular, it does not
concern itself with such issues as source address selection or the
selecting of an outgoing interface on a multihomed host.
5.1. Conceptual Data Structures
Hosts will need to maintain the following pieces of information for
each interface:
Neighbor Cache
- A set of entries about individual neighbors to
which traffic has been sent recently. Entries are
keyed on the neighbor's on-link unicast IP address
and contain such information as its link-layer
address, a flag indicating whether the neighbor is
a router or a host (called IsRouter in this
document), a pointer to any queued packets waiting
for address resolution to complete, etc. A
Neighbor Cache entry also contains information used
by the Neighbor Unreachability Detection algorithm,
including the reachability state, the number of
unanswered probes, and the time the next Neighbor
Unreachability Detection event is scheduled to take
place.
Destination Cache
- A set of entries about destinations to which
traffic has been sent recently. The Destination
Cache includes both on-link and off-link
destinations and provides a level of indirection
into the Neighbor Cache; the Destination Cache maps
a destination IP address to the IP address of the
next-hop neighbor. This cache is updated with
information learned from Redirect messages.
Implementations may find it convenient to store
additional information not directly related to
Neighbor Discovery in Destination Cache entries,
such as the Path MTU (PMTU) and round-trip timers
maintained by transport protocols.
Prefix List - A list of the prefixes that define a set of
addresses that are on-link. Prefix List entries
are created from information received in Router
Advertisements. Each entry has an associated
invalidation timer value (extracted from the
advertisement) used to expire prefixes when they
become invalid. A special "infinity" timer value
specifies that a prefix remains valid forever,
unless a new (finite) value is received in a
subsequent advertisement.
The link-local prefix is considered to be on the
prefix list with an infinite invalidation timer
regardless of whether routers are advertising a
prefix for it. Received Router Advertisements
SHOULD NOT modify the invalidation timer for the
link-local prefix.
Default Router List
- A list of routers to which packets may be sent.
Router list entries point to entries in the
Neighbor Cache; the algorithm for selecting a
default router favors routers known to be reachable
over those whose reachability is suspect. Each
entry also has an associated invalidation timer
value (extracted from Router Advertisements) used
to delete entries that are no longer advertised.
Note that the above conceptual data structures can be implemented using a variety of techniques. One possible implementation is to use a single longest-match routing table for all of the above data structures. Regardless of the specific implementation, it is critical that the Neighbor Cache entry for a router is shared by all Destination Cache entries using that router in order to prevent redundant Neighbor Unreachability Detection probes. Note also that other protocols (e.g., Mobile IPv6) might add additional conceptual data structures. An implementation is at liberty to implement such data structures in any way it pleases. For example, an implementation could merge all conceptual data structures into a single routing table. The Neighbor Cache contains information maintained by the Neighbor Unreachability Detection 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 found in Section 7.3.2. INCOMPLETE Address resolution is in progress and the link-layer address of the neighbor has not yet been determined. REACHABLE Roughly speaking, the neighbor is known to have been reachable recently (within tens of seconds ago). STALE The neighbor is no longer known to be reachable but until traffic is sent to the neighbor, no attempt should be made to verify its reachability. DELAY The neighbor is no longer known to be reachable, and traffic has recently been sent to the neighbor. Rather than probe the neighbor immediately, however, delay sending probes for a short while in order to give upper-layer protocols a chance to provide reachability confirmation. PROBE The neighbor is no longer known to be reachable, and unicast Neighbor Solicitation probes are being sent to verify reachability.
5.2. Conceptual Sending Algorithm
When sending a packet to a destination, a node uses a combination of the Destination Cache, the Prefix List, and the Default Router List to determine the IP address of the appropriate next hop, an operation known as "next-hop determination". Once the IP address of the next hop is known, the Neighbor Cache is consulted for link-layer information about that neighbor. Next-hop determination for a given unicast destination operates as follows. The sender performs a longest prefix match against the Prefix List to determine whether the packet's destination is on- or off-link. If the destination is on-link, the next-hop address is the same as the packet's destination address. Otherwise, the sender selects a router from the Default Router List (following the rules described in Section 6.3.6). For efficiency reasons, next-hop determination is not performed on every packet that is sent. Instead, the results of next-hop determination computations are saved in the Destination Cache (which also contains updates learned from Redirect messages). When the sending node has a packet to send, it first examines the Destination Cache. If no entry exists for the destination, next-hop determination is invoked to create a Destination Cache entry. Once the IP address of the next-hop node is known, the sender examines the Neighbor Cache for link-layer information about that neighbor. If no entry exists, the sender creates one, sets its state to INCOMPLETE, initiates Address Resolution, and then queues the data packet pending completion of address resolution. For multicast- capable interfaces Address Resolution consists of sending a Neighbor Solicitation message and waiting for a Neighbor Advertisement. When a Neighbor Advertisement response is received, the link-layer addresses is entered in the Neighbor Cache entry and the queued packet is transmitted. The address resolution mechanism is described in detail in Section 7.2. For multicast packets, the next-hop is always the (multicast) destination address and is considered to be on-link. The procedure for determining the link-layer address corresponding to a given IP multicast address can be found in a separate document that covers operating IP over a particular link type (e.g., [IPv6-ETHER]).
Each time a Neighbor Cache entry is accessed while transmitting a unicast packet, the sender checks Neighbor Unreachability Detection related information according to the Neighbor Unreachability Detection algorithm (Section 7.3). This unreachability check might result in the sender transmitting a unicast Neighbor Solicitation to verify that the neighbor is still reachable. Next-hop determination is done the first time traffic is sent to a destination. As long as subsequent communication to that destination proceeds successfully, the Destination Cache entry continues to be used. If at some point communication ceases to proceed, as determined by the Neighbor Unreachability Detection algorithm, next- hop determination may need to be performed again. For example, traffic through a failed router should be switched to a working router. Likewise, it may be possible to reroute traffic destined for a mobile node to a "mobility agent". Note that when a node redoes next-hop determination there is no need to discard the complete Destination Cache entry. In fact, it is generally beneficial to retain such cached information as the PMTU and round-trip timer values that may also be kept in the Destination Cache entry. Routers and multihomed hosts have multiple interfaces. The remainder of this document assumes that all sent and received Neighbor Discovery messages refer to the interface of appropriate context. For example, when responding to a Router Solicitation, the corresponding Router Advertisement is sent out the interface on which the solicitation was received.5.3. Garbage Collection and Timeout Requirements
The conceptual data structures described above use different mechanisms for discarding potentially stale or unused information. From the perspective of correctness, there is no need to periodically purge Destination and Neighbor Cache entries. Although stale information can potentially remain in the cache indefinitely, the Neighbor Unreachability Detection algorithm ensures that stale information is purged quickly if it is actually being used. To limit the storage needed for the Destination and Neighbor Caches, a node may need to garbage-collect old entries. However, care must be taken to ensure that sufficient space is always present to hold the working set of active entries. A small cache may result in an excessive number of Neighbor Discovery messages if entries are discarded and rebuilt in quick succession. Any Least Recently Used (LRU)-based policy that only reclaims entries that have not been used
in some time (e.g., ten minutes or more) should be adequate for garbage-collecting unused entries. A node should retain entries in the Default Router List and the Prefix List until their lifetimes expire. However, a node may garbage-collect entries prematurely if it is low on memory. If not all routers are kept on the Default Router list, a node should retain at least two entries in the Default Router List (and preferably more) in order to maintain robust connectivity for off-link destinations. When removing an entry from the Prefix List, there is no need to purge any entries from the Destination or Neighbor Caches. Neighbor Unreachability Detection will efficiently purge any entries in these caches that have become invalid. When removing an entry from the Default Router List, however, any entries in the Destination Cache that go through that router must perform next-hop determination again to select a new default router.
(page 38 continued on part 3)