How IPv6 networks create DNS configuration problems

Automatic configuration in IPv6 networks

SLAAC allows for distributed address assignment, where each host automatically learns the network prefixes that should be employed for the local network and subsequently configures its own IPv6 addresses by selecting an appropriate interface identifier (analogous to IPv4's host ID) for each network prefix. SLAAC also allows for some other basic network configuration, such as IPv6 default routes, and it is deemed a lightweight network configuration protocol, capable of satisfying the automatic configuration needs for most simple network setups.

On the other hand, DHCPv6 is deemed as a full-fledged network configuration protocol. DHCPv6 allows for centralized host configuration, where a DHCPv6 server -- or set of DHCPv6 servers -- provides all the necessary network configuration information to IPv6 hosts. Similar to its IPv4 counterpart, DHCPv6 "leases" IPv6 addresses to IPv6 hosts and can also provide all kinds of network configuration information, such as web proxies.

Support for SLAAC is mandatory, while support for DHCPv6 is optional. This means that SLAAC is the "lowest common denominator" when it comes to automatic IPv6 host configuration.

Automatic DNS configuration in IPv6

Early on in the design of SLAAC and DHCPv6, the only pieces of network configuration information that were considered as crucial were an IPv6 address and an IPv6 default route. All other configuration information was mostly deemed optional, and thus left out of SLAAC, and supported only with DHCPv6.

Thus, network setups that required the automatic configuration of an RDNSS -- servers whose role is to provide the correct IP address of an intended domain name to a requesting host -- had to employ DHCPv6 for conveying such information. Over time, it became clear that domain name system (DNS)-related information was, in practice, as crucial as IPv6 addresses or IPv6 routes, since most network services are accessed via domain names, rather than by their corresponding IP addresses. Support for DNS-related configuration was eventually added to SLAAC by means of experimental DNS options for SLAAC in 2007. And it was only in 2010 that a production-ready standard for such DNS options was finally published.

Partially as a result of such late standardization, a number of SLAAC implementations never incorporated support for DNS-related options and relied on the corresponding DHCPv6 support for DNS configuration. On the other hand, those IPv6 implementations that did incorporate support for the aforementioned DNS-related options essentially deemed DHCPv6 support as unnecessary and thus opted to not support DHCPv6 at all -- not even for configuring DNS-related information.

Support for automatic DNS configuration in IPv6 eventually became part of a battle in Internet Engineering Task Force circles between SLAAC vs. DHCPv6 supporters, with the SLAAC supporters (such as Google's Android) refusing to implement DHCPv6, and DHCPv6 supporters (such as Microsoft) refusing to implement the SLAAC DNS options.

This situation not only affected host implementations, but also router and server implementations. For example, some router devices implement SLAAC, but fail to implement the SLAAC DNS-related options. Similarly, some network devices meant to provide network configuration information fail to implement the DHCPv6 -- even the basic DHCPv6-server functionality that would allow them to convey DNS-related information via DHCPv6.

DNS configuration problems in IPv6 networks

The lack of support of SLAAC DNS-related options or DHCPv6 in different popular IPv6 implementations led to a situation in which there is no single mechanism that can be employed to provide DNS-related information to all major IPv6 host implementations. In other words, given that different host implementations can learn DNS-related information only via DHCPv6 or SLAAC, a network meant to support all major IPv6 implementations must make DNS-related configuration information available via both SLAAC and DHCPv6.

The same holds true for router and server implementations: Not all router implementations support both the SLAAC DNS options and DHCPv6. Thus, supporting a specific mechanism for DNS configuration, whether SLAAC or DHCPv6, may be unfeasible or require additional network devices with the corresponding support.

In many network setups, recursive DNS configuration problems have been masked by the fact that most deployments of IPv6 networks are dual-stack, both IPv6 and IPv4, rather than IPv6-only. Because DNS-related information is readily available via DHCPv4, dual-stack nodes can always rely on IPv4-based DNS queries.

But dual-stack won't be the dominant deployment option forever. In fact, some mobile networks are now IPv6 only, and it's only a matter of time before RDNSS problems become more widespread.

Using both SLAAC and DHCPv6 isn't the answer

IPv6-only networks have no other option than conveying DNS-related information via both SLAAC and DHCPv6. Yet this alternative creates three key problems: additional complexity, the possibility of out-of-sync information between SLAAC and DHCPv6, and the possibility of inconsistent host configuration.

Supporting two different protocols for conveying the same configuration information results in unnecessary complexity, which results in increased difficulty when troubleshooting network configuration problems.

Since server-side SLAAC and DHCPv6 configuration is typically performed separately, it is quite likely for the associated configurations to become out of sync or even conflicting. For example, an administrator might update the RDNSS addresses in the SLAAC configuration, but fail to update such information in the corresponding DHCPv6 configuration. Thus, the network would provide conflicting information via these two protocols.

Additionally, operating systems could end up with different network configurations, depending on whether they support only SLAAC, as Microsoft has done; only DHCPv6; or both. This is clearly a drawback from a network operation and management perspective, as reflected by a 2017 Internet Engineering Task Force study that examined how recursive DNS servers were affected by individual OSes.

Configuring RDNSS within IPv6-only networks will continue to be a challenge, until some consensus regarding the best way to convey that information is reached. For now, dual-stack deployments typically cope with recursive DNS configuration problems by relying on DHCPv4. For such dual-stack deployments, this is lingering problem that is likely to result in unpleasant surprises in the near or long term.