4 ms·

I disagree that the missing of 464-XLAT is a problem for Apple. 464-XLAT is a big incentive for companies like Skype et al. to keep shipping software that only

I disagree that the missing of 464-XLAT is a problem for Apple. 464-XLAT is a big incentive for companies like Skype et al. to keep shipping software that only works on IPv4. Instead, the need for 464-XLAT on iOS is completely overruled by the new policy that requires apps to be able to correctly operate in IPv6 mode only from iOS9 onwards (or they get rejected). So Skype will now be forced to fix their backend servers to handle IPv6 connections, or they won't be able to ship on iOS9. This way, Apple completely bypassed the need of a transition solution. In fact, iOS support might even be a good global push for companies to transition to IPv6 support (just like Mobile Safari has been for begin dropping Flash and supporting HTML5 videos). If anything, I think this policy change should overrule whatever negative points you want to give to them for not supporting 464-XLAT.

ploxiln 11y ago
In fact, I'd argue that "transition aids" have significantly hampered ipv6 adoption thus far. I remember back in ~2007 (edit: actually 2005 I think) when on my home linux system firefox started hanging for 30 seconds when loading web pages. It was because it was trying ipv6 first, but I of course didn't have real ipv6 connectivity. I was more novice back then and I'm not sure what exactly in the OS or router pretended to have ipv6 connectivity. But this problem got worse with Windows Vista and "Teredo" automatic tunnels and 6in4 and various schemes. Too often, these schemes don't work close enough to 100% reliably, and then to be safe, ipv6 has to be disabled. In fact, ipv6 was enabled in early versions of Firefox and OS X, and then in later updates it was disabled because too many people unknowingly had broken ipv6 setups because of hare-brained "transition aids". And then a couple years later they came up with "happy eyeballs" so they could turn ipv6 back on again. The major transition over the past year is only due to major cable ISPs offering native ipv6 subnet broadcasts to consumer connections. So much for automatic tunneling, magic multi-homed public-ish 6in4 routers, etc. They added great amounts of complexity to ipv6 and delayed adoption because they were flaky. And only now is native ipv6 catching on.

ploxiln 11y ago

In fact, I'd argue that "transition aids" have significantly hampered ipv6 adoption thus far. I remember back in ~2007 (edit: actually 2005 I think) when on my home linux system firefox started hanging for 30 seconds when loading web pages. It was because it was trying ipv6 first, but I of course didn't have real ipv6 connectivity. I was more novice back then and I'm not sure what exactly in the OS or router pretended to have ipv6 connectivity. But this problem got worse with Windows Vista and "Teredo" automatic tunnels and 6in4 and various schemes. Too often, these schemes don't work close enough to 100% reliably, and then to be safe, ipv6 has to be disabled. In fact, ipv6 was enabled in early versions of Firefox and OS X, and then in later updates it was disabled because too many people unknowingly had broken ipv6 setups because of hare-brained "transition aids". And then a couple years later they came up with "happy eyeballs" so they could turn ipv6 back on again. The major transition over the past year is only due to major cable ISPs offering native ipv6 subnet broadcasts to consumer connections. So much for automatic tunneling, magic multi-homed public-ish 6in4 routers, etc. They added great amounts of complexity to ipv6 and delayed adoption because they were flaky. And only now is native ipv6 catching on.