By: Shane Kerr
One of the common themes within the IETF community is that the IETF has not done enough either to encourage adoption of IPv6 or to make the technology useful. While it may be true that IPv6 has problems, the assumptions about support from the IETF are wrong.
Until a few years ago, when Geo? Huston started publishing his analyses, estimates of when we could expect to see the last unallocated IPv4 address were quite vague. Geoff’s research indicates that the unallocated address pool will be exhausted in the next few years. His arguments are compelling, and his estimates have been widely accepted. By contrast, folks in the Regional Internet Registry (RIR) community usually choose a date far in the future-a strategy intended to build trust in the current IP allocation regime.
Under the current IPv4 allocation regime, when new addresses are needed they get allocated from an unallocated part of the address space. Once the entire address space has been allocated, the process will need to change. As awareness of the need for change grows, the group of people who are thinking about the implications of a depleted IPv4 address pool has become larger and more diverse. This is not surprising: the Internet is important, and the e?ects of running out of IPv4 addresses could be wide reaching. Also as a result, those who have long been following the development of IPv6 are repeating their observations, either as complaints or as encouragement.
As people begin learning about IPv6, it’s natural for them to ask questions. As IPv4 address space moves closer to exhaustion, lack of wide-spread IPv6 adoption begins to look more and more like a problem. There are genuine concerns about the technology-for example, that IPv6 autocon?guration wastes half of the address space. Some of the concerns are valid; others are not. In this environment, however, even questions can seem like criticisms.
Early Days and Design Decisions
Note: There are a number of resources on the Internet that cover the early history of IPv6. Google is your friend if you’re interested.
From its beginning, IPv6 was the creation of a group of talented engineers who were working in a difficult area: attempting to design a protocol for an unknown future.
It has been nearly 20 years since the IETF began considering the problem of IPv4 address exhaustion.See the Running out of Internet addresses?. Serious work on ways to deal with the problem began more than 15 years ago. While the Internet was certainly successful at the time, it was still used mostly by technical professionals. Identifying the “end of life” for IPv4 was the first in a long series of issues identified and dealt with by the engineers working in the IETF.
Several new technologies, ranging from minor tweaks of IPv4 to completely new approaches to addressing and routing, were proposed to deal with the problem. Following the usual IETF process, a number of decisions were made in those early days. For instance:
- There would be no “?ag days” to switch from one protocol to the next.
- A longer, but still fixed-length, address would be required.
- Addresses would continue to be used in a hierarchy.
- Routing would be basically the same..
Other components were added to IPv6, such as multiple addresses per interface, address autocon?guration, and multicast support. This is understandable, considering the prevailing assumption that IPv6 would be the “?nal” version of IP-at least for the lifetime of the people designing it. There was an effort to limit the number of changes and additions, but many made it in.For any given decision, you can argue that it was the wrong one. For any given feature, you can argue that it is unnecessary or poorly specified. People did then! That doesn’t mean that IPv6 as a whole is poorly designed, however, or that it fails to meet the goals set out for it.
Transition Plans and Tools
The core IPv6 protocol was defined in 1995. Even before that, a lot of thought had been given to how the Internet would switch from using IPv4 to using IPv6. Shortly after the IPv6 protocol became an RFC, other RFCs were published that documented ideas and tools to help with the transition. The engineers who designed and implemented IPv6 knew that real-world network administrators would still have to change their networks and that advice and tools that would make the work easier were essential. The ng-trans working group was created as a place to work on those technologies as well as to coordinate with the 6bone project (more on the 6bone later).
At the time, and as it is today, it was understood that there is no one-size-?ts-all method for converting to IPv6. Every network is unique, and each would experience different problems in an e?ort to migrate to IPv6. So more than one idea was explored, and each was documented. If you look at the old ngtrans page, See Next Generation Transition (ngtrans) – you will see that there are quite a few RFCs on the subject, some of which cover multiple scenarios.
From one point of view, the ngtrans working group was unsuccessful; IPv6 is not widely used, and it certainly has not replaced IPv4. On the other hand, the working group did meet its stated goals. There are now a number of defined mechanisms that are useful in implementing IPv6 networks.
Even today, though, nobody knows how IPv6 will actually get adopted, nor does anyone know what it will look like when it does. Ten years ago, I was told that IPv6 would arrive from the edges and move in. Now I hear it will arrive at the core and move to the edges.
Rather than being negligent, the engineers within the IETF actually did the best thing possible, which is to consider IPv6 transition in many different environments, some of which would turn out to be used infrequently. There was no way to know which of these environments would be the most common, so extra e?ort was spent to try to cover them all.
IETFTM Brand Dog Food
When a company uses the product it makes, that phenomenon is sometimes called eating your own dog food. The IETF is mainly a standards-making organisation, not a product development company or a network operations company. However, the IETF does have computers on the Internet. And thousands of people attend IETF meetings. And the IETF has always made some e?ort to use the standards it develops, including the IPv6 standards.
Using IPv6 at IETF meetings has not always been painless. At many past IETF meetings, I had to disable IPv6 connectivity on my computer because the routing went through such a poorly connected system of IPv6 tunnels that it was basically unusable. Nevertheless, this is exactly the kind of operational experience that results in useful information.
As the field has grown explosively, specialisation has set in, and market pressures have risen, there has been less and less operator participation in the IETF,” Harald Alvestrand noted back in 2003: IESG proposed statement on the IETF mission
A long-standing complaint about the IETF is that there is not enough operator participation. Whether this is true or not, the IETF has tried to get some of its own experience, at least in recent years. The IETF has not always been a first adopter (as recently as two years ago, the IETF servers were not IPv6 reachable – See IETF servers aren’t for testing thread – but it’s often an early adopter).
Shortly after the first IPv6 RFCs were published, a group of engineers created a test bed network called the 6bone. While the 6bone was not an IETF project, many of the 6bone participants were also active in the IETF, and there are RFCs that document the address allocation and operation of the network. Originally started to test standards and implementations, the 6bone evolved into a test bed for operations and, finally, into an almost-production-quality network (See RFC 2772).
The end of the 6bone, on 06-06-2006, is a sign of its success. An Internet-wide IPv6 test network is no longer needed, as IPv6 is used more widely on the “real” Internet now than it ever was on the 6bone.
Even before IPv6 appeared for the first time on the Internet, the IETF was coordinating with the Internet Assigned Numbers Authority (IANA) and with the RIRs.The IANA maintains not only a number of registries that are necessary for IPv6 to function, including the address space registry itself, but also other IPv6-related information, such as DHCPv6 option codes or ICMPv6 parameters. Most of the interaction between the IETF and the IANA is straightforward, because the IANA is an administrative body and able to implement the recommendations of the IETF when appropriate.
Coordination with the RIRs is more complex, as each RIR has its own policies and methods for updating policies. In many ways, working with an RIR is similar to working with the IETF. Discussions occur on open mailing lists, and consensus is generally required for decisions to be made. This means that the policies are bottom-up and that they reflect the requirements of the network operator community. But creating new policies or changing existing policies is difficult in this environment; it requires considerable education, on the part of both the IETF and the RIR communities. The IETF and the RIRs worked closely together during the development of the first IPv6 policies to ensure that the technical requirements were met. The RIRs have all had working IPv6 policies for years now. Coordination between the operator communities and the IETF is still important, but it now follows the regional RIR policy development procedures.
The IETF has done a lot to make it easier for the people using the Internet to adopt IPv6. The IETF mission is to produce documents (see RFC 3935), and from this point of view, the IETF has done exactly what it should.
Documents will not by themselves cause people to adopt IPv6. Software must be developed, networks built, users educated, and policies updated. At the end, IPv6 adoption is largely a business decision, and money saved by using IPv6 may motivate the work. These activities often depend on the documents the IETF produces, but they are outside the IETF mission. Individuals in the IETF and the organisations they work for can do a lot to encourage IPv6 adoption outside the scope of the IETF.
New standards are being produced to create and extend protocols, and recommendations are made for developers, users, and operators, and these should not try to duplicate the work already done. Remember the work that has already been done when considering what the IETF can do for IPv6.