Our business case calculations and the common opinion that IPv6 has no business case are based on expectations and predictions. What we think will be happening in three to five years is what we base our judgments on.

If we look at history, though, we see that our capacity for accurate predictions is pretty limited. Back in the early 1980s, studies were conducted to determine the likelihood that in the future there would be a computer on every desk of an organization. The results showed that this was very unlikely. But only a few years later, a computer on every desk was a reality, and soon people often had not just one, but multiple computers.

In the early 1990s, studies showed that it was highly unlikely that everyone would soon have a cell phone. After all, the early versions were heavy and looked like sewing machines. Only a few years later, however, schools had to prevent students from using their cell phones during lectures and exams because they were using them to exchange results with each other. And at the same time, nobody spotted the business case for SMS (text messages). It was mainly a leftover from development, and it simply wasn’t removed from production. Yet, SMS hit the world, became widely used overnight, and today is making gigantic profits for many organizations.

So are we good at making predictions and determining business cases? Obviously not. Did someone foresee the emergence and success of Google, Skype, Facebook, and Twitter? Was there a careful business case defined before these technologies were developed? It seems that services can become very successful even if we haven’t thought about a business case beforehand; and in fact, had the developers tried to make a business case for the aforementioned technologies, they may well have arrived at the conclusion that there wasn’t one and opted not to deploy the service.

This is how evolution works. Technology and science are an expression of the evolution of human consciousness. And because this is a collective factor, it is highly unpredictable. In the 1920s, for instance, it was a huge problem that more and more people were starting to use horses for transport. Initially, only the rich could afford traveling by horse, but soon everyone was using them. Trend analysts predicted that mankind would soon drown in horse dung. This was a serious concern, and nobody could think of a useful answer to this problem. The solution came from a very unexpected angle. It was the invention of the car, and it revolutionized not only the transportation system, but also the whole industry. This example confirms Albert Einstein’s assertion that “no problem can be solved from the same level of consciousness that created it.” Now we face new problems that have emerged from the invention of the car, and just like with the horse dung dilemma, we don’t really know how to solve them. Chances are, the true solution will come from an unexpected evolutionary angle again.

For the car to be used widely, we needed better streets. Today we have an extended high-level street system in large parts of the world to enable transport for all the cars in use. Was there a business case for building all these streets? I guess nobody asked the question in this way; otherwise, we would probably not have our current street system.

Some creative developers designed IPv4 in the early 1970s. Their goal was to develop a protocol to connect a handful of computers. They managed to create a protocol that is the basic transport for our gigantic modern-day Internet (approximately 2 billion users in 2011, growing exponentially; up from 360 million in 2001). But these developers did not have anything like the Internet in mind. There was no business plan and no business case for the Internet. It just happened during the 1990s; the world picked it up and started using it on a widespread scale, from online ecommerce in the mid-1990s to today’s social networking and cloud services. And the IETF (Internet Engineering Task Force) responded to the market demand and developed all the extensions to IPv4 that we currently use.

And by the way, don’t think this is the end—evolution is also never-ending. For example, Vint Cerf, the “father of the Internet,” and one of the guys who developed IPv4 in those early days, is now working on standardizing the Interplanetary Communication protocol based on the Bundle Protocol (RFC 5050); first implementations are currently available and tests are being run. So, while we may think this sounds crazy because we’re focused on planetary issues like danger from atomic power, natural catastrophes, wars, and financial crisis, some visionaries are working on the future— with no business case, but fueled by evolutionary impulses.

The Internet has definitely reshaped our world, changed the way we communicate, impacted the way we approach business and education, broken down hierarchies, and established an important ingredient for globalization. It happened because we all jumped on the bandwagon, saw it as a useful tool, and started investing and participating in building and extending it. It is a global collective collaboration.

So what is the business case for IPv6? If you want, we can put it like this:

Without the introduction of IPv6, the Internet cannot continue to grow now that the IPv4 address space is definitely exhausted. This means that everyone who uses and profits from the Internet has to do his part in helping integrate IPv6. Integration too will have to be a global collective collaboration. For some corporate cultures, this might be a sufficient business case.

But let’s go on and analyze the business case question in detail in a more practical context.

