Address Resolution for IPV6

The TCP/IP Address Resolution Protocol (ARP) is a fairly generic protocol for dynamically resolving network layer addresses into data link layer addresses. Even though it was designed for IP version 4, the message format allows for variable-length addresses at both the hardware and network layers. This flexibility means it would have been theoretically possible to use it for the new version of IP—version 6, or IPv6—that is in our future. Some minor changes might have been required, but the technique could have been about the same.

The designers of IPv6 chose not to do this, however. Changing IP is a big job that has been underway for many years, and represents a rare opportunity to change various aspects of TCP/IP. The IETF decided to take advantage of the changes in IPv6 to overhaul not only IP itself, but also many of the protocols that “support” or “assist” IP. In IPv6, the address resolution job of ARP has been combined with several functions performed by ICMP in the original TCP/IP suite, supplemented with additional capabilities and defined as the new Neighbor Discovery (ND) protocol.

The term “neighbor” in IPv6 simply refers to devices on a local network, and as the name implies, ND is responsible for tasks related to communicating information between neighbors (among other things). I describe ND briefly in its own section, including a discussion of the various tasks it performs. Here I want to focus specifically on how ND performs address resolution.

Basic IPv6 Address Resolution Method

The basic concepts of address resolution in IPv6 ND aren't all that different from those in IPv4 ARP. Resolution is still dynamic and is based on the use of a cache table that maintains pairings of IPv6 addresses and hardware addresses. Each device on a physical network keeps track of this information for its neighbors. When a source device needs to send an IPv6 datagram to a local network neighbor but doesn't have its hardware address, it initiates the resolution process. For clarity in the text let's say that, as usual, device A is trying to send to device B.

Instead of sending an ARP Request message, A creates an ND Neighbor Solicitation message. Now, here's where the first big change can be seen from ARP. If the underlying data link protocol supports multicasting, like Ethernet does, the Neighbor Solicitation message is not broadcast. Instead, it is sent to the solicited-node address of the device whose IPv6 address we are trying to resolve. So A won't broadcast the message, it will multicast it to device B's solicited-node multicast address.

Device B will receive the Neighbor Solicitation and respond back to device A with a Neighbor Advertisement. This is analogous to the ARP Reply and tells device A the physical address of B. Device A then adds device B's information to its neighbor cache. For efficiency, cross-resolution is supported as in IPv4 address resolution. This is done by having Device A include its own layer two address in the Neighbor Solicitation, assuming it knows it. Device B will record this along with A's IP address in B's neighbor cache.

 

 

Using Solicited-Node Multicast Addresses For Resolution

The solicited-node multicast address is a special mapping that each device on a multicast-capable network creates from its unicast address; it is described in the topic on IPv6 multicast addresses. The solicited-node address isn't unique for every IPv6 address, but the odds of any two neighbors on a given network having the same one are small. Each device that receives a multicasted Neighbor Solicitation must still check to make sure it is the device whose address the source is trying to resolve. (This is similar to how multicast is handled in IPv4, with 32 different IP addresses potentially sharing a multicast MAC address.)

Why bother with this, if devices still have to check each message? Simple: the multicast will affect at most a small number of devices. With a broadcast, each and every device on the local network would receive the message, while the use of the solicited-node address means at most a couple of devices will need to process it. Other devices don't even have to bother checking the Neighbor Solicitation message at all.

Key Concept: Address resolution in IPv6 uses the new Neighbor Discovery (ND) protocol instead of the Address Resolution Protocol. A device trying to send an IPv6 datagram sends a Neighbor Solicitation message to get the address of another device, which responds with a Neighbor Advertisement. When possible, the request is sent using a special type of multicast address rather than broadcast, to improve efficiency.

This is actually a fairly simplified explanation of how resolution works in IPv6—the Neighbor Discovery protocol is quite complicated. Neighbor solicitations and advertisements are also used for other functions such as testing reachability of nodes and determining if duplicate addresses are in use. There are many special cases and issues that ND addresses to ensure that no problems result during address resolution. ND also supports proxied address resolution.

Note: Even though I put this topic where it would be near the other discussions of address resolution, the Neighbor Discovery protocol really isn't a “layer connection” or “lower level” protocol like ARP. It is analogous to ICMP in its role and function, and in fact makes use of ICMP(v6) messages. One advantage of this architectural change is that there is less dependence on the characteristics of the physical network, so resolution is accomplished in a way more similar to other network support activities. Thus it is possible to make use of facilities that can be applied to all IP datagram transmissions, such as IP security features. The section on ND contains much more information on this subject.