NAT64 and DNS64 with A10 Networks Thunder CGN

The arrival of the RIPE NCC last phase of the IPv4 address run out in November 2019 (https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-run-out), makes network deployments using only IPv6 addresses more necessary and common. When deploying IPv6 only networks or network segments, we quickly find out that some significant IPv4 only services still exist on the global Internet. An example of such a common IPv4 only service is www.github.com, which is often used for deploying servers and services.

To avoid the resulting significant delay in the deployment of IPv6 only servers and clients, NAT64 (a mechanism to translate IPv4 into IPv6 addresses) in combination with DNS64 (a mechanism to translate A records into AAAA records) can be used. This is done utilising A10 Networks’ Thunder CGN appliance, providing NAT64 and DNS64 services while operating as an IPv6 Secure Router and Stateful Firewall at the same time.

In this blog, we will have a look at two different scenarios and traffic flows of IPv6 only clients in such a deployment.

NAT64 and DNS64 with A10 Networks Thunder CGN

Scenario 1:
IPv6 client to IPv6 service

The IPv6 client sends out a DNS query towards the A10 Thunder CGN appliance asking for the AAAA (IPv6 to DNS mapping) DNS record of the specific resource it wants to reach (e.g. google.com). A10 Thunder CGN now forwards this AAAA query to an external DNS Server and receives back an IPv6 address for the record. This reply in turn is send back to the client.

Now the client can access the resource using A10 Thunder CGN as its Default Gateway without any additional tweaks – the A10 Thunder CGN appliance acts as an IPv6 Router.

Scenario 2:
IPv6 client to IPv4 only service

The IPv6 client wants to reach an IPv4 only service (e.g. github.com). It does not know the service is IPv4 only and hence sends out a DNS query for an AAAA record. In this case, A10 Thunder CGN is not able to resolve the query externally since no AAAA record exists for this service (receiving NXDOMAIN from the external DNS Server).

This is where the DNS64 mechanism kicks in: A10 Thunder CGN now sends out a DNS query for an A (IPv4 to DNS mapping) record of the requested service, and this time will receive an answer (e.g. 140.82.121.3). As the IPv6 only client, however, cannot handle the IPv4 address, it requires translation to an IPv6 address.

This is where the NAT64 mechanisms kicks in: A specific IPv6 prefix (64:ff9b::/96) is set aside to map the complete IPv4 address space into IPv6 addresses (e.g. 140.82.121.3 becomes 64:ff9b::8c52:7903).

In the process the IPv6 /96 IP prefix is large enough (32 bits for hosts) to map all existing IPv4 addresses 1:1 into IPv6 addresses. This can be done, since the complete IPv4 address space is 32bits wide.

So, once the A10 Thunder CGN receives the IPv4 address in the reply of the external DNS Server it will automatically:

send out a DNS reply to the IPv6 client sending out the mapped IPv6 address (e.g. 64:ff9b::8c52:7903) for the requested IPv4 only service
set up a NATing resource so that any traffic towards the mapped IPv6 address (e.g. 64:ff9b::8c52:7903) on the inside interface will be source address translated to the IPv4 pool dedicated to the outside of A10 Thunder CGN and vice versa

This way the IPv6 only client assumes it communicates with an IPv6 service as it is sending towards 64:ff9b::8c52:7903. The IPv4 only service thinks it communicates with an IPv4 only client as it is receiving traffic from the IPv4 pool IP address on the A10 appliance outside.

A10 Thunder CGN takes care of the translation in both directions. Depending on the amount to IPv6 only clients/servers the IPv4 pool used can be very small and may consist of one IPv4 address only.

Adding Stateful Firewalling

The connections, regardless of being directly routed or using NAT64/DNS64, can optionally be statefully firewalled using the A10 Converged Firewall Service (CFW).

This way we can control which traffic is allowed to traverse the A10 Thunder CGN in both inbound and outbound direction. CFW can be used in parallel with NAT64 services on the same appliance and allows for tight control of the allowed traffic flows.

A typical deployment would allow all outbound connections from the IPv6 only client, but only selective or no access from the outside towards the client.

Limitations

NAT64 can only be used with IPv4 resources that are reachable via IPv4 DNS records as it relies on DNS64 to work properly. If IPv4 services are only reachable via a literal IPv4 address, the mechanism would not work.

Conclusion

NAT64 and DNS64 can be used to allow IPv6 only clients to access IPv4 only services while native IPv6 traffic can follow freely through the same A10 Thunder CGN appliance.
In this setup, A10 Thunder CGN enables IPv6 only deployments with very little use of IPv4 addresses for reaching legacy (IPv4 only) resources.
The utilisation of A10 Thunder CGN reduces the amount of appliances from three (dedicated Router, CGNAT appliance and dedicated Firewall) to just one system.