Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4)       9  TCP/IP Network Interface / Internet "Layer Connection" Protocols            9  Address Resolution and the TCP/IP Address Resolution Protocol (ARP)

TCP/IP Address Resolution For IP Multicast Addresses 1 2 Reverse Address Resolution and the TCP/IP Reverse Address Resolution Protocol (RARP)

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.

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.

TCP/IP Address Resolution For IP Multicast Addresses 1 2 Reverse Address Resolution and the TCP/IP Reverse Address Resolution Protocol (RARP)