IPv6 Deployment Series Part 6: SLAAC vs DHCPv6

RYAN HARRIS | Sr. Network Engineer 

This blog post is part of a series detailing the various parts of planning and deploying IPv6 for enterprise networks. It is meant as a primer for the network engineer or architect to understand the various concepts they may be unaware of when developing their IPv6 production design.  

If you have not read the previous posts, I would highly recommend that you start at the beginning:   

• Part 1 – Hierarchical Subnetting Design  
• Part 2 – Routing Design  
• Part 3 – OSPFv3 
• Part 4 – Security 
• Part 5 – Transitional Client Addressing 

Config Flags 

ICMP neighbor discover router advertisement packets are sent by the local gateway on a LAN segment by default every 3 seconds to the all-nodes multicast address. However, a client can also send a router solicitation packet to receive an immediate unicast response.  

The ICMP RA packet header contains a couple of fields that are of interest for our understanding of SLAAC—the Prefix Information variable located in the “Options” field, the auto-config flags, and the router lifetime. The prefix information is self-explanatory. It provides the /64 network prefix to the clients, and this information is used for the clients to create their own IP address. 

The auto-config flag fields are straightforward but not completely obvious at first. There are two flags, the M-flag, or the managed address configuration flag, and the O-flag, or the Other Stateful Configuration flag. Additionally, in the options field, when using the prefix information variable field, there is an additional flag relevant to specifying the address configuration method, the A-flag, or the Autonomous address-configuration flag. With these different flags, the RA packet can communicate to the client what method they should use to configure their IPv6 addresses. And yes, it is possible and common for clients to configure more than one IPv6 address at a time. 

If the M-Flag is set to on, this tells the client that they should get both their address and options (DNS, NTP, etc.) from the DHCP server. If the M-flag is set, the O-flag is ignored as it is redundant. The M-flag is going to be most familiar to the IPv4 world. This is called the “managed config flag” and is configured with the command “ipv6 nd managed-config-flag” on Cisco routers. 

If the O-flag is set to on, this tells the client to create an auto-configuration address but to receive options from the DHCP server. This configuration is called the “Other config flag” and is enabled with the command “ipv6 nd other-config-flag” on Cisco routers. If both the m-flag and o-flag are configured on the same RA, the o-flag is interpreted to be ignored. 

If the A-flag is set to on, this tells the client to auto-configure its IP address. This is the default operation of most routers and at first, it is a little counter-intuitive that it would be set in the options header rather than directly in the RA header. This is because there is not an RA sent per-IPv6 subnet but rather just a single RA with each of the configured prefixes attached under its own options header.  

SLAAC 

Stateless Address Auto-Configuration, or SLAAC, is meant to be the primary mechanism by which IPv6 clients are assigned IPv6 addresses. SLAAC works by a client automatically creating a link-local address as soon as the interface is operational. Once this link-local address is functional, it uses it to receive ICMPv6 router advertisement packets containing IPv6 prefix information. This prefix information is combined with the MAC address of the endpoint to create a unique IPv6 address. 

RDNSS

RDNSS, or Recursive DNS Server, is a later addition to the NDP RA options that allows the router to advertise DNS server IP addresses and DNS Search list for domain suffixes. The primary failing of SLAAC in its original form was that it lacked the ability to dynamically advertise the addresses of DNS servers, leaving DHCPv6 as the only way for network administrators to dynamically configure that information. 

RDNSS is an additional option header for router advertisement packets. 

Device(config)# interface ethernet 3/3 

Device(config-if)# ipv6 nd ra dns server 2001:DB8:FF::DEAD:BEEF 1000 sequence 0 

Device(config-if)# ipv6 nd ra dns server 2001:DB8:FF::BEEF:CAFE infinite sequence 1 

Device(config-if)# ipv6 nd ra dns search-list netcraftsmen.com 100 sequence 1 

Device(config-if)#^Z 

Device(config)# show ipv6 nd ra dns server 

Recursive DNS Server List on: mgmt0 

Suppress DNS Server List: No 

Recursive DNS Server List on: Ethernet3/3 

  Suppress DNS Server List: No 

  DNS Server 1: 2001:DB8:FF::DEAD:BEEF Lifetime:1000 seconds Sequence:0 

  DNS Server 2: 2001:DB8:FF::BEEF:CAFE Infinite Sequence:1 

