Stateless Autoconfiguration

August 22, 2015

A packet series about IPv6

If you perform nearly any role in the information technology world, you’re no doubt familiar with the issue of IPv4 exhaustion and the challenges of IPv6 adoption. While it doesn’t mean that every business, small and large, will be renumbering their entire networks anytime soon, it does mean that every IT professional should have a familiarity (I’d argue comfortability) with this new addressing scheme that will be directing our packets to and from their destinations in the future.

While you can get a run-down of the basic IPv6 concepts in 10 minutes on Youtube, I thought it would be beneficial to take a deep-dive into the packet structure and protocols that enable IPv6 to function. IPv6 isn’t just IPv4 with letters and more fields. Rather, the IPv6 community proposes a rich set of protocols that hope to alleviate some of the issues experienced with IPv4 (not the least of which is address exhaustion). That’s going to be the purpose of this series of articles: to explore, at a packet level, the protocols that claim to dictate the future of our network traffic.

I don’t know how many articles there will be, or even every topic that I intend to cover. If you’re the type of person who enjoys splitting your monitor between a packet capture and an RFC, then this will (hopefully) be the series for you. While the goal will be to take a plunge into some of the many topics surrounding IPv6, this series of articles will by no means be an exhaustive explanation of IPv6. For a deep dive into IPv6, I would recommend Silvia Hagen’s book: IPv6 Essentials. In fact, her book has been one of my main sources of IPv6 knowledge, and these articles will follow along somewhat with the chapters in the book.

I will also aim to provide reproducible experiments that you can follow along with. I’ll be using GNS3, Virtualbox, and Wireshark in this series. Each article will have complete topology information, including configurations, so that you can follow along yourself. This series will assume basic competency with these tools, and a basic familiarity with IPv6 and it’s addressing format.

Now that introductions are out of the way, let’s discuss the first topic: Stateless Address Autoconfiguration.

IPv6 Addressing Basics

Just like with IPv4, the first thing that a host needs is an address. With IPv4, we typically had two methods of device addressing: static assignment or DHCP. IPv6 introduces a new form of addressing, known as stateless autoconfiguration (or stateless address autoconfiguration, aka SLAAC) that allows hosts to automatically obtain an IP address for both local communication (using the FE80::/10 prefix) or global communication (using router advertisements to derive the prefix). In this article, we’ll be taking a packet look at how the autoconfiguration process works.

Before we start talking about autoconfiguration, let’s remind ourselves of the ways that a host can obtain an IP address with IPv6:

Manual configuration – one or more IPv6 addresses are assigned to an interface via static configuration on the device.
Stateful autoconfiguration – a device is automatically assigned an address via a method that maintains state, such through DHCPv6. The DHCPv6 server maintains state about the addresses that it has handed out. Records such as time, lifetime of the lease, and details about the host may be stored by the DHCP server.
Stateless autoconfiguration – a device is automatically assigned an address via a method that does not maintain state. This is the method that we will be exploring in this article. A device assigns itself an IPv6 address either based on it’s MAC address or via a pseudo-random method. No information about the address’s state is tracked by any protocol or server.

Stateless Autoconfiguration Overview

Stateless autoconfiguration is primarily defined in RFC 4862. We’ll be taking a packet look at some of the processes that drive the ability of a host to give itself both local and global IPv6 addresses and ensure that no other hosts are currently using these addresses. At a high-level a host will autoconfigure itself by performing the following steps:

Generate a tentative link local address within the FE80::/10 prefix, using the details specified in Section 5.3 of RFC 4862. This involves using the MAC address of the Ethernet interface to create a predictable 64-bit host identifier via the EUI-64 process. We won’t discuss this process, as there are many great explanations of it already, such as the TCP/IP Guide’s explanation. Since a global IP address being based on a unique MAC address may have privacy concerns, use of RFC 4941 may be desired to generate a pseudo-random interface identifier that changes over time.
Join the all-nodes multicast group (FF02::1) and the solicited-node multicast group for the tentative link local address. A tentative address is exactly what it sounds like: it hasn’t yet been confirmed to be unique, and it can’t yet be used for communication.
Perform duplicate address detection (DAD) by using Neighbor Solicitations sent with the target IP of the tentative address. Assuming no conflicts are found, the tentative address can then become a preferred address.
Discover routers and additional prefixes by sending out a router solicitation to the all-routes multicast group (FF02::2). If router advertisements are received, the autoconfiguration process is performed for each prefix within the received messages.

Topology Overview