Corporations and organizations have maintained networks for many years. When we started maintaining them, mostly in the early 1990s, the networks were small and few were the tools we had available to manage them. Soon the number of network devices and the variety of network services were growing exponentially. At the same time, the requirements for management, administration, and security were increasing. When we started designing our IPv4-based networks, we did not have a real understanding of what lay ahead. But we learned while growing the networks and whenever we faced new challenges, we finally found solutions; and when public demand became obvious, the IETF developed all the useful extensions to the IPv4 protocol, such as DNS, DHCP, IPSec, and NAT.

With regard to the business case, we can say that the evolution, extension, and optimization of our network infrastructure always came at a cost. In other words, evolving our network has always been part of our returning budget—costs used to maintain a state-of-the-art infrastructure capable of running state-of-the-art services. We have to extend our infrastructure for more bandwidth constantly, as the services running on top continue to consume more bandwidth. We have to replace network devices in regular cycles, and when it comes to replacing core routers, this is usually a substantial cost factor. We also have to invest a lot into securing our networks and providing an infrastructure that can accommodate the demands of mobile users. And we constantly upgrade operating systems to newer versions, such as the currently ongoing migration from Windows Server 2003 to Windows Server 2008.

Do all these investments have a business case? What is the business case in upgrading a core router? What is the business case in upgrading a server operating system? Both do their job—they route or run services—so why should we invest in upgrading them?

The business case is not in the router or in the operating system. But we know that if we don’t upgrade to a current version, the devices or operating systems will perform poorly or fail at some point, or we won’t be able to run new services on top of them. This is a common case for Windows servers; Microsoft does a good job of keeping us all busy with constant upgrades by developing services and applications that don’t run on older infrastructures.

Prudent investments in networking and other infrastructure are not just an expense—they often result in improved capabilities and a foundation for future innovation. Public cost of network capacity per megabit has continued to drop over time, enabling new services such as broadband video and distributed high-performance computing. And another important point to note is that all these investments can only make sense when viewed with a perspective longer than just six months or a year.

Likewise, IPv6 is not an application or a service that needs a business case. It is part of our infrastructure, it is the highway over which we can run our services, just as routers are part of that highway. So the introduction of IPv6 is the next natural step in evolving our infrastructure to be compatible with new services. And I guarantee that applications and services will be developed that will run only on an IPv6 network, because they use new features of the protocol that cannot be run on an IPv4 network. Microsoft has already started that trend by delivering DirectAccess as part of a Windows 7 license, which provides VPN functionality at no extra cost but uses IPv6 exclusively.

So the business case is not in IPv6, the business case is in applications and services that will soon require IPv6, or need so many IP addresses that IPv4 can’t handle them anymore. And by the way, don’t wait until your customers ask for IPv6, because they probably never will. They will ask for services, and those services might just happen to require an IPv6 infrastructure. Or your CEO may suddenly ask for a new and cool ecommerce application, or a new collaboration tool that happens to use IPv6 features—and he’ll probably want it implemented in three months.

Integrating IPv6 under time pressure creates many disadvantages. High costs and unnecessary risks are the consequences. You lose the opportunity to learn as you go, to carefully plan, evaluate and test. By integrating IPv6 you lay the foundation for your next generation network. Take your time to do it carefully. By delaying the adoption of IPv6 for too long, you are putting your company’s competitiveness at risk.

The integration of IPv6 in a more complex network can take three to five years if you want to do it in a risk-free and digestible way, with enough time to carefully build, secure, and manage a robust network and educate your team before that network encounters critical user traffic. You shouldn’t wait until your customer or your CEO asks for these IPv6 applications.

There are also several sound, leading indicators that IPv6 is part of our future, specifically in the areas of standards that require IPv6 for the delivery of new services. Based on the industry-developed standards, new services are starting to emerge in the areas of content delivery, mobility, and industrial networking.

IPv6 is enabled on the computers we are buying and the services we will depend on. There may be no immediate return on investment (ROI) for your organization, but failure to act now may leave some organizations in the land of yesterday, unable to compete or operate efficiently going forward.

We can turn the business case question around and ask: what do we lose if we don’t invest in and plan for IPv6?

For long-term business planning, it’s important to note that any investment in IPv4 is an investment in an end-of-life technology and must be migrated at some point. An investment in IPv6 is an investment in future technology. And yes, in the beginning it is more difficult, because we have to build knowledge and experience, but we’ll eventually have to do this anyway. So why not start today?