Device(config)# show ipv6 nd ra dns search-list  

  DNS Search List on: mgmt0 

  Suppress DNS Search List: No 

  DNS Search List on: Ethernet3/3 

  Suppress DNS Search List: No 

  DNS Server 1: netcraftsmen.com 100 Sequence:1 

DHCPv6 

I feel that there is an automatic want for most network engineers to deploy IPv6 with DHCPv6 as the client-addressing method of choice. We already know and understand the structure of the network, it is a centralized repository of the truth of a network. In addition to this, DHCP can often act as a pseudo-security layer to the network either through manual intervention from network administrators or through client registration portals. It’s a tough sell to suggest we should give this up in favor of letting the clients decide their address autonomously. 

Interestingly, IPv6 gives us a new operating mode for DHCP, the “Other Configuration Flag” mode gives us the autonomous address configuration of SLAAC with the ability to provide a wide range of information via the DHCP protocol in the form of DHCP options. This deployment could be useful for networks looking to deploy zero-touch provisioning for hardware such as wireless access-points or IP phones. 

Generally speaking, DHCPv6 has two disadvantages against SLAAC, the first being that it requires a stateful server to act as your DHCP server. Whether this is handled by your network infrastructure or on a separate server is an architectural decision, and the second is that Android devices do not support DHCPv6. This means that your wireless network likely cannot rely solely on DHCPv6 for client addressing.  

Additionally, I would argue that eliminating additional protocols and services from the network is generally a good thing, making DHCP less desirable for the purpose of reducing the complications of the network for troubleshooting. If you need to support Android devices on your network, you need to deploy your network using SLAAC, choosing to use DHCPv6 adds additional requirements to your network rather than replaces a protocol. 

It is interesting to note that in a divergence from the IPv4 DHCP protocol, default router information is not carried by the DHCPv6 packet. The default router is always advertised via the NDP router advertisement packet regardless of which configuration flag is set. 

DHCPv6 Prefix Delegation 

An interesting use case for DHCPv6 makes it perfect for deploying low-touch configurations. Instead of manually configuring every device for every subnet that it can use, DHCPv6 allows us to provide a prefix delegation to a device and use this prefix to subnet further into individual subnets. For example, a router might be assigned the prefix 2001:DB8::/56 and it can use this prefix as a variable and subnet further into /64 subnets like 2001:DB8:0:1::/64, 2001:DB8:0:2::/64, etc. The route for this prefix is registered with the upstream router and a default route is installed on the local router. 

Prefix delegation is extremely useful in ISP environments where the ISP does not have control over the user’s router but still needs to provide addressing information. By assigning a prefix, the end user can configure multiple subnets out of this prefix autonomously. In fact, there is a good chance that if your home’s ISP supports IPv6, they are assigning you a prefix using prefix delegation. 

Privacy Extensions 

If you are reading the SLAAC section and thinking that using your network interface’s MAC address must be a privacy or security issue, you are completely spot on. A machine that is using the EUI-64 process to generate IP addresses is going to be vulnerable to tracking by a third party, where they could easily be tracked at home, in the office, or in public Wi-Fi environments regardless of cookies or other client tracking strategies. 

IPv6 Privacy Extensions were created to mitigate this privacy risk by creating randomized client IDs for IPv6 networks and regularly regenerating new addresses to mitigate the long-term tracking of individual clients. The astute among you may have the question, “What if two machines on the same subnet accidentally generated the same random address?” Once an address is generated, the machine will send an NDP DAD packet to the all-nodes multicast address to check that it is not already in use. 

However, there are issues associated with IPv6 privacy extensions. For security purposes, some web developers will include a check against the IP address of a client that is presenting a session ID cookie to verify that it is the same. This check has the side effect that if the client moves networks, it will cause the client to be logged out of the web application. This issue can be present in IPv4 networks using NAT pools, CGNAT networks, or public IPv4 host addresses. 

Every major operating system on the market today (Windows, Mac OS-X, iOS, and Android, Linux (varies by distro)) supports and has privacy extensions enabled by default. 

It should be noted though that IPv6 privacy extensions do not guard against client tracking through other means such as through cookies, behavior tracking, etc.