Stateless Address Autoconfiguration (SLAAC) is one of the nine Neighbor Discovery mechanisms, but it is important and complex enough to have its own article.
This article uses the Sixscape SixConf app to help you understand SLAAC. If you haven’t installed it yet, please do so now (assuming you have a node running Windows Vista or later). Under IPv6 Settings, check the Router Discovery setting. If this is enabled, your node will use SLAAC. If this is disabled, SLAAC will not be used (and you will have to manually configure at least one global IPv6 address or you won’t have any). Since we are trying to understand SLAAC, make sure that Router Discovery is enabled.
SLAAC is one of the most important aspects of IPv6. It will be key to deployments of large numbers of IP phones, sensors, smart TVs, connected MP3 players, computers in a home network, etc. You know, the “Internet of Things“. SLAAC is not so well suited to nodes like a PC in a corporate network, where things such as clustering of IP addresses within a “/64” by organizational group, and centrally managed IP addresses are necessary. SLAAC is inherently a decentralized mechanism (unlike DHCPv4 in IPv4). The subnet routers send Router Advertisement messages, and the internal nodes autonomously generate global addresses based on that information. No central node is involved in that generation apart from supplying the prefixes valid in the subnet. The router has no idea of what addresses each node has generated (and no simple way to find that out). That is why it is “stateless” – no “state” (centralized information, kept over a long period of time) is maintained by the routers.
SLAAC allows any IPv6 compliant node to autonomously generate one or more globally unique IPv6 Unicast Addresses (or even Unique Local Addresses). SLAAC depends on having a node in each subnet (a gateway router) acting as a source of ND Router Advertisement messages (the software component that does this is usually called a Router Advertisement Daemon). Any IPv6 compliant router or firewall must have this capability, but it needs to be configured, and may have to be enabled. Without a source of RA messages, all IPv6 addresses on each node (except for the automatically generated link local address) must be manually configured. For an example of a gateway device that can supply Router Advertisements to enable SLAAC, see the info on pfSense open source firewall. It allows control over every aspect of the generated Router Advertisement messages.
No DHCPv6 server is required for SLAAC to happen, but SLAAC can inform nodes that a DHCPv6 server is available, from which it can obtain stateless information (such as IPv6 addresses of DNS) and (if the DHCPv6 server supports “stateful” operation), from which the node can also obtain a centrally managed global IPv6 Unicast address in addition to the address(es) it has generated with SLAAC. A source of Router Advertisement messages is not a direct replacement for a DHCP server because SLAAC is stateless – it does not manage a pool of addresses – it provides the information required for each node to autonomously create one or more valid global IPv6 addresses. There are good and bad aspects of this, that we will cover later.
Before a node even begins doing SLAAC it will autonomously generate an IPv6 link-local address. This is not part of SLAAC, and will happen even if SLAAC is disabled on a node, and whether or not there is a source of Router Advertisements in the subnet. This link-local address is used as the source address for the various steps of SLAAC.
The node first sends a Router Solicitation message.
The above RS message has a source address of fe80::b5ea:976d:679f:30f5 (the Link-Local address of node doing SLAAC) and destination address ff02::2 (all routers on local link). The ND Message Type is 133 (Router Solicitation), Code 0. It has one option, a Type 1: Source Link-Layer Address (00:22:15:24:32:9c, the MAC address of the node doing SLAAC).
The source address is not EUI-64. The node used Randomized Identifiers to generate a random Interface Identifier, so it is probably a Windows node (most BSD and Linux nodes default to EUI-64). It happens to be a Windows 7 node.
The destination address (ff02::2) maps onto the MAC address 33:33:00:00:00:02. The first 12 bits (33:33) indicates Ethernet multicast. The bottom 24 bits are the low 24 bits of the IPv6 multicast address (::2).
Each router on the subnet will respond with a Router Advertisement message.
Each RA message received can contain zero or more Prefix Information options. Each Prefix Information option contains details about one “/64” prefix that is currently in use on the subnet. For example, on my network I advertise the subnet global prefix 2001:470:3d:3000::/64, and the subnet ULA prefix fda4:73c2:e5b8:1000::/64. Every internal node (that has SLAAC enabled) will generate one (or two) IPv6 Unicast addresses for each of those advertised prefixes. If no RA message is detected within a certain amount of time, the node assumes there are no routers, and SLAAC aborts with no further addresses configured.
The above RA message has a source address of fe80::21b:21ff:fe1d:c159 (the Link-Local address of the router), and a destination address of ff02::1 (all nodes on local link multicast address). The ND Message Type is 134 (Router Advertisement), Code 0.
The source address has an EUI-64 Interface identifier, so it is probably a BSD or Linux node (it happens to be a FreeBSD node). The Interface Identifier contains the router’s MAC address (00:1b:21:1d:c1:59), with the value fffe in the middle, and the 7th bit of the first byte (0x02) set to 1 (::21b:21ff:fe1d:c159).
The destination address (ff02::1) maps onto the MAC address 33:33:00:00:00:01. The first 12 bits of the MAC address (33:33) indicates Ethernet multicast. The bottom 24 bits of the MAC address are the low 24 bits of the IPv6 multicast address (::1).
The M flag is 1, which means there is a stateful DHCPv6 server available. The O flag doesn’t matter (since the M flag is 1). The Router Lifetime is 180 seconds (which is greater than zero), so the router is willing to act as a gateway. It has two options:
- one Type 1: Souce Link-Layer address (the MAC address of the router), and
- one Type 3: Prefix Information option (a valid /64 prefix for this subnet)
The Prefix Information option has the L (On-Link) flag set, so this prefix can be used for on-link determination. It has the A (Autonomous configuration) flag set, so the node can do autonomous configuration using this prefix. The Valid lifetime is 2,592,000 seconds (30 days). The Preferred Lifetime is 604,800 seconds (7 days). The prefix is a Global Unicast prefix of 2001:470:3d:3000::/64.
This particular RA message does not have an MTU option.
If the node received at least one RA message with at least one Prefix Information option in it, the node then adds the Link-Local source address of each received RA message into a the potential gateway list (for every router willing to act as a gateway). Routers indicate their willingness to act as a gateway by publishing a router lifetime greater than zero. The node uses Neighbor Unreachability Detection to determine the best router to use from the list of potential gateways.
Next, for each received subnet prefix, a global Unicast IPv6 address is generated and assigned to the interface, by appending the the generated suffix used in the autonomously generated Link-Local address, to each advertised prefix. The state of each generated address is set to TENTATIVE. The address’ preferred and valid lifetimes are set to the subnet default values from the Prefix Information option. The node performs Duplicate Address Detection, and assuming no one is already using that address on the subnet, the address state advances to PREFERRED. If the preferred and valid lifetimes are not infinite, they start counting down immediately. If the preferred lifetime reaches zero, the address advances to the DEPRECATED state. If the valid lifetime state reaches zero, the address is removed from the node. Typical subnet default preferred lifetime is 7 days, and typical valid lifetime is 30 days.
The node doing SLAAC had a Link-Local address of fe80::b5ea:976d:679f:30f5. It combined the advertised prefix (2001:470:3d:3000::) with the Interface Identifier of the Link-Local address, for a primary Global Unicast address of 2001:470:3d:3000:b5ea:976d:679f:30f5.
If the Temporary Address option is enabled on the node, a second global IPv6 Unicast address is generated from the same prefix information with a randomly generated suffix and a shorter lifetime. Typically both preferred and valid lifetimes are set to 7 days for Temporary Addresses.
The generated Temporary address had a prefix of 2001:470:3d:3000::, but a randomly generated Interface Identifier.
NetConf allows you view all Unicast IP addresses assigned to your node, either by automatic generation (the autonomous Link-Local address), manual assignment, or DHCPv6 assignment. It shows all Unicast addresses, including what kind of address each is (Link-Local Unicast, Global Unicast, ULA, etc). It shows the remaining preferred and valid lifetimes and the current state of each Unicast address (preferred or deprecated). It shows the source of each address (automatically generated, generated with SLAAC, obtained from DHCPv6, manually assigned, etc).
You can also view all IPv4 and IPv6 multicast groups that your node has joined. You can see the Solicited Node Multicast groups created automatically for each Unicast or Anycast address.
NetConf also allows you to easily enable or disable things like Randomized Identifiers, Temporary Addresses, and even Router Discovery (these are on the IPv6 Settings page). You can play around with these settings to get a good idea of how they actually work. You can also manually assign addresses (in the case of IPv6, Unicast or Anycast), enable or disable DHCPv4, manually configure default gateways and DNS addresses, watch addresses age from preferred state through deprecated state, then disappear. Create an address with 30 second preferred lifetime and 1 minute valid lifetime, then keep clicking the Refresh button to watch it age.
This will really help you to understand how these mechanisms work.
RFC 6106 – RDNSS – Publishing DNS Information via SLAAC
RFC 6106, “IPv6 Router Advertisement Options for DNS Configuration”, November 2010, added two new options that can be provided to IPv6 internal nodes during SLAAC. These are the Recursive DNS Server option and the DNS Search List option. If your server supports this (e.g. ISC dhcpd 4.2) and your client supports this (e.g. FreeBSD 9.x), then your node can configure DNS addresses (and search list) during SLAAC, without using DHCPv6.
Here are the packet captures of an RS message and the reply RA message, that includes these two new options. These messages were generated with a virtual Dual Stack router created with FreeBSD 9.1 (see the projects).
The node first sends a Router Solicitation message.
The above RS message has a source address of fe80::a00:27ff:fe2a:3b0d (the Link-Local address of node doing SLAAC) and destination address ff02::2 (all routers on local link). The ND Message Type is 133 (Router Solicitation), Code 0. It has one option, a Type 1: Source Link-Layer Address 08:00:27:2a:3b:0d, (the MAC address of the node doing SLAAC).
The source address is EUI-64. The node did not use Randomized Identifiers to generate a random Interface Identifier, so it is probably a FreeBSD or Linux node (Windows Nodes default to Randomized Interface Identifiers). It happens to be a FreeBSD node.
The destination address (ff02::2) maps onto the MAC address 33:33:00:00:00:02. The first 12 bits of the MAC address (33:33) indicates Ethernet multicast. The bottom 24 bits of the MAC address are the low 24 bits of the IPv6 multicast address (::2).
Each router on the subnet will respond with a Router Advertisement message. Each RA message can contain zero or more Prefix Information options. Each Prefix Information option contains details about one “/64” prefix that is currently in use on the subnet. For example, on this subnet I advertise the global prefix 2001:470:3d:3001::/64. Every internal node (that has SLAAC enabled) will generate one (or two) IPv6 Unicast addresses for that advertised prefix. If no RA message is detected within a certain amount of time, the node assumes there are no routers, and SLAAC aborts, with no further addresses configured.
The above RA message has a source address of fe80::a00:27ff:fe13:7d55 (the Link-Local address of the router), and a destination address of ff02::1 (all nodes on local link multicast address). The ND Message Type is 134 (Router Advertisement), Code 0.
The source address has an EUI-64 Interface identifier, so it is probably a BSD or Linux node (it happens to be a FreeBSD node). The Interface Identifier contains router’s MAC address (00:08:27:13:77:d5), with the value fffe in the middle, and the 7th bit of the first byte (0x02) set to 1 (::a00:27ff:fe13:7d55).
The destination address (ff02::1) maps onto the MAC address 33:33:00:00:00:01. The first 12 bits (33:33) indicates Ethernet multicast. The bottom 24 bits are the low 24 bits of the IPv6 multicast address (::1).
The M flag is 1, which means there is a stateful DHCPv6 server available. The O flag doesn’t matter (since the M flag is 1). The Router Lifetime is 3600 seconds (which is greater than 0) so the router is willing to act as a gateway. It has five options:
- one Type 1: Souce Link-Layer address (the MAC address of the router)
- one type 5: MTU option
- one Type 3: Prefix Information option (a valid /64 prefix for this subnet)
- one type 25: Recursive DNS Server, and
- one type 31: DNS Search List.
The Source Link-Layer Address option contains the MAC address of the router that sent the RA message (08:00:27:13:77:d5).
The MTU option contains the value 1500 (bytes).
The Prefix Information option has the L (On-Link) flag set, so this prefix can be used for on-link determination. It has the A (Autonomous configuration) flag set, so the node can do autonomous configuration using this prefix. The Valid lifetime is 604,800 seconds (7 days). The Preferred Lifetime is 172,800 seconds (2 days). The prefix is a Global Unicast prefix of 2001:470:3d:3001::/64.
The Recursive DNS Server option contains two IPv6 addresses of DNS servers: 2001:470:3d:3000::13 and 2001:470:3d:3000::14.
The DNS Search List option contains one domain name, “v6lab.info”.
Deploy FreeBSD Router Advertisement Daemon
You can install and configure the FreeBSD Router Advertisement Daemon (rtadvd) on FreeBSD 9.1, by doing this project: Create a Virtual Dual Stack Router with FreeBSD 9.1. This inlcudes sending DNS information in the Router Advertisement messages (per RFC 6106).
What is Good About SLAAC?
SLAAC is well suited to large networks of simple, undifferentiated nodes, for example: sensor arrays, IP phones, consumer electronics devices, etc. It accomplishes almost the same thing that DHCPv4 does, but no server is required (just a source of RA messages), and no state is maintained. Every IPv6 compliant device (e.g. temperature sensors, IP phones, WiFi connected MP3 players, etc) supports SLAAC. Devices are required to support it by RFC 2460.
Basically, assuming you have a correctly configured source of RA messages on your subnet, within seconds of connecting an IPv6 compliant device to that subnet, it is fully configured complete with a Link-Local Unicast address, a valid default gateway, and one or two valid Global Unicast IPv6 addresses per advertised prefix. If there is a DHCPv6 server (stateless or stateful), it will also obtain IPv6 addresses of DNS. No one has to have configured any servers (except for DHCPv6 to get DNS addresses). Pretty cool.
What is Bad About SLAAC?
Addresses assigned via SLAAC, whether using EUI-64 or Random suffix generation, are effectively randomly distributed over much (or all) of the subnet’s /64 address block(s). They are definitely not clustered into address ranges by organizational group. This means firewall and Network Access Control rules either have to apply equally to all nodes that obtained addresses via SLAAC, or separate rules must be configured for each node (and updated whenever addresses expire and are renewed).
If your nodes have Temporary Addresses enabled, you will have a new IPv6 address magically appearing on each node, on a periodic basis (typically one per week). This may be good for security, but it is bad for network management. By default, Windows nodes try to register all of their node addresses in DNS. Also by default, the DNS on Windows Servers accepts dynamic DNS registration from all nodes in the subnet. This is a bad combination. It leads to clutter in DNS, and possibly no-longer-valid addresses being published there, which can lead to failed connections.
Randomly assigned addresses (and even worse, periodically changing random addresses) are difficult to create firewall rules for. If you want to allow incoming VoIP to all internal nodes, that is not a problem. If you want to allow incoming VoIP only for executives, that is a much harder problem if you are using SLAAC. You will have to create a separate firewall rule for each executive (which in a bank, could be lots of rules).
Because of the stateless, decentralized nature of SLAAC, there is no simple way to keep track of assigned addresses on a central node, let alone centrally manage address assignments. With DHCPv6, you can assign at least one managed address to each node (and you can even have that be a static assignment if you use DHCPv6 reservations). Sounds like DHCPv6 gets us partway to address management.
Unfortunately, when nodes make outgoing connections, they may use the SLAAC addresses as source, instead of the managed address. The rules for choosing which address to use as source (from among possibly several global addresses) are very complex. When you surf to www.v6address.com (an IPv6 version of whatismyipaddress.com), it appears to be mostly random which of the global addresses owned by your node will appear as “your” IPv6 address. What if a secure server restricts connections to only specific IP addresses? How do you get your node to use the specific IPv6 address that will be accepted? Maybe the one assigned by DHCPv6? There is no simple way to get it to use a specific global address as source.
A subnet with real people sitting at PC workstations has very different address management requirements than a bunch of undifferentiated network enabled devices (e.g. IP phones, temperature sensors, MP3 players, etc). We have evolved ways of doing this with IPv4, but SLAAC really isn’t at all suited to such schemes, even if you manage to assign one managed address to each node with DHCPv6. Both incoming and outgoing connections may use SLAAC generated addresses, instead of your nice DHCPv6 assigned managed address.
It would be ideal if you could partition a /64 into several sub-blocks, like the following:
You could then associate an organizational group (e.g. admin, accounting, development, etc) with each sub-block. You could then assign addresses using an Interface Identifier from block 0 for the first group (admin), addresses using an Interface Identifier from block 1 for the second group (accounting), etc.
This could be done by assigning addresses manually to each node, or through DHCPv6 with a lot of work creating address reservations with a DUID and IAID for each node. But then, SLAAC would also assign additional addresses all over the /64. And there would be no simple way to force the nodes to use the manually assigned or DHCPv6 assigned addresses as source for outgoing traffic. Usually the other end will just use the source address of received packets as the destination address for reply traffic. So much for your carefully crafted firewall rules, or using servers that restrict access by IP address. To keep nodes from obtaining global addresses via SLAAC, you could configure your router to not send any Prefix Information options. But then simple devices, like printers or consumer electronics would not be able to obtain any global addresses.