Apple snuggles closer to IPv6 With the latest public betas of iOS 9 and the already-patched “El Capitan” OS X 10.11, Apple is leaning further towards IPv6. In a post to the IETF's v6ops mailing list, Apple CoreOS networking engineer David Schinazi says the new releases include a re-vamped version of the three-year-old Google-authored “Happy Eyeballs” RFC …
There's a prevalence for ipv4 showing a good tcp setup time even though the path isn't optimal for the whole transfer, for example fragmentation. IPV6 takes a little longer e.g. to ensuring no frag, but you get a better persistent connection, and no CGN. Weighting IPv4 down has shown better results.
Apple have done nothing with IPv6 for the last 4 years. In that time user adoption has got up to over 21% in the US. So it is very welcome that someone in there is finally working on IPv6 again. The recent changes they announced to better support IPv6-only PDP/PDN connections in iOS are also welcome. They still have a critical gap in their IPv6-only support in iOS. They don't yet support IPv4 hotspot when the PDP/PDN connection is IPv6-only.
On the one hand they're saying IPv6-only is critical but on the other they aren't supporting it to a level that can be deployed. Android, Windows Phone and Jolla solve the IPv4 tethering problem using 464xlat.
Finally! When Apple first introduced (their version of) "Happy eyeballs" they made the critical mistake of choosing whichever version of the protocol was faster without regard for the future of either protocol, specifically the harm that behaviour would do to an increasingly NATed IPv4 network. Now it looks like they've got a clue (for whatever reason) and are now preferring the protocol that will actually grow the network going forward.
Good!
Most of the major operating systems have had pretty good support for IPv6 for a while now. Adoption has been hindered by ISPs, websites like El Reg, and routers. I suspect a large number of people have routers are only configured for IPv4 and that isn't likely to change anytime soon. Will this allow the computer to setup a tunnel through such routers? How will that affect the firewall function of the router?
Most people have routers supplied and configured by their ISPs, if the ISP supplies a router configured for v6 then users will use it without even realising (very common in the US).
The problem is that very few ISPs in the UK support v6 at all, and the few that do are small ones which attract tech savvy customers anyway.
Amongst business it's even worse, virtually everyone simply ignores v6, and those very few that might consider implementing v6 find that they're stuck with ISPs who don't support it anyway.
It's different in the US primarily because the government requires that all government sites are dual stack and that any company supplying the government support and use v6. Without being forced, business users will never bother using it at all.
Of course, it only works at all if the user has a connection that is somehow IPv6-capable.
Instead, if the first responder is IPv4, the algorithm sets a 25 ms timer to see if a response comes back from an IPv6 host.
Like a lot of people, I am currently using BT's internet service. BT only offer IPv4. So this means that my OS will unnecessarily add 25ms connect latency when there is no possibility of connecting over IPv6?
Hopefully there is a kernel option to switch this behaviour off, until I can afford an ISP who does IPv6.
(Have tried experimenting with a Hurricane Electric 6-over-4 tunnel but couldn't get the routing working thanks to certain intricacies of my router...)
The article doesn't make it particularly clear as to whether the OS will manage its own tunnel even on an IPv4 only connection, it should be perfectly capable of doing this, but this does possibly open up new attack vectors. One of the advantages of being behind a wired router is that it's one more machine that needs to be hacked before people get to mine. A lot of routers also have reasonable firewall defaults.
But I don't want to be alarmist on this. I suspect that Apple is making the switch because IPv6 on LTE could have noticeably lower latency than on anything running IPv6 NAT. Then there is all that extra information to be read if privacy extensions aren't enabled. Practically no need for cookies with persistent IPv6 addresses.
Not really an issue for me as my router is dual-stack supplied by my ISP (Unitymedia). Privacy extensions enabled, of course.
ISPs that don't get their act together on IPv6 do not inspire confidence.
"Apple's been a long-time supporter of IPv6, having first introduced support for the protocol in 2006"
So what does that make Microsoft, who first shipped an IPv6 implementation back in 1998 and then included a production ready stack in XP-SP1 in 2002? I'd say Apple are relatively new member of the IPv6 ready club.
Reading this article, I could help but think about the recent article about VPN's which showed that because of a lack of joined up thinking, many client systems were leaking information over their IPv6 stack. It would seem that this implementation of IPv6 DNS will leak by design.
> It would seem that this implementation of IPv6 DNS will leak by design.
It will leak no more and no less by design then before. The leakage is not because the host OS is using IPv6, it's because the VPN endpoint isn't doing it's job properly.
Put another way, the IPv6 leakage is due to a crap VPN only dealing with IPv4 traffic. There is absolutely no excuse for this - any VPN worthy of the name should handle IPv6 traffic, or at the absolute least (configurably, but default to on) disable it while the IPv4 tunnel is up.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
