Apple has done amazing things for IPv6 on the client side; first defaulting to IPv6 for link-local traffic, and then being an early adopter of Happy Eyeballs and putting relatively good IPv6 support in their AirPorts.
Interesting, now I am not even sure how much credibility can be given to the networking engineers from Apple: we're in 2015 and I still need to manually tune the TCP stack of my mac to get decent download speeds!
Exactly. It is Core OS, not CoreOS and it doesn't mean what they think it means. But's that's as much you're going to hear from someone that's actually from inside Apple.
Almost any technology low in Apple's stack is called 'Core ...'. A quick search at developer.apple.com yields Core Animation, Core Video, Core Text, Core Graphics, Core Image, Core Data, JavaScriptCore, WebCore, Core Audio, Core Bluetooth, Core Foundation, and Core Media Framework.
That convention started with Mac OS X, when they had to somehow unite the low-level technologies of classic Mac OS and NextStep.
I finally pulled IPv6 resolvers out of my config for this very reason. I was getting 4+ second lookups against both Comcast and Google v6 resolvers even though direct v6 sockets worked instantly; made worse because HSTS apparently makes Chrome put "establishing secure connection" in the status bar while resolving (maybe?), so I ended up down a rabbit hole of identifying reasons for phantom TLS stalls. Finally cut down to just v4 resolvers and it's a brand new computer.
That is pretty much what I saw. I was somewhat worried if it was the AT&T modem config or OSX, but nothing I tried fixed it (including explicitly setting DNS sources and so on).
I don't think this update really changes anything about the status quo, then, other than the fact that IPv6 seems to have a much higher likelihood of being favored (based on the ratios provided by the poster).
If you had privacy concerns about using IPv6 before, they remain, and (presumably) you can still disable it at a systemwide level.
Personally, if you're sophisticated enough to be using a VPN for privacy purposes, you can probably figure out whether or not your given solution supports IPv6.
In addition, I disagree that IPv6 is some sort of abject reduction in privacy. Many households already have a single member, so IPv4 wasn't providing much cover there. And (speaking from some experience) IP addresses aren't the best resource when doing tracking: that's what evercookies and supercookies are for.
This is actually a huge change for Apple as iOS and OS X would only use IPv6 ~20% of the time because of the IPv4 bias the old algorithm used. After this change, I expect to see IPv6 at the level's we see at facebook with our app to approach 80%, which is a huge improvement and hopefully results in a good rise in IPv6 usage on the internet.
> And (speaking from some experience) IP addresses aren't the best resource when doing tracking:
No, but IP-based tracking is even easier than many other methods and can be done passively.
The IP address may not be the only identifying piece of information, but IPv6 includes strictly more information that can be used to track you, and it makes it far easier to take advantage of that information. Supercookies are bad, but it takes even less tech sophistication and effort to track someone by IP address than with a supercookie.
> Many households already have a single member, so IPv4 wasn't providing much cover there.
A lot of people sit behind NAT with many members. Much as I hate NAT, it does provide this benefit, if only by accident. IPv6 makes it far easier to disambiguate two users behind the same NAT without having to look at any other bits of information (cookies, UA strings, etc.).
IPv6 has privacy extensions. On my home network my computer grabs a new IPv6 address every 30 minutes. Yes it's all out of the same /64, but this provides the same sort of smearing that NAT does.
To your second point, I don't understand how this is a problem with IPv6. It sounds like you are actually lamenting the obsolescence of NAT- which you can still have on IPv6 if you really wanted.
The FUD surrounding NAT going away both here and on other sites (Ars Technica in particular) is just completely amazing to me.
IPv6 with privacy extensions is just as "private" as NAT would be, and a default-deny firewall is just as secure. How these basic fundamentals of networking have escaped so many supposedly "in the know" people is astounding.
From a naive end-user perspective, NAT provides a de-facto firewall and "solves" the issue of opening ports. Little do people realize how much of a pain in the ass UDP hole-punching is (not to mention how much latency it produces) and how much UPnP announcement spam floods their network.
Are you sure that (current) Apple devices continue to route IPv6 directly when connected to a VPN that does not forward it? (A quick Google confirms that some VPN clients do this, but since the mailing list post is about Apple devices, let's stick to that. Although I'm on OS X, I can't test this easily because I don't have any VPN services set up.) If they do, I feel like that would be very surprising behavior that should be considered a bug, or at least a reason for the OS to provide the user with an obvious button to turn it off... maybe worth filing a Radar over?
Apple continues to route IPv6 over the default route when connected to a VPN that is v4 only (at least for OpenVPN that is the case, I don't have any experience with others).
So that means if you have a v4 only VPN provider all IPv6 happily goes over the default route.
This is not surprising to me at all, traffic should follow the default route that is given. If you are privacy conscious you should already know how to disable IPv6... Honestly if it is a bug anywhere it is a bug in the VPN providers that they are not providing IPv6 services for their customers.
Thankfully with OpenVPN IPv6 setup is simple, and while it doesn't provide the privacy extensions like SLAAC (you can only get a single static IPv6 address on the other end of the tunnel), it does allow you to easily tunnel IPv6 traffic as well. I personally do this by pushing 2000::/3 across from my OpenVPN server.
On OS X 10.9 I don't have a way to disable IPv6 that I can find. In Network > Advanced > TCP/IP > Configure IPv6, there are only three choices: automatic, manual, link local. And as soon as I configure it with either manual or link local, the wifi connection changes from green to yellow and I no longer have even IPv4 Internet, although it remains identically configured as before. A while ago this popup had an Off option just like the Configure IPv4 menu does.
Doesn't work that way for me. On 10.9.5 setting the wifi connection's IPv6 setting to "Link-local only" causes me to be unable to ping6 other machines but IPv4 is unaffected.
> If they do, I feel like that would be very surprising behavior that should be considered a bug,
Not really. Since VPNs have many different purposes (privacy is only one, and arguably not even the most common one), disabling all IPv6 traffic whenever a v4-only VPN is enabled may be a bad default for other use cases. In fact, I would be rather surprised if they did this (though pleasantly surprised).
They don't do this, it follows the route tables for the appropriate protocol. If you are v4 VPN connected the VPN overwrites the route table, but v6 will be unencumbered.
