1.

Introduction
It is well realized that the lifetime of the IPv4 address space is limited. The day when no more
32-bit IP network addresses are left may, and most certainly will, arrive. Since the new
IPv6/IPng architecture solves the address space problem in an effective way, at least for some
time, the need for deployment to the new version is real.

Because of the huge size and coverage of the Internet, it is impossible to expect a fast, centrally
coordinated cutover. To make the whole transition concept feasible, the coexistence of both IPv4
and IPv6 must be arranged in a practical and simple way. It is also important to encourage the
transition process to overcome the resistance on the field. The transition is definitely a costly
issue for large organizations and as long as IPv4 is not its back against the wall, the temptation to
stay with the old technology is strong.

For smooth, stepwise and independent transition a set of techniques have been specified. They
implement mechanisms for true internetworking, coexistence, easy address mapping and name
service migration, for example. In addition to these, hopefully temporary transition phase
techniques, the final benefits of a pure IPv6 environment must be encouraging enough for the
users to initially trigger the whole process of migration [1].

The IETF specifications for IPv6 contain a lot of information concerning the transition issues.
Most of the documents are presented in form of RFCs, and some material is available as Internet
Drafts. This area is under extensive evaluation and engineering work. However the information
currently available pretty well reflects the most significant subjects of IPv4 to IPv6 transition.

2. Requirements for smooth transition

The actual transition process from IPv4 to IPv6 can be compared to the migration processes of
smaller scale that take place all the time. Operating system and software development
environment version changes are good examples of such migration. The main constraints set for
the IPng transition should be generally the same as in any smaller scale migration. However, for
the global Internet community the fulfillment of the constraints is much more important, and few
shortcuts can be tolerated.

2.1. Minimizing the resistance

The general attitude of large organizations to IPng is assumed to be disfavor. This subject is
discussed in a memo made in the Boeing Company [2]. The viewpoints of the IETF and industry
are different, which may lead to significant resistance in adopting the new technology. Industry
sees the world from the business point of view. Computing is a tool for doing business; the
techniques used are never a primary factor.
Where internet engineering people concentrate on the shining state-of-the-art technology and
new capabilities of IPng, a large corporate user is concerned about the flexibility of the
transition, compatibility with old systems and predictable cost of migration [3]. The full
deployment of IPv6 will probably take a decade. But it will never complete unless the transition
techniques are seen acceptable by most of the users of Internet.

2.2. Constraints

Stepwise transition

We are already aware of that the transition cycle will take years and there is no way to
synchronize the process on different sites. A distributed approach is necessary. Presumably only
the smallest user organizations are able to switch over to IPv6 in a single step. All others must be
able to make their own staged transition plan, and proceed in it with as few interdependencies as
possible. IPv4 and IPv6 network equipment must be allowed to coexist and interoperate. It
should even be realized that some old, small-scale systems may never be capable of running
IPv6. They will maintain the old protocol suite in the network to the end of the old hardware
usage time [4][5][6].

Coexistence and internetworking

The transition independency means that the order of migration on unique computers and network
devices is not tied to the upgrade of some other systems in the network. The release dates of new
computer systems, routers and application software cannot be commonly synchronized. Old
equipment and software will be used in the network while the IPng-based systems and
applications are deployed. The old systems should run without modifications and be able to
communicate with both the old and new systems. In practice this means a strict requirement for
simultaneous support for both IPv4 and IPv6 on all new systems [4].

Feasible address mapping scheme

IPng brings the advantage of a very large address space where even multiple addresses can be
easily reserved for each host. In addition to the complex scheme of 128-bit IPv6 address
distribution, a simplified method is necessary. To make the transition process easier an optional
simple mapping from an old IPv4 address is desireable. Since it is not possible to assume that all
IPv4 addresses used are globally unique, the mapping may be site-specific in some cases instead
of a fixed prefix, for example [4].

Smart management tools

During the transition and existence of dual protocol networks the demand for a whole set of
management tools is clear. The new tools must be clever enough to separate IPv4 and IPv6
characteristics on multiple levels. Detection of different routes and possible translation points
must be implemented. A mechanism for checking the IPng capability of remote hosts and
devices is essential. Without appropriate management applications the complexity of a dual
protocol network will become a nightmare. [4].
3. Transition components
3.1. Hosts

In practice the concept of stepwise transition means that for many years the global Internet
contains both hosts restricted to traditional IPv4 operation and hosts equipped with IPv6
capability. To allow seamless interoperation, all hosts running IPng must still be able to
communicate with the older technology. On the application level software designed for IPv4 uses
the older API while new IPng applications use the new API. Thus the application actually knows
which protocol suite it is using. The IPv4 API and standard applications should be available on
IPv6 hosts as well if interoperation with common tools (e.g. FTP, Telnet) is expected with older
IPv4 hosts.

3.2. Routers and routing protocols

From the protocol version support point of view of the routers must follow the same rules as
individual hosts. New devices with IPng capability cannot assume that all other systems they are
interacting with are equipped with the latest protocol support. The compatibility constraint
applies to routing protocols as well. While commercial issues gain more and more interest within
the Internet infrastructure, IPng routing procedures must allow routing based on traffic source
and destination in detail. Especially policy routing and accounting are necessary for funding
agencies [4].

