A Brief History of Life, the Universe, and Network Auto-addressing
In keeping with our recent theme of covering topics for IPv6 beginners, this blog will cover the basics of IPv6 Stateless Address Autoconfiguration – more commonly referred to as SLAAC (defined in RFC 4862).
What SLAAC stands for pretty much tells us in the simplest terms what it does: stateless auto-configuration of addresses.
A node on the network needs a unique address to communicate with other nodes and networks. But how does it get such an address? In the ye olden days of networking, some poor schlub would have to manually configure such an address on every device that needed network access. In older networks with no more than a few hundred nodes, this task was drudgery for the earliest breed of network and system administrators but not impossible. For one thing, once an address was assigned, it rarely required changing.
[Here’s where I provide some historical context for auto-addressing. If you just want to dive in to how SLAAC works, feel free to skip ahead to the next section. –Tom]
Still, there were early attempts by other routed address protocols to introduce automated addressing. One early example of this was Apple’s networking technology, AppleTalk, which included both routing and routed protocols as part of a suite of network-related protocols and services. Incidentally, RTMP or the Routing Table Maintenance Protocol, the routing protocol part of AppleTalk was remarkable for its use of unsolicited broadcasts of all the routing information at an interval of every 10 seconds by all connected routers.
But setting aside the apparent depravity of this particular routing mechanism, other components of AppleTalk seem advanced for its time (circa 1980s). An example of this is its end-node auto-addressing function. As Wikipedia describes it: “AppleTalk’s internal protocols negotiated a working network address number, automatically gave the computer a human-readable name, and collected up a list of the names and types of other machines on the network so the user could browse the devices through the GUI-based Chooser.”
Once IP began to win the war of the routed protocols, and networks began to grow in size and vary in design and use, a new way to auto-address nodes with IP addresses was called for.
Dynamic Host Configuration Protocol, or DHCP, was the protocol and service built to meet the auto-addressing requirements of IP networks. However, like many other networking protocols and services, DHCP as defined in RFC 1541 relied heavily on earlier protocols that have since fallen out of general use. The first of these was RARP (RFC 903) or Reverse Address Resolution Protocol, which, as you may have inferred, does the opposite of what ARP does: instead of sending a broadcast frame to the attached network with the IP address of the target and requesting the target’s link-layer (MAC) address, RARP broadcasts a packet containing its own link-layer address, requesting a response informing it of its own IP address.
RARP evolved into BOOTP (RFC 951), overcoming some of RARP’s limitations. These included hosts needing to be directly attached to a Layer 3 switch where the IP-address-to-link-layer mappings had to be configured. BOOTP permitted the use of one or more relay agent that permitted the forwarding of BOOTP requests by routers allowing one BOOTP server to provide addressing for more than one broadcast domain and associated IP subnet. RARP was also not able to provide additional host parameters (such as default gateway and DNS server information) – something BOOTP made possible.
DHCP initially enhanced BOOTP’s functionality by adding dynamic allocation and, critically, reclamation of address leases (BOOTP permitted only static address assignments and thus had no mechanism to automatically reclaim any unused addresses). The relative simplicity and extensibility of DHCP guaranteed that it would be both widely adopted and continually enhanced.
As the IPv6 protocol was being initially designed and debated within the IETF community, one area of particular interest was some mechanism of support for auto-addressing. Of course, adding auto-addressing directly to the protocol would entail a fair amount of additional complexity (as compared with IPv4). One argument for including it would have certainly been that it would help drive IPv6 adoption. In this way, IPv6 auto-addressing might be seen as an early version of the vaunted and chimerical IPv6 “killer app”; i.e., the one application whose simultaneous popularity and reliance on IPv6 would compel rapid and full adoption of IPv6. (While IPv6 skeptics may be fond of pointing out no one such app has appeared, the standard retort to those folks is that the killer app has been here all along: It’s called the Internet and it can’t continue to scale effectively and affordably without IPv6!).
Whatever IPv6 auto-addressing pros and cons might have been discussed at the time, the argument for including it won the day and SLAAC was born.
Enough with the ancient networking history! So how does SLAAC work, exactly?
The following diagram sequence will show the high-level steps of SLAAC. The first thing every IPv6 node typically does is configure itself with a link-local address (Figure 1). The primary purpose of the link-local address is to provide the node with a unicast address that can be used to communicate at Layer 3 with other IPv6 nodes (both hosts and routers) on – and only on – the local segment. Since the hop count of all packets originated by the node with its link-local source have a hop count of 255 (out of 255), those packets should never be forwarded off of the link where they were originated.
Figure 1. An IPv6 node configures itself with a link-local address.
The prefix for all link-local addresses is fe80::/64. The interface identifier (or last 64 bits from left to right) of the address is typically auto-generated by using the modified EUI-64 method (RFC 4291), which uses the link-layer address (i.e., the MAC address) of the interface to which the address will be assigned and pads it with a hexadecimal value of ff:fe in the 7th through the 10th nibbles of the 16 nibbles available in the IID (in other words, the 25th through the 40th bits of the available 64 bits). Here is an example of modified EUI-64 formation (Example 1).
Example 1. Steps for modified EUI-64 formation.
Once the IPv6 node has a link-local address, it needs to ensure that no other node on the segment is using that address (Figure 2). It does this using a mechanism called Duplicate Address Detection (or DAD) (RFC 7527).
Figure 2. An IPv6 node performs Duplicate Address Detection (DAD).
Given that the address is typically configured using the node interface’s MAC address, the likelihood of any address conflict is exceedingly small. The check itself involves a clever use of multicast: every IPv6 node must subscribe to (i.e., join) the multicast group defined as solicited-node and identified by the address ff02::1:ffxx:xxxx, where xx:xxxx are the last 6 nibbles of that particular node’s link-local address. Thus, any DAD-based ICMPv6 Neighbor Solicitation (NS) will be responded to by any node with (what will be assumed to be, based on the last 6 nibbles) a duplicate link-local address.
Once DAD has taken place and the IPv6 node has confirmed it has a unique link-local address, it can then use that address as the basis for any Layer 3 communications exclusively on the Layer 2 link it’s connected to (Figure 3).
Figure 3. An IPv6 node sends a Router Solicitation message using its validated link-local address.
This includes the first step of obtaining a globally-scoped address using SLAAC, which is to send an ICMPv6 Router Solicitation (RS) message to the link-locally scoped all-routers multicast address of ff02::2 and sourced with the soliciting node’s link-local address.
The IPv6 router on the link receives the Router Solicitation and responds with a Router Advertisement sourced from its own link-local address and targeting the link-local unicast address of the requesting IPv6 node (Figure 4). The Router Advertisement in this case includes the Global Unicast Allocation (GUA) prefix 2001:db8:66:6::/64.
Figure 4. An IPv6 router unicasts a Router Advertisement.
Finally, the IPv6 node combines this prefix with its interface identifier (0536:e8ff:febb:14cb) resulting in the GUA address 2001:db8:66:6:536:e8ff:febb:14cb (Figure 5).
Figure 5. An IPv6 node configures its globally routable address.
The global-scope of this address allows traffic sourced from it to be routed off of the local link to external destinations, including the Internet (in the case that the local network has an IPv6 connection to it).
That’s it for this entry! In the next post, we’ll look at some other aspects of SLAAC including how Router Advertisement flags determine which type of auto-addressing gets used. We’ll also look at temporary and private addresses as well as some of the current operational practices with IPv6 auto-addressing (both SLAAC and DHCPv6).
