Jeff’s Blog

I am a member of the Internet Engineering Task Force (IETF), and have been from very close to “the beginning” having attended over 50 meetings of the group. In the 1990’s the IETF developed what is now known as IPv6, the next generation of the Internet Protocol (the current generation is referred to as IPv4).

As early as 1988 (long before the Internet “boom”) members of the IETF recognized that the IPv4 architecture had fundamental limitations that would cause it to not be able to scale to a global scale network. Around 1991 the IETF started to address this with its Routing and Addressing Group (ROAD Group). The ROAD group went off to define the problem and look at solutions. One of the early papers was entitled “One Question, Three Problems, Seven Solutions” (I have been unable to find a copy of it on-line!). The “One Question” was something [I’m working from memory hear] like “Will the Internet Succeed?” meaning “Do we have to solve the three problems.” The paper answered this question by stating that it didn’t matter if the Internet succeeded or not, we had to solve the three problem, just in case…

The three problems were:

1. Running out of class “B” addresses (don’t worry if you don’t know what this means).
2. The Internet Routing Table was growing too rapidly for technology to keep up.
3. Running out of Internet Addresses in general.

The paper then went on to propose seven ways to address the three questions. Unfortunately there were seven ways, not one. One of the things that I have learned is that technical people (read, the kind of people at the IETF in the early 1990’s) have a hard time selecting between proposals of roughly equal merit. What ensued was an messy process that resulted in some proposals loosing support and other proposals merging until we finally wound up with what would become IPv6.

So how did IPv6 solve the three problems. Well for one thing it expanded the size of IP addresses from 32 bits (not enough for everyone to have one…) to 128 bits (enough to give one to every light switch on earth). It introduced the notion that people would not have their own IP address ranges, but would get a “sub-block” from their Internet Service Provider (ISP). This would keep the routing tables at the core of the Internet reasonably small because they would not have to have a route for every user and institution but instead only for each major ISP. But when an enterprise changed ISP, it would have to assign new addresses to all of its computers. So one of the key goals of IPv6 was to make this process easy (as opposed to be very hard under IPv4). Oh, and to encourage adoption of IPv6, the IETF made the security portions of the standard “mandatory” to implement so that the IPv6 networking world would in theory be more secure then the IPv4 world.

IPv6 was mostly completed by 1996 and made a “DRAFT” standard (which unlike its name implies, is a very stable IETF standard) in 1998. So where are we today…

Well, IPv6 hasn’t really taken off. It has been 9 years since it was declared a DRAFT standard, and yet deployment has been minuscule. Why is that?

There are several reasons:

1. IPv6 is not compatible with IPv4, there is no incremental upgrade path.
2. Other “hacks” have been deployed in the IPv4 network to extend its ability to scale, so there is no strong business driver.
3. To work all end-point computers need to support IPv6.
4. It is just harder to work with for people familiar with IPv4 technology. Some people may scoff at me when I say this…. but one of the problems is that you cannot “talk about” an IPv6 address and you can about an IPv4 address. Just the way we choose to represent addresses when we write them down and when we talk about them matters!

For example an IPv4 address might be 18.7.21.1. Whereas an IPv6 address is something like: fe80::20c:29ff:fe97:d844/64. You can say the former simply as “Eighteen dot seven dot twenty one dot one.” Go ahead, say the IPv6 address out loud!

Another failure has been provider based addressing (getting your addresses as a sub-block of your ISP). Easy re-numbering (say if you want to switch providers) has just never really come about. It is a hard problem! Finally, provider based addressing doesn’t solve the case of an institution connected to multiple ISPs (as is common for many enterprises in the 21^st century Internet).

But perhaps the two biggest reasons are the lack of business driver and the hacks done to preserve IPv4. One of the important properties of the hacks is that they have been incrementally deployable and in general they do not require changes on all of the end-point computers.

So what do we need to do?

Perhaps its is time to admit that IPv6 was too little too early… A new architecture is needed. For one thing we need a new layer of abstraction called “end point identifiers” which are addresses for devices that are independent of the routing layer of the Internet. They would remain constant even when an institution changes ISP. The addresses that would change would be quasi invisible, mapped by a protocol from an end-point identifier. This is not a new idea. Such concepts were discussed back in 1991, but were just too radical to make it into IPv6.

We also need to develop a new protocol that is incrementally deployable on today’s Internet. IPv6 required too much of a “fork lift” upgrade to be successful. Unfortunately I don’t have any easy answers on how to do this. I just know that we need to figure this one out. We need a “bridge” from today’s Internet to the Internet of the future.

Make no mistake, we will have to solve these problems. IPv4’s days are probably numbered (exactly what those numbers are is subject to debate) there will be a day when the hacks run out or fail and no new computers can be connected to the Internet. Will this result in a fork lift upgrade to IPv6… or to something newer and better…