Key issues in porting applications from IPv4 to IPv6
Note: This information is from Deliveable 3.2A (find more information in the LONG Web Page)

Today the Internet is predominantly based on IPv4. As a result, most of end systems and network devices are able to exchange packets all together in a global network. However, there is no a single global IPv6 network on the same scale and it will take some time to get it. Therefore, new applications should be designed to work in all environments: single IPv4, single IPv6 or mixed communication when group collaborative applications are considered.

In the design of applications to use IPv6 some characteristics must be taken into account. First of all it is necessary to separate the transport module from the rest of application functional modules. This separation makes the application independent on the network system used. Then, if the network protocol is changed, only the transport module should be modified. Transport module should provide the communication channel abstraction with basic channel operations and generic data structures to represent the addresses. These abstractions could be instantiated as different implementations depending on the network protocol required at any moment. The application will deal with this generic communication channel interface without knowing the network protocol used. Using this design if a new network protocol is added, application developers only need to implement a new instance of the channel abstraction which manages the features of this new protocol.
Once the transport module has been designed, there are some implementation details related to the type of the nodes which will run the application: IPv4-only nodes, IPv6-only nodes or both, dual stack.
Within the transport module the use of the new API with extensions for IPv6 is mandatory, but it is strongly recommended to make the program protocol independent (for instance, using the BSD socket API consider getaddrinfo and getnameinfo instead of gethostbyname and gethostbyaddr). The new IPv6 functions are only valid if this protocol is supported by all installed systems. IPv6 is now reaching maturity and most popular systems provide it as default in their standard distributions. However, IPv6 support does not force to use it, only after the complete network configuration is defined, applications will use IPv4 or IPv6.
Protocol independent code is feasible if design is based on the principal building block for transitioning, the dual stack. Dual stacks maintain two protocol stacks that operate in parallel and thus it is allowed to operate via either protocol. The operating system running dual stack translates IPv4 addresses to IPv4-mapped IPv6 ones when communicating to IPv4 remote applications. In the following sections the connections between IPv6 server and IPv6 client applications when they are running on a dual stack node will be analyzed.
If a server application is running bound to the IPv6 wildcard address and a known port on a dual stack node, it will be able to accept connections from IPv4 and IPv6 clients, see Figure 2. When an IPv4 client is connecting to this IPv6 server, the dual stack kernel converts the client IPv4 address to the IPv4-mapped IPv6 address since the IPv6 server can only deal with IPv6 connections. The communication between the IPv4 client and the IPv6 server will take place using IPv4 datagrams, but the server will not know that it is communicating with an IPv4 client, unless the server explicitly checks it.
When running an IPv6 client application on a dual stack node, the client can connect to an IPv6 or IPv4 server. Since the client node runs dual stack, client will try to open an IPv6 connection to the server. If  server is running over IPv4, the resolved server address returned by the resolver system is the IPv4-mapped IPv6 one. Then, the communication between IPv4 server and IPv6 client, which is running on the dual stack, is carried out using IPv4 but the IPv6 client will not know it, unless the client explicitly checks it.
Figure - Protocol independent application on dual-stack host

Although applications are written following program protocol independent rules, other points have to be considered such as the movement of binary code between IPv4-only nodes, dual stacks nodes or IPv6-only nodes.
Compilation options (#ifdefs in C language) can be provided throughout the code to select the proper use environment. If IPv6 is not supported the IPv4-only code will be selected for compilation during installation process. However, if IPv6 is supported (Kernel level support) by installed systems, the code for IPv6 or the IPv4 could be selected for compilation, depending on the requirements of applications. Notice that if IPv6 is supported by the kernel, it only means the IPv6 option could be activated and while this option is disabled the node will be only use IPv4 stack. During the transition period nodes are usually running dual stack, both IPv4 and IPv6 stacks. The problem with the conditional compilation approach is that the code becomes littered with compilation options very quickly and harder to follow and maintain.
If an application is compiled on a system which supports dual stack and move the binary code to an IPv4-only node without IPv6 kernel support, the source code must be  recompiled to use the original IPv4 API. The binary code generated on the dual stack uses the new system functions which are not supported in the IPv4-only node.
If the binary code is moved, which has been compiled on a dual stack, to an IPv4-only node with IPv6 kernel support and IPv6 stack not activated, recompilation is not required. Since the IPv6 stack is not activated, the node can not establish IPv6 connections. However, the  resolver system could return an IPv6 address to an application query and the application should be prepared to discard this IPv6 address and select the IPv4 one to open connections.
All these alternatives are summarized in Table 4.
Table - IPv4 or IPv6 activation
In summary, if applications follow the recommendations explained above, using a separated protocol independent transport module, which provides a generic communication API, it is easy to adapt them to new network protocols. Besides, the generic communication API could be implemented as a communication library to be used for many applications. This solution encourages the code reusability and makes communication modules of applications easy to maintain.