Add a Comment Now - We Want to Hear From You
By Dr. Cathy Fulton
In the beginning, Al Gore created the Internet. (Okay, I have to be fair, Vint Cerf has given Al Gore a lot of credit for his work in government.)
IP version 4 was created back in 1981, and in August of 1990, at an IETF meeting, three individuals predicted that the IPv4 Class B address space would be consumed as early as March of 1994, the “date of doom,” and that would cause all sorts of issues.
That stimulated a lot of publicity and action, on how the address space seed shortage would be handled. A working group was formed in December 1993 that published a request for whitepapers asking for solutions to the IPv4 problem – including next-generation IP protocols.
They were so worried, however, that they would run out so quickly, that they believed there would be no time for new features. The ALE working group was tasked with determining how long they had before the Internet collapsed, due to routers unable to keep up with the increased routing tables. Could next-gen IP add new features, or did they just have to implement an emergency measure?
The working group came back with an estimate in 1994, and said that the collapse of the net would be somewhere between 2005 and 2011. That gave the IETF time to develop a full protocol, add new features, and figure out where they were going next.
In 1994, technical criteria by which the IP next generation protocol would be judged were introduced. The current specification was proposed in 1998, and is now a draft standard – one step away from full Internet standard.
So, where’s IPv5?
(Continued...)
IPv5 was a streaming protocol – still with experimental status. IPv7, IPv8, and IPv9 all pre-date IPv6. There was a second release of that IPv5 protocol and others assumed that it was going to be assigned IPv6 – so they started working with the next version protocol, IPv7. IPv8 was merged with SIP to become SIPP, the basis for IPv6.
Allow me to explain.
In the original whitepaper outlining the protocols, the IETF called for scalability to 10^12 nodes – that would have taken you to a 40 bit address space. IPv4 uses 32 bits. They thought that adding another byte would have solved the problem.
Anyway, they decided to add some features to encourage people already on IPv4 to transition. They published that RFC, and only 21 whitepapers were received. Considering that this is a request for ideas on what the next IP protocol should be – that’s huge - and you only need a whitepaper a reasonable 10 pages in length, it’s surprising that there were so few whitepapers submitted.
In December of 1994, another RFC was published, this one with a list of technical criteria. There were two guiding principles: Improve scalability, both in terms of address space and in terms of routing, and encourage users to make the switch by focusing on easy transition and new features. What was happening was that routing tables for backbone internet routers were growing at 1.5 times the rate that the amount of memory was increasing, so the IETF knew they had a problem. They also knew it had to scale to handle increased bandwidth that they expected in the future. They also wanted something that had features encouraging people to switch from IPv4 to the next-gen IP protocol – and it needed to be easy to do so.
There were five general principles they issued, among them archectectural simplicity and “live long and prosper.” They wanted the next IP protocol to last a long time – ideally 20 years – and encourage new technologies and applications. Technical criteria also required support for at least 10^12 nodes.
They figured there would be about 10^10 people on the globe. Then they figured that each person should get their own network – not just their own IP – so they came up with 10^12, or two extra orders of magnitude for safety. This again only required adding one byte onto IPv4’s four byte address.
In response to the RFC, the IETF received seven proposals for the next generation IP protocol. Of those seven, three of them merged, leaving five proposals. Of those five, one was mentioned in name only, another was mentioned as a research project – neither one, it seems, was really considered a serious candidate.
So the three remaining protocols became IPv7, IPv8, and IPv9. IPv7 was later nicknamed CATNIP and rejected because it was considered an incomplete specification. IPv9, or TUBA, was arguably the best – but the fundamental objection to TUBA was that it wasn’t based on an IETF standard but an ISO standard called CLNP, and the IETF was concerned that they would not be able to modify it without the approval of the ISO – rejected because of politics, not the protocol itself.
SIPP, or IPv8, was rejected because it used a 64-bit extendable address. Keep in mind, 10^12 – the requirement of the protocol – is only 40 bits. However, it was this extension that made the IETF committee uncomfortable because there was not extensive experience in handling extendable addresses. Fundamentally, though, they thought 64-bits was not enough – and when IPv8 was revised to include a fixed 128-bit address, it was accepted and because there was an existing “blank space” in the organizational numbers, IPv8 became IPv6.
The current draft standard version of IPv6, RFC 2460, was written in December, 1998.
Dr. Cathy Fulton is CTO of NetQoS.
