Interoperability between IPv6 and IPv4

IPv6 and IPv4 are two completely separate protocols. IPv6 is not backwards
compatible with IPv4, and IPv4 hosts and routers will not be able to deal
directly with IPv6 traffic (and vice versa).

Unfortunately, it is a fact of life both that

there will be extreme difficulties with address allocation and routing if
the Internet is to continue be run indefinitely using IPv4

it is impossible to switch the entire Internet over to IPv6 overnight

Therefore for a long period of time we are going to be dealing with a network
in which the two protocols will be operating side by side. A common estimate
of the length of time involved is 10 years ö in terms of the history of the
Internet, a very long time indeed, but probably a realistic figure in terms of
the amount of installed IPv4 software and infrastructure, all of which will need
to be replaced or upgraded.

During the transition period, IPv6 nodes are going to need to communicate
with IPv4 nodes, and isolated 'islands' of IPv6 installations are going to need
to use the wider IPv4 network to connect to each other.

Dual IP stacks have been proposed to solve the first problem, and tunneling to
solve the latter.

Dual IP Stacks

Nodes with dual IP stacks will have both and IPv4 protocol stack and an IPv6
one. When communicating with IPv6 nodes, they use IPv6 and when
communicating with IPv4 nodes, they revert to IPv4. These nodes have what are
called IPv4 compatible IPv6 addresses - these are addresses where the first
96 bits of the address are zeroes and the last 32 forms a valid IPv4 address.
Every current IPv4 address can be transformed to an IPv6 address in this way.

Unfortunately, this
requires all dual-stack nodes to have IPv4 addresses. This may not be
feasible considering that one of the major reasons for transitioning
to IPv6 is that the available address space is set to run out.

It is also
burdensome for routers. Consider a LAN where all hosts are IPv6 enabled,
but are running dual IP stacks to communicate with the outside world.
All the network infrastructure, i.e. routers and bridges etc will
need to be able to deal with both protocols, maintain double routing tables, etc.
Simplicity of routing is supposed to be a strength of IPv6, if this sort of
transition mechanism were used it would become a weakness.

To get around these two problems, the following three more advanced
transition mechanisms have been developed. These can be used in
situations where a network has been completely converted to IPv6, but which
still needs to communicate with the outside IPv4 world. They all rely on
various servers or devices that sit between the IPv6 and IPv4 networks doing some form of
translation.

Dual Stack Application Level Gateway (Dual Stack ALG)

Dual-stack servers are used as proxies to perform protocol translation with
one proxy server per application (http, ftp, smtp, etc). This has the advantage
that very few IPv4 addresses are required (they are only needed for the
proxies), and the protocol translation step may not be such a large price to
pay in situations where firewalls and proxy server already exist, which is the
case in many LANs.

Network Address Translator - Protocol Translator (NAT-PT)

Dedicated hardware devices are placed at thr boundary of the IPv6 network
and perform protocol translation at a low level. To do this, they also store
session information. With NAT-PT, no dual stacks would be needed.

Dual Stack Transition Mechanism, or DSTM

All hosts have dual stacks, but they do not have permanent IPv4 addresses.
IPv4 addresses are temporarily assigned whenever a host contacts or is
contacted by and IPv4 host. The host encapsulates all its IPv4 packets within
IPv6 headers to tunnel them over the local IPv6 network. When the DSTM
router at the edge of the network sees these packets, they are decapsulated.

This would find natural uses on networks where IPv4 addresses are already
allocated dynamically.

IPv6 over IPv4 tunneling

Tunneling is a mechanism to allow IPv6 domains that are connected via IPv4
networks to communicate with each other, or to allow isolated IPv6 hosts that
are not directly connected to an IPv6 router but only to IPv4 machines to
reach the wider IPv6 network. Naturally, to use tunneling a host must have a dual IP
stack in order to send and receive IPv4 datagrams. In most cases, however, this won't
apply to large numbers of machines - just some routers and isolated IPv6 machines on
IPv4 networks.

Tunneling IPv6 packets over IPv4 network infrastructure is simple in theory ö
just prepend an IPv4 header and send them via the normal IPv4 mechanisms
to a router with a dual IP stack. There are also issues about dealing with IPv4
ICMP errors, which are reported to the encapsulating node rather than the
original sender, and to do with fragmenting IPv6 packets, but these canbe dealt with.

However, the straightforward approach involves network managers
configuring information about tunnel endpoints into the encapsulating node ö
this is time consuming and non-scalable.
It is also impossible to expect single isolated users who may be dialing into
the IPv4 network through their ISP to configure tunnels.
Therefore a dynamic solution is
required. The following methods have been proposed to get over the
problems of configuring tunnels. They are each useful in different scenarios.

