IPv4 has two ways to provision a useable address on a host. You can either manually assign it (i.e., statically configure it on the host) or you can use DHCP. Technically, it is possible for a host to provision a self-assigned address in the Automatic Private IP Addressing (APIPA) range (169.254.0.0/16) but this isn’t particularly useful as self-assigned addresses cannot be used globally to connect to the Internet. This is true even through a Network Address Translation (NAT) gateway device, because the host configured with such an address has no way to determine the IPv4 default gateway.
In IPv6, we have more options on how to provision an address on a host. You can use the following methods:
- Manual assignment (i.e., statically configure it on the host)
- Stateless Address Autoconfiguration (SLAAC) (RFC 4862)
- Dynamic Host Configuration Protocol version 6 (DHCPv6) (RFC 8415)
One of the interesting aspects of IPv6 (as compared with IPv4) is the fact that it uses a router to announce information to the local hosts on a given network segment (a VLAN for example). The router does this through two main methods: Router Advertisements (RAs) and Router Solicitations (RS). Both methods rely on ICMPv6 messages delivered via multicast. We will focus on RAs, as they are a common method a router uses to share specific configuration information with hosts on a given network segment. The router shares this information by using two Router Advertisement flags (M and O) to specify whether hosts should use DHCPv6 in the provisioning of an address (and if so, which method). There is also an A flag in the Router prefix information option header which is used to tell hosts if they should utilize SLAAC to auto-provision an address from the prefix that the router is providing. There are other additional flags, such as the On-Link (L) flag and the Mobile IPv6 Home Agent flag (H) but they are beyond this discussion. You can read about these in RFC 5175.
In summary:
| Flag Type | Name | Message | Manual | SLAAC | DHCPv6 |
| A | Autonomous | Prefix Information | No | Yes | Maybe |
| M | Managed | ICMPv6 134 RA | No | No | Yes |
| O | Other | ICMPv6 134 RA | No | Maybe | Yes |
Some key critical elements must work on the host operating system to provision an IPv6 address. First, the OS must support IPv6. Secondly, the OS must understand what the RA is signaling–specifically, the A, M and O flag combinations. There are other flag options that can affect host OS behavior (L comes to mind) but we will set those aside to discuss another time. The breakdown above shows that there are a lot more combinations and options that IPv6 provides when compared to IPv4. In theory, greater flexibility means potentially more operational challenges since you have to account for many more variations, but we are only looking at one side of the process (from the network’s perspective). We also need to look at how all the major OS manufacturers have included support for IPv6 in their stack.
Let’s examine the major OS manufacturers and what they support.
| Manufacture | OS | SLAAC (A flag) | RFC 8106 – RDNSS (A flag + DNS info) | DHCPv6 Client (M & O flag) |
| Microsoft | Windows | Yes | Post Windows 10 creators update | Yes |
| Canonical | Ubuntu Linux | Yes | Yes | Yes |
| Red Hat | RHEL | Yes | Yes | Yes |
| CentOS | CentOS Linux | Yes | Yes | Yes |
| Apple | MacOS | Yes | Yes | Yes |
| Apple | iOS | Yes | Yes | Yes |
| Android | Yes | Yes | No | |
| Chrome | Yes | Yes | No |
What you realize when you put on your operations hat is that there are only a few combinations of host OS address provisioning models that are optimal. Many of the operational choices are dictated by other factors. Those could be:
- Do you need each host OS to only obtain a single IPv6 address for tracking and security compliance reasons?
- Do you need all hosts to use IPv6 because you are going to run an IPv6-only network?
- Do you require the widest available support for all operating systems, regardless of manufacturer, vendor, and address provisioning method they support?
With these questions in mind, I won’t walk through all the combinations because some of them make no operational sense at all and are unlikely to be encountered in an actual deployment. Basically, the issues come down to whether an OS supports RFC 8106 (RDNSS) or DHCPv6. The reason is those are the only way to provide the OS with working DNS name resolution. Your OS needs some way to resolve names to IPv6 and IPv4 addresses and you must get that information to the OS via one of those two methods (or manually provide one–which is why you’re probably already familiar with Google’s 8.8.8.8 IPv4 address or Cloudflare’s 1.1.1.1 IPv4 address). Earlier versions of Windows did not have RDNSS support while Android and Chrome OS still do not have DHCPv6 client support. So, from an operations perspective, it was really hard to support those combined client types on the same IPv6 network. You had to do both SLAAC and DHCPv6 in order to get everything to work if you wanted to run IPv6-only or have no dependency on IPv4 at all for DNS.
When you consider the above along with some other use cases you typically end up with the following operational choices:
- Run dual-stack with SLAAC and RDNSS in the guest Wi-Fi network as it has the broadest support and means all host operating systems will behave and have access to the entire (i.e., IPv4 and IPv6) Internet.
- If you need strict controls, run DHCPv6 while also being aware that Android and Chromebooks won’t get an IPv6 addresses as they don’t have a DHCPv6 client installed by default. They will be IPv4-only.
- Run dual-stack with SLAAC and RDNSS for client access (wired and wireless) in the corporate environment. You may have parts of that client access network set up as IPv6-only for IoT, specific platforms or for testing.
- Run dual-stack in the data center but run DHCPv6 or configure hosts manually (perhaps using scripting or automation) for virtual machines, virtual server hosts and bare-metal systems.
So, there you have it: some insight into how to achieve operational practicality for host provisioning of IPv6 addresses. There is still more to cover so keep an eye open for the next blog post!
You can find me on twitter as @ehorley and remember…
IPv6 is the future and the future is now
– Ed
Ed Horley (@ehorley) is CEO of HexaBuild.io, an IPv6 consulting and training company. Ed is Co-chair of the California IPv6 Task Force (CAv6TF) and authored the Apress Press book on Practical IPv6 for Windows Administrators. Follow HexaBuild on Twitter and LinkedIn.
