Juha Lehtovirta
Tascomm Engineering Oy
lehtovirta@tascomm.fi
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 intially 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 be complete, unless the transition techniques are seen acceptable by most of the users of Internet.
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, 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]:
| 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. |
| IPv6-only node | A host or router that implements IPv6 and does not implement IPv4. These are not feasible for general purpose Internet use until the transition has proceeded into a 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:
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.
| 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 |