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
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.
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 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.
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.
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.
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 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.
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:
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.
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.
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.
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.
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.