“If it ain’t broke, don’t fix it.” I consider this one of my favorite pieces of folk wisdom. I generally like to stick with what works, as do most people. And IP version 4 works pretty darned well. It’s been around for decades now and has survived the growth of the Internet from a small research network into a globe-spanning powerhouse. So, like a trusty older car that we’ve operated successfully for years, why should we replace it if it still gets the job done?

Like that older car, we could continue to use IPv4 for the foreseeable future. The question is: at what cost? An older car can be kept in good working order if you are willing to devote the time and money it takes to maintain and service it. However, it will still be limited in some of its capabilities. Its reliability may be suspect. It won’t have the latest features. With the exception of those who like to work on cars as a hobby, it eventually stops making sense to keep fixing up an older vehicle.

In some ways, this isn’t even that great of an analogy. Our highways aren’t all that much different than they were in the 1970s, and most other issues related to driving a car haven’t changed all that much in the last 25 years either. The choice of updating a vehicle or not is based on practical considerations more than necessity.

In contrast, look at what has happened to the computer and networking worlds in the last 25 years! Today’s handheld PCs can do more than the most powerful servers could back then. Networking technologies are 100 or even 1000 times as fast. The number of people connecting to the global Internet has increased by an even larger factor. And the ways that computers communicate have, in many cases, changed dramatically.

IPv4 could be considered in some ways like an older car that has been meticulously maintained and repaired over time. It gets the job done, but its age is starting to show. The main problem with IPv4 is its relatively small address space, a legacy of the decision to use only 32 bits for the IP address. Under the original “classful” addressing allocation scheme, we would have probably already run out of IPv4 addresses by now. Moving to classless addressing has helped postpone this, as have technologies like IP Network Address Translation (NAT) that allow privately-addressed hosts to access the Internet.

In the end, however, these represent patch jobs and imperfect repairs applied to keep the aging automobile that is IPv4 on the road. The core problem, the 32-bit address space that is too small for the current and future size of the Internet, can only be addressed by moving to a larger address space. This was the primary motivating factor in creating the next version of the Internet Protocol, IPv6.

IPv6 Standards

IPv6 represents the first major change to the Internet Protocol since IPv4 was formalized in 1981. For many years, its core operation was defined in a series of RFCs published in 1998, RFCs 2460 through 2467. The most notable of these are the main IPv6 standard, RFC 2460 (Internet Protocol, Version 6 (IPv6) Specification), and documents describing the two “helper” protocols for IPv6: RFC 2461, which describes the IPv6 Neighbor Discovery Protocol, and RFC 2463, which describes ICMP version 6 (ICMPv6) for IPv6.

In addition to these, two documents were also created in 1998 to discuss more about IP addressing: RFC 2373 (IP Version 6 Addressing Architecture) and RFC 2374 (An IPv6 Aggregatable Global Unicast Address Format). Due to changes in how IPv6 addressing was to be implemented, these were updated in 2003 by RFC 3513 (Internet Protocol Version 6 (IPv6) Addressing Architecture) and RFC 3587 (IPv6 Global Unicast Address Format).

Many other RFCs define more specifics of how IPv6 functions, and also describe IPv6-compatible versions of other TCP/IP protocols like DNS and DHCP. IPv6 is still very much a work in progress with new standards for it being proposed and adopted on a regular basis.

Design Goals of IPv6

The problem of addressing was the main motivation for creating IPv6. Unfortunately, this has caused many people to think that the address space expansion is the only change made in IP, which is definitely not the case. Since making a change to IP is such a big deal, it’s something done rarely. It made sense to correct not just the addressing issue but to update the protocol in a number of other respects as well, to ensure its viability. In fact, even the addressing changes in IPv6 go far beyond just adding more bits to IP address fields.

Some of the most important goals in designing IPv6 include:

• Larger Address Space: This is what we discussed earlier. IPv6 had to provide more addresses for the growing Internet.
• Better Management of Address Space: It was desired that IPv6 not only include more addresses, but a more capable way of dividing the address space and using the bits in each address.
• Elimination of “Addressing Kludges”: Technologies like NAT are effectively “kludges” that make up for the lack of address space in IPv4. IPv6 eliminates the need for NAT and similar workarounds, allowing every TCP/IP device to have a public address.
• Easier TCP/IP Administration: The designers of IPv6 hoped to resolve some of the current labor-intensive requirements of IPv4, such as the need to configure IP addresses. Even though tools like DHCP eliminate the need to manually configure many hosts, it only partially solves the problem.
• Modern Design For Routing: In contrast to IPv4, which was designed before we all had any idea what the modern Internet would be like, IPv6 was created specifically for efficient routing in our current Internet, and with the flexibility for the future.
• Better Support For Multicasting: Multicasting was an option under IPv4 from the start, but support for it has been slow in coming.
• Better Support For Security: IPv4 was designed at a time when security wasn’t much of an issue, because there were a relatively small number of networks on the internet, and their administrators often knew each other. Today, security on the public Internet is a big issue, and the future success of the Internet requires that security concerns be resolved.
• Better Support For Mobility: When IPv4 was created, there really was no concept of mobile IP devices. The problems associated with computers that move between networks led to the need for Mobile IP. IPv6 builds on Mobile IP and provides mobility support within IP itself.

IPv6: The Evolution of IP

At the same time that IPv6 was intended to address the issues above and many others with traditional IP, we should keep in mind that its changes are evolutionary, not revolutionary. During the many discussions in the IETF in the 1990s, there were some who said that while we were updating IP, perhaps we should make a complete, radical change to a new type of internetworking protocol completely. The end decision was not to do this, but to define a more capable version of the IP we’ve been using all along.

The reason for this is simple: IP, like our trusted older car, works. IPv6 represents an update that strives to add to the best characteristics of IPv4 rather than making everyone start over from scratch with something new and unproven. This design ensures that whatever pain may result from the change from IPv4 to IPv6 can be managed, and hopefully, minimized.