6over4

6over4 is an elegant solution for interconnecting isolated IPv6 hosts in an IPv4 site.
IPv6 multicast is implemented over IPv4 multicast. Using IPv6 multicast, IPv6 nodes can then
use Neighbour Discovery to configure themselves.
Unfortunately, IPv4 multicast is not generally available on all networks, and there are scalability
issues with this appraoch. It is ideal for small self contained networks where multicasting is available.

6to4

The motivation for 6to4 is to allow isolated small domains or single hosts on a LAN or WAN
with no native IPv6 support to communicate with the minimum manual configuration.
IPv6 domains build their own IPv6 prefix based on the IPv4 address of the border router.
The prefix is '2002:' followed by the 32 bit IPv4 address of the border router.

Therefore any IPv6/IPv4 router trying to tunnel encapsulated IPv6 packets to a domain that
starts with the "2002:" prefix can immediately determine the address of the IPv4 router
to tunnel the packets to.

To get access to the wider IPv6 network, you then need an IPv6/IPv4 router to decapsulate your tunneled IPv6 packets and forward them to the backbone, and likewise encapsulate
any IPv6 packets destined for your domain and tunnel them over IPv4 to the border router.

So the three pieces of information you need to use this are:

Your outside-visible IP address (this might be a gateway or similar)
from which you derive your IPv6 48 bit prefix (and then somehow choose the rest of your
address)

The address of a 6to4 gateway to use, to connect to the rest of the IPv6 world.

Tunnel Brokering

Dedicated servers configure tunnels on behalf of IPv6 clients.
The main application of this will be for dial-up users of ISPs who will not be able
to reconfigure their tunnels manually every time they connect.
6over4 will not be suitable as they will not be on a multicast network.

Tunnel brokering is very simple from the user's point of view and hence good for isolated
users, but it does have some issues regarding states of tunnels - if the client does
not request the tunnel be torn down before ending a session it will persist and future
users of the same IPv4 address may receive encapsulated IPv6 packets intended for the
first user.

Discussion

One point it is important to glean from the above discussion is that different
transition mechanisms will be appropriate in different scenarios ö different
networks, different points in the transition process. Scenarios include isolated

IPv6 hosts on IPv4 networks, isolated IPv6 networks connected to the wider
IPv6 network only by the IPv4 network through the gamut to small IPv4
networks connected only to the overarching IPv6 network ö a situation that
may occur late in the transition period.

In order to get decent performance from networks during the transition,
transition mechanisms should be chosen carefully and tailored to the
situation.

Application Software

The programming APIs for IPv6 will not be the same as for IPv4 - they need to allow
programmers to make use of IPv6's added capabilities in the areas of security, QoS and other. They will also have to take into account the longer address length. Current IPv4 programs will simply not be able to address IPv6 hosts without modification.

All current software that makes use of networking capabilities uses IPv4 APIs. IPv6 APIs will probably be supersets of current IPv4 APIs.

Eventually all current software will have to be ported to IPv6. This might be as simple as
recompiling using the new APIs, or as complex as having to rewrite proprietary code to store IP addresses as 128 bit numbers rather than 32 bit ones. It completely depends on how the original code was written.

Meanwhile existing binaries should be able to use the IPv4 protocol stack on dual stack
machines. Alternstively, two methods have been proposed to allow the OS to automatically
generate IPv6 traffic if talking to other Ipv6 nodes - even if using IPv4 binaries.
These are called Bump in the Stack and Bump in the API.
Bump in the stack is a low level procedure that translates the IPv4 traffic produced into
IPv6 traffic, using standard header translation techniques.
Bump in the API is a higher leve approach - it detects the IPv4 API invocations and
if appropriate, changes them into IPv6 API invocations. This second appoach is thought
to be more efficient and elegant in general.

DNS

The Domain Name System must be updated to deal with IPv6. A new type of record has been defined
to store IPv6 addresses - the AAAA record. The main problems in this area lie with IPv4 compatible
IPv6 addresses - namely, what should the DNS server return when both an A record for an IPv4 address and
an AAAA record for the corresponding IPv6 address exist. For IPv6 hosts, DNS should return both entries.

Conclusion

There are solutions available for achieving interoperability of the two protocols for every scenario.
If the means of interoperating is chosen wisely, moving to IPv6 should not be too traumatic once the
initial change is complete - no long-lasting efficiency penalties are necessary, and configuration
need not be a huge burden.