RFC 1970
Neighbor Discovery for IP Version 6 (IPv6)
7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION This section describes the functions related to Neighbor Solicitation and Neighbor Advertisement messages and includes descriptions of address resolution and the Neighbor Unreachability Detection algorithm. Neighbor Solicitation and Advertisement messages are also used for Duplicate Address Detection as specified by [ADDRCONF]. In particular, Duplicate Address Detection sends Neighbor Solicitation messages with an unspecified source address targeting its own "tentative" address. Such messages trigger nodes already using the address to respond with a multicast Neighbor Advertisement indicating that the address is in use. 7.1. Message Validation 7.1.1. Validation of Neighbor Solicitations A node MUST silently discard any received Neighbor Solicitation messages that do not satisfy all of the following validity checks: - The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router. - If the message includes an IP Authentication Header, the message authenticates correctly. - ICMP Checksum is valid. - ICMP Code is 0. - ICMP length (derived from the IP length) is 24 or more octets. - Target Address is not a multicast address. - All included options have a length that is greater than zero. The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options;
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. While waiting for address resolution to complete, the sender MUST, for each neighbor, retain a small queue of packets waiting for address resolution to complete. The queue MUST hold at least one packet, and MAY contain more. However, the number of queued packets per neighbor SHOULD be limited to some small value. When a queue overflows, the new arrival SHOULD replace the oldest entry. Once address resolution completes, the node transmits any queued packets. While awaiting a response, the sender SHOULD retransmit Neighbor Solicitation messages approximately every RetransTimer milliseconds, even in the absence of additional traffic to the neighbor. Retransmissions MUST be rate-limited to at most one solicitation per neighbor every RetransTimer milliseconds. If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT solicitations, address resolution has failed. The sender MUST return ICMP destination unreachable indications with code 3 (Address Unreachable) for each packet queued awaiting address resolution. 7.2.3. Receipt of Neighbor Solicitations A valid Neighbor Solicitation where the Target Address is not a unicast or anycast address assigned to the receiving interface, and the Target Address is not a "tentative" address on which Duplicate Address Detection is being performed [ADDRCONF] MUST be silently ignored. If the Target Address is tentative, the Neighbor Solicitation should be processed as described in [ADDRCONF]. Upon receipt of a valid Neighbor Solicitation targeted at the node, the recipient SHOULD update the Neighbor Cache entry for the IP Source Address of the solicitation if the Source Address is not the unspecified address. If an entry does not already exist, the node SHOULD create a new one and set its reachability state to STALE as specified in Section 7.3.3. If a cache entry already exists and is updated with a different link-layer address its reachability state MUST be set to STALE. If the solicitation contains a Source Link- Layer Address option, the entry's cached link-layer address should be replaced with the one in the solicitation. If the Source Address is the unspecified address the node MUST NOT create or update the Neighbor Cache entry.
After any updates to the Neighbor Cache, the node sends a Neighbor Advertisement response as described in the next section. 7.2.4. Sending Solicited Neighbor Advertisements A node sends a Neighbor Advertisement in response to a valid Neighbor Solicitation targeting one of the node's assigned addresses. The Target Address of the advertisement is copied from the Target Address of the solicitation. If the solicitation's IP Destination Address is a unicast or anycast address, the Target Link-Layer Address option SHOULD NOT be included; the neighboring node's cached value must already be current in order for the solicitation to have been received. If the solicitation's IP Destination Address is a solicited-node multicast address, the Target Link-Layer option MUST be included in the advertisement. If the node is a router, it MUST set the Router flag to one; otherwise it MUST set the flag to zero. If the Target Address is either an anycast address or a unicast address for which the node is providing proxy service, or the Target Link-Layer Address option is not included in the outgoing advertisement, the Override flag SHOULD be set to zero. Otherwise, it SHOULD be set to one. Proper setting of the Override flag insures that nodes give preference to non-proxy advertisements, even when received after proxy advertisements, but that the first advertisement for an anycast address "wins". If the source of the solicitation is the unspecified address, the node MUST set the Solicited flag to zero and multicast the advertisement to the all-nodes address. Otherwise, the node MUST set the Solicited flag to one and unicast the advertisement to the Source Address of the solicitation. If the Target Address is an anycast address the sender SHOULD delay sending a response for a random time between 0 and MAX_ANYCAST_DELAY_TIME seconds. 7.2.5. Receipt of Neighbor Advertisements When a valid Neighbor Advertisement is received (either solicited or unsolicited), the Neighbor Cache is searched for the target's entry. If no entry exists, the advertisement SHOULD be silently discarded. There is no need to create an entry in this case, since the recipient has apparently not initiated any communication with the target. Once the appropriate Neighbor Cache entry has been located, the specific actions taken depend on the state of the Neighbor Cache entry and the flags in the advertisement. If the entry is in an INCOMPLETE state (i.e., no link-layer address is cached for the
target) the received advertisement updates the entry. If a cached link-layer address is already present, however, a node might choose to ignore the received advertisement and continue using the cached link-layer address. If the target's Neighbor Cache entry is in the INCOMPLETE state, the receiving node records the link-layer address in the Neighbor Cache entry and sends any packets queued for the neighbor awaiting address resolution. If the Solicited flag is set, the reachability state for the neighbor MUST be set to REACHABLE; otherwise it MUST be set to STALE. (A more detailed explanation of reachability state is described in Section 7.3.3). The Override flag is ignored if the entry is in the INCOMPLETE state. If the target's Neighbor Cache entry is in any state other than INCOMPLETE when the advertisement is received, the advertisement's Override flag's setting determines whether the Target Link-Layer Address option (if present) replaces the cached address. If the Override flag is set, the receiving node MUST install the link-layer address in its cache; if the flag is zero, the receiving node MUST NOT install the link-layer address in its cache. An advertisement's sender sets the Override flag when it wants its Target Link-Layer Address option to replace the cached value in Neighbor Cache entries, regardless of their current contents. If the target's Neighbor Cache entry is in any state other than INCOMPLETE when the advertisement is received, the advertisement's Solicited flag setting determines what the entry's new state should be. If the Solicited flag is set, the entry's state MUST be set to REACHABLE; if the flag is zero, the entry's state MUST be set to STALE. An advertisement's Solicited flag should only be set if the advertisement is a response to a Neighbor Solicitation. Because Neighbor Unreachability Solicitations are sent to the cached link- layer address, a receipt of a solicited advertisement indicates that the forward path is working. Receipt of an unsolicited advertisement, however, suggests that a neighbor has urgent information to announce (e.g., a changed link-layer address). Regardless of whether or not the new link-layer address is installed in the cache, a node should verify the reachability of the path it is currently using when it sends the next packet, so that it quickly finds a working path if the existing path has failed (e.g., as would be the case if the unsolicited Neighbor Advertisement is sent to announce a link-layer address change). In those cases where the cached link-layer address is updated, the receiving node MUST examine the Router flag in the received advertisement and update the IsRouter flag in the Neighbor Cache entry to reflect whether the node is a host or router. In those
cases where the neighbor was previously used as a router, but the advertisement's Router flag is now set to zero, the node MUST remove that router from the Default Router List and update the Destination Cache entries for all destinations using that neighbor as a router as specified in Section 7.3.3. 7.2.6. Sending Unsolicited Neighbor Advertisements In some cases a node may be able to determine that its link-layer address has changed (e.g., hot-swap of an interface card) and may wish to inform its neighbors of the new link-layer address quickly. In such cases a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited Neighbor Advertisement messages to the all-nodes multicast address. These advertisements MUST be separated by at least RetransTimer seconds. The Target Address field in the unsolicited advertisement is set to an IP address of the interface, and the Target Link-Layer Address option is filled with the new link-layer address. The Solicited flag MUST be set to zero, in order to avoid confusing the Neighbor Unreachability Detection algorithm. If the node is a router, it MUST set the Router flag to one; otherwise it MUST set it to zero. The Override flag MAY be set to either zero or one. In either case, neighboring nodes will immediately change the state of their Neighbor Cache entries for the Target Address to STALE, prompting them to verify the path for reachability. If the Override flag is set to one, neighboring nodes will install the new link-layer address in their caches. Otherwise, they will ignore the new link-layer address, choosing instead to probe the cached address. A node that has multiple IP addresses assigned to an interface MAY multicast a separate Neighbor Advertisement for each address. In such a case the node SHOULD introduce a small delay between the sending of each advertisement to reduce the probability of the advertisements being lost due to congestion. A proxy MAY multicast Neighbor Advertisements when its link-layer address changes or when it is configured (by system management or other mechanisms) to proxy for an address. If there are multiple nodes that are providing proxy services for the same set of addresses the proxies SHOULD provide a mechanism that prevents multiple proxies from multicasting advertisements for any one address, in order to reduce the risk of excessive multicast traffic. Also, a node belonging to an anycast address MAY multicast unsolicited Neighbor Advertisements for the anycast address when the node's link- layer address changes.
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 576 octets in size.
A router MUST limit the rate at which Redirect messages are sent, in
order to limit the bandwidth and processing costs incurred by the
Redirect messages when the source does not correctly respond to the
Redirects, or the source chooses to ignore unauthenticated Redirect
messages. More details on the rate-limiting of ICMP error messages
can be found in [ICMPv6].
A router MUST NOT update its routing tables upon receipt of a
Redirect.
8.3. Host Specification
A host receiving a valid redirect SHOULD update its Destination Cache
accordingly so that subsequent traffic goes to the specified target.
If no Destination Cache entry exists for the destination, an
implementation SHOULD create such an entry.
If the redirect contains a Target Link-Layer Address option the host
either creates or updates the Neighbor Cache entry for the target.
In both cases the cached link-layer address is copied from the Target
Link-Layer Address option. If a Neighbor Cache entry is created for
the target its reachability state MUST be set to STALE as specified
in Section 7.3.3. If a cache entry already existed and it is updated
with a different link-layer address its reachability state MUST also
be set to STALE.
In addition, if the Target Address is the same as the Destination
Address, the host MUST treat the destination as on-link and set the
IsRouter field in the corresponding Neighbor Cache entry to FALSE.
Otherwise it MUST set IsRouter to true.
Redirect messages apply to all flows that are being sent to a given
destination. That is, upon receipt of a Redirect for a Destination
Address, all Destination Cache entries to that address should be
updated to use the specified next-hop, regardless of the contents of
the Flow Label field that appears in the Redirected Header option.
A host MAY have a configuration switch that can be set to make it ignore a Redirect message that does not have an IP Authentication header. A host MUST NOT send Redirect messages. 9. EXTENSIBILITY - OPTION PROCESSING Options provide a mechanism for encoding variable length fields, fields that may appear multiple times in the same packet, or information that may not appear in all packets. Options can also be used to add additional functionality to future versions of ND. In order to ensure that future extensions properly coexist with current implementations, all nodes MUST silently ignore any options they do not recognize in received ND packets and continue processing the packet. All options specified in this document MUST be recognized. A node MUST NOT ignore valid options just because the ND message contains unrecognized ones. The current set of options is defined in such a way that receivers can process multiple options in the same packet independently of each other. In order to maintain these properties future options SHOULD follow the simple rule: The option MUST NOT depend on the presence or absence of any other options. The semantics of an option should depend only on the information in the fixed part of the ND packet and on the information contained in the option itself. Adhering to the above rule has the following benefits: 1) Receivers can process options independently of one another. For example, an implementation can choose to process the Prefix Information option contained in a Router Advertisement message in a user-space process while the link-layer address option in the same message is processed by routines in the kernel. 2) Should the number of options cause a packet to exceed a link's MTU, multiple packets can carry subsets of the options without any change in semantics. 3) Senders MAY send a subset of options in different packets. For instance, if a prefix's Valid and Preferred Lifetime are high enough, it might not be necessary to include the Prefix Information option in every Router Advertisement. In addition, different routers might send different sets of options. Thus, a receiver MUST NOT associate any action with the absence of an option in a
particular packet. This protocol specifies that receivers should
only act on the expiration of timers and on the information that is
received in the packets.
Options in Neighbor Discovery packets can appear in any order;
receivers MUST be prepared to process them independently of their
order. There can also be multiple instances of the same option in a
message (e.g., Prefix Information options).
If the number of included options in a Router Advertisement causes
the advertisement's size to exceed the link MTU, the router can send
multiple separate advertisements each containing a subset of the
options.
The amount of data to include in the Redirected Header option MUST be
limited so that the entire redirect packet does not exceed 576
octets.
All options are a multiple of 8 octets of length, ensuring
appropriate alignment without any "pad" options. The fields in the
options (as well as the fields in ND packets) are defined to align on
their natural boundaries (e.g., a 16-bit field is aligned on a 16-bit
boundary) with the exception of the 128-bit IP addresses/prefixes,
which are aligned on a 64-bit boundary. The link-layer address field
contains an uninterpreted octet string; it is aligned on an 8-bit
boundary.
The size of an ND packet including the IP header is limited to the
link MTU (which is at least 576 octets). When adding options to an
ND packet a node MUST NOT exceed the link MTU.
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize and
continue processing the message.
10. PROTOCOL CONSTANTS
Router constants:
MAX_INITIAL_RTR_ADVERT_INTERVAL 16 seconds
MAX_INITIAL_RTR_ADVERTISEMENTS 3 transmissions
MAX_FINAL_RTR_ADVERTISEMENTS 3 transmissions
MIN_DELAY_BETWEEN_RAS 3 seconds
MAX_RA_DELAY_TIME .5 seconds
Host constants:
MAX_RTR_SOLICITATION_DELAY 1 second
RTR_SOLICITATION_INTERVAL 4 seconds
MAX_RTR_SOLICITATIONS 3 transmissions
Node constants:
MAX_MULTICAST_SOLICIT 3 transmissions
MAX_UNICAST_SOLICIT 3 transmissions
MAX_ANYCAST_DELAY_TIME 1 second
MAX_NEIGHBOR_ADVERTISEMENT 3 transmissions
REACHABLE_TIME 30,000 milliseconds
RETRANS_TIMER 1,000 milliseconds
DELAY_FIRST_PROBE_TIME 5 seconds
MIN_RANDOM_FACTOR .5
MAX_RANDOM_FACTOR 1.5
Additional protocol constants are defined with the message formats in
Section 4.
All protocol constants are subject to change in future revisions of
the protocol.
The constants in this specification may be overridden by specific
documents that describe how IPv6 operates over different link layers.
This rule allows Neighbor Discovery to operate over links with widely
varying performance characteristics.
11. SECURITY CONSIDERATIONS
Neighbor Discovery is subject to attacks that cause IP packets to
flow to unexpected places. Such attacks can be used to cause denial
of service but also allow nodes to intercept and optionally modify
packets destined for other nodes.
The protocol reduces the exposure to such threats in the absence of
authentication by ignoring ND packets received from off-link senders.
The Hop Limit field of all received packets is verified to contain 255, the maximum legal value. Because routers decrement the Hop Limit on all packets they forward, received packets containing a Hop Limit of 255 must have originated from a neighbor. The trust model for redirects is the same as in IPv4. A redirect is accepted only if received from the same router that is currently being used for that destination. It is natural to trust the routers on the link. If a host has been redirected to another node (i.e., the destination is on-link) there is no way to prevent the target from issuing another redirect to some other destination. However, this exposure is no worse than it was; the target host, once subverted, could always act as a hidden router to forward traffic elsewhere. The protocol contains no mechanism to determine which neighbors are authorized to send a particular type of message e.g. Router Advertisements; any neighbor, presumably even in the presence of authentication, can send Router Advertisement messages thereby being able to cause denial of service. Furthermore, any neighbor can send proxy Neighbor Advertisements as well as unsolicited Neighbor Advertisements as a potential denial of service attack. Neighbor Discovery protocol packet exchanges can be authenticated using the IP Authentication Header [IPv6-AUTH]. A node SHOULD include an Authentication Header when sending Neighbor Discovery packets if a security association for use with the IP Authentication Header exists for the destination address. The security associations may have been created through manual configuration or through the operation of some key management protocol. Received Authentication Headers in Neighbor Discovery packets MUST be verified for correctness and packets with incorrect authentication MUST be ignored. It SHOULD be possible for the system administrator to configure a node to ignore any Neighbor Discovery messages that are not authenticated using either the Authentication Header or Encapsulating Security Payload. The configuration technique for this MUST be documented. Such a switch SHOULD default to allowing unauthenticated messages. Confidentiality issues are addressed by the IP Security Architecture and the IP Encapsulating Security Payload documents [IPv6-SA, IPv6- ESP].
REFERENCES [ADDRCONF] Thomson, S., and T. Narten, "IPv6 Address Autoconfiguration", RFC 1971, August 1996. [ADDR-ARCH] Deering, S., and R. Hinden, Editors, "IP Version 6 Addressing Architecture", RFC 1884, January 1996. [ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. [ARP] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, November 1982. [HR-CL] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989. [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [ICMPv6] Conta, A., and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 1885, January 1996. [IPv6] Deering, S., and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, January, 1996. [IPv6-ETHER] Crawford, M., "A Method for the Transmission of IPv6 Packets over Ethernet Networks", RFC 1972, August 1996. [IPv6-SA] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995. [IPv6-AUTH] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995. [IPv6-ESP] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995. [RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991. [SH-MEDIA] Braden, R., Postel, J., and Y. Rekhter, "Internet Architecture Extensions for Shared Media", RFC 1620, May 1994. [ASSIGNED] Reynolds, J., and J. Postel, "ASSIGNED NUMBERS", STD 2, RFC 1700, October 1994.
[SYNC] S. Floyd, V. Jacobsen, "The Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking, April 1994. ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z AUTHORS' ADDRESSES Erik Nordmark Thomas Narten Sun Microsystems, Inc. IBM Corporation 2550 Garcia Ave P.O. Box 12195 Mt. View, CA 94041 Research Triangle Park, NC 27709-2195 USA USA Phone: +1 415 786 5166 Phone: +1 919 254 7798 Fax: +1 415 786 5896 Fax: +1 919 254 4027 EMail: nordmark@sun.com EMail: narten@vnet.ibm.com William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 USA EMail: Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com
APPENDIX A: MULTIHOMED HOSTS There are a number of complicating issues that arise when Neighbor Discovery is used by hosts that have multiple interfaces. This section does not attempt to define the proper operation of multihomed hosts with regard to Neighbor Discovery. Rather, it identifies issues that require further study. Implementors are encouraged to experiment with various approaches to making Neighbor Discovery work on multihomed hosts and to report their experiences. If a multihomed host receives Router Advertisements on all of its interfaces, it will (probably) have learned on-link prefixes for the addresses residing on each link. When a packet must be sent through a router, however, selecting the "wrong" router can result in a suboptimal or non-functioning path. There are number of issues to consider: 1) In order for a router to send a redirect, it must determine that the packet it is forwarding originates from a neighbor. The standard test for this case is to compare the source address of the packet to the list of on-link prefixes associated with the interface on which the packet was received. If the originating host is multihomed, however, the source address it uses may belong to an interface other than the interface from which it was sent. In such cases, a router will not send redirects, and suboptimal routing is likely. In order to be redirected, the sending host must always send packets out the interface corresponding to the outgoing packet's source address. Note that this issue never arises with non-multihomed hosts; they only have one interface. 2) If the selected first-hop router does not have a route at all for the destination, it will be unable to deliver the packet. However, the destination may be reachable through a router on one of the other interfaces. Neighbor Discovery does not address this scenario; it does not arise in the non-multihomed case. 3) Even if the first-hop router does have a route for a destination, there may be a better route via another interface. No mechanism exists for the multihomed host to detect this situation. If a multihomed host fails to receive Router Advertisements on one or more of its interfaces, it will not know (in the absence of configured information) which destinations are on-link on the affected interface(s). This leads to a number of problems: 1) If no Router Advertisement is received on any interfaces, a multihomed host will have no way of knowing which interface to send packets out on, even for on-link destinations. Under similar
conditions in the non-multihomed host case, a node treats all
destinations as residing on-link, and communication proceeds. In
the multihomed case, however, additional information is needed to
select the proper outgoing interface. Alternatively, a node could
attempt to perform address resolution on all interfaces, a step
involving significant complexity that is not present in the non-
multihomed host case.
2) If Router Advertisements are received on some, but not all
interfaces, a multihomed host could choose to only send packets out
on the interfaces on which it has received Router Advertisements.
A key assumption made here, however, is that routers on those other
interfaces will be able to route packets to the ultimate
destination, even when those destinations reside on the subnet to
which the sender connects, but has no on-link prefix information.
Should the assumption be false, communication would fail. Even if
the assumption holds, packets will traverse a sub-optimal path.
APPENDIX B: FUTURE EXTENSIONS
Possible extensions for future study are:
o Using dynamic timers to be able to adapt to links with widely varying
delay. Measuring round trip times, however, requires acknowledgments
and sequence numbers in order to match received Neighbor
Advertisements with the actual Neighbor Solicitation that triggered
the advertisement. Implementors wishing to experiment with such a
facility could do so in a backwards-compatible way by defining a new
option carrying the necessary information. Nodes not understanding
the option would simply ignore it.
o Adding capabilities to facilitate the operation over links that
currently require hosts to register with an address resolution
server. This could for instance enable routers to ask hosts to send
them periodic unsolicited advertisements. Once again this can be
added using a new option sent in the Router Advertisements.
o Adding additional procedures for links where asymmetric and non-
transitive reachability is part of normal operations. Such
procedures might allow hosts and routers to find usable paths on,
e.g., radio links.
APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE
This appendix contains a summary of the rules specified in Sections
7.2 and 7.3. This document does not mandate that implementations
adhere to this model as long as their external behavior is consistent
with that described in this document.
When performing address resolution and Neighbor Unreachability
Detection the following state transitions apply using the conceptual
model:
State Event Action New state
- Packet to send. Create entry. INCOMPLETE
Send multicast NS.
Start retransmit timer
INCOMPLETE Retransmit timeout, Retransmit NS INCOMPLETE
less than N Start retransmit timer
retransmissions.
INCOMPLETE Retransmit timeout, Discard entry -
N or more Send ICMP error
retransmissions.
INCOMPLETE NA, Solicited=0, Record link-layer STALE
Override=any address. Send queued
packets.
INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE
Override=any address. Send queued
packets.
!INCOMPLETE NA, Solicited=1, - REACHABLE
Override=0
!INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE
Override=1 address.
!INCOMPLETE NA, Solicited=0, - STALE
Override=0
!INCOMPLETE NA, Solicited=0, Record link-layer STALE
Override=1 address.
!INCOMPLETE upper-layer reachability - REACHABLE
confirmation
REACHABLE timeout, more than - STALE
N seconds since
reachability confirm.
STALE Sending packet Start delay timer DELAY
DELAY Delay timeout Send unicast NS probe PROBE
Start retransmit timer
PROBE Retransmit timeout, Retransmit NS PROBE
less than N
retransmissions.
PROBE Retransmit timeout, Discard entry -
N or more
retransmissions.
The state transitions for receiving unsolicited information other
than Neighbor Advertisement messages apply to either the source of
the packet (for Neighbor Solicitation, Router Solicitation, and
Router Advertisement messages) or the target address (for Redirect
messages) as follows:
State Event Action New state
- NS, RS, RA, Redirect Create entry. STALE
INCOMPLETE NS, RS, RA, Redirect Record link-layer STALE
address. Send queued
packets.
!INCOMPLETE NS, RS, RA, Redirect Update link-layer STALE
Different link-layer address
address than cached.
!INCOMPLETE NS, RS, RA, Redirect - unchanged
Same link-layer
address as cached.
APPENDIX D: IMPLEMENTATION ISSUES
Appendix D.1: Reachability confirmations
Neighbor Unreachability Detection requires explicit confirmation that
a forward-path is functioning properly. To avoid the need for
Neighbor Solicitation probe messages, upper layer protocols should
provide such an indication when the cost of doing so is small.
Reliable connection-oriented protocols such as TCP are generally
aware when the forward-path is working. When TCP sends (or receives)
data, for instance, it updates its window sequence numbers, sets and
cancels retransmit timers, etc. Specific scenarios that usually
indicate a properly functioning forward-path include:
- Receipt of an acknowledgement that covers a sequence number (e.g.,
data) not previously acknowledged indicates that the forward path was
working at the time the data was sent. - Completion of the initial three-way handshake is a special case of the previous rule; although no data is sent during the handshake, the SYN flags are counted as data from the sequence number perspective. This applies to both the SYN+ACK for the active open the ACK of that packet on the passively opening peer. - Receipt of new data (i.e., data not previously received) indicates that the forward-path was working at the time an acknowledgement was sent that advanced the peer's send window that allowed the new data to be sent. To minimize the cost of communicating reachability information between the TCP and IP layers, an implementation may wish to rate- limit the reachability confirmations its sends IP. One possibility is to process reachability only every few packets. For example, one might update reachability information once per round trip time, if an implementation only has one round trip timer per connection. For those implementations that cache Destination Cache entries within control blocks, it may be possible to update the Neighbor Cache entry directly (i.e., without an expensive lookup) once the TCP packet has been demultiplexed to its corresponding control block. For other implementation it may be possible to piggyback the reachability confirmation on the next packet submitted to IP assuming that the implementation guards against the piggybacked confirmation becoming stale when no packets are sent to IP for an extended period of time. TCP must also guard against thinking "stale" information indicates current reachability. For example, new data received 30 minutes after a window has opened up does not constitute a confirmation that the path is currently working. In merely indicates that 30 minutes ago the window update reached the peer i.e. the path was working at that point in time. An implementation must also take into account TCP zero-window probes that are sent even if the path is broken and the window update did not reach the peer. For UDP based applications (RPC, DNS) it is relatively simple to make the client send reachability confirmations when the response packet is received. It is more difficult and in some cases impossible for the server to generate such confirmations since there is no flow control, i.e., the server can not determine whether a received request indicates that a previous response reached the client. Note that an implementation can not use negative upper-layer advise as a replacement for the Neighbor Unreachability Detection algorithm. Negative advise (e.g. from TCP when there are excessive retransmissions) could serve as a hint that the forward path from the
sender of the data might not be working. But it would fail to detect when the path from the receiver of the data is not functioning causing, none of the acknowledgement packets to reach the dgement