3 ms·

The negative thing about this is that they don't use a XLAT464 resolver. With DNS64, they break DNSSEC. Android has an built-in XLAT464 resolver since version 4

by eloy 10y ago

The negative thing about this is that they don't use a XLAT464 resolver. With DNS64, they break DNSSEC. Android has an built-in XLAT464 resolver since version 4.1 IIRC. So a carrier can't choose for this as long as there is a vendor (Apple) that don't support it. T-Mobile in the USA is currently using such a network, which is the best transition method in my opinion.

X-Istence 10y ago
DNSSEC would only matter to the end client (the iPhone in this case) if it actually verified DNSSEC responses on the client, but it doesn't. So unless your application contains a full DNS resolver that can walk the roots itself, you are relying on the DNS server from your provider to provide you with DNSSEC validated results. In this case the provider can simply return results without any of the DNSSEC results and things will be more than happy to continue on. XLAT464 is not some sort of panacea, and requires a bunch of extra software running on the device to properly function. NAT64 with DNS64 means you ignore all of that, and only the provider has to know that translation is happening, from a device perspective it looks like it is running on top of a IPv6 only network with all endpoints only being IPv6. It's simpler, and maybe just the push providers need to roll out IPv6 more aggressively.
- eloy 10y ago
  > DNSSEC would only matter to the end client (the iPhone in this case) if it actually verified DNSSEC responses on the client, but it doesn't. If you tunnel the DNS resposes over a TLS connection, then it would be secure. This has been specified in an RFC recently. And about XLAT464: Apple could've just added that to iOS, instead of this. Google did the same a few years ago. If all the vendors would apply the same transition mechanism, that would make it a lot more easier for carries to deploy IPv6.
  - ay 10y ago
    464XLAT (https://tools.ietf.org/html/rfc6877 https://tools.ietf.org/html/rfc6877), is a stateless NAT46 on the phone, coupled with a stateful NAT64 on the headend, and sometimes with DNS64. This (edit: 'this' being the presence of stateless translation on the device) means the device has to do extra translation work on a per-packet basis, which would not help the battery life, and also the apps remains IPv4-only. I.e.: it is technical debt. Apple has a stronger influence on the developers + a lot of address-family independent APIs, so they could exercise this option of allowing operation on IPv6-only access networks while also progressing towards all applications being future-proof.
  - djrogers 10y ago
    >If all the vendors would apply the same transition mechanism, that would make it a lot more easier for carries to deploy IPv6. The nice thing about NAT64/DNS64 is that there is no support for anything beyond IPv6 required on the client - it's entirely handled by the network, and is completely transparent / invisible to the endpoints.
gsnedders 10y ago
What makes it a better transition method than operator-level NAT for IPv4 (and no NAT for IPv6)? Like, what do you gain by having the client not ever speak IPv4 directly?
- eloy 10y ago
  It's less ugly than Dual Stack. Just one address per device, nothing more. This should be the long term goal too.
  - ay 10y ago
    Indeed. Also, in 3GPP until Release 9 there had to be two PDP contexts per device - one for IPv4 and one for IPv6, thus resulting in performance issues, and licensing costs for some vendors too. This was fixed in later releases when a new type was added, IPv4v6, which combined both stacks within a single context, but I heard this created issues with roaming if the "guest" operator network did not support this context type. But indeed just one address family is less overhead, and less work for the device. Thus, potentially better battery life.

by eloy 10y ago

X-Istence 10y ago

DNSSEC would only matter to the end client (the iPhone in this case) if it actually verified DNSSEC responses on the client, but it doesn't. So unless your application contains a full DNS resolver that can walk the roots itself, you are relying on the DNS server from your provider to provide you with DNSSEC validated results. In this case the provider can simply return results without any of the DNSSEC results and things will be more than happy to continue on. XLAT464 is not some sort of panacea, and requires a bunch of extra software running on the device to properly function. NAT64 with DNS64 means you ignore all of that, and only the provider has to know that translation is happening, from a device perspective it looks like it is running on top of a IPv6 only network with all endpoints only being IPv6. It's simpler, and maybe just the push providers need to roll out IPv6 more aggressively.

eloy 10y ago
> DNSSEC would only matter to the end client (the iPhone in this case) if it actually verified DNSSEC responses on the client, but it doesn't. If you tunnel the DNS resposes over a TLS connection, then it would be secure. This has been specified in an RFC recently. And about XLAT464: Apple could've just added that to iOS, instead of this. Google did the same a few years ago. If all the vendors would apply the same transition mechanism, that would make it a lot more easier for carries to deploy IPv6.
- ay 10y ago
  464XLAT (https://tools.ietf.org/html/rfc6877 https://tools.ietf.org/html/rfc6877), is a stateless NAT46 on the phone, coupled with a stateful NAT64 on the headend, and sometimes with DNS64. This (edit: 'this' being the presence of stateless translation on the device) means the device has to do extra translation work on a per-packet basis, which would not help the battery life, and also the apps remains IPv4-only. I.e.: it is technical debt. Apple has a stronger influence on the developers + a lot of address-family independent APIs, so they could exercise this option of allowing operation on IPv6-only access networks while also progressing towards all applications being future-proof.
- djrogers 10y ago
  >If all the vendors would apply the same transition mechanism, that would make it a lot more easier for carries to deploy IPv6. The nice thing about NAT64/DNS64 is that there is no support for anything beyond IPv6 required on the client - it's entirely handled by the network, and is completely transparent / invisible to the endpoints.

gsnedders 10y ago

What makes it a better transition method than operator-level NAT for IPv4 (and no NAT for IPv6)? Like, what do you gain by having the client not ever speak IPv4 directly?

eloy 10y ago
It's less ugly than Dual Stack. Just one address per device, nothing more. This should be the long term goal too.
- ay 10y ago
  Indeed. Also, in 3GPP until Release 9 there had to be two PDP contexts per device - one for IPv4 and one for IPv6, thus resulting in performance issues, and licensing costs for some vendors too. This was fixed in later releases when a new type was added, IPv4v6, which combined both stacks within a single context, but I heard this created issues with roaming if the "guest" operator network did not support this context type. But indeed just one address family is less overhead, and less work for the device. Thus, potentially better battery life.