It is still a widely held perception that there is no immediate pressure to migrate to IPv6. There’s also a persistent misbelief that if you have enough IPv4 addresses for your corporate devices, you don’t need to integrate IPv6, even as of February 3, 2011, the date on which the depletion of the global IANA IPv4 address pool was announced.

So let’s look at the situations that can create time pressure for you. Anticipating these situations will help you plan your integration accordingly so you can avoid having to deploy IPv6 without adequate preparation.

The first two items in this list (lack of IPv4 addresses, and customer or corporate demand) are not really predictable, so your best option is to prepare for IPv6 anyway so you will be ready when the time comes. Before you can actually deploy IPv6, you need to allow for a long planning phase, so my recommendation is to get that done as soon as possible. During planning, you will get a good picture of what’s required for the different parts of your network, so you can define milestones and timelines for deployment. The moment when you really need IPv6 might be different for different parts of your network, so it’s important to have a clear picture of what integration involves. You can easily resolve the risks associated with the fourth item (IPv6 currently running on your network) if you understand how IPv6 works and can make a few simple configuration adjustments.

When you’re working on a high-level implementation plan (discussed in Chapter 2) and determining the order of the steps to complete, it’s important to consider what other IT projects are planned for the next three to five years.

When I ask customers this question, I often get answers such as:

If you run all these projects without considering IPv6, you’re wasting a lot of money. If you move your data center without accounting for IPv6, you will probably touch it all again soon after. If you evaluate new core routers without clear requirements for IPv6 support, you may choose a model that will not support your IPv6 integration optimally. Because a router is a high-end IPv4-optimized router and costs a lot of money doesn’t mean it is also a high-end IPv6 router with all the features you need. Asking for IPv6 support for a core router is not sufficient; you have to be much more specific about what features are required to support your transition plan. And to be able to be more specific, you need a high-level implementation plan. The same is true for security devices such as firewalls or intrusion-detection systems. Most customers’ core router environment has a life cycle of more than five years. If you buy new core routers next year, chances are really low that you won’t have to enable IPv6 during their lifetime.

If you redesign your DMZ without understanding how you will design security for a dual-stack network, you may find later that you would have done it differently had you known about the requirements for IPv6. So, again, you can save money if you consider IPv6 right from the beginning. The same rule goes for all other possible projects on this list, such as introducing Windows 7, Windows Server 2008, or any other service.

When it comes to introducing a completely new service, such as VoIP, you must ask another important question: is it possible to integrate this new service as IPv6-only right from the beginning? If the answer is yes—and it could be, in the example of VoIP—this has several advantages. One is that if you go the IPv6-only route right from the beginning, you don’t have to touch it again in this regard. It runs on the future technology. Why spend time on testing and implementing it with IPv4 if you can afford to go IPv6-only right away? The other advantage is that it may free up or save IPv4 addresses that you might need for other purposes or in the event that you run out of your internal IPv4 address space.

Your opportunity to save money with your IPv6 integration lies in aligning it with other IT projects, with your regular product life cycles and in considering IPv6 in all your vendor and product evaluations and vendor and supplier contracts. So turn on IPv6 in your head, and whatever you do in your network from this point forward, do it with IPv6 integration in mind.

I have one very important recommendation with respect to outsourcing contracts. If you sign an outsourcing contract that will run for 5 or even 10 years, you’d better make sure to address the IPv6 support question. Having your high-level implementation plan worked out already will be an important part of requesting the specific IPv6 support you need and will help you define the right SLAs (service-level agreements) for IPv6.

Companies that outsource everything tend to think that they don’t need to care because it’s their supplier’s job. But you may want to make sure that the supplier is aware of the situation and has a roadmap that meets your needs. He needs to understand the requirements coming from the public space with IPv6-only users on the Internet. He should also be able to provide your public services as dual-stack services with a good IPv4 and IPv6 performance, and also be aware of the requirements for any applications you might introduce that need IPv6 support in the internal network. Failing to do so can severely limit your services or create high-cost and high-risk transitions. And for sure, if you want to add IPv6 services during the lifetime of the contract, it’ll cost a lot more than if you include it right from the beginning.