Extended discussion about IPv4/IPv6 transition and interoperability

LONG IPv4 and IPv6 interoperability (Transition Mechanisms)

IPv4/IPv6 accessibility is a general requirement for smooth transition. From the point of view of applications (the real “users” of the network), different problems have been identified:

IPv6 applications communicating across an IPv4 network (note that in a further transition stage, the opposite problem will arise):

This case is solved by the network, through the use of tunnels, and it is transparent to the application. The LONG network makes extensive usage of IPv6 over IPv4 configured tunnels. Our experimental results, regarding a wide spectrum of tunnel flavours (configured, 6to4, and also less commonly used ones like automatic, or 6over4) show that the use of tunnels does not reduce performance significantly (if you want to read the description, see Deliverable 4.2, where you can find performance tests for several IPv4/IPv6 transition mechanisms).

IPv6-enabled applications interacting with IPv4 applications:
The second case, IPv6-enabled applications interacting with IPv4 ones, can be solved by:

a) The deployment of applications that can use both protocols provided that the applications run over dual-stack hosts.

The deployment of applications that can communicate with both IPv4 and IPv6 is a neat solution. It is especially useful for the deployment of servers. If a server is to be deployed in this way, either IPv4 or IPv6 clients can access the service. The restrictions due to translation (limited support for extension header translation, broken end-to-end relationship, etc.) are not an issue in this case. However, this model requires dual protocol connectivity for the host acting as server. And we have to consider that adding support for both protocols increases slightly the cost of application development. In the LONG network the deployment of DNS, Web, FTP, IRC, Mail, News and Isabel follow this approach. To consider the particular case of Isabel, IPv4 clients and IPv6 clients can connect to a FlowServer running in a dual stack host, since this component handles communication with both network protocols.
If the network does not support both protocols, but a dual-stack machine were hosting a dual protocol application, tunnels can be used to establish communication with another host using the protocol not natively supported by the network. For example, if an Isabel FlowServer running on a dual-stack machine is placed inside an IPv6 only network, DSTM could be used for tunnelling IPv4 packets over IPv6 from a border router to reach the FlowServer (or a static tunnel could be configured for this purpose). This latter scenario is not being tested in the LONG network.

b) The deployment of translators.
If the application

-         does not support dual protocol communication,

-         is hosted in a single stack machine, or

-         is hosted in a dual stack host but the network does not allow by any means the communication for both protocols,

protocol translation is required. Several services have been tested in such way in the LONG network. In the stable LONG infrastructure, Isabel, NFS and the Tetris game are translated by NAT-PT (the most mature and universal translation service) to allow IPv4 nodes to access to IPv6. IRC is translated using TRT. You can see a map of UC3M, to see the topology of the network in which NAT-PT is exercised. NAT-PT has proven to offer enough performance when not too many flows are translated simultaneously (Deliverable 4.2), even to fulfil the real-time communication requirements of Isabel.
One of the design criteria is to place the burden of translation as close to the server as possible, avoiding to force the client network to care about it. The deployment of IRC, News and LDAP in the LONG network achieves this goal by offering different servers for IPv4 and IPv6 access, and translating the communication among the servers with a transition mechanism. IPv4 clients access IPv4 servers, and vice versa (see graphic for IRC). When client to server translation cannot be avoided, as is the case for Web or FTP, proper DNS configuration is required for allowing easy access. Regarding to the particular translation technology to use on each case, either in server-to-server or client-to-server communication, the applicability of the translator and its performance have to be checked for each application. For example, if translation were required for Isabel, NAT-PT should be the only choice, since it is the only available mechanism for translating both UDP and TCP traffic (NAT-PT is transport independent). NAT-PT is a translation mechanism that can be used in many cases, and there are implementations with convenient features such as FTP application level translation support.

In brief, the list of transition mechanisms tested is: Configured Tunnels and Tunnel Broker, Automatic Tunnels, 6to4, 6over4, ISATAP, DSTM, NAT-PT, TRT, SOCKS64. You can see performance figures about some of them at Deliverable 4.2).