In the last article, we discussed the router discovery process and mentioned that router discovery also includes information that helps with parameter discovery (e.g., MTU) and prefix discovery. In this article, we will be discussing prefix discovery.
We are already familiar with the router advertisement message but, in the last article, we saw only two of the ICMPv6 options—MTU and Source link-layer address options. In this article, we will see the Prefix Information option, which provides hosts with on-link prefixes and possibly prefixes for address autoconfiguration. We will continue using our network scenario, as shown below, but with a few tweaks:
I have added two new unicast addresses on R1’s Fa0/0 interface. The first one is a global unicast address of 2001:db8:1000::1/64 and the second one is a unique local address of fda4:db8:1000:1/64, as shown below:
Therefore, when R1 sends router advertisement messages to the link to which Fa0/0 is connected, it will include those prefixes in the advertisement. Our Wireshark capture shows this:
Notice that there are two Prefix information options each carrying one of the prefixes we defined newly on R1. This tells us that the Prefix information option can be included more than once in a router advertisement. Actually, there will be one Prefix information option for each on-link prefix that a router has. The only prefix that should not be sent is the link-local prefix because the link-local address is always on-link.
Let’s take a look at one of these prefix information options.
This prefix information contains the prefix 2001:db8:1000::/64. In the flags section, there are three flags. RFC 4861 defines the first two flags while the last flag (router address flag) is defined in RFC 6275: Mobility support for IPv6.
When the L-bit (on-link flag) is set, it means that the prefix can be used for on-link determination. When this bit is not set, it does not mean that the prefix is off-link. The A-bit (autonomous address-configuration) specifies whether the prefix can be used for stateless address autoconfiguration (when set to 1) or not (when set to 0).
There are also two lifetime fields. The first field , valid lifetime, specifies how long (in seconds) the prefix is valid for on-link determination. The default is 2592000 seconds (30 days). The second field, preferred lifetime, specifies how long (in seconds) addresses generated from the prefix remain preferred. The default is 604800 seconds (7 days).
Going back to our captured packet, we can see that both the L-bit and A-bit are set for this prefix. This means that our host will add the prefix to its prefix list for on-link determination and also generate an address using that prefix.
Notice that this host has two addresses for each prefix. The two extra addresses are temporary addresses generated from temporary interface identifiers. This provides a level of animosity for hosts, otherwise it becomes very easy to determine the address of a host using its permanent interface ID irrespective of the prefix. This is documented in RFC 4941.
As shown from below, these generated addresses are completely usable and I can ping R1 on both prefixes:
Also, notice that it is the temporary addresses that are used to initiate the connections, as shown by the neighbor cache of R1.
So far, we have talked about address resolution, duplicate address detection, next-hop determination, router discovery, parameter discovery and, just above, prefix discovery. Let’s now talk about another function—redirect.
A router sends a redirect message to inform a host of a better next-hop address for a particular address. For example, rather than a host going through R1-R2-Dest, the router can inform the host to go directly through R2-Dest, if R2 is also a router on the same link. This situation can arise when there are multiple routers in the default router list and the host is using one that is “farther” from the destination.
Another instance when a redirect message can be sent is when the destination address that the host is trying to reach is actually a neighbor. This is possible if the host does not have that neighbor’s prefix in its prefix list. A destination that is not in the prefix list will be forwarded to the default router.
Let’s see how the redirect message is triggered in response to a better next-hop address. I have configured a loopback interface on R2 with an IP address of 2001:db8:2222::2/64:
I have also added a static route for this new address on R1 pointing to the link-local address of R2:
What would happen if our host tries to ping 2001:db8:2222::2? Since that prefix is not contained in its prefix list, it will assume that the destination is off-link and so will send the traffic to its default router. Let’s check the current default router of the host:
Since fe80::1 (R1) is listed first, it seems the host is using that as its default gateway. So let’s ping:
As you can see, the ping goes through; however, let us use Wireshark to look at what happened in the background:
The capture shows the first ping request that was sent to R1, being the default gateway. I know it was sent to R1 because the destination MAC address of that packet is the MAC address of R1.
R1 receives this packet and processes it. It knows the packet was received from a neighbor and, by looking at its routing table, it determines that the packet should be sent to R2. At this point, R1 knows that both the host that sent the packet and the next-hop address for the packet (R2) are on the same link, i.e., they are neighbors. Therefore, R1 will forward the packet on to R2 but will also send a redirect message to the host informing the host of a better next-hop address for that destination.
You can see the redirect message in the screenshot above after the first pick request packet. The contents of that message are as shown below:
The Redirect message is carried in an ICMPv6 message of type 137. The Target Address field contains the address of the better next-hop, i.e., R2. The Destination Address field contains the address of the destination being redirected to the target. In the case where the router is informing the host that the destination is a neighbor, both of these fields will contain the same value.
Next, this redirect message contains two options. The first option is the Target link-layer address option, where R1 specifies the link-layer address of the target (i.e., R2):
The second option is the redirected header, which contains as much of the IP packet that triggered the sending of the redirect message. If you look closely at the contents of this option as shown below, you will notice it contains the first ping request packet.
The result of a redirect message is that the host will update the entry for that destination in its destination cache with the better next-hop address.
Therefore, subsequent ping packets will be sent to this new next-hop address, as shown below. Notice that the destination MAC address is now that of R2:
This brings us to the end of this article, in which we have discussed the prefix discovery function of the neighbor discovery protocol. We saw that this function is achieved using the Prefix information option carried in router advertisement messages.
We then went on to discuss the redirect function also performed by the ND protocol using the redirect message. The redirect message is used to inform a host of a better next-hop address for a destination or to inform the host that the destination address is a neighbor on the link.
At this point, we have covered seven of the nine functions performed by ND and, in the next article, we will be looking at another one, Neighbor Unreachability Detection. I hope you have found this article insightful and I look forward to writing the next one in the series.
References and Further Reading
RFC 4861: Neighbor Discovery for IP version 6 (IPv6): http://tools.ietf.org/html/rfc4861
Introduction to IPv6: http://technet.microsoft.com/library/bb726944.aspx