The night the IETF turned off IPv4

At a meeting this week, the Internet Engineering Task Force decided to kill …

Google to the rescue

Virtually none of the better known web destinations were reachable over IPv6. That changed  when popped into existence. At first, Google's IPv6-capable servers weren't reachable from the IETF meeting, but this was addressed within a few hours. After the plenary session was finished, someone from Google indicated that, while all of this was not "rocket science," the community needs to take IPv6 more seriously. As evidence, he pointed to basic routing issues that would never be allowed to persist in IPv4.

Google's is an interesting case in a number of ways. First of all, Google chose to give it IPv6 addresses only—over IPv4, this site is unreachable. So changing your browser's search box to point to this name isn't advisable unless you're absolutely sure you're never without IPv6 connectivity. The preferred approach is to have a name that has both IPv4 and IPv6 addresses so the site is reachable to both IPv4 and IPv6 users. It's understandable that Google and other big web destinations don't yet want to make their normal URLs IPv6-enabled: if they do that, and a user has an IPv6 connectivity issue, the user in question has to wait for the browser to decide that IPv6 doesn't work and retry over IPv4.

The use of the new domain and the subsequent experimentation also revealed a few things about how Google runs its services. When you go to, you're greeted by the normal search page, except that the letters in "Google" jump up one by one—presumably, an homage to the turtle that dances (if you have IPv6) on the KAME web site. Search works as usual, but if you click on news, maps, or mail, you're redirected to,, or—which don't have IPv6 addresses, and didn't work during the experiment. But by changing the news or maps part back to "ipv6," it's possible to reach those services over IPv6. Some people even got Gmail to work over IPv6 in a similar manner with more advanced hacking. So, apparently, a given Google server can support all the main services.

Thursday morning, I had the opportunity to talk to Paul Hoffman of the Internet Mail Consortium, who had spent a good amount of time making his own server reachable over IPv6 prior to the outage. "It's the funniest thing; I get hits from all over," Hoffman told me. "A fair number of people are currently set up to do IPv6. There's a fair amount coming from other IPv6 addresses, not just from here."

He thought the IPv4 shutdown went very well. "The experiment was a success on both the client and server layers... Those who didn't really care about the experiment discovered that it wasn't so hard to get IPv6 going and seemed amused that it worked," noted Hoffman. "On the server side once you had an IPv6 address, you had to think about which parts of the server configuration you had to touch, but it wasn't so bad after that. It's less intrusive than adding a new service or—God forbid—changing your SMTP server. But just because an application is IPv6-capable it doesn't mean it's going to work."

Apple and IPv6 

Apple's Stuart Cheshire, who recently started a term as a member of the Internet Architecture Board, was happy to see that the core Mac OS X and the Safari web browser had no issues with IPv6, although he was slightly dismayed with the inconsistent IPv6-functionality in Apple's IM application iChat. It is possible to get iChat to do Jabber over IPv6, but there are numerous caveats. Another disappointment was the need to run DHCPv6 to autoconfigure DNS addresses—which the Mac doesn't do.

"The promise of IPv6, all those years ago, was that it would make networking simpler, and therefore more reliable," said Cheshire. "IPv6 offered the promise that machines could autoconfigure themselves in a simple lightweight way, without needing a heavyweight solution like IPv4's DHCP. Well, the IPv6 designers forgot one little thing—the DNS addresses, which had to be entered by hand, which is clearly not a viable long-term solution. Now, ten years later, it's looking like we might end up needing all of the complicated DHCP code after all, just to get that one missing bit of information."

Cheshire also observed that IPv6 connectivity is often inferior to IPv4 connectivity. "The situation where the user has a lesser experience over IPv6 is not acceptable," he argued. "But on the other hand, we don't want to give users knobs to manage this manually. When you give a user choices, every choice should be a valid one. It's the system's job to avoid the invalid choices.

Today, a user of Apple's browser Safari may see a significant delay if there seems to be IPv6 connectivity but it doesn't work. Rather than let the user disable IPv6, or prefer IPv4 over IPv6, Cheshire suggests that the browser would detect a failing IPv6 connection attempt, and after several of those, move to IPv4 automatically.

All in all, the experiment succeeded in its goals of taste-testing and increasing IPv6 momentum—for the moment. But even if you think you know everything you need to know about IPv6, there are surprises when you flip the IPv6 switch. There's still a lot to do before the IPv4 addresses are used up within four years or so.

Expand full story

You must to comment.