In wake of World IPv6 Day, browsers resist IPv6 brokenness—but should they?

IPv6 brokenness is on the decline, but browser and operating system makers are …

At a plenary session during the Internet Engineering Task Force (IETF) meeting in Quebec City, Canada two weeks ago, World IPv6 Day was rehashed at some length. It took place on June 8 this year, and Google, Facebook, Yahoo and others turned on IPv6 for 24 hours in an effort to flush out broken IPv6 setups. Immediately after IPv6 day, and again six weeks later, we noted that there didn't appear to be much breakage to speak of. But at the IETF meeting, several of the Web companies had a little more information to share (PDF).

The most interesting presentation came from Cisco's Mark Townsley. Unlike companies such as Google, Yahoo, Limelight, and Akamai, Cisco isn't a Web company. It does make most of its money through cisco.com, though; as such, it was hard to convince management to participate in IPv6 day, since nobody really wants to put any part of $30 billion in revenue at risk. But apart from the argument that Cisco should be "eating our own dogfood," the management found one argument compelling: many others would be doing the same thing, so this was the one and only chance to try it without much risk of a customer backlash. 1.11 percent of all traffic to www.cisco.com was IPv6 on June 8 and zero IPv6-related support tickets opened that day.

Google's Lorenzo Colitti showed a graph indicating slowly declining levels of "issues" with IPv6, but this number excluded users of Google's Chrome browser. For Chrome, Colitti reported a reduction in problems by as much as 80 to 90. However, this figure only applies to the user experience; Chrome now has a "fast fallback" option which makes the browser switch to IPv4 if an initial IPv6 connection attempt doesn't progress in 300 milliseconds. (According to Colitti, Firefox implements a similar workaround.)

Of course, such fixes only apply to browser use—other applications still experience much longer timeouts when using a machine that thinks it has IPv6 connectivity when IPv6 doesn't actually work.

As of Mac OS 10.7 Lion, Apple implements something similar in its lower layer networking frameworks. This means that all applications that use these frameworks automatically gain this user-friendly behavior. As explained by Apple's Josh Graessley on the company's IPv6 dev mailing list, the address (IPv4 or IPv6) that has the lowest minimum round trip time is initially selected for connections. Round trip times are continuously measured during TCP connections and stored for some time in the system's routing table. If this information isn't available, the system uses a set of rules to determine which addresses are "better" than others. However, unlike Windows, FreeBSD, and Linux, Mac OS doesn't allow the user or system administrator to change these "RFC 3484" rules.

There's also some DNS timeout magic going on in Apple's implementation of decisions based on previous RTT measurements (which was also present in Mac OS 10.6, but remained buggy until version 10.6.8). In Chrome's approach, it tries IPv6 first and the browser only falls back to IPv4 if there is no answer over IPv6 within 300 milliseconds. Apple's approach layers several mechanisms on top of each other, each dependent on ever changing timing information, so it becomes pretty much impossible to predict whether the system is going to connect over IPv6 or IPv4.

For users, this doesn't matter. If IPv6 doesn't work, their Mac will connect over IPv4 automatically and the broken IPv6 connectivity is never an issue. However, for system and network administrators, this behavior can be extremely problematic. Applications, operating systems, and various network devices change on a regular basis, and it's quite common for these changes to break connectivity. Broken IPv4 connectivity immediately leads to complaints and is thus fixed very quickly. But if broken IPv6 connectivity is now hidden by numerous "happy eyeballs" algorithms, this means that any broken connectivity is never even detected, let alone fixed. This makes it easier to enable IPv6 on large Web properties without any problems, but makes it harder to learn much from the experience.

All of this seamless fallback to IPv4 is also going to make it harder to eventually turn off IPv4, because lots of people who think they have IPv6 will in fact have broken IPv6 without realizing it. The worst part about this is that Apple refuses to allow power users to disable this automatic behavior or change the RFC 3484 policies used by their system, frustrating efforts to find and fix IPv6 brokenness.

However, not all software uses Apple's networking frameworks, which leads to some interesting results. At home, I use a tunnel so IPv6 packets are carried in IPv4 packets, which makes IPv6 slower than IPv4. This ensures I get two different results when I test my IPv6 connectivity. Using Safari, Apple's browser, my system only connects over IPv4 when it has the choice between IPv4 and IPv6, since that's the faster option. ipv6test.google.com even tells me I don't have IPv6. But Firefox uses lower-layer Unix network code and thus connects over IPv6 where possible. So, with that browser, Google's IPv6 test tells me I do have working IPv6.

I'm afraid that the efforts by Google (Chrome), Mozilla (Firefox), and Apple to hide broken IPv6 will produce a short-term victory, but at a cost of delaying the long-term solution.

Iljitsch van Beijnum
Iljitsch is a contributing writer at Ars Technica, where he contributes articles about network protocols as well as Apple topics. He is currently finishing his Ph.D work at the telematics department at Universidad Carlos III de Madrid (UC3M) in Spain. Emaililjitsch.vanbeijnum@arstechnica.com//Twitter@iljitsch

