RFC 2461
Neighbor Discovery for IP Version 6 (IPv6)
4. MESSAGE FORMATS 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 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. 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 message periodically, or in
response to a Router Solicitation.
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
Authentication Header
If a Security Association for the IP Authentication
Header exists between the sender and the
destination address, then the sender SHOULD include
this header.
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, hosts use the administered (stateful) protocol
for address autoconfiguration in addition to any
addresses autoconfigured using stateless address
autoconfiguration. The use of this flag is
described in [ADDRCONF].
O 1-bit "Other stateful configuration" flag. When
set, hosts use the administered (stateful) protocol
for autoconfiguration of other (non-address)
information. The use of this flag is described in
[ADDRCONF].
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
maximum value corresponds to 18.2 hours. 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 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
multihomed host 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 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header.
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 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header.
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 have 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
Authentication Header
If a Security Association for the IP Authentication
Header exists between the sender and the
destination address, then the sender SHOULD include
this header.
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 which 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 1280 octets.
4.6. Option Formats Neighbor Discovery messages include zero or more options, some of which may appear multiple times in the same message. 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.
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. For
instance, the prefix might be used for address
configuration with some of the addresses belonging
to the prefix being on-link and others being off-
link.
A 1-bit autonomous address-configuration flag. When
set indicates that this prefix can be used for
autonomous 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].
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 1280
octets.
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 insure 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 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., IPv6 Mobility) 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). If the Default Router List is empty,
the sender assumes that the destination is on-link.
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 insure 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 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 37 continued on part 3)