We’ll be using the topology above for our packet dive into autoconfiguration. The router is a Cisco 3725 running 12.4(15)T14 Advanced Enterprise Services K-9 IOS. The host is running CentOS 6.7. The entire topology is virtualized using GNS3 and VirtualBox. The router configuration can be found here, and the /etc/sysconfig/network-scripts/ifcfg-eth0 configuration file can be found here.

The network under study uses two IPv6 prefixes: FDE4:8DBA:82E1:1::/64 and FDE4:8DBA:82E1:2::/64. Both subnets are available for unique local address use (roughly equivalent to private IPv4 IP addresses) within the larger FC00::/7 unique local address space defined in RFC4193. We use two prefixes because it allows us to better explore the autoconfiguration process.

Diving into the packets

Alright, now let’s take a look at the packets that make autoconfiguration a reality!

First, we’ll take a look at the general packet trace seen above. We can see clearly the process discussed earlier. The first packets are the multicast listener reports for joining the solicited-node multicast group for our tentative link-local address. Next, we see the neighbor solicitation for the tentative address, the router solicitation and advertisement to obtain autoconfiguration information, and the resulting multicast listener reports and neighbor solicitations for our newly configured addresses. Next, we’ll take a closer look at the multicast report message.

Let’s begin by taking a look at the Ethernet and IPv6 headers for the multicast listener report message. At the Ethernet layer, we can see that the message is being sent with a source MAC address of the CentOS virtual machine (08:00:27:4D:CD:1A) and a destination MAC address of the IPv6 multicast address for multicast listener discovery (33:33:00:00:00:16). Section 7 of RFC 2464 specifies that the Ethernet destination for a multicast message should begin with 33:33 as the first two octets, and the last four octets should contain the destination multicast address. In this case, that destination is 16, because the destination IPv6 multicast address for multicast listener discovery (MLD) is FF02::16.

Next, we can take a look at the IPv6 header. We see that the source address is set to all zeroes. This is because the host does not yet have a valid preferred IPv6 address. The current autoconfigured address is only tentative, until the duplicate address discovery process is performed. The destination address is the well-known multicast address for multicast listener discovery (FF02::16), as specified in Section 11 of RFC 3810. We can also see that the Router Alert IPv6 option has been set.

RFC 2711 details the router alert option. Router alert is used to alert the router that an IPv6 packet requires inspection by the router, as is the case with control protocols like MLD. The use of router alert allows a router to forward all other packets as quickly as possible, knowing that if the router alert option is not set, then the router does not have to perform any specific processing of the packet. We can see that the router alert is set for MLD, as expected. Next, we’ll finally take a look at the MLD message itself.

Finally, we can see the ICMPv6 MLD report for the solicited-node multicast group of the tentative IPv6 address. Multicast Listener Discovery Version 2 is defined in RFC 3810. We can see that this report is of type “change to exclude,” and it does not contain any addresses in it’s number of sources. This indicates that the host is not excluding any sources. It is joining to the FF02::1:FF4D:CD1A group, which is the solicited-node multicast group for the earlier generated address. This will help in the duplicate address detection mechanism, as discussed in the next section.

You will also notice that the multicast address won’t exactly match the generated IPv6 address. The solicited-node multicast address is a link local address that is created by appending the last 24 bits of the unicast address to the FF02::1:FF00:0/104 prefix, as defined in Section 2.7.1 of RFC 4291. Examples of this address conversion can also be found on Wikipedia.

We earlier mentioned that the host must also join the all-nodes multicast address. However, we don’t see any MLD messages for the all nodes FF02::1 address. This is because Section 6 of RFC 3810 indicates that all nodes must be permanently listening to this group on all interfaces. Therefore, there is no need for hosts to send join messages, as it is implied that they are listening to this multicast address by nature of being IPv6 compliant.

The host then sends an ICMPv6 neighbor solicitation message. I’m hoping to spend more time taking a look at neighbor solicitation messages at a later time, but for our current purposes we can think of it like Address Resolution Protocol (ARP) in IPv4. During this stage of the autoconfiguration process, the host is performing duplicate address detection (DAD) as discussed in Section 5.4 of RFC 4862.

The Ethernet and IPv6 header destination fields merit brief discussion. The neighbor solicitation is sent to the IPv6 solicited-nodes multicast address for the desired host. In this case, the host is performing DAD to ensure that the tentative address (FE80::A00:27FF:FE4D:CD1A) is not already taken. Therefore, it will send a neighbor solicitation to the solicited-node multicast address of FF02::1:FF4D:CD1A.

