When the clock hits midnight on Wednesday, June 8 UTC, World IPv6 day begins. Many Web destinations—including the four most popular (Google, Facebook, YouTube, and Yahoo)—will become reachable over IPv6 for 24 hours. (In the US, that's 8PM EDT, 5PM PDT on Tuesday). As the current IPv4 protocol is quickly running out of its remaining 32-bit addresses, adopting its successor's Brobdingnagian 128-bit address space is long overdue.

AAAA records



Still, it's widely expected that a small fraction of all users will encounter issues when they type "facebook login" into Google come Tuesday evening. On June 8, the World IPv6 Day participants will add AAAA ("quad A") records holding IPv6 addresses to their domain name (DNS) servers, in addition to the normal A (for "address") records that exist for IPv4 addresses. This makes the DNS servers "dual stack," having both IPv4 and IPv6 connectivity.

Depending on various cache timeouts, applications will start seeing these IPv6 addresses within minutes to hours—or perhaps only after an application is restarted or the entire system is rebooted. If the system doesn't have IPv6 connectivity, it will ignore the IPv6 addresses in the DNS and connect over IPv4 as usual. If the system thinks it has IPv6 connectivity, it will try to connect to the destination over IPv6. If the connection works, the content is loaded over IPv6 and everything otherwise works like it normally does.

Potential issues



However, there are three possible ways in which loading content over IPv6 can be derailed. The least problematic one is that at some point, the OS in your computer or a router along the way realizes the IPv6 destination can't be reached. The OS, possibly with help from an ICMPv6 (Internet Control Message Protocol for IPv6) error message sent by a router, will then tell the requesting application that the connection couldn't be made. This happens pretty much immediately, so well-behaved applications will simply continue their connection attempts with the next available address—probably an IPv4 address.

I had this happen once during an Internet Engineering Task Force (IETF) meeting when the IETF had only recently made its servers reachable over IPv6. The routers that connected the meeting network didn't know where to send packets addressed to the IETF servers, but because of the ICMPv6 messages, my browser immediately fell back to IPv4 and I never even noticed the IPv6 dis-connectivity until I tried the command line FTP tool.

Things get worse when there are no ICMPv6 error messages or these messages are ignored. In that case, it usually takes some time for the system to determine that a connection attempt isn't going anywhere, so the user will be looking at a blank page for 10 to 60 seconds. Then, most browsers or other applications will retry over IPv4. Timeouts may apply to elements such as images, too, so loading an entire page this way can take a long time. But at least it loads... eventually.

The worst situation is the one where small packets make it to the server and back, so the TCP session gets established (the initial TCP setup packets are small), but then large packets containing actual data don't make it through. In and of itself, a packet size mismatch is a normal situation that is solved through Path MTU Discovery (PMTUD), but some firewalls filter the ICMPv6 packets that make PMTUD work.

The result is that sessions get established (so there is no fallback to IPv4), but actual data can't be transferred. Sessions then hang forever. (Though some operating systems have PMTUD "black hole detection" that will get the data flowing eventually.)

Expert views



DNS expert Cricket Liu is eager to see what comes out of World IPv6 Day. "We don't really know what's going to happen when AAAA records will be deployed along with A records on a global scale. That's why these big players are going to deliberately induce this to see what happens. We know that some fraction of clients think they have IPv6 but it doesn't work. But there's also the issue where both a server and a client have IPv6 connectivity, but the two ISPs involved haven't set up any peering."

Liu currently works for Infoblox, a company producing an appliance that uses DHCP and DNS technology to manage naming and addressing in corporate networks. "We began supporting IPv6 several years ago," Liu told Ars. "We now see a dramatic surge in IPv6 interest, but relatively few enterprises are implementing IPv6 right away. Most are in the information gathering phase."

"Having separate names for IPv6, such as ipv6.google.com, is untenable in the future, this way IPv6 will be a second-class citizen. Content producers need to enable dual stack, but we don't know what impact this will have. The big players are going to induce this deliberately on World IPv6 Day to see what happens. It's going to be an interesting day."

Qing Li, chief scientist at Blue Coat, expresses a similar sentiment. "Nobody can foresee all these issues. Some will be simple, some will be harder," he said.

Li advocates application proxies as a way to get the transition to IPv6 underway. Not coincidentally, his employer makes just such proxies, but he makes a good point. Just adding IPv6, which is going to happen on World IPv6 Day, is an easy first step. Providing all services over IPv6 will be much harder. Webpages are made up of many elements that are loaded from many different servers; making sure those are all IPv6-capable won't be easy.

Li also has a warning to prospective IPv4 address buyers. "Trading addresses is risky. Addresses come with a history; they may have been the sources of botnets and been blacklisted for years. Buying addresses without knowing their history is a bad idea," he said.

Li plans to use the opportunity afforded by World IPv6 Day to observe where all the IPv6 requests originate. "From which region, mobile or fixed, corporate, botnets?" he said. "We want to analyze security threats at the application level after the experiment. We are very invested in security over IPv6 at the application layer."