Welcome back! Last time we looked at a bit of the general history of IP auto addressing and how that led to IPv6 SLAAC. We then examined how SLAAC works with a simple example that included an IPv6 router and IPv6 node.
So now that we know the basics of how SLAAC works, how do we configure it? From our example we know that we have an IPv6 router and an IPv6 node but what configuration changes need to be made on each to support SLAAC?
Well as it happens, all of the required configuration takes place exclusively on the IPv6 router. But before we get into that we need to talk a little bit more about the IPv6 Router Advertisement (RA) I mentioned in the last blog.
Let’s look at the message format of the IPv6 Router Advertisement (Figure 1).
Figure 1: Router Advertisement (RA) message format
This is the message that is sent out periodically by IPv6 routers (or in response to a Router Solicitation (RS)).
For the purposes of better understanding how SLAAC works we need to focus on three fields in this message (Figure 2):
- The M, or managed address configuration, flag field
- The O, or other configuration, flag field
- The Optionsfield – specifically when the Prefix Information Option is present
Figure 2: The M, O, and Options fields of the Router Advertisement message
Let’s cover these one at a time.
When the M, or managed address configuration, flag field is set to “1”, it indicates that addresses should be available to be assigned via a DHCPv6 server. In other words, this flag tells the client to attempt to get an IPv6 address from a DHCPv6 server.
When the O, or other configuration, flag field is set to “1”, it specifies that configuration information other than the IP address should be available as well (typically, via the same DHCPv6 server that would be providing the IP address). This information would usually include DNS server addresses. In other words (pun intended), this flag tells the client to attempt to get additional configuration information such as the address of the recursive DNS servers from a DHCPv6 server.
For SLAAC, the Options field, should include the Prefix Information Option.
According to the RFC 4861: Neighbor Discovery for IP version 6 (IPv6), the Prefix Information option “provide hosts with on-link prefixes and prefixes for Address Autoconfiguration.”
The message format for the Prefix Information Option (Figure 3) includes two fields that are critical for the proper functioning of SLAAC.
Figure 3: The A flag and Prefix fields of the Prefix Information Option
The Prefix field contains an IPv6 prefix to be used by the client as part of the SLAAC process to construct an IPv6 address that is global in scope: Recall that the client already has a configured link-local address that facilitates communication with other IPv6 node on the same link. You can also expect to see that the prefix is a /64 which is the standard prefix length for server or desktop access networks.
When the A (or autonomous address-configuration) flag is set to “1”, it specifies that the included prefix can be used for SLAAC. Thus, the Prefix Information Option message must include both a prefix and the A flag set to one for SLAAC to function properly.
As you may have observed, a fair amount of configuration information must be present and properly configured to permit our client(s) to configure an IPv6 address using SLAAC (or DHCPv6, for that matter). The flag settings have often been a source of confusion for those that are new to configuring IPv6 auto-addressing. Let’s take a look at a brief summary that should help clarify these configuration settings (Figure 4).
Figure 4: Address Auto-configuration Router Advertisement flag settings
It’s important to keep in mind that auto-address configuration via one method does not prevent other methods from working as well. For example, if a Router Advertisement has all three flags – the A, M, and O – set to one, the client will attempt to configure both a SLAAC and DHCPv6 address. Depending on the presence of a properly configured DHCPv6 server and an IPv6 prefix in the Router Advertisement, the client will end up with both a DHCPv6 and SLAAC address.
For our example, we’ll restrict our configuration to provide only an address via SLAAC. Here’s what the configuration elements for a basic IPv6 SLAAC configuration look like in Cisco IOS:
!
ipv6 unicast-routing
!
! [Among other things, this setting turns on Router Advertisements for interfaces that have IPv6 enabled]
!
interface GigabitEthernet0/0
no ip address
ipv6 address 2001:db8:66:6::1/64
!
! [The only other configuration element required to enable SLAAC is a configured IPv6 address (the prefix of which will be used in the Prefix Information Option)]
!
Next, let’s look at a packet capture of the Router Advertisement that results from the above the router configuration (Figure 5).
Figure 5: Packet capture of a Router Advertisement based on simple Cisco IOS IPv6 configuration
Note that the first highlighted field recalls what we covered in the last blog: namely, that SLAAC relies on the link-local address of the advertising router (in this case, fe80::c801:aff:feb9:8) and the all-nodes link-local scoped multicast address (ff02::1).
The highlighted flag fields show that the M and O flags of the Router Advertisement are set to “0”. The A flag of the Prefix Information Option within the RA is set to “1”.
Finally, the prefix of 2001:db8:66:6:: is included. Notice that this prefix is derived from the IPv6 address configured on the router interface.
Here is the resulting IPv6 address on a Windows 7 client attached to the same link as the router (Figure 6).
Figure 6: Resulting Windows 7 IPv6 address configuration
Note that two addresses are configured on the client: a non-temporary address and a temporary address. Temporary addresses are explained in detail in RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6. As the title of the RFC suggests, they’re used to attempt to add an additional layer of privacy for the client, given that the client’s MAC address is used when a non-temporary address is derived using the EUI-64 method described in part 1 of this blog.
Also note the Preferred designation. All auto-configured IPv6 addresses have a lifetime associated with them (note the Valid and Preferred lifetime fields in Figure 3 and in the packet capture in Figure 5). We’ll likely cover this in more detail in a later blog but the gist of it is that addresses are defined as Preferred based on the default interval and Valid for a longer interval (7 days and 30 days, respectively, in Cisco IOS). While Preferred, an address can be used for new and existing connections. Once the Preferred interval has elapsed but the Valid interval has not, an address is considered deprecated and should only be used for existing connections. Once both the Preferred and Valid intervals have elapsed, the address is considered invalid and cannot be used at all. (For more information about these timers, refer again to RFC 4192 & RFC 4861.)
That’s it for now! Obviously, there are many additional configuration options and considerations when deploying SLAAC (or DHCPv6 for that matter), but we’ll save the discussion of those for a later date. In the meantime, if you have any questions or comments – especially related to your own experiences deploying SLAAC – please leave a comment below. Thanks for reading!