3.3. Domain Name System

During the transition phase the new IPng capable hosts have both a 32-bit IPv4 address and a
128-bit IPv6 address. Old systems not upgarded yet naturally have an IPv4 address. However, an
IPv6 address may already have been assigned to them as well. DNS has to reply with both
addresses, if available, for queries from IPng hosts. It is then the decision of the communicating
host to select which protocol to use. For old-fashioned queries from IPv4-only hosts the response
is the IPv4 address only. A special condition arises when an IPv6 address has been attributed to a
specific host in DNS, but the host is not really IPng capable yet. This is called a black hole in the
IPng address space and the associated protocol software on communicating hosts must handle
such exceptions in an acceptable way [4].

3.3. Component dependencies

The less dependencies apply to the order of transition of different network components, the less
resistance and delays are faced. DNS servers are the first physical devices to upgrade after a
suitable IPng address allocation and mapping scheme is available. This allows new IPv6 hosts to
perform name service lookups for IPv6 addresses. Furthermore, the order of migration on host
and router software is less critical. The concept of protocol dualism allows IPv4 systems to
continue their operation without any modifications. The changes in routing protocols can also be
performed with no hurry as the number of IPng capable routers increases.

4. Transition techniques
During the years of transition we can have three different types of IP nodes, depending on their
capability to support different protocols [7]:
A host or router that implements only IPv4. An IPv4-only node does not understand
IPv4-only
IPv6. The installed base of IPv4 hosts and routers existing before the transition
node
begins are IPv4-only nodes.
IPv6/IPv4
A host or router that implements both IPv4 and IPv6.
node
A host or router that implements IPv6 and does not implement IPv4. These are not
IPv6-only
feasible for general purpose Internet use until the transition has proceeded into a
node
phase where most of the community have upgraded to IPng.

4.1. Simplified address mapping

One of the major constraints set for the transition process was the alternative for simple and
straightforward IPv4-to-IPv6 address mapping. This is performed by placing the 32-bit IPv4
address to the rightmost four bytes of the 128-bit IPv6 address and subsituting a fixed site-
specific or global prefix to the remaining 96 bits.

For automated protocol compatibility mechanisms, like IPv6-in-IPv4 encapsulation (tunneling),

a special prefix of all zeros have been reserved. This is called an IPv4-compatible address. It is
structured as follows:

96 bits (12 bytes) 32 bits (4 bytes)

0:0:0:0:0:0 IPv4 address

The rest of the IPv6 address space is reserved for pure IPng addresses, termed IPv6-only
addresses. However, direct mapping of IPv4 addresses may still occur using service provider
specific prefixes. This is mainly to help the configuration and administration of the address
dualism in user organizations [7].

4.2. Dual IP layer

The most straightforward procedure to satisfy the requirement for full intersystem compatibility
is to include a complete IPv4 implementation to new IPv6 systems. This is what we call an
IPv6/IPv4 node. They are able to transmit both IPv4 and IPv6 packets and thus interact with all
IP systems in the network. When combined with protocol encapsulation, interaction of IPv6
applications will be possible between two IPv6/IPv4 nodes, even if the devices on the route have
not yet been upgraded to IPng.
The dual stack approach does not necessary imply that the system should contain two separate
protocol implementations. It just should act as if it did. From the application point of view there
are still two separate APIs and the true decision whether IPv4 or IPv6 is used is made on the
application level [4] [7] [8].

4.3. Protocol encapsulation

During the deployment of IPv6 the construction of the new IPng compliant routing infrastructure
will take time. It would be an intolerable limitation if IPv6 hosts on the different edges of the
network cannot interoperate using IPng capabilities until all intermediate routers are upgraded.
This issue can be solved using a technique called IPv6-in-IPv4 encapsulation or IPv6-over-IPv4
tunneling [4] [7].

Tunneling of IPv6 datagrams takes place by encapsulating them within IPv4 packets. This way
IPv6/IPv4 hosts and routers can tunnel IPv6 traffic over regions of IPv4 routing topology. In the
simplest form the encapsulating node adds an IPv4 header to the packet and transmits it. The
decapsulating node removes the IPv4 header and processes the remaining IPv6 packet as if it
were normally received via IPv6 topologies. In practice the mechanism is not this simple. The
tunneling procedures must handle several special conditions properly:

 Fragmentation to several datagrams when the original IPv6 packet is too big to fit into the
data area of a resulting IPv4 packet. The discovery of optimal MTU sizes for the path
may be used to minimize the fragmentation process.
 Implementation of proper hop limit (TTL). By default, the IPv6-over-IPv4 tunnel,
regardless how long it actually is, is seen as a single hop on the route from the IPv6 point
of view. The TTL values to encapsulating IPv4 headers must be set in an implementation
dependent manner.
 Handling of IPv4 ICMP errors. If IPv4 ICMP errors are detected inside the tunnel path,
special mechanisms may be necessary to pass the error information back to the original
initiator.

