System Administration Guide, Volume 3

Chapter 15 Transitioning From IPv4 to IPv6

As hosts and routers are upgraded to support IPv6, they must be able to interoperate over the network with the nodes (hosts and routers) that support only IPv4. This chapter provides an overview of the approach and the standardized solutions to transitioning from IPv4 to IPv6. RFC 1933 also provides detailed solutions to the transition problem.

Transition Requirements

The transition does not require any global coordination. Instead, it allows sites and Internet Service Providers (ISPs) to transition at their own pace. Furthermore, an effort has been made to minimize the number of dependencies during the transition. For instance, the transition does not require that routers be upgraded to IPv6 prior to upgrading hosts.

Different sites have different constraints when transitioning. Also, early adopters of IPv6 are likely to have different concerns than production users of IPv6. RFC 1933 defines the transition tools currently available. The driving force for transition is either the lack of IPv4 address space or required use of new features in IPv6, or both. The IPv6 specification requires 100% compatibility for the existing protocols and applications during the transition.

To understand the transition approaches, the following terms have been defined.

IPv4-only node - A host or router that implements only IPv4. An IPv4-only node does not understand IPv6. The installed base of IPv4 hosts and routers existing before the transition begins are IPv4-only nodes.
IPv6/IPv4 node - A host or router that implements both IPv4 and IPv6, also known as dual stack
IPv6-only node - A host or router that implements IPv6, and does not implement 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.
Site - Piece of the private topology of the Internet, that is, topology that does not carry transit traffic for anybody and everybody. The site can span a large geographic area. For instance, the private network on a multinational corporation is one site.

Standardized Transition Tools

RFC 1933 defines the following transition mechanisms:

When you upgrade your hosts and routers to IPv6, they retain their IPv4 functionality to provide compatibility for all IPv4 protocols and applications. These hosts and routers are known as dual stack.
They use the name service (for example, DNS) to carry information about which nodes are IPv6 capable.
IPv6 address formats can contain IPv4 addresses.
You can tunnel IPv6 packets in IPv4 packets as a means of crossing routers that have not been upgraded to IPv6.

Implementing Dual Stack

The dual stack term normally refers to a complete duplication of all levels in the protocol stack from applications to the network layer. An example of this would be OSI and TCP/IP protocols running on the same machine. However, in the context of IPv6 transition, it means a protocol stack contains both IPv4 and IPv6, with the rest of the stack being identical. Consequently, the same transport protocols (TCP, UDP, and so on) and the same applications will run over both IPv4 and IPv6.

The following figure illustrates dual stack protocols through the OSI layers.

Figure 15-1 Dual Stack Protocols

In the dual stack approach, subsets of both hosts and routers are upgraded to support IPv6, in addition to IPv4. This ensures that the upgraded nodes can always interoperate with IPv4-only nodes by using IPv4. Thus, upgrading from IPv4 to dual stack does not break anything.

Configuring Name Services

A dual node must determine if the peer can support IPv6 or IPv4 in order to know which IP version to use when transmitting. Controlling what information goes in the name service accomplishes this. You define an IPv4 node's IP address and the IPv6 node's IP address in the name service. Thus, a dual node has both addresses in the name service.

However, the presence of an IPv6 address in the name service also signifies that the node is reachable, using IPv6 from all nodes that get information from that name service. For example, placing an IPv6 address in NIS implies that the IPv6 host is reachable using IPv6 from all IPv6 and dual nodes that belong to that NIS domain. Placing an IPv6 address in global DNS requires that the node is reachable from the Internet IPv6 backbone. This is no different than in IPv4 where, for example, mail delivery and HTTP proxy operation depend on there being only IPv4 addresses for nodes that can be reached using IPv4. When no reachability exists in IPv4, for instance, due to firewalls, the name service must be partitioned into an inside firewall and outside firewall database so that IPv4 addresses are visible only where they are reachable.

The protocol used to access the name service (DNS, NIS, NIS+, or something else) is independent of the type of address that can be retrieved from the name service. This name service support, coupled with dual stacks, allows a dual node to use IPv4 when communicating with IPv4-only nodes and use IPv6 when communicating with IPv6 nodes, provided that there is an IPv6 route to the destination.

Using IPv4 Compatible Address Formats

In many cases you can represent a 32-bit IPv4 address as an 128-bit IPv6 address. The transition mechanism defines the following two formats.

IPv4 compatible address