Part of the issue I see at this point, is that beyond having IPv6 tunnel support in your router, there really doesn't seem to be a standardised method for serving IPv6 subnets from ISPs. Some want to use DHCPv6 and some 6rd. What WAN side methods should routers be supporting for acquiring subnet prefixes?

Theoretically many of those routers could be fixed with a firmware upgrade. The bigger concern for me is the sluggishness at which ISPs have been rolling out IPv6 deployments thus far. Tunnels are pretty much only for testing, real world deployment requires real network support.

I so badly want to go IPv6 just to get the dynamic DNS features and finally once and for all not have to constantly port-forward through my router to get server apps working... hurry up and get it done, already!

Part of the issue I see at this point, is that beyond having IPv6 tunnel support in your router, there really doesn't seem to be a standardised method for serving IPv6 subnets from ISPs. Some want to use DHCPv6 and some 6rd. What WAN side methods should routers be supporting for acquiring subnet prefixes?

I'm curious about how that's going to work, too. I was under the impression that IPv6 addresses should all be subnetted, and that we will no longer need NAT. That makes things like port forwarding a thing of the past, and it should really simplify VoIP, since you don't need SIP proxies if you can contact any Internet host directly by their IP address.

The question, then, is how many local addresses an individual will get. Do we get 1? 5? 10? As many as we need for local operations? Back in the days before NAT routers, you could actually lease multiple addresses on your cable modem connection. I did this at my house to get our two computers on-line. (I eventually set up an internal proxy server so I could add my laptop.)

Nowdays, thanks to NAT, I've got more than a dozen IP addresses in regular use at my house: 4 PC's, 3 smartphones, 2 Android tablets, 2 Wireless Access Points, a weather receiver, 2 Nintendo DS's, and a Wii console. That doesn't even count transient users, such as friends who come over with their laptops.

Ideally, all those addresses should get public Internet addresses. That would let me host a game on my PC without having to port forward, and it would allow VoIP services without an intermediary. (You'd just need to know the other party's DNS address.)

However, I have a feeling that someone will find a way to mess that up for us.

The question, then, is how many local addresses an individual will get. Do we get 1? 5? 10? As many as we need for local operations?

It has to be at least 64 bits worth of space for auto-configuration to work, and I think ISPs are supposed to be handing out /48 network prefixes with /32 available to those that need it. So worst case you should have enough for about 18 quintillion addresses.

