Join me as we probe without further delay the secrets of the IPv6 Neighbor Discovery cache. I’m sure we’ll find our goal of better managing IPv6 eminently reachable without incomplete knowledge or stale writing!
Lately, I’ve been revisiting Jeff Doyle’s classic Routing TCP/IP volumes and they are as great as I remember them. If you’ve ever had the pleasure of meeting Jeff, his writing style is very much like his affect in real life: approachable and friendly. Relatedly, in his texts, he manages both a thorough and precise review of the subject matter without resorting to the coldly technical prose that is a better fit for the actual RFCs he’s explicating for the reader.
The volume 1 chapter on IPv6 is particularly good and, in spite of the decade plus that has passed since the latest edition was published, doesn’t feel dated. Granted, the technical content hasn’t really changed significantly: for example, Neighbor Discovery circa 2005 is essentially the same Neighbor Discovery we’re still dealing with in 2017. But the combination of Mr. Doyle’s affable writing style and expert sense of what’s critically important to cover make the chapter an excellent choice to visit, and revisit, often.
In fact, it was Jeff’s sub-chapter on IPv6 Neighbor Unreachability Detection that reminded me I probably needed a refresher on the various possible states for Neighbor Discovery cache entries. So with the incomparable Mr. Doyle and his writing as the inspiration, let’s review the IPv6 Neighbor Discovery cache and its various states.
But before we get to that, a quick review of IPv6 Neighbor Discovery is in order. IPv6 Neighbor Discovery is commonly referred to and most basically understood as the replacement for IPv4 Address Resolution Protocol (ARP). At its most fundamental IPv6 ND contains the set of mechanisms responsible for mapping Layer 3 (IPv6) to Layer 2 (link-layer; most typically Ethernet MAC) addresses on a network segment or link. Also, IPv6 nodes can use ND to discover routers on the link as well as to learn which other IPv6 nodes are still reachable (and also if link-layer addresses have changed).
All of these functions are facilitated by the Neighbor Discovery cache. The ND cache is nearly identical in contents and format to the ARP cache in IPv4.
Recall that IPv4 ARP relies on the use of the Layer 2 broadcast. A host learns the IP address of the device it wishes to communicate with (via DNS, for example) but still doesn’t know the link-layer address of that device. ARP sends a frame with the target IP address as the destination to the broadcast address. All devices connected to that link must process this broadcast frame but only the device whose IP address matches the destination will respond back to the requesting host, filling in the destination link-layer address. This becomes an ARP entry like the ones displayed above: an IPv4 address corresponding to a physical address. Future packets destined for that IP address can now be immediately (i.e., no additional ARP process required) encapsulated in Layer 2 frames with the proper destination link-layer address supplied by the ARP cache.
An obvious liability of this mechanism is that every host must process all broadcast frames whether or not those frames actually contain an ARP request destined for that host. The more hosts on a LAN segment, the more compute resources are wasted by processing unwanted ARP requests.
IPv6 Neighbor Discover functions in a similar way but with some critical optimizations. The basic scenario requiring the resolution of a Layer 3 address to a Layer 2 address is the same as in IPv4 ARP: An IPv6 host knows the IPv6 address of the destination but not its link-layer address. However, instead of sending the ARP request to a broadcast destination address as in IPv4, it sends a Neighbor Solicitation message to the solicited node multicast destination address. This solicited node multicast address is derived from the Layer 3 unicast address on the target host (see examples below). Only the host listening to the multicast group address corresponding to its solicited node multicast address (which itself corresponds to its Layer 3 unicast address) will respond with a Neighbor Advertisement message, providing its link-layer address to the requesting node which then creates a Neighbor Discovery cache entry.
Because obviously networks can and do change, with devices that were once available going offline and new devices coming online, both the ARP cache and ND cache must offer mechanisms to bring their entries up-to-date — as well as information reflecting the current status of the ND cache entries.
This is where the five states of IPv6 Neighbor Discovery cache come into play. They are:
- Incomplete
- Reachable
- Stale
- Delay
- Probe
A status of incomplete indicates that address resolution is in concurrently progress and the neighbor’s link-layer address has yet to be determined. In strict terms this means that a Neighbor Solicitation message with the solicited node address of the target has been sent but a corresponding Neighbor Advertisement has yet to be received.
A status of reachable indicates that a positive confirmation of reachability for the associated ND cache entry was received within a certain time interval (defined as the ReachableTime). This positive confirmation could be the receipt of a Neighbor Advertisement following a Neighbor Solicitation or an upper-layer protocol successfully using the ND cache entry.
A stale ND cache entry means the ReachableTime has elapsed before a subsequent confirmation of reachability has been received.
A status of delay indicates that, though the ReachableTime has expired, a packet was recently sent to the cache entry’s address by an upper-layer protocol. After a defined interval, a Neighbor Solicitation is sent and the ND cache entry is changed to probe status. The delay status merely provides time for upper-layer protocols to potentially refresh the cache entry without resorting to a Neighbor Solicitation.
As just mentioned, the probe status occurs when a Neighbor Solicitation is sent, and possibly resent, until a response is received. (Ideally, an upper-layer protocol would have verified reachability during the delay phase.)
So now that we know what the IPv6 Neighbor Discovery cache entry states are, how do we observe them on popular operating systems? We’ll take a look at that and more in part 2!
https://blogs.infoblox.com/ipv6-coe/ipv6-neighbor-discovery-cache-part-1-of-2/
https://blogs.infoblox.com/ipv6-coe/ipv6-neighbor-discovery-cache-part-2-of-2/