000 ... 000

IPv4 Address
IPv4 mapped address

000 ... 000

0xffff

IPv4 Address

The compatible format is used to represent an IPv6 node. This format enables you to configure an IPv6 node to use IPv6 without having a real IPv6 address. This address format lets you experiment with different IPv6 deployments because you can use automatic tunneling to cross IPv4-only routers. However, you cannot configure these addresses using the IPv6 stateless address autoconfiguration mechanism. This mechanism requires existing IPv4 mechanisms such as DHCPv4 or static configuration files.

The mapped address format is used to represent an IPv4 node. The only currently defined use of this address format is part of the socket API. It is convenient for an application to have a common address format for both IPv6 addresses and IPv4 addresses by representing an IPv4 address as a 128-bit mapped address. However, these addresses can also be used when there are IPv4 to IPv6 protocol translators.

Tunneling Mechanism

To minimize any dependencies during the transition, all the routers in the path between two IPv6 nodes do not need to support IPv6. This mechanism is called tunneling. Basically, IPv6 packets are placed inside IPv4 packets, which are routed through the IPv4 routers. The following figure illustrates the tunneling mechanism through routers (R) using IPv4.

Figure 15-2 Tunneling Mechanism

Different uses of tunneling in the transition are:

Configured tunnels between two routers (as in the figure above)
Automatic tunnels that terminate at the dual hosts

A configured tunnel is currently used in the Internet for other purposes, for example, the MBONE (the IPv4 multicast backbone). Operationally, it consists of configuring two routers to have a virtual point-to-point link between them over the IPv4 network. This kind of tunnel is likely to be used on some parts of the Internet for the foreseeable future.

Automatic Tunnels

The automatic tunnels have a more limited use during early experimental deployment. They require IPv4 compatible addresses and can be used to connect IPv6 nodes when there are no IPv6 routers available. These tunnels can originate either on a dual host or on a dual router (by configuring an automatic tunneling network interface), and they always terminate on the dual host. These tunnels work by dynamically determining the destination IPv4 address (the endpoint of the tunnel) by extracting it from the IPv4 compatible destination address.

Interaction With Applications

Even on a node that has been upgraded to IPv6, the use of IPv6 is dependent on the applications. An application might not use a networking API that asks the name service for IPv6 addresses, either because the application uses an API (such as sockets) that requires changes in the application, or the provider of the API (such as an implementation of the java.net class) has no support for IPv6 addresses. In either case the node only sends and receives IPv4 packets like an IPv4 node.

The following names have become standard terminology within the Internet community:

IPv6-unaware--This application cannot handle IPv6 addresses; that is, it cannot communicate with nodes that do not have an IPv4 address.
IPv6-aware--This application can communicate with nodes that do not have an IPv4 address, that is, the application can handle the larger IPv6 addresses. In some cases this might be transparent to the application, for instance, when the API hides the content and format of the actual address.
IPv6-enabled--This application can, in addition to being IPv6-aware, take advantage of some IPv6 specific feature such as flow labels. The enabled applications can still operate over IPv4, though in a degraded mode.
IPv6-required--This application requires some IPv6 specific feature and cannot operate over IPv4.

IPv4 and IPv6 Interoperability

During the gradual transition phase from IPv4 to IPv6, existing IPv4 applications must continue to work with newer IPv6 enabled applications. Initially, vendors provide host and router platforms that are running a dual stack, that is, both an IPv4 protocol stack and an IPv6 protocol stack. IPv4 applications will continue to run on a dual stack that is also IPv6 enabled with at least one IPv6 interface. No changes need to be made to these applications (no porting required).

IPv6 applications running on a dual stack can also use the IPv4 protocol. This is possible by using an IPv4-mapped IPv6 address. Because of the design of IPv6, separate applications (IPv4 and IPv6) are not needed. For example, you do not need an IPv4 client on a dual host to talk with a server on an IPv4-only host and a separate IPv6 client to talk with an IPv6 server. Implementors only need to port their IPv4 client application to the new IPv6 API. The client can communicate with both IPv4 only servers as well as IPv6 servers running on either a dual host or an IPv6 only host.

The address the client gets back from name server determines if IPv6 or IPv4 is used. For example, if the name server has an IPv6 address for a server, this means that the server runs IPv6.

The following table summarizes the interoperability between IPv4 and IPv6 clients and servers. It also assumes that the dual-stack host has both an IPv4 and IPv6 address in the respective name service database.