The ICMPv6 header is of type 135 for neighbor solicitation, and the target IP is the EUI-64 link-local address generated by the host. If another host on the network is already using this IP address, then it will have registered to the solicited-node multicast address of FF02::1:FF4D:CD1A and will respond with an ICMPv6 Neighbor Advertisement message. The host will become aware that an address conflict exists. At this point, the autoconfiguration process will halt, and administrative intervention is required. As we can see from the earlier packet trace overview, no such advertisement is received.

The process continues with a router solicitation ICMPv6 message sent to the all-routers multicast address of FF02::2. Section 4.1 of RFC 4861 defines one option for this message: the source link-layer address, which can be seen in the packet above. All routers on the network segment will process the router solicitation and respond with router advertisements, as seen below. This packet is also the first packet to use the host’s preferred link-local IPv6 address of FE80::A00:27FF:FE4D:CD1A as the source address in the IPv6 header. Having completed the DAD process, the host can now begin to use the address in communication.

The router advertisement is described in Section 4.2 of RFC 4861. We can see that the router advertisement is an ICMPv6 type 134 message sent to the all-nodes multicast address. We can see a router lifetime of 18000 seconds. We can also see a reachable time and a retrans timer of 0, which indicates that the retrans timer is unspecified by the router. Finally, we come to the ICMPv6 options that are relevant to the autoconfiguration process.

The source link-layer address contains the MAC address of the router interface, and serves the same purpose as discussed earlier. We then see an option specifying the MTU of 1500 for the segment. Finally, we can see two prefix information options that specify the IPV6 prefixes configured on our local network. Let’s drill down into one of these prefix information sections.

The prefix information option, which is ICMPv6 Option 6, is described in Section 4.6.2 of RFC 4861. The first relevant field is the prefix length field, which specifies a value of 64. This is expected, as we are using the FDE4:8DBA:82E1:1::/64 subnet. Next, we have the on-link flag, which indicates that this prefix is located on the local layer 2 domain. The autonomous address-configuration flag indicates that this prefix can be used in the stateless autoconfiguration process, and our host is free to assign itself an address via the means that we have discussed so far.

The next two values before our prefix are the valid and preferred lifetimes. The valid lifetime specifies the length of time that the prefix can be used for on-link determination. In other words, this value specifies the number of seconds that the host can use this prefix when determining if other hosts are on the same layer 2 domain. The preferred lifetime is the number of seconds that the host’s generated autoconf address for this prefix can be considered a preferred address. The expiration of a preferred autoconfigured address is discussed in Section 5.5.4 of RFC 4862.

Finally, the actual prefix of FDE4:8DBA:82E1:1:: is given. Our host can now use this prefix to generated a tentative address and perform the DAD process. Once the host is sure that no other host is using the address, it will have a preferred address for the specified prefix. The router advertisement contains two Prefix Information options: one for the FDE4:8DBA:82E1:1::/64 prefix and one for the FDE4:8DBA:82E1:2::/64 prefix. For the sake of brevity, we won’t be examining the second option, since it is largely the same as the first.

Our CentOS host must register to the solicited-node multicast address and perform the DAD process for each address that it creates via the stateless autoconfiguration process. Above, we can see this process after the router advertisement is received by the host. Since we’ve already covered this process (and these packets) in thorough detail, we won’t go over it again.

Now that the stateless autoconfiguration process is complete, we see that our CentOS host has the three addresses that we expect:

An address on the FDE4:8DBA:82E1:2::/64 subnet
An address on the FDE4:8DBA:82E1:1::/64 subnet
A link-local address with the FE80::/10 prefix

Notice that each address ends in the EUI-64 identifier for the host’s MAC address: a00:27FF:FE4D:CD1A. Earlier, we mentioned privacy extensions designed to randomize the interface identifier in an IPv6 address. This functionality is disabled by default on our CentOS host, according Red Hat documentation about the IPV6_PRIVACY interface configuration option.

Conclusion

The IPv6 stateless address autoconfiguration process enables a host to assign itself an IPv6 address with minimal configuration on the host and infrastructure devices. This process results in complete address configuration, including the configuration of link-local and global addresses with duplicate address detection to ensure that no IP address conflicts occur on the local network. This process involves a well defined series of packets that enable the rapid use of IPv6 on a network segment.

While troubleshooting autoconfiguration issues in packet detail will (hopefully) be a rare administrative task, a packet-level understanding of this process can help us understand and appreciate some of the goals of IPv6. While autoconfiguration can be a useful tool for fast network deployment, many administrators choose to disable it due to security concerns. However, a through understanding of this process can provide a useful foundation for understanding the other IPv6 protocols and algorithms that enable an IPv6 network deployment.