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 along 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."
The evangelist
We also spoke with Owen DeLong, "IPv6 evangelist" at service provider Hurricane Electric, where "every day is World IPv6 Day." DeLong expects that the experiment will show that the scope of the connection problem is smaller than currently estimated.
"As such, I am hoping it will provide more of an impetus for content developers to deploy AAAA records," he said.
On the other hand, he's not that optimistic about the ability of ISPs to light up native (as opposed to tunneled) IPv6 in the short term. "The last mile infrastructure situation for IPv6 is still pretty abysmal, with many systems still lacking meaningful IPv6 support, especially in the DSL and PON (passive optical networks, like Verizon's FiOS) environments, but, even in many of the deployed DOCSIS systems," he said. "A lot of DOCSIS deployments still use DOCSIS 2.0, and even with DOCSIS 3.0 the management systems may not be ready for IPv6. At least the CPE [customer premises equipment, or home router] guys know it's important now, even though that's 12 to 18 months late."
Paradoxically, the fact that we're now witnessing the last months of the IPv4 address supply has finally brought IPv6 the attention that it hasn't been getting for so many years, but the depletion of the IPv4 address pools may also make it harder to actually deploy IPv6. After all, IPv6 doesn't buy you access to IPv4 services, so heroic efforts will be necessary to keep some form of IPv4 running, with Carrier Grade or Large Scale Network Address Translators (CGNs/LSNs) using many layers of network address translation to allow a large number of users to share a small number of IPv4 addresses. This takes away time and money that could otherwise be spent on deploying IPv6.
This is a waste of time, according to DeLong: "LSN, NAT64, and the like all offer a severely degraded experience. I think that the only good way to address the IPv4 shortage is migration to IPv6. Everything else is putting a band-aid on an arterial bleed. All that really does is create a blood-soaked bandage, but the patient is still suffering critical blood loss. IPv4 simply isn't sustainable much beyond its current point no matter what we do."
But there's also good news. "I think the next few years are going to be very exciting," he said. "I'm looking forward to the transition, actually, because I think we're on the verge of being able to bring real innovation back to the Internet and remove a lot of limitations that we have taken for granted in the consumer space for the last 20 years."
Hurricane Electric routinely handles several Gbps of IPv6 traffic, which will likely "significantly jump" for WIPv6D, as IPv6 customers will be able to reach many more destinations over IPv6. However, DeLong isn't worried about the additional traffic. "The IPv6 traffic displaces IPv4 traffic, so the total amount of traffic will remain the same," he said.
The issues
In some ways, efforts to implement IPv6 are like Zeno's paradox of the tortoise and Achilles. In this ancient thought experiment, a tortoise challenges Achilles to a race, claiming that even though the (semi-) invincible hero Achilles is much faster, he would never win the race if the tortoise received a head start. After all, by the time Achilles covered the 10 meter head start—yes, apparently ancient Greece used the metric system—the tortoise would have also progressed, say by one meter. By the time Achilles traversed that additional meter, the tortoise would be 0.1 meters further along, and so on, ad infinitum; Achilles never pulls even with the tortoise.
In the same way, whenever a feature is implemented for IPv6, something new has been added to IPv4 that must also be added to IPv6 before the new protocol reaches parity with the old one.
But it gets worse. In its early days, IPv6 deployment was helped by training wheels in the form of automatic tunnels that magically turn IPv4 connectivity into IPv6 connectivity. There are two popular forms of automatic tunneling: 6to4 and Teredo. The difference is that 6to4 requires a public IPv4 address, so it can only run on a home router (or computer) that is directly connected to the outside world; Teredo is set up to work through IPv4 Network Address Translators (NATs). These protocols have been getting a lot of bad press these days, but that's unfair: they are very useful as a quick and easy way to get IPv6 connectivity.
The problem is that Apple turned on 6to4 by default on its Airport Extreme base stations some time ago, and Microsoft has 6to4 and Teredo enabled by default on all Windows systems that have IPv6 enabled. (That would be XP after IPv6 is explicitly enabled and Vista or 7 unless it's explicitly disabled.) In this article, Geoff Huston uncovers how surprisingly bad Teredo connectivity works in practice: it fails at least 37 percent of the time, and it's almost always a lot slower than regular IPv4 or IPv6 when it does work. The saving grace is that although Windows Vista and 7 have Teredo enabled out of the box, they are set up to avoid using it because Windows will ignore IPv6 addresses in the DNS if it only has Teredo.
Although Windows doesn't ignore IPv6 addresses in the DNS if it has 6to4 connectivity, it will prefer IPv4-to-IPv4 over 6to4-to-IPv6. A few point updates ago, Mac OS 10.6 was also changed to do the same. So these training wheels should be out of the way now and not end up between the spokes of the main IPv4 or IPv6 wheels.
In a presentation at the RIPE meeting last November, Tore Anderson explored some more subtle interactions between suboptimal DNS behavior and 6to4/Teredo, and between native IPv6 and 6to4/Teredo. The former has been addressed in Mac OS, Firefox, and Opera updates, so assuming everyone uses the latest versions of everything, the number of people experiencing problems on World IPv6 Day could be as low as 0.04 percent. We'll see.
The solutions
A very good way to see if your system will behave as it should come World IPv6 Day is to check RIPE's IPv6 eyechart. This page loads images from 42 sites that are currently dual stack and from 13 WIPv6D participants. If the image loads, a green badge is shown; if it doesn't load within a reasonable time, a red badge is shown. If everything is green, you're in the clear. If you have broken IPv6, you'll see the 42 dual stack sites in red. You may also see only a few in red in the case of localized problems.
If you see more than one or two red badges, you may want to consult ARIN's IPv6 wiki, which has a long list of potential problems with different hardware, software, operating systems, and ISPs. If you're on Windows, aquick and temporary fix is available on the Microsoft Support website. The fix consists of a small utility that makes the system prefer IPv4 over IPv6 until WIPv6D. Afterwards, the normal behavior of preferring IPv6 over IPv4 will be reinstated.
Because the eyechart page needs to be reachable for people who have broken IPv6, it only has IPv4, so it can't be used to get an overview of IPv6-only reachability. However, if you are running an IPv6-only (or dual stack) system, you can check ipv6.ipv6eyechart.ripe.net. Apparently, a few World IPv6 Day participants didn't want to wait, because some already turn up in green using only IPv6, while others aren't yet reachable over IPv6.
If all of this has inspired you to join the IPv6 fun, but your ISP doesn't offer IPv6 connectivity, the best way to move forward is by using a tunnel broker. These offer free one-to-one tunnels with much better reliability than the automatic tunneling systems. The disadvantage is that the tunnels need to be configured manually and often require the installation of drivers. If you have a static IPv4 address, Hurricane Electric's tunnelbroker.net is a good place to get a tunnel. SixXS also offers "anything in anything" tunnels that use UDP encapsulation to work better through NAT. These also dynamically discover the tunnel endpoints so a static IPv4 address isn't required.
Have a happy World IPv6 Day, and don't forget to report back to us if you encounter any problems.
No comments:
Post a Comment