Before you read this post, it is important to stress that its content is based on the IETF draft titled “IPv6 only capable resolver utilising NAT64”, which can be found here.
This document solves an existing problem, promotes IPv6 deployment, reduces the use of NAT and the need for IPv4 addresses, and although it is just beginning its journey within the IETF —it is very likely that it will first be adopted by the WG— we believe that its content and the mechanisms it implements will be widely deployed. So much so that Bind and Unbound have already advanced with their first implementations. Alejandro Acosta, LACNIC R+D Coordinator
As the deployment of IPv6 networks continues to grow, one challenge that has emerged is that some DNS zones are only served by IPv4-only authoritative servers. This can cause problems for IPv6-only iterative resolvers that do not have access to an IPv4 network, resulting in the inability to resolve all DNS zones.
At the recent DNS-OARC 39 conference, Toyota Yasunobu and I presented research on this issue. We discussed how the deployment of IPv6 single-stack networks with a NAT64 service can be facilitated by using an IPv6-only capable resolver that uses NAT64. In this blog post, we summarize the key points of our presentation and explain how resolvers can be ‘IPv6-only capable’.
NAT64 is a technology that allows IPv6-only networks to communicate with IPv4-only servers. It converts IPv4 addresses to IPv6 addresses and vice versa, using a special format called ‘IPv4-Embedded IPv6 Address Format’ described in RFC 6052. This allows IPv6-only devices to communicate with IPv4-only servers via the NAT64 service on the network (see RFC 6146 for more information).
(Free access, no subscription required)
The deployment of IPv6-only networks is becoming more widespread as IPv6 adoption continues to grow. However, the transition to IPv6-only operation brings specific challenges, one of which is that some DNS zones are only served by IPv4-only authoritative servers. This can cause problems for IPv6-only iterative resolvers as they do not have access to an IPv4 network and may be unable to resolve these DNS zones.
Figure 1 — NAT64 overview.
The following is an example of an IPv6-only iterative resolver failing to resolve ieee.org. The root server and the following authoritative servers are dual-stack, but ns1.ieee.org is IPv4 single-stack, preventing the IPv6-only iterative resolver from sending queries to it.
The deployment of IPv6-only networks is becoming more widespread as IPv6 adoption continues to grow. However, the transition to IPv6-only operation brings specific challenges, one of which is that some DNS zones are only served by IPv4-only authoritative servers. This can cause problems for IPv6-only iterative resolvers as they do not have access to an IPv4 network and may be unable to resolve these DNS zones.
Figure 1 — NAT64 overview.
The following is an example of an IPv6-only iterative resolver failing to resolve ieee.org. The root server and the following authoritative servers are dual-stack, but ns1.ieee.org is IPv4 single-stack, preventing the IPv6-only iterative resolver from sending queries to it.
Figure 2 — IPv6-only iterative resolver failing to resolve ieee.org.
Many resolvers today are either IPv4-only or dual-stack. However, the number of IPv6-only networks is growing, and IPv6-only networks that want to minimize the use of IPv4 addresses just for NAT64 devices may want the iterative resolver to be IPv6-only.
On the left in Figure 3 is an example of current iterative resolvers with an IPv4 address. On the right is an iterative resolver inside the IPv6-only network without an IPv4 address; this is the topology we want to achieve.
Figure 3 — The network topology we want to achieve where the resolver is inside the IPv6-only network.
To understand how many IPv6-only iterative resolvers have trouble resolving domain names, we performed a small experiment where we attempted to resolve A records for the top 100,000 domains from the Tranco list using both an IPv4-only resolver and an IPv6-only resolver. The results showed that the IPv4-only resolver was able to successfully resolve 99.5% of the domains, while the IPv6-only resolver was only able to resolve 71.7% of the domains. This significant difference highlights the challenges posed by IPv6-only iterative resolvers and the need for a solution to this problem.
Resolving A records
Resolving AAAA records
Resolving with IPv4
0.5%
0.6%
Resolving with IPv6
28.3%
28.1%
Table 1 — The percentage of iterative resolvers failing to resolve domains, from the Tranco list’s top 100,000.
We propose that a possible solution to this problem is an IPv6-only capable iterative resolver using NAT64. In cases where this resolver finds only an A record for the authoritative server, it performs address synthesis to convert the server’s IPv4 address to an IPv6 address. By sending IPv6 packets with the destination address set to the synthesized IPv6 address, the iterative resolver can initiate communication with IPv4-only authoritative servers using NAT64 in the network. This allows an IPv6 single-stack network with NAT64 service to have an iterative resolver with only an IPv6 address.
Figure 4 — Proposed solution: The resolver performing customer-side translation.
We have submitted an Informational Internet Draft documenting this proposal for an IPv6-only iterative resolver utilizing NAT64. We have presented the draft to the IETF 115 v6ops Working Group and received positive feedback on the mailing list. There are also implementations of an IPv6-only iterative resolver using NAT64 on both BIND and Unbound. However, these are currently in Pull Request (PR) form and have yet to be merged into the mainline.
In conclusion, the deployment of IPv6-only networks is underway, but the challenge posed by IPv6-only iterative resolvers needs to be addressed to facilitate the smooth operation of these networks. This challenge can be overcome by using an IPv6-only capable iterative resolver using NAT64, and IPv6-only networks can operate with a functioning iterative resolver. Network operators and engineers should consider implementing this solution to ensure the successful deployment and operation of IPv6-only iterative resolvers.
Momoka Yamamoto is a first-year master’s student at the University of Tokyo interested in network standardization.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.
