4 ms·

Does this mean all backends that an app communicates with need to be accessible over IPv6?

by lucaspiller 10y ago

deleted 10y ago
[deleted]
subway 10y ago
No. The device only needs to be able to function on IPv6-only networks where NAT64 and DNS64 are present.
aaron42net 10y ago
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 10y ago
  > 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 10y ago
    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 10y ago
      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 10y ago
      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.
btown 10y ago
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/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html 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.

Does this mean all backends that an app communicates with need to be accessible over IPv6?

deleted 10y ago

[deleted]

subway 10y ago

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

aaron42net 10y ago

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 10y ago
> 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 10y ago
  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 10y ago
    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 10y ago
    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.

btown 10y ago

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/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html 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.