The Internet has become a victim of its own success. This generalized, open approach for reliably transmitting large volumes of data across a widely distributed network of devices readily lends itself to a wide range of applications. From high‐value business transactions to the latest viral video, the Internet protocols continue to be used for increasingly diverse applications. When the Internet began in the early days of the Arpanet, only government and research computers were linked over the network. Today, business servers, home appliances, and mobile phones are connected to the Internet—and more devices are on the way. The demand to connect more devices to the Internet has presented a fundamental problem to network designers.
To appreciate the need for IPv6, it helps to understand a bit of engineering and history.
Fortunately, the Internet is a fairly young creation, so the history is appropriately short.
Each device on the Internet must be uniquely addressable. Obviously, when someone logs into an online banking service, their personal financial information should only go to the device they are using. The addressing elements of the Internet Protocol (IP) make this possible. In the simplest case, each device, such as a server or a laptop, is assigned a unique address. Unlike street addresses, though, it is not possible to keep creating new IP addresses ad infinitum. IP addresses have a fixed structure. In the case of IPv4 (the widely deployed IP version in use today), addresses consist of 4 octets, such as:
192.168.0.1
Each of the four octets can range, roughly, in value from 0 to 255 (actually some addresses are reserved and non‐routable, so they are not available for general use). Each octet can be stored by an 8‐bit number, which can represent a number from 0 to 255.
When IP was created, the protocol designers had to choose a range of addresses, known as the address space. At the time IPv4 was created, the designers chose to provide for a set of 232 or 4,294,967,296 possible addresses. Network designers could see the growth of the Internet would eventually exhaust the pool of possible IP addresses and began developing approaches to avoid running out of address space.
One approach was to conserve IP addresses by sharing. This idea became popular in the form of network address translation (NAT). With this solution, a set of devices on a private network can use NAT protocols to route network packets from the public Internet to the private network. With this method, a single (IP) address can be used by multiple devices. NAT has been widely adopted as a means to address the problem of IPv4 address exhaustion.
Figure 1: Network address translation was one method for delaying the exhaustion of the IPv4 address space.
Methods such as NAT helped reduce the demand for IPv4 addresses, but eventually the rate of demand for addresses exhausted the pool of available addresses. In February 2011, the last unallocated block if IPv4 addresses was allocated. The consequences were clear as noted by some of those responsible for managing the allocation of IP addresses:
'It's only a matter of time before the [Regional Internet Registry] RIRs and Internet Service Providers (ISPs) must start denying requests for IPv4 address space,' said Raúl Echeberría, Chairman of the Number Resource Organization, the umbrella organization of the five RIRs. 'Deploying IPv6 is now a requirement, not an option.'
Although this event is newsworthy, it was also expected:
'This is a major turning point in the on‐going development of the Internet,' said Rod Beckstrom, ICANN's President and Chief Executive Officer. 'No one was caught off guard by this. The Internet technical community has been planning for IPv4 depletion for some time. But it means the adoption of IPv6 is now of paramount importance, since it will allow the Internet to continue its amazing growth and foster the global innovation we've all come to expect.'
Perhaps the most significant contribution of IPv6 is a larger address space—and it is not just a factor of two or three bigger or even an order of magnitude bigger. The IPv6 address space is enormous. Whereas the addressable space of IPv4 was 232, the addressable space of IPv6 is 340,282,366,920,938,463,463,374,607,431,770,000,000 addresses. The enhanced address space is available because IPv6 addresses consist of eight hexadecimal numbers such as:
2001:db8:aaaa:bbbb:cccc:dddd:eeee:ffff
It is hard to imagine a scenario in which the address space would be exhausted without venturing into the realm of science fiction.
IPv6 implements a set of security protocols known as IP Security (IPSec) that reduces the risk of a variety of threats to Internet communications (IPSec can be implemented in IPv4 but it is not required as it is in IPv6). IPv6 security features include:
These features are similar to those provided by encryption protocols such as SSL and TSL, but they are built into the IPv6 protocol and are available to all communications over the protocol.
There are both positive and negative impacts of the IPv6 protocol. On the positive side, we can now support more addressable devices. For the foreseeable future, we will not have a problem with exhausting the IPv6 address space. We will not have to come up with clever engineering solutions, such as NAT, to minimize the assignment of IPv6 addresses. There are so many addresses available in IPv6, we can assign addresses to every server, desktop, laptop, mobile device, appliance, automobile, and other devices without risking running out of addresses.
The security enhancements in IPv6 over IPv4 will help mitigate the risk of spoofing and loss of confidential data. Spoofing can occur when an attacker successfully masquerades as someone else. With IP‐level encryption based on digital certificates and public key cryptography, the risk of spoofing is substantially mitigated. Data is transmitted in encrypted form, so even if an attacker were able to intercept communications, the attacker would be unable, without the decryption key or significant time, effort, and resources, to understand the contents.
There is, however, one significant drawback of IPv6, at least in the short run: the need for both the IPv4 and IPv6 protocols. The differences between IPv4 and IPv6 are substantial. Network software is different. Routing is different. Applications designed to use IPv4 may not function correctly on an IPv6 network.
Consider the simple case of a server application storing an IP address for a client device. The server makes a call to a programming language library to retrieve an IP address and then stores it in a 4‐octet data structure. This setup works well on an IPv4 network but will generate an error when the program attempts to store the 128‐bit address returned by an IPv6 network. Of course, this assumes the programming language library supports IPv6 and returns an address instead of generating an error.
One approach to migrating from IPv4 to IPv6 is to support both protocols. This method is known as the dual stack approach. As you might expect, it requires more time and effort to manage than a single protocol, so properly planning a transition to IPv6 is crucial.
Planning for IPv6 is a multifaceted task and one that we will explore in more detail later in this series. The following list summarizes key elements of the planning process:
Although the IPv6 transition is fundamentally a networking issue that most users will never see, it helps to start at the point end users do see: their applications. All business applications should be assessed with regards to support for IPv6. This is not a new protocol and software vendors have had time to plan for this transition. Are your enterprise applications capable of running reliably on IPv6? What about custom applications, especially the small, targeted applications that provide connections in the flow of information between systems? These may have been developed by in‐house developers and contractors who have left scant documentation. It is important to review not just the major enterprise applications but also those that move data between the enterprise applications.
As noted earlier, a common method for supporting both IPv4 and IPv6 is to use dual stacks. This setup requires two sets of network software installed and maintained on each client device. Both stacks will require memory and CPU resources. Newer desktops and laptops will often have sufficient memory and processor capacity. Devices near the end of their usable life may not be able to provide adequate performance if additional demands are placed on networking services. Assess end user infrastructure to identify devices that may need to be replaced or upgraded.
With a clear picture of applications requirements and device capabilities, you can prioritize application transition. How you prioritize is a matter of several factors, such as which applications can be migrated to IPv6 with the fewest hardware changes? Are strategic initiatives hampered by the overhead of NAT or other network management strategy designed to deal with IPv4 address exhaustion? You also need to consider network architecture issues. Changes to IPv6 will require changes to routing mechanisms, which in turn, have ripple effects on all devices on subnets as well as routing to external devices.
IPv6 is needed to sustain the growth of the Internet. In theory, we could continue to use IPv4 and work around the address space and security limitations of that protocol, but eventually, the cost of staying with IPv4 will outweigh the benefits. IPv6 eliminates concerns about address exhaustion while improving security. The transition to IPv6 will require planning and likely some degree of support for both protocols during the transition period. As noted by those responsible for managing Internet addresses, it is only a matter of time before IPv4 is no longer viable. Early planning will help ensure the transition is no more difficult than it need be.