Finding your way through the new IP A primer, Network World, 12/16/96. A transition checklist What to consider before making the move. IPv6 home page Includes details of the activities of the IPng Transition Working Group. RFC 1933, Transition Mechanisms for IPv6 Hosts and Routers, defines some terms you'll need to know to get your nodes straight: IPv4-only node: A host or router that implements only IPv4. An IPv4-only node does not understand IPv6. The current installed base of IPv4 hosts and routers are IPv4-only nodes. IPv6/IPv4 node: A host or router that implements both IPv4 and IPv6. IPv6-only node: A host or router that implements IPv6, but not IPv4. IPv6 node: Any host or router that implements IPv6. IPv6/IPv4 and IPv6-only nodes are both IPv6 nodes. IPv4 node: Any host or router that implements IPv4. IPv6/IPv4 and IPv4-only nodes are both IPv4 nodes. Miller is president of DigiNet Corp., a Denver-based data communications engineering firm. He has written 11 books on internetwork design and analysis, including Troubleshooting TCP/IP and Analyzing Broadband Networks, and last fall he led a Network World Technical Seminar entitled IPv6 - the Next Generation for TCP/IP internetworks. Miller may be reached at mark@ diginet.com.

By Mark Miller
Network World, 1/20/97

It's a new year - complete with personal resolutions, fresh calendars and replenished budgets. And the protocol world is recharged, as well, with IPv6 poised to launch into the internetworking marketplace.

Moving to Internet Protocol Version 6 will provide greatly expanded addressing capabilities, plus a number of protocol enhancements, including automatic node configuration, support for real-time traffic flows, authentication, encryption and others (NW, Dec. 16, 1996, page 43).

But taking advantage of those features will require some careful planning, as the capabilities - and complexities - of the new protocol greatly exceed those of the current IPv4. Net managers that don't chart a course from the present to the future may feel as if they have hit the fast-forward button and ended up in the next millenium.

Most internetworks are heterogeneous systems, with routers, hosts and other equipment from different vendors, each of which will follow different timetables for the enhancements to their products. If all parts of such a multivendor system were to be upgraded at one time, IPv6 capabilities would be required on all of the individual elements before the larger project could be attempted. That, in the minds of most net managers, would be the cutover to end all cutovers.

Another, and much larger issue is the Internet, which operates across 24 different time zones. Upgrading this system in a single step would be even more difficult, if not impossible.

The developers of IPv6 recognized these issues and acknowledged that not everyone would upgrade from IPv4 to IPv6 in the immediate future - some may not do it for years to come, or possibly never. With that in mind, the Internet Engineering Task Force (IETF) laid the transition groundwork, with several request for comment (RFC) documents that detail the tools and techniques available to make the transition as painless as possible.

Building for the future

• Incremental upgrade. Existing IPv4 hosts may be upgraded at any time without a dependency on other hosts or routers being upgraded.
• Incremental deployment. New IPv6 hosts and routers can be installed at any time without any prerequisites.
• Easy addressing: When IPv4 hosts or routers are upgraded to IPv6, they may continue to use their existing address. They do not need to have new addresses assigned.
• Low start-up costs. Little or no preparation work is needed in order to upgrade existing IPv4 systems to IPv6, or to deploy new IPv6 systems.

The operative words here are existing and incremental - take what you have now, and upgrade it to the new version as logic dictates. To aid in that process, two mechanisms have been designed: dual stacks and tunneling.

A dual approach

The simplest mechanism for IPv4 and IPv6 coexistence is for both of the protocol stacks to be implemented on the same device. That device, which could be either a host or a router, is then referred to as an IPv6/IPv4 node. Such a node has the capability to send and receive both IPv4 and IPv6 packets, and can, therefore, interoperate with nodes of either type in their native format.

The IPv6/IPv4 node would be configured with addresses that support both protocols - a 32-bit address or addresses for IPv4 functions, and a 128-bit address or addresses for the IPv6 functions. Other address-related functions, such as the Dynamic Host Configuration Protocol (DHCP), the BOOTP Protocol and the Domain Name System (DNS) that provide address lookup, configuration and distribution, may also require changes. Naturally, any protocols supporting the IPv6 side of the equation, such as DNS, would have to be upgraded to handle the larger IPv6 addresses. Current IETF documents describe the protocol updates that are required.

Tunneling to a new land

The tunneling process involves three distinct steps: encapsulation, decapsulation and tunnel management. At the encapsulating node, or tunnel entry point, an IPv6 packet is placed within the data field of an IPv4 packet. The resulting IPv4 packet contains both an IPv4 header and an IPv6 header, plus all of the upper layer information, such as the TCP header, application data and so on. In terms of management, the encapsulating node may maintain configuration information regarding the tunnel or tunnels that are established, such as largest chunk of data (called the maximum transfer unit, or MTU) that can be sent down a particular tunnel.

The IPv4 header is read by intermediary routers, which ferry the packet across the IPv4 network to the decapsulating node, or tunnel endpoint. There, the IPv4 header is examined and then discarded, leaving the IPv6 header plus data that is then delivered to the IPv6 destination host.

But remember that tunneling is a process, which becomes incorporated into a network design. To implement a tunnel requires an understanding of the different configurations that are possible, and where they are most likely to be implemented within the internetwork.

RFC 1933 defines four possible tunnel configurations that could be established between routers and hosts:

• Router to router: IPv6/IPv4 routers that are separated by an IPv4 infrastructure tunnel IPv6 packets between themselves.
• Host to router: An IPv6/IPv4 host tunnels IPv6 packets to an IPv6/IPv4 router via an IPv4 infrastructure.
• Host to host: IPv6/IPv4 hosts that are interconnected by an IPv4 infrastructure tunnel IPv6 packets across the IPv4 infrastructure.
• Router to host: IPv6/IPv4 routers tunnel IPv6 packets to an IPv6/IPv4 host, which is the final destination.

A tunnel has both an entry point and an endpoint, and to get the data across, addresses for both points must be known. Defining the entry point is straightforward, since it occurs at the boundary of the IPv4 infrastructure. Defining the tunnel endpoint is much harder - the IPv6 node cannot ''see the light'' at the end of an IPv4 tunnel because the protocols are distinct. Therefore, the IPv6 node needs some assistance to define that endpoint, using one of two techniques: configured tunneling or automatic tunneling.

With configured tunneling, the network administrator will be involved in defining the endpoint configuration. With automatic tunneling, mechanisms within the IPv6 protocol will assist with the configuration. Let's examine these two options separately.

Configured tunneling

Note that the tunnel endpoint address (an IPv6/IPv4 router) is different from the final destination endpoint address (an IPv6 node). This requires the node performing the encapsulation to determine the tunnel endpoint from some self-contained routing tables that you'll need to enter into the router's database. The information would be stored in that encapsulating node in much the same way routing tables operate today. If a packet comes in with a particular destination, a table lookup is performed, and that packet is forwarded out a specific port on its way to the final destination.

Automatic tunneling

From the four tunneling scenarios that were discussed previously, the host-to-host and router-to-host terminate on a host. In this case, the tunnel endpoint address and the IPv6 packet endpoint address both identify the same device the host. The only difference is that the tunnel endpoint is an IPv4 address, while the host address is an IPv6 address. If these two addresses can somehow be related, the tunneling process can be simplified considerably.

This is the purpose of the IPv4-compatible IPv6 address. The 32-bit IPv4 address occupies the lower 32 bits of the IPv6 address, and the balance of the address, including the address prefix, is completely filled with zeros, thus identifying it as a special address. To derive that IPv4 address, the high-order 96 bits are removed, leaving the remaining 32 bits. Thus, this single address does double duty - it identifies the tunnel endpoint (the IPv4 portion of the address), and also identifies the host (the entire IPv6 address).

Remember that host-to-router communication uses configured tunneling, while router-to-host communication uses automatic tunneling. There is a hybrid approach, often called the semi-automatic or half-manual tunnel, that combines both techniques to provide communication in both directions. Thus, configured tunneling is used in the host-to-router direction, while automatic tunneling is used in the router-to-host direction. As before, the type of endpoint determines the type of tunnel configuration - host endpoints can use automatic tunneling, while router endpoints use configured tunneling - and the combination of the two techniques maximizes the use of the new protocol's capabilities.

Transition strategies

With extensive investment in existing IPv4 infrastructures, few, if any, network managers will opt to build an IPv6 network from scratch. Instead, the cooperative transition mechanisms - dual stacks and tunneling - will be incorporated into both routers and hosts, to facilitate a gradual and orderly transition.

If the reason driving the migration is for host-based issues, such as using the IPv6 security features, authentication and encryption, then equipping those hosts with dual IPv6/IPv4 stacks would be the first step. The existing IPv4 infrastructure could remain in place, and host-to-host tunnels could be established for IPv6 communication between the hosts. IPv4 communication would proceed as before. Supporting functions, such as DNS, would also be upgraded to handle the larger IPv6 address records.

Likewise, servers may justify an upgrade to dual IPv6/IPv4 stacks to provide the greatest flexibility to their clients. In this way, existing IPv4 applications could continue to run over IPv4, and new IPv6 applications, or perhaps clients that needed to migrate to IPv6 because of address exhaustion issues, could communicate with that server using IPv6.

The tunneling function could exist at either the hosts or the border routers - those that are at the entry and exit points of the existing IPv4 infrastructure. This choice will likely be determined by your mix of host and router vendors, and the degree to which they support the IPv6 transition mechanisms. Once the industry becomes more mature, that choice could be predicated on the processing overhead of each device, and the degree to which it can accommodate the added functions of encapsulation and decapsulation.

Once the tunneling location was determined, and the mix of communicating endpoints determined, then either automatic or configured tunneling would be implemented. If automatic tunneling is desired, then each dual host would be assigned IPv4-compatible IPv6 addresses. If configured tunneling is desired, then the dual nodes (hosts and/or routers) would have their routing tables updated to include the new paths across the IPv4 infrastructure.

Some of this process will be dependent on the vendors involved, constrained by the degree of support that they provide for a particular type of tunneling, within a given platform. Much of the configuration work, however, such as assigning new addresses and programming router tables, will fall on the shoulders of the network manager, much as it does today. In any event, collaborative work with your vendors will be required, as this is a new technology for both vendors and users alike.

If the issues driving the migration are router-based functions, such as the capabilities for IPv6 to support address autoconfiguration or real-time data flows, then the routing infrastructure must be upgraded to IPv6, as well. This process is likely to be more time-consuming, especially for widely distributed internetworks, because each router, plus the routing protocols, such as RIP and OSPF, must be upgraded to IPv6.

In any event, the best advice is to build a small test network, test it with all vendors' IPv6 updates, and also test using the 6bone network, an IETF-sponsored worldwide test network that covers North America, Europe and Japan. And expect to exercise some patience during the process - remember that Rome was not built in a day, and the Internet will not migrate to a new version of IP without some real work, either.