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 IPv4 routers (R).

Figure 4-2 Tunneling Mechanism

The different uses of tunneling in the transition follow:

• Configured tunnels between two routers, as in the previous figure

• 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, the tunnel consists of two routers that are configured to have a virtual point-to-point link between the two routers 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

Note - The preferred method for creating automatic tunnels is through 6to4 tunneling. For detailed information about the 6to4 routing and tunneling mechanism, refer to 6to4 as a Transition Mechanism.

Automatic tunnels require IPv4-compatible addresses. Automatic tunnels can be used to connect IPv6 nodes when IPv6 routers are not available. These tunnels can originate either on a dual host or on a dual router by configuring an automatic tunneling network interface. The tunnels always terminate on the dual host. These tunnels work by dynamically determining the destination IPv4 address, the endpoint of the tunnel, by extracting the address 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. The application might use an API, such as sockets, which requires changes in the application. Also, the provider of the API, such as an implementation of the java.net class might not support IPv6 addresses. In either situation, the node only sends and receives IPv4 packets like an IPv4 node would.

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

• IPv6-unaware--This application cannot handle IPv6 addresses. This application 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 situations, the address might be transparent to the application, for example, when the API hides the content and format of the actual address.

• IPv6-enabled--This application can, in addition to being IPv6-aware, can use 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. This application 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. A dual-stack is both an IPv4 protocol stack and an IPv6 protocol stack. IPv4 applications 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 that run on a dual-stack can also use the IPv4 protocol. IPv6 applications use 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. Also, you do not need a separate IPv6 client to talk with an IPv6 server. You need only to port their IPv4 client application to the new IPv6 API. The client can communicate with IPv4-only servers. The client can also communicate with IPv6 servers that run on either a dual host or an IPv6-only host.

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

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

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

X means that the server cannot communicate with the client.

(IPv4) denotes that the interoperability depends on the address that is chosen by the client. If the client chooses an IPv6 address, the client fails. However, an IPv4 address that is returned to the client as an IPv4-mapped IPv6 address causes an IPv4 datagram to be sent successfully.

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 each ISP requires different steps during the transition phase. This section provides some examples of site transition scenarios.

The first step to transition a site to IPv6 is to upgrade the name services to support IPv6 addresses. For DNS, upgrade to a DNS server that supports the new AAAA (quad-A), 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 new 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 distribute IPv6 addresses, you can start transitioning hosts. You can transition hosts in the following ways:

• Upgrade one host at a time. Use IPv4-compatible addresses and automatic tunneling. No routers need to be upgraded. Use this method for initial experimental transition. This method offers only a subset of the IPv6 benefits. This method does not offer stateless address autoconfiguration or IP multicast. You can use this scenario to verify that applications work over IPv6. This scenario also verifies that the application can use IPv6 IP-layer security.

• Upgrade one subnet at a time. Use configured tunnels between the routers. In this scenario, at least one router per subnet is upgraded to dual. The dual routers in the site are tied together by 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.

• Upgrade all the routers to dual before any host is upgraded. Though this method appears orderly, the method does not provide any IPv6 benefits until all the routers have been upgraded. This scenario constrains the incremental deployment approach.

6to4 as a Transition Mechanism

The Solaris operating system includes 6to4 as a preferred interim method for making the transition from IPv4 to IPv6 addressing. 6to4 enables isolated IPv6 sites to communicate across an automatic tunnel over an IPv4 network that does not support IPv6. To use 6to4 tunnels, you must configure a boundary router on your IPv6 network as one endpoint of the 6to4 automatic tunnel. Thereafter, the 6to4 router can participate in a tunnel to another 6to4 site, or, if required, to a native IPv6, non-6to4 site.

This section provides reference materials on the following 6to4 subjects:

• Topology of the 6to4 tunnel

• 6to4 addressing, including the format of the advertisement

• Description of packet flow across a 6to4 tunnel

• Topology of a tunnel between a 6to4 router and 6to4 relay router

• Points to consider before you configure 6to4 relay router support.

More information about 6to4 routing is available from the following sources.