Two different types of tunneling may occur. In configured tunneling the tunnel path endpoint
IPv4 address is defined in the configuration of the encapsulating node. This approach does not
require any interdependency between IPv4 and IPv6 addresses but requires a lot of effort to
manage. In automatic tunneling the tunnel endpoint address is directly translated from the
original destination IPv6 address. The IPv6 addresses used must be IPv4-compatible addresses.

4.4. DNS "AAAA" records

A new DNS resource record type named "AAAA" is used for 128-bit IPv6 addresses. For
IPv6/IPv4 nodes the name service must also contain the traditional 32-bit IPv4 "A" record. The
resolver libraries will then retrieve the address that is actually requested by the application (using
IPv4 or IPv6 API). For IPv4-compatible IPv6 addresses it is not necessary to respond to queries
with both "AAAA" and "A" records if the IPv6 resolver library is able to extract the IPv4 address
directly from the 128-bit form [7].

4.5. IP header translation

A technical alternative for the dual IP layer approach presented above would be to use dynamic
header translation between IPv4 and IPv6 packets. However, the practical difficulties seen in this
concept have been considered to be too big, and this alternative has been abandoned by the IETF.
Since IPng functionality is richer than IPv4 functionality, successful translation between the
protocols without losing the new advanced features is difficult without complex manual
configuration of interworking applications and translators. The administration of translator units
would also be very impractical unless they are completely automatic and constantly aware of the
transition state of other hosts in the network [4].

5. Migrating the applications

A very large number of existing applications using an IP transport layer protocol, like TCP, have
been implemented over the years. The main concern in all this software is that the network
addresses are handled in a very low level form, in practice by assuming that the IP host address
length is the IPv4 fixed 32 bits and usually internally storing the address in a 32-bit wide
application variable. Thus the immediate conclusion is that an existing TCP/IP application
cannot directly address an IPv6-only host.

5.1. Socket API changes

The IPv4 socket API structures are defined to contain a 32-bit field for IP addresses. For IPv6
these structures will definitely change. Should major modifications to the application source
code occur, depends on the way the program handles the addresses and especially the variable
syntax used for allocating space for them. At the easiest form the conversion could be a simple
recompilation using the new API structure definitions. At the worst form a lot of code must be
changed, reviewed and debugged to produce a properly functioning and robust module. To avoid
this kind of massive software modification demand in the future, a new, network protocol
independent transport layer specification in being written [1] [9].

5.2. Binary compatibility

In hosts equipped with both IPv4 and IPv6 support the preservation of existing IPv4 binaries is
expected. In practice this can be implemented by running them over the native IPv4 stack, or by
automatically converting the traffic to take place over IPv6. The latter alternative still restricts
the functionality to the IPv4 features and may encounter problems, for example, if manual
mapping of IPv6 addresses to addresses used by the application is required [1].

6. Conclusions
It is clearly a challenge to release IPng in a form that is rapidly and commonly accepted by the
large commercial user organizations of Internet. The home users and educational sites are not a
problem. The transition risk is small and the technological perspective is often seen as the
primary factor for the decision.

In an ideal transition concept the pushing force would be the technical advantage and new
features offered by IPng, not any commonly decided timetable that is justified by the termination
of support for the older technology, the IPv4.

The transition techniques specified by the IETF so far satisfy the general requirements rather
well. The represented scheme is easy to adopt. The main areas of improvement are in the
configuration and administration tasks which may get complicated during the transition phase
protocol dualism.

One interesting question, which will most probably remain unaswered for years, is if there ever
will be a day when no more IPv4 functionality support is required in the global Internet.

References
[1]
Brander, S.; Mankin, A. IPng, Internet Protocol Next Generation, Addison-Wesley, 1995,
ISBN 0-201-63395-7
[2]
Fleischman, E. A Large Corporate User's View of IPng, RFC 1687, 1994
[3]
Britton, E.; Tavs, J. IPng Requirements of Large Corporate Networks, RFC 1678, 1994
[4]
Carpenter, B. IPng White Paper on Transition and Other Considerations, RFC 1671, 1994
[5]
Partridge, C.; Kastenholz, F. Technical Criteria for Choosing IP The Next Generation
(IPng), RFC 1726, 1994
[6]
Bradner, S.; Mankin, A. The Recommendation for the IP Next Generation Protocol, RFC
1752, 1995
[7]
Gilligan, R.; Nordmark, E. Transition Mechanisms for IPv6 Hosts and Routers, Internet
Draft (ngtrans), 1995
[8]
Clark, R.; Ammar, M.; Calvert, K. Multiprotocol Interoperability In IPng, RFC 1683,
1994
[9]
Carlson, R.; Ficarella, D. Six Virtual Inches to the Left: The Problem with IPng, RFC
1705, 1994

Glossary
API Application Programming Interface
Datagram Internet Protocol network data packet
DNS Domain Name System
FTP File Transfer Protocol
ICMP Internet Control Message Protocol
IETF Internet Engineering Task Force
IP Internet Protocol
MTU Maximum Transmission Unit
RFC Request for Comments
TTL Time To Live