NAT64/DNS64, presumably run by any ISPs who desire to provide only IPv6 addresses to their clients, would allow those clients to connect to IPv4 backends by dynamically responding to DNS queries for IPv6 addresses with a requisitioned mapping address. Apple explains it well in the link in the OP:

https://developer.apple.com/library/tvos/documentation/Netwo...

Sadly, it seems this breaks WebSockets in certain cases. Most WebSocket apps have fallbacks, BUT sometimes these long-polling fallbacks are unreliable on PaaS systems that timeout HTTP(S) connections, such as Heroku. I think that Heroku keeps connections alive if there's a heartbeat, so Meteor apps on Heroku will likely still work. But there are definitely apps out there that roll their own WebSocket connections without well-designed fallbacks, and it's likely they will no longer be accepted.

No. The device only needs to be able to function on IPv6-only networks where NAT64 and DNS64 are present.

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.

> 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

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.

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.

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.