Section 10.9. Applications

10.9. Applications

It will take some time until all applications support the transport over IPv6. There are applications that have no direct dependency on the IP layer. They run equally well without modification in IPv4 and IPv6 environments. But some applications have dependencies and need to be modified. And they should be modified to be protocol-independent if possible so that they can be used in IPv4 networks as well as in IPv6 networks. The results of different tests in the Moonv6 network have shown that most applications behave well in a dual-stacked or tunneled environment. More problems currently arise for applications in IPv6-only networks.

This section is not a guide to porting applications. The goal here is to make you aware of situations that you will face and what to look out for.

You will encounter the following situations:

• IPv4 applications on dual-stack nodes

• IPv6 applications on dual-stack nodes

• Applications supporting IPv4 and IPv6 on dual-stack nodes

• Applications supporting IPv4 and IPv6 on IPv4-only nodes

• Applications supporting IPv4 and IPv6 on IPv6-only nodes

The challenge for developers is to develop applications that work well in all situations. DNS names should be used whenever a service has to be called. But the DNS reply is not a reliable indicator of which protocol to use. For example, a host may be dual stack and have an A record with an IPv4 address and a AAAA record with an IPv6 address in DNS. But on this host, there may be an IPv4-only application. So even though resolving the host name returns an IPv6 address, the application is not reachable over IPv6. A workaround would be to enter services names with corresponding record types (A records for IPv4 services and AAAA records for IPv6 services) in DNS. But how this is handled depends on operational practice and is therefore not reliable. A node resolving a DNS name and getting multiple addresses in the reply should try them all until a connection can be established.

The following list shows the most important IP dependencies in applications:

• Format of the IP address (32-bit dotted decimal or 128-bit hexadecimal with colons)

• API functions for the establishment of connections and data exchange

• DNS, resolving host names to IP addresses and vice versa

• IP address selection, caching/storage of addresses

• Multicast applications, depending on situation; correspondence of IPv4 and IPv6 multicast addresses and selection of correct socket configuration options

The best way to go is to make applications independent of the IP version. This means that the source code should not have any IP dependencies. The communication library should provide APIs that have no dependencies on IP.

Find a more detailed discussion of these issues in RFC 4038, "Application Aspects of IPv6 Transition."

The University of Tokyo and the Yokogawa Electric Corporation started the TAHI project in 1998. They develop tests that can be used by IPv6 developers to test their implementations for conformance to the standard and for interoperability. The tests can be used at no cost. This is their contribution to an efficient development and deployment of IPv6. The results of the tests are also provided to the developer community at no cost. On the TAHI web site (http://www.tahi.org), all tests are listed and documented.

The TAHI project works closely with other well-known projects: the WIDE project (http://www.wide.ad.jp), the KAME project (http://www.kame.net), and the USAGI project (http://www.linux-ipv6.org).