At IETF 71 in Philadelphia, the IETF put the spotlight on the next generation of Internet addressing by switching off attendees’ access to IPv4 during its Wednesday plenary meeting. For an hour, Internet engineers could access the Internet only by using an IPv6 network; their machines had to connect to the network by using IPv6, and they could reach only other IPv6 Internet sites. The experience not only highlighted that IPv6 is a deployed reality; it also underscored the fact that there is a long way to go before there is as much content (and solid connectivity) as we are accustomed to in the predominantly IPv4-based Internet.
To fully appreciate the significance of the one-hour event, it is necessary to take a few steps back in time. IPv6 has been top of mind at IETF meeting plenaries for some time. As noted in Volume 3, Issue 2, of the IETF Journal, IPv6 was a predominant theme at IETF 69 in July 2007. At that meeting, the IAB and the IESG had a joint meeting to review the then current understanding of IPv6 deployment, impediments, and predictions. At the time, there were considerable speculation and debate concerning the various statistics being presented, which were intended to emphasize that IPv4 address allocations will change in nature in the upcoming years as the IANA free pool of IPv4 address space to allocate to the Regional Internet Registries runs out. By IETF 70 in November 2007, more-pointed questions were being asked at the plenary, such as, What can we do with or for IPv6?
IETF 71 IPv4 outage Wiki page
When the room is full of Internet engineers who would like to do something, this is not the sort of question that bears much discussion in the abstract. So, when Rohan Mahy leaned over during the IETF 70 plenary meeting and whispered, “Why don’t we just shut off IPv4 during the next plenary?” I instantly urged him to make that suggestion to the IETF chair. Russ Housley didn’t waste time: Upon confirmation of the technical feasibility of such an activity, Russ put the plan to the community in December. With that, people were given notice: An opportunity for community spirit was upon us; computers and/or home networks and resources should be readied.
The initial reaction to the plan was mixed, but it helped refine the parameters of the experiment. Wireless IPv6-only connectivity would be available (by choice) through the entire week, so that people could get prepared. The IPv4 outage would be limited to one hour, and it would be implemented only in the plenary room’s wireless coverage itself. The IETF meeting network crew is well versed in providing IPv6 connectivity, so it was clear from the outset that IPv6 networking would not be the challenge – beyond the usual need to plan carefully. Introducing network changes in the middle of an operational meeting requires planning and care. Instead, the biggest question mark was user reluctance. In many ways, this mirrors the state of IPv6 diffusion in the world today.
As planning was under way in the early months of the year, similar IPv6 events were announced and executed in other meetings (NANOG and APRICOT each had IPv6-only hours). The intended experience of the IETF event was different, as reflected in the choice not to provide IPv4/IPv6 protocol translation (NAT-PT). Stepping beyond questions of transition, the intent was to provide engineers with some firsthand experience in working with IPv6 in the wild. As Shane Kerr noted in his article on the IETF and IPv6 in IETF Journal Volume 3, Issue 2, “eating our own dog food” is the only way for Internet engineers to fully grasp and prioritize the range of issues that can and should be addressed in order to continue to support the practical deployment of IPv6.
The early announcement of the event clearly motivated several IETF attendees to prepare. While some IETF attendees use IPv6 on a regular basis, many do not, so the event was largely intended to target those engineers for whom this was going to be new ground. Some made sure their home networks and Internet resources were IPv6 capable in time for the event. Even some of the regular IPv6 users had surprises when they were attached to an IPv6-only network, such as problems associated with missing IPv6 DNS glue records for their domains.
The big news of the day was Google’s announcement – at the IETF meeting – of an IPv6-accessible site for its search engine (http://ipv6.google.com). In true IETF fashion, rumours were circulating in advance of the announce-ment, including detections of Google IPv6 routing announcements and DNS entries indicating that Google was up to something. The reality is that engineers at Google had been working hard to address both technical issues and skepticism, using the IETF event as a target for the delivery of an IPv6-accessible site. Google’s announcement in the plenary drew a round of appreciative applause from attendees. Lorenzo Colitti showcased the work as an illustration of what is possible with IPv6. According to Lorenzo, it hadn’t been difficult, since all of the necessary pieces were available, but it had required persistence. He urged other organisations not to be afraid and to press on with IPv6.
One of the biggest technical hurdles was known in advance of the IETF meeting; that is, that Windows XP does not (natively) support DNS resolution over IPv6. Since the IETF event was not providing NAT-PT, this slowed down a number of attendees: Windows XP users with IPv6 turned on could connect to other sites over the Internet – but only by manually entering the IPv6 address. Elwyn Davies, for one, was determined not to be stumped. Early in the week, he set out to run BIND on his Windows XP notebook to provide IPv6-capable DNS resolution for his notebook’s applications, but he soon discovered a bug in BIND. Fortunately, Mark Andrews of ISC was quickly able to provide an interim fix for the code. This is the sort of playful engineering that made the event fun as well as useful.
At its peak, about 190 computers were connected to the IPv6-only network during the IETF 71 IPv6-only hour, reaching out to a combined total of some 750 different global IPv6 addresses. Relatively few glitches were reported, though there were some challenges with global routing. This is not surprising, given that IPv6 deployment is still only as diffused as the very early days of the Internet.
IPv6 Wiki page
IETF 71 meeting host Comcast was also using the week as an opportunity to run IPv6-related networking experiments. Fully supportive of IPv6 deployment, Comcast’s Alain Durand is also focusing on transition issues and supporting large-access networks even as IPv4 addresses become scarcer. To that end, a separate network was available to those IETF attendees who knew where to find it in the form of a double-NATed IPv4-IPv6-IPv4 network; with that network, attendees could connect to it as an IPv4 network and access the rest of the IPv4 Internet (only). However, the packets were carried across an intervening IPv6 network, transparently to either end. The full model and motivation are provided in draft-durand-v6ops-natv4v6v4. The NATing from IPv4 to IPv6 and then back to IPv4 (the double NAT) may introduce issues for some types of applications. It could also potentially cause a reduction in network performance. This particular network’s availability was announced about 30 minutes into the IPv6 event, by which time folks who had not been able to get onto the IPv6 network for one reason or another were quite willing to test its performance.
In the end, response to the IPv6 event was quite positive. IETF attendees expressed enthusiasm for what they learned about IPv6 as well as interest in repeating the effort. During the Thursday technical plenary, suggestions were made to continue with having IPv6 events during future IETF plenaries or perhaps similarly showcasing other technologies in need of review and airing. As always, the challenge is to find a balance between providing a solid operational network, upon which the meetings and attendees depend, and providing an experimental environment in which engineers can play on real-scale networks.
No single one of these IPv6 events is going to cause an instant uptick in the amount of IPv6 activity on the Internet. However, such events are breaking down the barriers of fear, uncertainty, and doubt and enabling core Internet engineers and operators to discuss how to deploy IPv6 rather than questioning whether IPv6 is deployable. For the IETF, the value of this event will be seen in ongoing working group meetings, as more participants have their own firsthand IPv6 usage experience to draw on.