In the last article, we began discussing the Neighbor Discovery (ND) protocol. We highlighted the functions performed and ICMPv6 packet types used by this protocol. We then went on to discuss the address resolution function in detail where we encountered the neighbor solicitation and neighbor advertisement messages. We looked in-depth into the neighbor solicitation message, and in this article, we will conclude our discussion of the address resolution function, see the neighbor advertisement message and also cover another function performed by ND.

The network setup that we are using is as shown below:

Our address resolution began when we initiated ping traffic from R1 to R2, while capturing packets on R2’s Fa0/0 interface. The Wireshark capture is shown below with the neighbor solicitation and neighbor advertisement messages highlighted in red.

We discovered that when R1 wanted to send the traffic to R2, it sent a neighbor solicitation message to discover the link-layer (MAC) address of R2’s IP address. This message was sent to the solicited-node multicast address of R2’s IP address. Like we said in the previous article, R2 must be listening for messages on that solicited-node multicast address as shown below:

Therefore, R2 receives the message, processes it and sees that the Target Address contained in the neighbor solicitation message belongs to one of its interfaces. Therefore, it prepares a Neighbor Advertisement message and sends it back to the requester. Let’s now look at that message in detail:

Again, we will begin with the upper-layer protocol (ICMPv6) and move down. The ICMPv6 message brought into focus is as shown below:

We see that this is a Neighbor Advertisement message because it has a type value of 136. You will also notice that this message contains a set of three flags as explained below:

  1. Router flag: When this flag is set (i.e. the R-bit has a value of 1), it means the neighbor advertisement message was sent by a router.
  2. Solicited flag: When the S-bit is set, it means the neighbor advertisement message was sent in response to a neighbor solicitation message. There are other times when this flag will not be set, such as when an unsolicited neighbor advertisement is sent or when the destination address is a multicast address.
  3. Override flag: When the O-bit is set, it means the advertisement should override and update the existing cache entry of a link-layer address.

As you can see, all the flags are set in this particular neighbor advertisement message. Next, the Target Address field contains the same value as the Target Address field in the neighbor solicitation message: it contains the IP address that needs to be resolved to a link-layer address. In an unsolicited advertisement, this field will contain the IP address of the interface whose link-layer address has changed.

Finally, in the ICMPv6 option field, we have the Target link-layer address, which contains the link-layer address of the sender of the advertisement. In this scenario, the sender of the advertisement is R2 from its Fa0/0 interface which has a MAC address of c2:01:2c:fc:00:00.

The general format of the Neighbor Advertisement message is as shown below. We have already discussed the various fields in the preceding sentences.

Now we move to the IP layer.

You should be familiar with the fields of the IPv6 header by now. For example, the Next header field contains the value of 58 because ICMPv6 is the upper-layer protocol. You will also notice that the Hop limit is set to 255 as discussed in the last article. In fact, for all five ICMPv6 packet types that ND uses, the hop limit will be set to 255 in the IPv6 header. The source address is the address of R2’s Fa0/0 interface. Also, we notice that the destination address is now a unicast address (i.e. the address of the sender of the neighbor solicitation message) and not a multicast address as we saw in the neighbor solicitation message.

Finally, we look at the Ethernet frame.

Again, because this message is unicast, the destination MAC address will be the MAC address of R1’s Fa0/0 interface and the source MAC address is the MAC address of R2 (its Fa0/0 interface).

When R1 receives this advertisement message, it updates its neighbor cache with the link-layer address specified in the Target link-layer address field of that message and can now send the ping traffic to R2 as highlighted below in the Wireshark capture:

Duplicate Address Detection

Now that we have covered address resolution, let us look at another function of the Neighbor Discovery protocol – Duplicate Address Detection. The same two messages – Neighbor solicitation and Neighbor advertisement – are used to accomplish this function but with a few differences in their field values.

Before a node will use the address assigned (manually or automatically) to an interface, it must first perform duplicate address detection to determine that there is no other node on the link using that same address. This was accomplished by gratuitous ARP in IPv4.

In IPv6, a node will send a neighbor solicitation message to the solicited-node multicast address of that IP address to be checked for duplication. If it gets a neighbor advertisement back from another node using that address, it knows the address is a duplicate and does not assign it.

Let’s see this in live capture. I have shut down the Fa0/0 interface of R2, changed its IP address to fe80::1 (which R1 is currently using) and then brought the interface back up. This triggers the duplicate address detection and a neighbor solicitation message is sent as shown below:

The Target Address field contains the IP address to be checked for duplication. Now, let us highlight the differences between this message and the one sent for address resolution. First, there is no ICMPv6 Source link-layer address option because R2 is still trying to determine if anyone is using that address. Secondly, the source address in the IPv6 header is the unspecified address i.e. “::”. We have finally seen a use of the unspecified IPv6 address.

In the Ethernet frame, the source MAC address is c2:01:24:80:00:00 which is the MAC address of R2’s Fa0/0 interface as shown below. Finally, the destination MAC address is the Ethernet multicast MAC address of the solicited-node multicast address.

Note: I have restarted the routers between this section and the previous section on address resolution. That is why the MAC addresses have changed.

Now, because R1 is already using that IP address, it will send a Neighbor advertisement message, basically saying “Hey, I’m already using that address. Back off!” But where will R1 send this message to since R2 used the unspecified IPv6 address? The Wireshark capture will reveal this:

R1 sends that advertisement to the all-nodes link-local multicast address, i.e. ff02::1. Since R2 is necessarily a part of this multicast group, it will definitely receive the advertisement and know that the address it intends to use is already in use. Lastly, notice that the S-bit (Solicited flag) is not set in this advertisement because it is being sent to a multicast destination.

If that address was not being used on the link, R2 will not get any neighbor advertisements back and thus it will begin using that address. This is how duplicate address detection works in a nutshell. For further study of this process, you can read the RFC description here.

Summary

This brings us to the end of this article where we have concluded our discussion on the address resolution function of the Neighbor Discovery protocol. We encountered the second ICMPv6 packet type used by ND – Neighbor Advertisement message – and looked at the fields contained therein. We then went on to see how these two messages (Neighbor solicitation and Neighbor advertisement) come into play in the Duplicate Address Detection on IPv6 links.

In the next article, we will continue looking at the other functions performed by ND. I hope you have found this article helpful.

References and further reading

  1. RFC 4861: Neighbor Discovery for IP version 6 (IPv6): http://tools.ietf.org/html/rfc4861
  2. RFC 4862: IPv6 Stateless Address Autoconfiguration: http://tools.ietf.org/html/rfc4862