Please join me, we are about to explore the secrets of IPv6 Neighbor Discovery Cache. I am sure we will find that our goal is to better manage IPv6 without requiring incomplete knowledge or outdated text!
Recently, I have been reviewing the classic "TCP/IP Routing" by Jeff Doyle, and they are as good as I remember. If you are lucky enough to meet Jeff, then his writing style is very similar to his influence in real life: approachable and friendly. Related to this is that in his article, he conducts a thorough and precise review of the subject without resorting to cold technical prose, which is more suitable for the actual rfc he is explaining to readers.
The chapter on IPv6 in Volume 1 is particularly good. Although more than ten years have passed since the latest edition was published, it is not considered outdated. Of course, the technical content has not really changed significantly: Neighbor Discovery around 2005, for example, is essentially the neighbor discovery that we were still dealing with in 2017. However, Doyle's amiable writing style, coupled with his professional understanding of vital content, make this chapter an excellent choice for people to study and revisit frequently.
In fact, it is Jeff's sub-chapter on IPv6 Neighbor Unreachability Detection that reminds me that I may need to update the various possible states of Neighbor Discovery cache entries. So, inspired by the incomparable Mr. Doyle and his works, let us review the IPv6 Neighbor Discovery cache and its various states.
But before that, we first need to quickly review IPv6 Neighbor Discovery (ND). IPv6 Neighbor Discovery is generally considered to be an alternative to IPv4 Address Resolution Protocol (ARP). The most basic IPv6 discovery (ND) contains a set of addresses responsible for mapping layer 3 (IPv6) addresses within the same network segment or on the link to layer 2 (link layer; most commonly Ethernet MAC) addresses mechanism. Similarly, IPv6 nodes can use ND to discover routers on the link and learn which other IPv6 nodes are still accessible (and whether the link-layer address has changed).
All these functions are realized through the neighbor discovery (ND) cache. The content and format of the ND cache are almost the same as the ARP cache in IPv4.
To recap, IPv4 ARP relies on the use of the second layer broadcast mechanism. The host already knows the IP address of the device it wants to communicate with (for example, through DNS), but it still doesn't know the link-layer address of the device. ARP sends frames destined for the target IP address to the second layer (data link layer) using the second layer broadcast address. All devices connected to the link must receive and process this broadcast frame, but only the device whose IP address matches the target will respond to the requesting host, and the response contains the target link layer address. This becomes the ARP entry as shown above: the IPv4 address and its physical layer address. From now on, in the future, packets destined for this IP address can be used immediately (that is, no additional ARP processing is required) to encapsulate the layer 2 data frame with the correct destination link layer address provided by the ARP cache.
An obvious flaw of this mechanism is that each host must process all broadcast frames, regardless of whether these frames actually contain an ARP request sent to the host. The more hosts on the LAN segment, the more computing resources are wasted to process unnecessary ARP requests.
The function of IPv6 Neighbor Discover is similar to that of IPv4 ARP, but there are some key optimizations. The basic scheme for resolving layer 3 addresses to layer 2 addresses is the same as in IPv4 ARP: IPv6 hosts know the IPv6 address of the target, but they do not know its link layer address. However, instead of sending the ARP request to the broadcast target address as in IPv4, it sends a neighbor solicitation message to the requested node by multicasting the target address. The requested node multicast address is derived from the layer 3 unicast address on the target host (see example below). Only the host that listens to the multicast group address corresponding to the multicast address of the requested node (which itself corresponds to its layer 3 unicast address) will respond with a neighbor advertisement message and provide its link layer address to the sender The requested node then creates a neighbor discovery cache entry by that node.
Since the network will obviously and will change, once available devices go offline, and new devices go online, both ARP cache and ND cache must provide mechanisms to update their entries, as well as information that reflects the current status of ND cache entries.
This is where the five states of the IPv6 neighbor discovery cache come into play. They are:
- Incomplete
- Reachable
- Stale
- Delay
- Probe
The Incomplete state indicates that the address resolution is in progress, and the neighbor's link-layer address has not yet been determined. Strictly speaking, this means that a Neighbor Solicitation message with the target requested node address has been sent, but the corresponding Neighbor Advertisement has not yet been received.
The reachable state indicates that the reachability confirmation of the associated ND cache entry is received within a certain time interval (defined as ReachableTime). This positive confirmation may be that the neighbor advertisement was received after the neighbor request, or the upper layer protocol successfully used the ND cache entry.
An expired ND cache entry (Stale state) indicates that the ReachableTime has passed, after which subsequent confirmation of reachability is received.
The Delay state indicates that although the ReachableTime has expired, there are still upper-layer protocols that have recently sent data packets to the address of the cache item. After the defined time interval, a neighbor request will be sent and the ND cache entry will be changed to the detection state. The delayed state only provides time for the upper-layer protocol to possibly refresh the cache entry without neighbouring solicitation.
As mentioned earlier, the detection state occurs when the neighbor request is sent (possibly re-sent) until the response is received. (Ideally, the upper layer protocol will verify reachability during the delay phase)
Now that we know the status of the IPv6 neighbor discovery cache entries, how do we observe them on popular operating systems? We will cover this in detail in Part 2!