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.
This is called DNS64/NAT64 and has some small performance penalty. Making content directly accessible by IPv6 removes the 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
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.
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.