[aaron42net]

Recent Android on T-mobile US uses IPv6-only transport. T-mobile's DNS servers are only asked by these devices to translate hostnames to IPv6 addresses. If they can't find an IPv6 address, they will look up the IPv4 address for a hostname, and pack it into the bottom 32 bits of an IPv6 address that routes to a IPv6-to-IPv4 NAT device at T-Mobile.

This is called DNS64/NAT64 and has some small performance penalty. Making content directly accessible by IPv6 removes the penalty.

[djrogers]

> This is called DNS64/NAT64 and has some small performance penalty.

While there may be some implementations that have a small performance penalty, certainly not all of them do. The NAT can be done in FPGA or ASIC, and there's not any difficult work being done to translate the DNS response.

* I've been installing NAT64 networks for several years

[X-Istence]

The performance penalty is that now my packets travel:

Phone -> T-Mobile -> NAT -> T-Mobile -> Internet -> My hosting provider

Whereas with IPv6:

Phone -> T-Mobile -> Internet -> My hosting provider

That NAT is an extra step, and will add a small amount of latency.

[Dylan16807]

The NAT, if set up right, would not cause the packets to take a different route.

Changing the packet format requires nanoseconds, no more than normal packet processing.

It's possible to set up anything wrong, but there's nothing about this technology that would introduce latency when done correctly.

[djrogers]

That NAT in many cases happens on the same edge router that'd be dropping your packets off on the internet anyway, so it doesn't have to add an extra hop.