Neighbor Unreachability Detection

This mechanism is used to determine the current reachability of other nodes in your subnet. This improves robustness of packet delivery in the presence of failing routers or links. It can identify “partially failing” links (where packets can go from alice-pc to bob-pc, but not from bob-pc to alice-pc). it also improves packet delivery to nodes that change their link-local address, such as mobile nodes that move off-link without losing connectivity due to stale ARP caches (which is what happens in IPv4).

Each entry in the Neighbor Cache on any IPv6 compliant node contains an IPv6 address, a link-layer (e.g. MAC) address, and the reachability status for some node elsewhere on the subnet. The Neighbor Cache is similar to the ARP cache used in IPv4, but it contains more information for each entry.

There are five possible states for each entry in the Neighbor Cache:

INCOMPLETE – a new cache entry is created (with a link-layer address of zero), and address resolution is in progress. Any transmitted packets to this node are queued. When the address resolution is complete, the link-layer address is added into the new entry, and the state is changed to REACHABLE.

REACHABLE – any packets queued for this node are immediately sent. Any newly transmitted packets are then sent normally. If more than a certain amount of time passes without any traffic to or from the address in the entry, then the reachability state changes to STALE.

STALE – the reachability of the node is unknown. The entry for a node remains in this state until traffic to that node is generated. At that point, the packets are queued and the state changes to DELAY.

DELAY – the entry remains in the DELAY state for a short period. The status is still unknown. Once the delay expires, a Neighbor Solicitation message is sent, and the state changes to PROBE.

PROBE – a Neighbor Solicitation message has been sent to the node to determine reachability. The status is still unknown. If the expected response (a solicited Neighbor Advertisement message) is seen, reachability has been confirmed, and the state changes to REACHABLE. If no response is forthcoming within a certain interval, then the node is considered to be unreachable. In that case, any queued traffic is discarded, the neighbor cache entry is discarded, and an ICMPv6 Time Exceeded message (with Code=0) is sent to the source address of any queued packets.

You can cause most or all of the link-local addresses of nodes in your subnet to be added into your Neighbor Table by doing a “ping ff02::1” (“all nodes in local link” multicast address). Nodes that had not been in the table previously will be shown in the PROBE state for a few seconds, then those that are reachable with go into the REACHABLE state for a short while, then they will go into the STALE state. If you do the ping again again, those nodes that are reachable will change from STALE to REACHABLE for a short while.

In SixConf, select the IPv6 Neighbors tab to see the contents of the IPv6 Neighbor Table. Try doing the “ping ff02::1” then hitting Refresh every few seconds to watch the states change.

The Reachable Time from the Router Advertisement message specifies how long (in milliseconds) that a node that has just done NUD can assume the node is still reachable.

There is nothing corresponding to NUD in the IPv4 specification. However, in Windows 7, Microsoft has implemented the same basic functionality as is found in IPv6 NUD, and extended the ARP cache to contain reachability information. Linux has also done this. There do not appear to currently be any RFCs that cover this. Where possible, certain IPv6 innovations are being retrofitted into IPv4 like this. However, this is like putting a new saddle on an old horse that is about to die. It’s time to get a young, strong new horse.

In SixConf, select the IPv4 Neighbors tab to see the contents of the IPv4 Neighbor Table.