I would be happy enough if my ISP had a /48 and subdivided that into /120 for me as a customer. 256 devices/addresses would probably do me for my lifetime... as long as the ISP ( one of Canada's largest cable companies) gets with the program and starts to offer V6 SOON... like 2012 at the latest. The problem tho' will be the replacement of a zillion customer end "home terminals" routers with wifi and built in cable modems which currently, the one I have anyway, don't support V6.

However, I have a feeling that someone will find a way to mess that up for us.

I think any efforts to mess it up will break IPv6 fundamentally and interfere with traffic flow.

It could be done by ISPs deciding to use DHCPv6 and assigning customers only one IPv6 address.

I don't think that will happen because it will be even harder to support, customers already run as many devices they want behind their home router, trying to block and bill for that will probably cause more customer support problems than the revenue would be worth. Whether the ISPs see it that way, I don't know.

Rambling...

They are going to invest in something and getting a robust IPv6 infrastructure and encouraging adoption by service providers is probably the cheapest. Either way ISPs are going to have to build a large NAT infrastructure, either NAT64 to get IPv6-only clients to the existing IPv4-only internet or assign customers IPv4 10/8 space and run large IPv4 NAT at a ratio of maybe 1 NAT appliance for each 100 customers. Doing IPv4 NAT doesn't leave any exit strategy and is an ever-increasing cost of doing business whereas doing NAT64 will eventually peak and fall off in usage as more and more providers get IPv6 addressing for their services and can eventually be sunset (probably in 2036)

I would be happy enough if my ISP had a /48 and subdivided that into /120 for me as a customer. 256 devices/addresses would probably do me for my lifetime... as long as the ISP ( one of Canada's largest cable companies) gets with the program and starts to offer V6 SOON... like 2012 at the latest. The problem tho' will be the replacement of a zillion customer end "home terminals" routers with wifi and built in cable modems which currently, the one I have anyway, don't support V6.

You can't really configure anything smaller than a /64 per layer2 network as all of the IPv6 stack auto-configuration and address assignment kind of depend on it. An ISP could have your entire neighborhood on one layer2 network and use port security to keep customers from talking directly to one another using the same mechanisms that are widely deployed right now that would be unaffected by the layer3 protocol used.

Theoretically many of those routers could be fixed with a firmware upgrade. The bigger concern for me is the sluggishness at which ISPs have been rolling out IPv6 deployments thus far. Tunnels are pretty much only for testing, real world deployment requires real network support.

I'd love that to be the case but we all know that in reality hardware vendors will use it as an excuse to sell new hardware on the basis of ipv6 compatibility than provide a free firmware for existing devices.

So one of the bad things about this is that your IPv6 network could go belly up and the admins won't realize it because the users won't notice and complain because they have been shunted over to IPv4? It's been awhile since I was on the networking side of things, but since when do NOCs rely on users to tell them there is a problem? Whatever happened to monitoring and auditing your own network (especially after a potentially breaking change)? I don't see this particular argument as very compelling.

I can possibly see the issue of IPv4 sticking around longer because it has better performance, though. It is tempting to just say that it is up to the network architects to make their IPv6 implementations perform better, but that is easier said than done. That hand will eventually be forced.

"I can possibly see the issue of IPv4 sticking around longer because it has better performance"

Blizzard's chief network engineer said IPv6 will give better performance for their games, just because IPv6 is easier to route.

Once people get the kinks worked out of their IPv6 networks, that should be true. IPv6 day showed that there are plenty of kinks so I can agree that failover to IPv4 will likely happen fairly frequently early on as the article suggests.

I would be happy enough if my ISP had a /48 and subdivided that into /120 for me as a customer. 256 devices/addresses would probably do me for my lifetime...

No it won't not in the next gen smart homes, where even every light bulb has its own ip so it can report itself to your maintenance/controller (like on jaguar cars with can bus and similar on passenger aircraft ).The light bulb (for an old school filament bulb) report when its impedance changes and its about to blow or get to dim.

Could end up with even your toilet needing an ip. Image the fun you could have playing with one of those home systems if they weren't properly secured ;-)

I would be happy enough if my ISP had a /48 and subdivided that into /120 for me as a customer. 256 devices/addresses would probably do me for my lifetime... as long as the ISP ( one of Canada's largest cable companies) gets with the program and starts to offer V6 SOON... like 2012 at the latest. The problem tho' will be the replacement of a zillion customer end "home terminals" routers with wifi and built in cable modems which currently, the one I have anyway, don't support V6.

You can't really configure anything smaller than a /64 per layer2 network as all of the IPv6 stack auto-configuration and address assignment kind of depend on it. An ISP could have your entire neighborhood on one layer2 network and use port security to keep customers from talking directly to one another using the same mechanisms that are widely deployed right now that would be unaffected by the layer3 protocol used.

Hold on a second, even if I turn off IPv6 in my System Preferences on OS X it still does all of this? That can't be true. I honestly cannot believe that. Does Wireshark do ipv6? How can I test this?

What makes you think that? IPv6 is just on by default on OS X. It tries to connect over IPv6 and falls back to IPv4 if it can't connect. Exactly like it should be (on by default) and should behave (fallback to IPv4).

I would be happy enough if my ISP had a /48 and subdivided that into /120 for me as a customer. 256 devices/addresses would probably do me for my lifetime... as long as the ISP ( one of Canada's largest cable companies) gets with the program and starts to offer V6 SOON... like 2012 at the latest. The problem tho' will be the replacement of a zillion customer end "home terminals" routers with wifi and built in cable modems which currently, the one I have anyway, don't support V6.

You can't really configure anything smaller than a /64 per layer2 network as all of the IPv6 stack auto-configuration and address assignment kind of depend on it. An ISP could have your entire neighborhood on one layer2 network and use port security to keep customers from talking directly to one another using the same mechanisms that are widely deployed right now that would be unaffected by the layer3 protocol used.

That said, you don't have to use address autoconfiguration. It's perfectly legal to statically assign IPv6 addresses (and for testing purposes it's often easier to assign yourself something like 2001::1 instead of letting it autoconfigure all of those bits when you're not on the internet at large).

IMHO the best way to get smart on IPv6 is to simply hop on over to tunnelbroker.net and set you home/lab up with a tunnel. That's the best way to see the autoconfiguration in action, and probably teach you a bit about router advertising and how the addressing works.

V6 only clients are going to be rare for some time, especially in the west.

I don't know how it's going to go down for sure, but I assumed that once the IPv4 addresses ran out, some ISPs would start handing out both to everybody, and if someone tries to get on and there's no v4 address immediately available, then they'll only get the v6 address and be put in an invisible queue for the v4 address. As v4 addresses come available, they'll be assigned to the people at the head of the queue.

Hopefully this will spur websites to get their act together with respect to IPv6 so people don't start complaining that their site is broken for 10 or 15 minutes after the log in every time.

V6 only clients are going to be rare for some time, especially in the west.

I don't know how it's going to go down for sure, but I assumed that once the IPv4 addresses ran out, some ISPs would start handing out both to everybody, and if someone tries to get on and there's no v4 address immediately available, then they'll only get the v6 address and be put in an invisible queue for the v4 address. As v4 addresses come available, they'll be assigned to the people at the head of the queue.

Hopefully this will spur websites to get their act together with respect to IPv6 so people don't start complaining that their site is broken for 10 or 15 minutes after the log in every time.

There are already vast domains that are v6 only, right here in the west. Comcast, for example, makes extensive use of v6 only clients within their set top box domain. Why? They had already exhausted 10./8 and federated ten net islands wasn't going to work. Clients in the far east are going to be v6 only in the very near future.

My point was that if you're going to host DNS and use DHCP, you might as well dual-stack your setup to accomodate all clients. It's much cleaner than futzing around with NAT, and accomodates everyone.