464XLAT is a piece of technology that allows hosts that are provisioned only with IPv6 connectivity to configuring a local interface with IPv4 addressing on in, that has working connectivity to the IPv4 internet.

Thus, 464XLAT ensures that applications and services that have a hard dependency on IPv4 will continue work even in IPv6-only network environments. Some examples of where this might be beneficial include:

- Software making use of legacy IPv4-only functions such as gethostbyname() instead of the more modern and IPv6-aware getaddrinfo().
- Software not using DNS that explicitly do things like socket(AF_INET, ...) with no logic to also try AF_INET6
- Web sites that link to resources using literal IPv4 addresses in URLs rather than hostnames

In short, what happens is that the locally generated IPv4 packet gets translated to an IPv6 one within the host stack by a component called the CLAT (this is what the host needs to implement). The IPv6 packet is then sent to the provider's NAT64 device, where it is in turn translated back to IPv4 and routed to its destination across the IPv4 internet. Replies follow the reverse path back to the host.

While 464XLAT not specific to mobile broadband, it would appear that this is the IPv6 deployment strategy chosen by most 3GPP mobile broadband operators. From the top of my head, this has already been deployed by T-Mobile USA, Telenor Norway, and Orange Poland. I therefore expect that over time, 3GPP mobile nodes will be expected to support 464XLAT - Android already supports it, and I've been told that it is expected to show up in Windows Mobile 8.2 too.

I've made an implementation of a 464XLAT CLAT for Linux available at https://github.com/toreanderson/clatd . It is simply a Perl script that sets up the networking stack and then starts the user-space daemon (TAYGA) for performing the actual IPv4<->IPv6 translation of traffic. It works just fine, but NM is completely blind to what's going on - it would be better if 464XLAT CLAT was supported directly by NM, so that when having e.g. [ipv4] mode=auto would cause it to try 464XLAT CLAT if available and if so, consider it a success. I would be happy to make any necessary adaptation to clatd if would be interesting to make NM call it directly, or it would be certainly possibly to reimplement the entire logic in the script in NM (as it only sets up the routing environment) and then have NM start TAYGA directly instad. Or implement everything in NM, of course.

464XLAT is formally specified in RFC 6877:

http://tools.ietf.org/html/rfc6877

Finally, Cameron Byrne from T-Mobile USA gave a presentation about 464XLAT at NANOG61 last month. You might find that interesting:

https://www.youtube.com/watch?v=Xl-hIyZSAmA
https://www.nanog.org/sites/default/files/wednesday_general_byrne_breakingfree_11.pdf

Tore