Table 15-1 Client-Server Applications: IPv4 and IPv6 Interoperability


Type of Application (Type of Node)	IPv6-unaware server (IPv4-only node)	IPv6-unaware server (IPv6-enabled node)	IPv6-aware server (IPv6-only node)	IPv6-aware server (IPv6-enabled node)
IPv6-unaware client (IPv4-only node)	IPv4	IPv4	X	IPv4
IPv6-unaware client (IPv6-enabled node)	IPv4	IPv4	X	IPv4
IPv6-aware client (IPv6-only node)	X	X	IPv6	IPv6
IPv6-aware client (IPv6-enabled node)	IPv4	(IPv4)	IPv6	IPv6

X means that it is not possible to communicate between the respective server and client.

(IPv4) denotes that the interoperability depends on the address chosen by the client. Choosing an IPv6 address fails. However, choosing an IPv4 address, which is returned to the client as an IPv4-mapped IPv6 address, causes an IPv4 datagram to be sent and succeeds.

In the first phase of IPv6 deployment, most implementations of IPv6 are on dual-stack nodes. Initially, most vendors do not release IPv6-only implementations.

Site Transition Scenarios

Each site and ISP has different issues and requires different steps during the transition phase. This section provides some examples of site transition scenarios.

The first step in transitioning a site is to upgrade the name services to support IPv6 addresses. For DNS, this consists of upgrading to a DNS server that supports the new AAAA (quad-A) records such as BIND 4.9.4 and later. Two new NIS maps and a new NIS+ table have been introduced for storing IPv6 addresses. The new NIS maps and NIS+ table can be created and administered on any Solaris system. See "IPv6 Extensions to Solaris Name Services" for details on the new databases.

After the name service is able to hand out IPv6 addresses, you can start transitioning hosts. You can transition hosts in the following ways:

Upgrading one host at a time using IPv4 compatible addresses and automatic tunneling. No routers need to be upgraded. This can be used for initial experimental transition and offers only a subset of the IPv6 benefits. It does not offer stateless address autoconfiguration or IP multicast. You can use this scenario to verify that applications work over IPv6 and that the application can use IPv6 IP layer security.
Upgrading one subnet at a time using configured tunnels between the routers. In this scenario at least one router per subnet is upgraded to dual and the dual routers in the site are tied together using configured tunnels. Then hosts on those subnets can use all the IPv6 features. As more routers become upgraded in this incremental scheme, you can remove the configured tunnels.
Upgrading all the routers to dual before any host is upgraded. Though this approach appears orderly, it does not provide any IPv6 benefits until all the routers have been upgraded. This scenario constrains the incremental deployment approach.

Other Transition Mechanisms

The mechanisms specified previously handle interoperability between dual nodes and IPv4 nodes, where the dual nodes have an IPv4 address. They do not handle interoperability between IPv6-only nodes (or dual nodes that have no IPv4 address) and IPv4-only nodes. While most implementations could be made dual (duality is only an issue of memory footprint for the code), the real issue is whether there will be enough IPv4 address space to assign one address for every node that needs to interoperate with IPv4-only nodes.

Several possibilities enable you to accomplish this interoperability without requiring any new transition mechanisms.

Use application layer gateways (ALG) that sit at the boundary between the IPv6-only nodes and the rest of the Internet. Examples of ALGs in use today are HTTP proxies and mail relays.
Companies are already selling NAT boxes (network address translators) for IPv4 that translate between the private IP addresses (for example, network 10--see RFC 1918) on the inside and other IP addresses on the outside. It is likely that these companies will upgrade their NAT boxes to also support IPv6 to IPv4 address translation.

Unfortunately, both ALG and NAT solutions create single points of failure. Using these result in a much less robust Internet. The IETF is working on a better solution for IPv6-only interoperability with IPv4-only nodes. One proposal is to use header translators with a way to allocate IPv4 compatible addresses on demand. Another proposal is to allocate IPv4 compatible addresses on demand and use IPv4 in IPv6 tunneling to bridge the IPv6-only routers.

The stateless header translator would translate between IPv4 and IPv6 header formats as long as the IPv6 addresses in use can be represented as IPv4 addresses (that is, they have to be IPv4-compatible or IPv4-mapped addresses). The support for these translators has been built into the IPv6 protocol so that, barring any encrypted packets or rarely used features like source routing, the translation can occur without any information loss.