clatd VS tnat64

For Linux if you have the need for 464XLAT you can use clatd

I'd say no. This will break anything that uses literal IPv4 addresses, like games. Unless you also run clatd or something. Just run dual stack, then your IPv4 stuff will continue to work (as well as it ever has, through layers of NAT).

If you're not running IPv4 at all, you need clients to run something like clatd to do NAT46 locally.

You can run this on linux to get ipv4 on all types of connections: https://github.com/toreanderson/clatd

Most other OSes like Windows also have a built in CLAT implementation that works similarly.

On the two machines that have this (and whatever appliance devices, which I guess would include our phones), it means I have a full 464XLAT system, so applications running aren't necessarily aware that I don't have a full dual-stack network. On the flip side, I don't have clatd or anything similar running on my laptop, so any software that tries explicitly to create an IPv4 connection is going to fail.

There's nothing specific about t-mobiles 464xlat, you just need a clatd to do it. This one should work just fine

This is generally why 464XLAT was invented - at the OS level there's a CLAT daemon that presents itself as an IPv4 networking stack to applications, it translates the requested IPv4 address to a synthetic IPv6 address, sends that to a NAT64 upstream, gets the response over IPv6, and gives the responses to the application over IPv4 again.

Typically paired with 464xlat in an IPv6-only environment, for programs that are hard-coded for IPv4.

An excellent `just-works` example is https://github.com/toreanderson/clatd

If you don't want CLAT you could try using something like tnat64 - that hooks between Steam and the OS and actually turns the IPv4-only C library calls from Steam into IPv6-capable ones before they reach the C library; but I just tested it and it looks like Steam is using a bunch of features that this library does not yet support.