IPv6 ND Host-Host Communication Functions: Address Resolution, Next-Hop Determination, Neighbor Unr

IPv6 ND Host-Host Communication Functions: Address Resolution, Next-Hop Determination, Neighbor Unreachability Detection and Duplicate Address Detection

The delivery of datagrams in IP can be divided into two methods: direct and indirect. Indirect datagram delivery requires that routers provide help to hosts, which leads to the host-router discovery functions we examined in the previous topic. Direct delivery of datagrams is performed from one host to another on the same network. This doesn't require the use of routers, but necessitates other IPv6 ND protocol functions that involve Next-Hop Determination communication directly between local hosts.

Next-Hop Determination

The first task that any host must perform when it wants to send a datagram is Next-Hop Determination. This is the process by which a device looks at the destination address in a datagram and decides whether direct or indirect delivery are required. In early IPv4 this was done by looking at the class of the address, and later on, by using the subnet mask. In IPv6, the prefix information obtained from local routers is compared to the destination of the datagram to determine if the destination device is local or distant. If it is local, the next hop is the same as the destination address; if it is non-local, the next hop is chosen from the device's list of local routers (which are determined either by manual configuration or using the host-router discovery features of ND.)

For efficiency purposes, hosts do not perform this next-hop determination for each and every datagram. They maintain a destination cache that contains information about what the next hop should be for recent devices to which datagrams have been sent. Each time a next hop determination is performed for a particular destination, information from that determination is entered into the cache, so it can be used the next time datagrams are sent to that device.

 

Address Resolution

If a host determines that the destination of a datagram is in fact local, it will then need to send the datagram to that device. The actual transmission will occur using whatever physical layer and data link layer technology has been used to implement the local network. This requires that we know the layer two address of the destination, even though we only generally have the layer three address from the datagram. Getting from the layer three address to the layer two address is known as the address resolution problem.

In IPv6, the ND protocol is responsible for address resolution. When a host wants to get the layer two address of a datagram destination it sends a Neighbor Solicitation ICMPv6 message containing the IP address of the device whose layer two address it wishes to determine. That device responds back with a Neighbor Advertisement message that contains its layer two address. Instead of using a broadcast that would disrupt each device on the local network, the solicitation is sent using a special multicast to the destination device's solicited-node address. A more complete description of address resolution in IPv6 can be found in the general section on address resolution.

Note also that even though this discussion does concentrate on communication between hosts, address resolution may also be done when a host needs to send a datagram to a local router and has no entry for it in its destination cache. In the context of address resolution, a destination device is “just a neighbor”. Whether it is a host or a router only matters in terms of what happens after the datagram has been sent and received. In other words, these “host-to-host” functions are so named only because they are not specific to the communication between hosts and routers like the tasks in the preceding topic.

Updating Neighbors Using Neighbor Advertisement Messages

Devices do not routinely send Neighbor Advertisements the way routers send Router Advertisements. There really isn't any need for this: neighbors don't change much over time, and resolution will occur naturally over time as devices send datagrams to each other. In addition, having advertisements sent regularly by so many devices on a network would be wasteful.

A host may, however, send an unsolicited Neighbor Advertisement under certain conditions where it feels it is necessary to immediately provide updated information to other neighbors on the local network. A good example of this is a hardware failure—in particular, the failure of a network interface card. When the card is replaced, the device's layer two (MAC) address will change. Assuming this can be detected by the device's IP layer, it can send out an unsolicited Neighbor Advertisement message to tell other devices to update their resolution caches with the new MAC address.

 

Neighbor Unreachability Detection and the Neighbor Cache

Neighbor Solicitation and Neighbor Advertisement messages are most often associated with address resolution, but also have other purposes. One of these is Neighbor Unreachability Detection. Each device maintains information about each of its neighbors and updates it dynamically as network conditions change. The information is kept for both host and router devices that are neighbors on the local network.

Knowing that a device has become unreachable is important because a host can adapt its behavior accordingly. In the case of an unreachable host, a device may wait a certain period of time before trying to send datagrams to an unreachable host instead of flooding the network with repeated attempts to send to the host. An unreachable router, on the other hand, is a signal that the device needs to find a new router to use, if an alternate is available.

Each host maintains a neighbor cache that contains information about neighboring devices. Each time a host receives a datagram from a neighbor, it knows the neighbor is reachable at that particular moment, so the device makes an entry in the cache for the neighbor to indicate this. Of course, receiving a datagram from a neighbor now only means the neighbor is reachable now; the more time that elapses since the last datagram was received, the greater the chance that something has happened to make the neighbor no longer reachable.

For this reason, neighbor reachability information must be considered temporary. Each time a neighbor is entered into the cache as reachable, a timer is started. When the timer expires, the reachability information for that neighbor is considered stale, and reachability is no longer assumed for that neighbor. When a new datagram is received from the neighbor in question the timer is reset and the cache is again set to indicate that the device is reachable. The amount of time a host should consider a neighbor reachable before expiring it is communicated by a local router using a field in a Router Advertisement message.

A host can also dynamically seek out a neighbor if it needs to know its reachability status. It sends a Neighbor Solicitation to the device and waits for a Neighbor Advertisement in response. It then updates the cache accordingly.

Duplicate Address Detection

The last use of the two messages we have been discussing here is for Duplicate Address Detection. When a host uses the IPv6 autoconfiguration facility, one of the steps in the process is to ensure that the address it is trying to use doesn't already exist on the network. This is done by sending a Neighbor Solicitation message to the address the device wishes to use. If a Neighbor Advertisement is received in reply the address is already in use.

Key Concept: The second of the two main functional groups of the Neighbor Discovery protocol is the set of host-host communication functions. Two ICMPv6 messages are defined, Neighbor Advertisement and Neighbor Solicitation, which enable a variety of types of essential communication between adjacent hosts on a local network. These include address resolution, determining the next hop to which a datagram should be sent, and also the assessment of a neighboring device’s reachability.

 

http://www.tcpipguide.com/free/t_IPv6NDHostHostCommunicationFunctionsAddressResolut.htm