7. Address Resolution and Neighbor Unreachability Detection

This section describes address resolution and Neighbor Unreachability Detection. Address resolution is the process through which a node determines the link-layer address of a neighbor given only its IP address. Neighbor Unreachability Detection (NUD) is the process of tracking the reachability state of the path to a neighbor.

7.1. Address Resolution

Address resolution is performed only on addresses that are determined to be on-link. It is never performed on multicast addresses.

When a node has an IPv6 packet to send, it first examines the Destination Cache to determine the next-hop address for the destination. If the Destination Cache does not contain an entry for the destination, the node uses the next-hop determination algorithm (see Section 5.2) to determine the next-hop address.

Once the next-hop IP address is known, the sender examines the Neighbor Cache for link-layer information about the next hop. If no entry exists, the sender creates one, sets its state to INCOMPLETE, initiates Address Resolution, and queues the data packet pending completion of address resolution.

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 multicast IP address is described in a separate document that covers operating IP over a particular link type (e.g., [IPv6-ETHER]).

For unicast packets, address resolution is performed as follows. The sender creates a Neighbor Cache entry for the next-hop address (if one does not already exist), sets its state to INCOMPLETE, and initiates address resolution by sending a Neighbor Solicitation message to the solicited-node multicast address corresponding to the target address. The solicitation is sent from an address assigned to the interface from which the solicitation is sent.

The Target Address of the Neighbor Solicitation is set to the next-hop address. If the sender has an address assigned to the interface from which the Neighbor Solicitation is sent, the Source Link-Layer Address option SHOULD be included. If the sender does not have an address assigned to the interface from which the solicitation is sent (e.g., during initialization), the sender MUST NOT include the Source Link-Layer Address option.

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 number. Once address resolution completes, the node transmits any queued packets.

While waiting for address resolution to complete, the sender continues sending Neighbor Solicitations. Neighbor Solicitations for address resolution are sent every RetransTimer milliseconds until a Neighbor Advertisement is received or until the maximum number of Neighbor Solicitations (MAX_MULTICAST_SOLICIT) has been sent. If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT solicitations, address resolution has failed. The sender MUST free any cached copy of the packet and SHOULD return ICMP destination unreachable indications with code 3 (Address Unreachable) for each packet queued awaiting address resolution.

7.2. Neighbor Unreachability Detection

7.2.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 reaching the remote peer. If packets are reaching the peer, they must also be reaching the peer's IP layer, which is the requirement for Neighbor Unreachability Detection.

For off-link destinations, forward progress implies that the first-hop router is reachable. When such confirmation exists, an implementation MAY update the Neighbor Cache entry for the first-hop router and set its reachability state to REACHABLE. If an implementation does not track forward progress, it SHOULD assume that forward progress is being made when packets continue to be received from a remote peer.

Neighbor Unreachability Detection operates in parallel with applications that are sending packets. Sending a packet to a neighbor does not confirm its reachability; receipt of the corresponding acknowledgement does. An implementation MUST NOT conclude that a neighbor is reachable simply because it is actively being used.

When a node needs to perform address resolution on a neighboring address but already has a Neighbor Cache entry for the address in the STALE state, the node updates the state to DELAY rather than INCOMPLETE and sends a Neighbor Solicitation to confirm reachability. The node then waits DELAY_FIRST_PROBE_TIME seconds. If no reachability confirmation is received within that time, the entry's state is changed to PROBE, and Neighbor Unreachability Detection begins.

7.2.2. Neighbor Cache Entry States

A Neighbor Cache entry for a neighbor to which traffic is being sent can be in one of five possible states:

INCOMPLETE - Address resolution is currently 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 is performed 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 is performed 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 ensures that path failures are detected quickly. However, reachability is not actually verified until the entry is 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 unicast 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 unicast Neighbor Solicitations every RetransTimer milliseconds until a reachability confirmation is received or until the maximum number of probes (MAX_UNICAST_SOLICIT) has been sent. If no response is received after sending MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the entry SHOULD be deleted. Subsequent traffic to that neighbor will recreate the entry and perform 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 target more frequently than once every RetransTimer milliseconds.

7.2.3. Node Behavior

The Neighbor Unreachability Detection algorithm operates differently depending on whether the entry is being used to forward packets.

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 a node sends a packet to a neighbor whose entry is STALE, the node updates the entry's state to DELAY and 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, and a unicast Neighbor Solicitation is sent. The Neighbor Solicitation is sent using the cached link-layer address. Subsequent solicitations (if any) are sent using the same cached link-layer address. Neighbor Solicitations are retransmitted every RetransTimer milliseconds until a reachability confirmation is received or until MAX_UNICAST_SOLICIT solicitations have been sent.

If a Neighbor Advertisement is received in response to a unicast Neighbor Solicitation, and the Neighbor Advertisement's Solicited flag is set, the entry's state changes to REACHABLE. If the Solicited flag is not set, the entry remains in the PROBE state.

