Experimenting with ICMPv6

Post Views: 1,592

With more and more networking professionals tackling IPv6 and the changes incorporated into this next generation protocol, necessity requires that we look closely at the Internet Control Message Protocol as it has been highly modified for IPv6 support.

The experiment outlined below will walk you through a packet capture that contains ICMPv6 packet exchanges. You will need to use Wireshark(TM). Wireshark is available for download at www.wireshark.org.

With Wireshark available, the next preparation you must make is to download this file by simply clicking on the name: ICMPv6_Experiment2.pcap

If the file did not open immediately in Wireshark, then double click on the file in your download directory, or open it via the Wireshark interface. You should have a screen that looks something like this (actual output may vary based on your Wireshark configuration):

Background

Before we look at this, let’s fill in a little background. IPv6 and more specifically ICMPv6 adds “Stateless Autoconfiguration” as an option for getting IPv6 address prefixes onto devices you wish to access the Internet. Stateless means that there is no DHCP server, and no state information. All the network node does is start up with its interfaces and attempts to configure them with a FE80::/10 prefix. This prefix is called the link local address and is not routed. Therefore adding either the EUI-64 (the interface MAC address with FFFE between the OUI and the MAC) or a pseudo random address to this FE80 prefix procedure can be done as the node boots up.

The problem, however, is that the node has no idea whether this IPv6 Link Local address is unique and it must first perform a uniqueness test on the local network/VLAN before actually installing the address. If the address is unique then the node is ready. If it is not, then the node must generate a different interface ID and try again. Since MACS are supposed to be unique, the likelihood of passing the uniqueness test is very high.

Once uniqueness is determined, the node must now listen or request a Router Advertisement. That router advertisement will contain the IPv6 network prefix that the node can install along side the Link Local prefix (IPv6 supports more than one address on an interface), and the node can then begin communicating.

Experiment

Now lets explore this process by examining the packet capture more closely.

Step 1

In the Wireshark display, click on the second packet in the packet list. Then, expand (click on the small ‘+’) both the IPv6 and the ICMPv6 protocols. The result should look like this:

Step 2

Look first at the IPv6 protocol area you expanded. Note that Wireshark has identified this packet as a Next header ICMPv6 type 58 message. The source IPv6 address is “::”, meaning all 0’s for this message. This would be correct as we need to discover the neighbor and make sure there is no duplicate address.

Further, note the destination address is an IPv6 Multicast prefix FF02::1 (interpreted as all nodes on the local link), but is then followed by :FF94:B10E. When a MAC is added in this fashion, we call this the Solicited Node Multicast Address or SNMA, allowing the solicitation to be sent to a particular node that may have been learned via discovery (listening). We note here that ARP is no longer used in IPv6 networking.

Step 3

Now examine the ICMPv6 protocol area you expanded.

We see that this is a Neighbor Solicitation message, ICMPv6 Type 135.

Step 4

Now lets look at the next packet in the capture. Select packet #3, then only expand the IPv6 protocol for the moment.

We see the source now using its link local address and it is sending this ICMPv6 message to FF02::2, meaning all routers on the local link.

Step 5

Now close the IPv6 protocol area and expand the ICMPv6 protocol area as well as the ICMPv6 Option area by clicking on the “+” signs.

We see this is a Router Solicitation, Type 133 message. Further, we see the source MAC address is 00:1B:63:94:B1:0E. You will note that Wireshark has interpreted the first three numbers as the Organizational Unique Identifier (OUI) for Apple Computer.

Step 6

The response to the solicitation above, is a Router Advertisement. This is the next packet in the capture. Select packet 4. The Internet Control Message Protocol v6 should still be expanded, and you should note the Type is 134 Router Advertisement:

Step 7

Now expand the Flags item by clicking on the ‘+’ sign:

You can see that all the flags are defined in the Wireshark analysis according to the RFC’s definitions. In this capture the flags are all zeros indicating stateless autoconfiguration is in place for the network from which the capture was taken. Here is a chart that explains the combinations possible of the first two bits: the Managed Address Configuration flag (M) and the Other Configuration flag (O):

Station Parameters	Stateless Autoconfig.	Stateless DHCP	Stateful DHCP
Prefix/Length	From the Router Advertisement M=0 and O=0	From the Router Advertisement M=0 and O=1	From the Router Advertisement M=1 and O=1
Interface Identifier	Auto Configuration	Auto Configuration	From DHCPv6 Server
DNS, NTP address, etc.	Manual Configuration	From DHCPv6 Server	From DHCPv6 Server

Step 8

Now scroll down and expand all three ICMPv6 options by clicking each of the three ‘+’ signs (you may need to continue to scroll so they are all visible).

In the first option field, we see that the Link layer address of the advertising router is 00:1B:90:2D:0E:43, the OUI portion of which Wireshark has interpreted to be a Cisco device.

In the second option field, we see the link local MTU is 1500 octets. So when sending IPv6 packets this is the starting MTU. Keep in mind that the local node must keep a Path MTU cache so packets going to different destinations may go out with different (smaller) MTUs based on ICMPv6 error messages specific to certain destinations.

In the third option field, we see the Valid and Preferred lifetimes associated with the prefix being advertised. These are usually in seconds, so we see the Valid lifetime is 30 days and the preferred lifetime is 7 days. Lastly we see that the global IPv6 prefix to be used has been advertised to the node as 3FFE:80C0:22C1:0190:: (highlighted in green) which is a /64 prefix.

Step 9

Next, click on packet 5 of the capture.

We see that now a Neighbor Solicitation has been sent out on the local network with the new IPv6 prefix installed indicating success.

Summary

This experiment has shown the ICMPv6 protocol operation in Stateless Autoconfiguration. We have seen how a node does duplicate address detection, solicits the local router and then receives a router advertisement and has installed the advertised prefix.