The Need for More

Chapter 5, "The Date of Doom," looked at many of the reasons that motivated the development of IPv6 and the incredibly successful stopgap tools. Remember, these stopgaps were intended solely to buy enough time for the IPv4 address space for IPv6 to be developed. The motivating factor was the impending depletion of the Class B address space. A "Date of Doom" was projectedthe date on which the Internet would no longer be able to service the needs of many of its users because its address architecture proved to be less scalable than the Internet itself. The good news is that the scare tactic worked: The Internet's technical and engineering communities rallied and drew up a two-pronged battle plan. One group would be dedicated to solving the problem long-term. Another would focus on short-term tactical efforts to shore up the old protocol, buying some time for the long-term solution to be developed and implemented.

You have already seen some of the fruits of this labor. CIDR, DHCP, private addresses, and NAT are just some of the more-familiar patches applied to IPv4 to buy time for IPv6 to take shape. Other efforts included mundane things such as more-prudent husbandry of the remaining unallocated address spaces. Together, these stopgap efforts were so successful that the need for IPv6 has become the subject of great debate! However, fairness requires that we examine the progress made by the long-term teams rather than just summarizing the successes of the stopgap efforts.

When reviewing this brief summary, remember that IPv4 grew out of a relatively simple protocol suite that was designed for much simpler days. Its problems were the direct result of exponential growth in both scope and the number and types of applications that were designed specifically for use in IP networks. You shouldn't be surprised that IPv4 is showing its age; rather, you should be delighted at how well it has held up in the face of the Internet's explosive growth.

Solving the Long-Term Problem

The engineers focused on the long-term problem called their team IPng for IP, next generation. I guess there were a few Trekkies on the team! These engineers realized that they were given a golden opportunity. By taking a broader view of the problem, they could solve all of IPv4's shortcomings rather than just finding a way to build a more-scalable address architecture for the existing Internet Protocol suite.

The perceived problems with IPv4 included the following:

• A limited address hierarchy, which had an increasingly negative effect on routing efficiency and the size of the Internet's routing tables.

• A relatively small address size, compounded by a grossly inefficient (but mathematically logical) size-based classification system. Although the overall size of the IPv4 address space might have been large enough to service the world's connectivity needs indefinitely, the way it was carved up, allocated, and used actually wasted large numbers of addresses. Thus, the general perception is that the IPv4 address space was too small.

• Numerous functional limitations, including lack of native support for mobility, and performance requirements of specific applications. Mobile computing was starting to mature, as were applications that were highly sensitive to network delaysnone of which IPv4 could easily support.

The crew that developed all of IPv6's myriad components thought through every shortcoming and saw to it that the new protocol was the answer to all their problems and concerns.

NOTE

As you read through this chapter, you'll notice that the proposed replacement to IPv4 was IPv6. You might wonder whatever happened to IPv5. The answer is not at all obvious. IPv5 was assigned by the IETF to an experimental streaming protocol known as ST-II. ST-II never really got off the ground, and the IETF decided to simply retire the IPv5 designation rather than creating potential for confusion by reusing it to describe another protocol.

Barriers to Acceptance

Having established both the motives and the need for updating the Internet Protocol, it is imperative that we look at what might be slowing its acceptance. Because IPv6 is so radically different from IPv4, upgrading requires far more than just loading a software patch snarfed from the Net. The upgrade process can only be described as a migration, because many different elements must be moved, and that movement might take months or years to complete.

Technological migration of any sort must be worth the pain and effort required. Otherwise, the market has demonstrated time and again that the migration won't be undertaken. Examples within the narrow and specific field of telecommunications and data networking yield a plethora of evidence to back up this claim. For example, ISDN simmered for yearsa classic example of a solution in search of a need. Similarly, ATM as a local-area network technology enjoyed tremendous publicity in trade magazines and the like, but ultimately it failed because backward compatibility was a joke, and the market decided that migrating didn't bring enough reward to warrant the cost and risk.

The architects of IPv6 understood this implicitly. It is very easy to see how they bent over backward to make the new protocol as backward-compatible as possible. They took even greater pains to ensure that an entire suite of transition tools was available that would mitigate the difficulties of migrating from IPv4 to IPv6. As we examine IPv6's address hierarchy, special attention will be paid to the mechanisms specifically designed to mitigate the pain of migration.