If a reachability confirmation is received in the PROBE state, the entry's state changes to REACHABLE. If the maximum number of probes has been sent without receiving a reachability confirmation, the entry SHOULD be deleted, and future traffic to that neighbor will require performing address resolution again. An implementation MAY garbage collect stale entries at any time. However, entries in the INCOMPLETE state SHOULD NOT be deleted until address resolution has failed (i.e., MAX_MULTICAST_SOLICIT Neighbor Solicitations have been sent and no response has been received).

7.3. Neighbor Unreachability Detection Protocol

This section provides an overview of how the Neighbor Unreachability Detection algorithm operates.

7.3.1. Reachability Confirmation Events

The following events cause a cached link-layer address to be reconfirmed as REACHABLE:

1. Receipt of a solicited Neighbor Advertisement for an entry in any state except INCOMPLETE.

2. Receipt of an upper-layer reachability confirmation (e.g., positive TCP acknowledgement) for an entry in any state except INCOMPLETE.

3. For an entry in the STALE, DELAY, or PROBE state, sending a Neighbor Solicitation and receiving a solicited Neighbor Advertisement.

7.3.2. State Transitions

State transitions occur as follows:

INCOMPLETE -> REACHABLE: When a valid Neighbor Advertisement is received that contains the Target Link-Layer Address option.

INCOMPLETE -> (deleted): When address resolution fails (i.e., MAX_MULTICAST_SOLICIT Neighbor Solicitations sent with no response).

REACHABLE -> STALE: When ReachableTime milliseconds elapse without receiving a reachability confirmation.

STALE -> DELAY: When a packet is sent to a neighbor in the STALE state.

STALE -> REACHABLE: When a reachability confirmation is received.

DELAY -> PROBE: When DELAY_FIRST_PROBE_TIME seconds elapse without receiving a reachability confirmation.

DELAY -> REACHABLE: When a reachability confirmation is received.

PROBE -> REACHABLE: When a reachability confirmation is received.

PROBE -> (deleted): When MAX_UNICAST_SOLICIT probes are sent without receiving a reachability confirmation.

7.3.3. Sending Neighbor Solicitations

When sending a Neighbor Solicitation message for the purpose of Neighbor Unreachability Detection, the following rules apply:

• The Target Address of the Neighbor Solicitation MUST be set to the IP address of the neighbor whose reachability is being confirmed.

• The Neighbor Solicitation MUST be sent as a unicast packet using the cached link-layer address.

• The Source Address of the Neighbor Solicitation MUST be an address assigned to the interface from which the Neighbor Solicitation is sent.

• The Neighbor Solicitation SHOULD include the Source Link-Layer Address option.

7.3.4. Receiving Neighbor Solicitations

When a Neighbor Solicitation is received, the recipient checks if it is the target of the solicitation. If so, the recipient SHOULD create or update the Neighbor Cache entry for the sender. If a Neighbor Cache entry for the sender already exists, the recipient updates the entry's link-layer address (if different) and sets the entry's state as follows:

• If the entry is in any state and the Override flag in a received Neighbor Advertisement is set, the entry's link-layer address is updated.

• If the entry is in the INCOMPLETE state, the entry's link-layer address is set to the value in the Source Link-Layer Address option (if present) and the state is set to STALE.

• If the entry is in any state other than INCOMPLETE, and the received Source Link-Layer Address differs from the cached link-layer address, and the Override flag is set, the cached link-layer address is replaced with the received address, and the entry's state remains unchanged.

7.4. Sending Neighbor Advertisements

A node sends Neighbor Advertisements in response to Neighbor Solicitations and also sends unsolicited Neighbor Advertisements when its link-layer address changes.

7.4.1. Responding to Neighbor Solicitations

When a Neighbor Solicitation is received, the target node SHOULD respond with a Neighbor Advertisement. The Neighbor Advertisement is sent to the source address of the Neighbor Solicitation if it is not the unspecified address; otherwise, the Neighbor Advertisement is sent to the all-nodes multicast address.

The Target Address of the Neighbor Advertisement is copied from the Target Address of the Neighbor Solicitation. The Solicited flag is set to one if the Neighbor Advertisement is sent in response to a Neighbor Solicitation; otherwise, it is set to zero.

If the Target Link-Layer Address option is included in the Neighbor Solicitation, and the link-layer address differs from the receiving node's link-layer address, the Override flag is set to one; otherwise, it is set according to the circumstances.

7.4.2. Unsolicited Neighbor Advertisements

A node may send unsolicited Neighbor Advertisements to announce changes to its link-layer address. When a node detects that its link-layer address has changed (e.g., after hot-swapping an Ethernet interface), it SHOULD multicast a few Neighbor Advertisements to the all-nodes multicast address to quickly update the neighbors' Neighbor Cache entries.

For unsolicited Neighbor Advertisements, the Override flag SHOULD be set to one to ensure that neighbors update their cached link-layer addresses. The Solicited flag MUST be set to zero in unsolicited Neighbor Advertisements.

---