Last time we looked at NAT444, this time we will examine DNS64/NAT64. I always write the mechanism that way because the DNS lookup (and possible manipulation) comes first, then the NAT operation.
The DNS64/NAT64 mechanism (RFC 6147, RFC 6146) provides a way for an IPv6-only client to exchange IP packets with an IPv4-only server. Because (of course) IPv6 nodes can only send IPv6 packets, and vice-versa for IPv4-only nodes, translation must be performed on the packets somewhere along the path.
Translating IPv6 packets to IPv4 packets is not a particularly modern capability. For example, NAT-PT specified a similar capability (RFC 2766, February/2000). NAT-PT does not scale well, however, because so much manual state had to be developed and distributed to the participating nodes. As a result, NAT-PT was moved to “Historic” status (RFC 4966, July 2007). DNS64/NAT64 builds on NAT-PT, but enlists the DNS server capability, with some DNS64-specific extensions, to make IPv6-IPv4 packet translation scalable and deployable. One significant difference between NAT-PT and DNS64/NAT64 is that in the later the IPv6-only node must initiate the connection. That is why above I use the language “IPv6-only client” and “IPv4-only server”.
As we often do, let’s explore DNS64/NAT64 via an example.
The diagram shows a simplified and idealized provider network. This provider has chosen to deploy IPv6-only services towards subscribers, but wants to provide an IPv4 service as well, so that subscribers can reach both IPv6-only and IPv4-only services (and of course dual-stack services as well, on either stack). IPv6 services have been built out to the subscriber edge. The node at bottom left, for example, has the IPv6 address 2001:db8:5:4::a.
The subscriber has also built out the DNS infrastructure, and has included the DNS64 extensions. In a nutshell (and there are RFCs on this whole process, so this is *very* terse), this is the DNS64 capability:
1) upon receiving a AAAA query from a downstream client, behave as a “regular” DNS caching server and query upstream towards the authoritative DNS server
2) if an IPv6 address is returned, behave as a “regular” DNS caching server and return query result to the client
3) if **NO IPv6 address returned** , use DNS64 extension, and perform the following process
3a) send an A query for the same name
3b) if no IPv4 address returned, behave as a “regular” DNS caching server and return “no such name”
3c) if IPv4 address returned, create *synthetic* IPv6 address using well-know prefix (64:ff9b::/96, as defined in RFC 6052) and embedding returned IPv4 address in low 32 bits of IPv6 address, and return to client as AAAA query answer
Going back to the example, make “Client-A” the client, and the IPv4-only node “Server-A” the server. For DNS and DNS64 above, the recursive AAAA query would fail, and the DNS64-initiated A query would return 192.0.2.205. DNS64 would create the synthetic IPv6 address 64:ff9b::192.0.2.205 (same as 64:ff9b::c000:2cd), and return that to Client-A.
At this point DNS64 has completed. On to NAT64.
Client-A will launch the IPv6 session, convinced that Server-B is also an IPv6-capable node. The IPv6 packets will be sourced by Client-A from its IPv6 address and destined for the synthetic IPv6 address manufactured by DNS64. These packets will be routed within the IPv6 enclave (the network to the left in the diagram) to the NAT64 inside-facing interface (following the default route in this case). The NAT64 function knows that if there is an IPv6 packet, sourced internally and arriving on the inside interface, where the destination is within the prefix 64:ff9b::/96, that this is a packet that will be translated.
The NAT64 platform will translate the packet into IPv4, making the source address the IPv4-Internet-facing address (192.0.2.15) and making the destination the 32-bit value “plucked” from the low 32-bits of the IPv6 destination address (the synthetic address) – 192.0.2.205. The NAT64 device will also make a state entry for this session, using L4 port multiplexing, much like an IPv4 hide-NAT stateful device would use to track and manage sessions.
In this manner, many internal IPv6-only clients can access any IPv4-based server with an IPv4 address in the global DNS, all with no explicit manual configuration of sources and destinations.
And that’s it for DNS64/NAT64.
A few last quick points:
1) DNS64/NAT64 does have downsides; for one not all applications work well through the mechanism, and for another any content that uses IPv4 addresses rather than Fully Qualified Domain Names (FQDNs) (like an embedded link to a graphic within a webpage) will not work – translation depends on the DNS entry.
2) Note that IPv6 native traffic is simply routed at the enclave perimeter. This means that, for Client-A, sessions to IPv4-only Internet-based servers is translated, which is probably an “acceptable, but not great” solution, and sessions to IPv6-only Internet-based services runs as native IPv6 end-to-end, providing an excellent solution.
3) Now that World IPv6 Launch Day has come and gone, and as more content providers make their content reachable over IPv6, less and less traffic in the example scenario will use the DNS64/NAT64 translation service and more traffic will be carried natively.
That’s it for this blog entry. In the next installment of the NAT444 and DNS64/NAT64 story we’ll talk briefly about relative strengths and weaknesses of the two mechanisms and provide some practical deployment considerations.