The push to IPv6 was driven at first by a concern that the supply of available IP addresses would soon run out, and the addressing scheme had to be changed to allow for more addresses. But, especially in the United States, this shortage was never realized. Most large enterprises have address blocks so big they have never felt any address crunch at all. Furthermore, CIDR (Classless Inter-Domain Routing), NAT (Network Address Translation) and similar technologies have helped ease the strain on IP addresses. And, not surprisingly, somebody soon came up with a clever workaround for the problem: NAPT (Network Address Port Translation) lets administrators hide 254 computers behind each globally routable IPv4 address.
IPv6 has some real advantages, however, and with the proliferation of globally routable IP-aware devices, such as cell phones, video-game consoles and PDAs, and accompanying demand for wireless Web access, migration to it is becoming a necessity. Concerns over the address crunch are rising again in Japan, other parts of Asia and Europe. In fact, the Japanese government has imposed a deadline for upgrading to IPv6 by 2005. And during the next five to 10 years, IPv6 will replace IPv4 as the most common Internet protocol. Your long-term IT strategy should account for this eventuality. Migrating to IPv6 will require a significant amount of learning, training and restructuring. In addition, your IT department will need a migration strategy that preserves backward compatibility with existing network applications and IPv4 nodes.
Finessing the Addressing Issues
The biggest advantage to using IPv6 is the increased address space. IPv4 addresses are 32 bits long, written as four groupings of 8 bits; IPv6 addresses are a whopping 128 bits, written in eight groupings of 16 bits.
Another positive is that you'll no longer need to memorize important internal IP addresses, because you simply won't be able to. The new IPv6 address will look like this: E2A4:C0FF:EE0B:EEF3:0924:00A3:0001:A3B5. Fortunately, leading zeros can be omitted, so this address can be compressed to E2A4:C0FF:EE0B:EEF3:924:A3:1:A3B5. It's an improvement, though not much of one. And IPv4 addresses can be expressed in IPv6 format easily. For example, in IPv6 "::10.1.1.5" describes the IPv4 address 10.1.1.5. You won't need to convert IP addresses from Base 10 (decimal) to Base 16 (hexidecimal). But be prepared to rely heavily on your DNS systems to make it easier to connect to internal hosts.
The American Registry for Internet Numbers (ARIN) says it is going to be more cautious handing out IPv6 addresses than InterNIC and other groups were with IP addresses. In the 1980s, organizations that required 257 addresses got a Class B network (65,536 entries). Because of this we have a lot of wasted space. Organizations don't want to return the unused space, because doing so would require reconfiguring and possibly renumbering their entire IP infrastructures. In addition, routers would need to be reconfigured to reflect the new addresses, hard-coded IP addresses would have to be changed, and network-monitoring software might not work.
IPv6 supporters are claiming renumbering will be simple because of a built-in autoconfiguration mechanism (RFC 2462). With IPv4, an address must be assigned manually or dictated by a BOOTP or DHCP server. However, without some form of intervention, a node cannot determine a unique, globally routable Internet address. In contrast, a device with an IPv6 stack can obtain a routable address automatically by combining its MAC (Media Access Control) address with a network prefix from the nearest router. Embedded systems and roaming devices can connect directly to the Internet with no user intervention.
If a company changes its network provider and needs to renumber, the machines will reconfigure themselves to the new address space. This sounds simple, but the reality in enterprise settings is more complicated. Routers need to be reset, subnets reallocated, and all hard-coded IPs changed. Licenses tied to IP addresses need to be updated or rekeyed, and firewall rules need to be updated.
Finally, there is a delay for DNS entries to be globally updated (including expiring caches). This can vary from a few hours to a couple of days or weeks. Renumbering will not be simple. The time it takes for renumbering could translate into millions of dollars in downtime and staff hours. Autoconfiguration will work fine for small- to medium-sized networks and for companies that depend on devices like cell phones.
Applications Are Key
Another hurdle slowing implementation of IPv6 concerns applications. There must be a solid base of supporting applications for it to flourish. Cisco Systems' IOS 12.2(2)T and Juniper Networks' Junos5.1 routers support IPv6. In addition, IPv6 stacks are available for operating systems from Apple Computer, FreeBSD, Linux, Microsoft and Sun Microsystems.
IPv6 has been finalized, but many proposed standards--including RIPng for IPv6 (2080), transmission of FDDI networks (2467) and IPv6 over IPv4 clouds (3056)--need approval. And many vendors do not offer full support for IPv6 yet.
In many cases, applications will need to be rewritten to handle the increased size of an IPv6 address. If a program's internal data structures have hard-coded the size of an IPv4 address, there won't be enough buffer space for an IPv6 address. Fixing this could be as simple as changing a single constant in a header file, but even this fix requires finding the source code and rewriting, recompiling, testing and distributing that code. And any program that does sanity checking by seeing if the data input fits the format x.x.x.x will need its parser rewritten. Recoding can be complex depending on the program and the development team's change-management policies.
Taking advantage of other IPv6 features, such as security or QoS, will require even more updating. There are a few brights spots. Undoubtedly, some products will be designed with dual IP stacks, one for IPv4 and another for IPv6. This is not a new concept. Sites have been running multiple stacks--for example, simultaneous IP and IPX stacks--for years. Each stack uses a unique IP address.
The IETF has designed DNS extensions to support IPv6. The new DNS record type "AAAA" denotes an IPv6 host. If a dual-stack host queries a DNS server and receives a 128-bit address back, it knows to use IPv6. Also, secure DNS and Dynamic DNS services are built into DNSv6.
However, dealing with DNS is still a bit messy in IPv6. Autoconfiguration does not support informing clients of preferred DNS servers. One solution is to let a client discover its IP address via autoconfig, then have the client query a DHCPv6 server for additional configuration information. Some Internet drafts allow for autoconfiguration of DNS.
Bridging Complexities
There are other complexities in bridging IPv6 networks to IPv4 networks. Networks not directly connected probably will require the use of the current Internet to communicate with each other. IPv6 networks on the Internet will have to encapsulate to get across IPv4, using methods such as those suggested in RFC 2529, RFC 3056 and RFC 3142.
For a while we will have isolated IPv6 networks sitting in a giant sea of IPv4. But at least in the beginning, this problem can be solved with IPv6-to-IPv4 tunneling. A dual-stack router sits at the edge of the IPv6 network and encapsulates the IPv6 packet inside an IPv4 packet. The data is then forwarded through the Internet, and "unencapsulated" on the other end.
In some ways, the stumbling blocks to IPv6 are as much political and social as they are technology-based. If this migration had taken place in 1970, it would have meant calling up 12 people to upgrade every node on the Internet. But times have changed.
For a while there was an official "IPv6 haters" mailing list. Consider the metric system and its adoption in this country if you need an example of Yankee-style resistance. If the world moves to IPv6 but North American-based companies stick with IPv4, migration issues will be an even bigger headache.
But until key applications become IPv6-aware, and Microsoft and Cisco release stable production IPv6 stacks, migration in the United States is likely to remain slow. Without that address crunch, we're just not that motivated.
Michael J. DeMaria is an associate technology editor based at Network Computing's Syracuse University's Real-World Labs®. Send your comments on this article to him at mdemaria@nwc.com.
RSS
