Use NAT64 to get out of the dualstack hell!

 Ok, you know about the limitations if you use IPv6-only today ... Great!

Today we will look for a solution to get out of the dualstack hell!

foto credit mk. s

Why is dualstack the hell?

To be honest, there is no way to communicate between IPv4-only and IPv6-only except dualstack. So from a realistic point of view, you can't avoid dualstack.

When I say "dualstack", I mean, IPv4 and IPv6 is active on every interface. Let's think of your home network, all those windows PCs all smartphones etc ... 

In a home network dualstack is not a problem, you will expierence restrictions if you think of dualstack at scale: 50,000 end-devices, 10,000 K8s-containers ...

If you read posts about the restrictions of dualstack, I am sure you read:

• dualstack has additional operational costs, because you have to configure two(!) correct IP-stacks per interface (and asure, that both configs are correct for the whole lifetime)
  
• dualstack has a bigger security impact, because your system is attackable to ipv4 and ipv6 attacks

Although I agree, the most restrictive point isn't mentioned:

You are restricted to IPv4 possibilities!

We are going to implement IPv6, because we want to benefit from clear ip address structures and the hugh number of addresses. That is not usable, if you have to assign an ipv4 address to every interface (32 vs. 128 bit).

If you do some IPv6 planing or an "IPv6 concept" and you have to go for dualstack with every interface I'm not sure, if you will earn any benefit of IPv6.

Example: Think about Kubernetes. You could assign an ::/80 subnet to every K8s-host and it can assign IPv6-addresses out of that. Doing so, means 48 bits for addresses per K8s-host for pods, which means 281.474.976.710.656 addesses. That should last for a while 😅 e.g. for more than 8 million years, if you assign one new address a second. 

Just to remember: If you do the same with IPv4, then a /24 subnet lasts for 254 seconds (not years!).

 

If you wand to benefit from IPv6 you have to go for IPv6-only! Dualstack is the oposite of a benefit, it costs your money/time but without any (big) benefit.

Transitions 

Because we don't like to put money/time into dualstack with only a very limited benefit ("Hey boss, we now have this IPv6 thing running!"), we have to look for better ways to deal with dualstack.

As mentioned earlier, dualstack is the only way to get forward to IPv6-only. Transition techniques gave you the chance to centralize dualstack to only some devices. That is the case with NAT64 ("NAT six four").

NAT64 and NAT46

NAT64

It is used to make IPv4-only networks available to IPv6-only-devices. Ok, ok, from v6 to v4 ...64. Not more! You can read about details at RFC6146 (why is it not RFC6164?)

Because v6 and v4 have different IP headers, different to NAT44, not just the IP address is exchanged, the whole protocol header is changed. Great stuff, but which devices can do this?

Devices which do NAT mostly can do NAT64 - at an enterprise device level. If you are looking for no-costs-solutions, you will end up with some opensource solutions:

• jool (jool.mx seems to be outdated, use the provided github link)
  
• tayga

On an enterprise level, modern routers or loadbalancer could do NAT64 at scale. NAT64 will be part of the basis function set, so don't expect extra costs for it.

 

From the user perspective, you will have a prefix for NAT64 e.g. 2001:db8:6464::\96 it has 96 bits, because you only need additionals 32 bits for the ipv4 address (96 + 32 = 128).

 

There is well-known-prefix for NAT64 64:ff9b::/96, if you use that you will be able to use some public DNS64-Servers, addtional information later on.

 

So, the ipv4 address 9.9.9.9 would be 64:ff9b::9.9.9.9 or in hex 64:ff9b::909:909 (both writings are correct). The NAT64 device knows

• the prefix (64:ff9b::/96)
• the last 32 bits, which has to become the IPv4 destination address

Your NAT64 device needs an IPv4 address as a source address, may be - depends on your situation outside of home networks - you need an IPv4 address pool.

From that point, it works like NAT44 works (or PAT/Masquerading), the NAT64 device has a NAT table ... I think you know.

Normally, we don't use an IP address, exept for DNS. We use hostnames. DNS64 is the way you are looking for.

The DNS64 enabled DNS-Server (all major products can do that) can deliver an NAT64 address to an given prefix, if it only has an A-record for the hostname but an AAAA-record is requested.

Let's say your IPv6-only PC requests v4.google.com the DNS will only find the ipv4 address (142.251.39.110). This means, it could only deliver an A-record. No connection could be established :-(

If the DNS is DNS64 enabled and the prefix is 64:ff9b::/96 it will deliver - as I say - a faked IPv6 address: 64:ff9b::8efb:276e. You can establishe a connection, if you have an NAT64 service with the same prefix available.

NAT46 

There is no NAT46😟

OK,  I mean, there is no IETF RFC about NAT46, to translate between IPv4 to IPv6 (v4 to v6!) is part of NAT64. Although you have to do additional configuration, to achieve "NAT46".

The bottom line of NAT46 is easy, you need one IPv4 address per IPv6 you want to reach from the IPv4-only-world. That is hard, but there is no way to put 128 bit inside of 32 bits ...