| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
TCP/IP Address Resolution For IP Version 6 (Page 1 of 2) 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 IPversion 6, or IPv6that 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.
Home - Table Of Contents - Contact Us The TCP/IP Guide (http://www.TCPIPGuide.com) Version 3.0 - Version Date: September 20, 2005 © Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. |