Request for Comments: 4038 ETRI/NIST
Category: Informational Y-G. Hong
ETRI
J. Hagino
IIJ
P. Savola
CSC/FUNET
E. M. Castro
GSYC/URJC
March 2005
Application Aspects of IPv6 Transition
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
As IPv6 networks are deployed and the network transition is
discussed, one should also consider how to enable IPv6 support in
applications running on IPv6 hosts, and the best strategy to develop
IP protocol support in applications. This document specifies
scenarios and aspects of application transition. It also proposes
guidelines on how to develop IP version-independent applications
during the transition period.
Table of Contents
1. Introduction ................................................. 3
2. Overview of IPv6 Application Transition ...................... 3
3. Problems with IPv6 Application Transition .................... 5
3.1. IPv6 Support in the OS and Applications Are Unrelated... 5
3.2. DNS Does Not Indicate Which IP Version Will Be Used .... 6
3.3. Supporting Many Versions of an Application Is Difficult. 6
4. Description of Transition Scenarios and Guidelines ........... 7
4.1. IPv4 Applications in a Dual-Stack Node ................. 7
4.2. IPv6 Applications in a Dual-Stack Node ................. 8
4.3. IPv4/IPv6 Applications in a Dual-Stack Node ............ 11
4.4. IPv4/IPv6 Applications in an IPv4-only Node ............ 12
5. Application Porting Considerations ........................... 12
5.1. Presentation Format for an IP Address .................. 13
5.2. Transport Layer API .................................... 14
5.3. Name and Address Resolution ............................ 15
5.4. Specific IP Dependencies ............................... 16
5.4.1. IP Address Selection ........................... 16
5.4.2. Application Framing ............................ 16
5.4.3. Storage of IP addresses ........................ 17
5.5. Multicast Applications ................................. 17
6. Developing IP Version - Independent Applications ............. 18
6.1. IP Version - Independent Structures..................... 18
6.2. IP Version - Independent APIs........................... 19
6.2.1. Example of Overly Simplistic TCP Server
Application .................................... 20
6.2.2. Example of Overly Simplistic TCP Client
Application .................................... 21
6.2.3. Binary/Presentation Format Conversion .......... 22
6.3. Iterated Jobs for Finding the Working Address .......... 23
6.3.1. Example of TCP Server Application .............. 23
6.3.2. Example of TCP Client Application .............. 25
7. Transition Mechanism Considerations .......................... 26
8. Security Considerations ...................................... 26
9. Acknowledgments .............................................. 27
10. References ................................................... 27
Appendix A. Other Binary/Presentation Format Conversions ........ 30
A.1. Binary to Presentation Using inet_ntop() ............... 30
A.2. Presentation to Binary Using inet_pton() ............... 31
Authors’ Addresses ............................................... 32
Full Copyright Statement ......................................... 33
1. Introduction
As IPv6 is introduced in the IPv4-based Internet, several general
issues will arise, such as routing, addressing, DNS, and scenarios.
An important key to a successful IPv6 transition is compatibility
with the large installed base of IPv4 hosts and routers. This issue
has already been extensively studied, and work is still in progress.
[2893BIS] describes the basic transition mechanisms: dual-stack
deployment and tunneling. Various other kinds of mechanisms have
been developed for the transition to an IPv6 network. However, these
transition mechanisms take no stance on whether applications support
IPv6.
This document specifies application aspects of IPv6 transition. Two
inter-related topics are covered:
1. How different network transition techniques affect
applications, and strategies for applications to support IPv6
and IPv4.
2. How to develop IPv6-capable or protocol-independent
applications ("application porting guidelines") using standard
APIs [RFC3493][RFC3542].
In the context of this document, the term "application" covers all
kinds of applications, but the focus is on those network applications
which have been developed using relatively low-level APIs (such as
the "C" language, using standard libraries). Many such applications
could be command-line driven, but that is not a requirement.
Applications will have to be modified to support IPv6 (and IPv4) by
using one of a number of techniques described in sections 2 - 4.
Guidelines for developing such applications are presented in sections
5 and 6.
2. Overview of IPv6 Application Transition
The transition of an application can be classified by using four
different cases (excluding the first case when there is no IPv6
support in either the application or the operating system):
+-------------------+
| appv4 | (appv4 - IPv4-only applications)
+-------------------+
| TCP / UDP / others| (transport protocols - TCP, UDP,
+-------------------+ SCTP, DCCP, etc.)
| IPv4 | IPv6 | (IP protocols supported/enabled in the OS)
+-------------------+
Case 1. IPv4 applications in a dual-stack node.
+-------------------+ (appv4 - IPv4-only applications)
| appv4 | appv6 | (appv6 - IPv6-only applications)
+-------------------+
| TCP / UDP / others| (transport protocols - TCP, UDP,
+-------------------+ SCTP, DCCP, etc.)
| IPv4 | IPv6 | (IP protocols supported/enabled in the OS)
+-------------------+
Case 2. IPv4-only applications and IPv6-only applications
in a dual-stack node.
+-------------------+
| appv4/v6 | (appv4/v6 - applications supporting
+-------------------+ both IPv4 and IPv6)
| TCP / UDP / others| (transport protocols - TCP, UDP,
+-------------------+ SCTP, DCCP, etc.)
| IPv4 | IPv6 | (IP protocols supported/enabled in the OS)
+-------------------+
Case 3. Applications supporting both IPv4 and IPv6
in a dual-stack node.
+-------------------+
| appv4/v6 | (appv4/v6 - applications supporting
+-------------------+ both IPv4 and IPv6)
| TCP / UDP / others| (transport protocols - TCP, UDP,
+-------------------+ SCTP, DCCP, etc.)
| IPv4 | (IP protocols supported/enabled in the OS)
+-------------------+
Case 4. Applications supporting both IPv4 and IPv6
in an IPv4-only node.
Figure 1. Overview of Application Transition
Figure 1 shows the cases of application transition.
Case 1: IPv4-only applications in a dual-stack node.
IPv6 protocol is introduced in a node, but
applications are not yet ported to support IPv6.
Case 2: IPv4-only applications and IPv6-only applications
in a dual-stack node.
Applications are ported for IPv6-only. Therefore
there are two similar applications, one for each
protocol version (e.g., ping and ping6).
Case 3: Applications supporting both IPv4 and IPv6 in a dual
stack node.
Applications are ported for both IPv4 and IPv6 support.
Therefore, the existing IPv4 applications can be
removed.
Case 4: Applications supporting both IPv4 and IPv6 in an
IPv4-only node.
Applications are ported for both IPv4 and IPv6 support,
but the same applications may also have to work when
IPv6 is not being used (e.g., disabled from the OS).
The first two cases are not interesting in the longer term; only few
applications are inherently IPv4- or IPv6-specific, and should work
with both protocols without having to care about which one is being
used.
3. Problems with IPv6 Application Transition
There are several reasons why the transition period between IPv4 and
IPv6 applications may not be straightforward. These issues are
described in this section.
3.1. IPv6 Support in the OS and Applications Are Unrelated
Considering the cases described in the previous section, IPv4 and
IPv6 protocol stacks are likely to co-exist in a node for a long
time.
Similarly, most applications are expected to be able to handle both
IPv4 and IPv6 during another long period. A dual-stack operating
system is not intended to have both IPv4 and IPv6 applications.
Therefore, IPv6-capable application transition may be independent of
protocol stacks in a node.
Applications capable of both IPv4 and IPv6 will probably have to
work properly in IPv4-only nodes (whether the IPv6 protocol is
completely disabled or there is no IPv6 connectivity at all).
3.2. DNS Does Not Indicate Which IP Version Will Be Used
In a node, the DNS name resolver gathers the list of destination
addresses. DNS queries and responses are sent by using either IPv4
or IPv6 to carry the queries, regardless of the protocol version of
the data records [DNSTRANS].
The DNS name resolution issue related to application transition is
that by only doing a DNS name lookup a client application can not be
certain of the version of the peer application. For example, if a
server application does not support IPv6 yet but runs on a dual-stack
machine for other IPv6 services, and this host is listed with an AAAA
record in the DNS, the client application will fail to connect to the
server application. This is caused by a mismatch between the DNS
query result (i.e., IPv6 addresses) and a server application version
(i.e., IPv4).
Using SRV records would avoid these problems. Unfortunately, they
are not used widely enough to be applicable in most cases. Hence an
operational solution is to use "service names" in the DNS. If a node
offers multiple services, but only some of them over IPv6, a DNS name
may be added for each of these services or group of services (with
the associated A/AAAA records), not just a single name for the
physical machine, also including the AAAA records. However, the
applications cannot depend on this operational practice.
The application should request all IP addresses without address
family constraints and try all the records returned from the DNS, in
some order, until a working address is found. In particular, the
application has to be able to handle all IP versions returned from
the DNS. This issue is discussed in more detail in [DNSOPV6].
3.3. Supporting Many Versions of an Application is Difficult
During the application transition period, system administrators may
have various versions of the same application (an IPv4-only
application, an IPv6-only application, or an application supporting
both IPv4 and IPv6).
Typically one cannot know which IP versions must be supported prior
to doing a DNS lookup *and* trying (see section 3.2) the addresses
returned. Therefore if multiple versions of the same application are
available, the local users have difficulty selecting the right
version supporting the exact IP version required.
To avoid problems with one application not supporting the specified
protocol version, it is desirable to have hybrid applications
supporting both.
An alternative approach for local client applications could be to
have a "wrapper application" that performs certain tasks (such as
figuring out which protocol version will be used) and calls the
IPv4/IPv6-only applications as necessary. This application would
perform connection establishment (or similar tasks) and pass the
opened socket to another application. However, as applications such
as this would have to do more than just perform a DNS lookup or
determine the literal IP address given, they will become complex --
likely much more so than a hybrid application. Furthermore, writing
"wrapping" applications that perform complex operations with IP
addresses (such as FTP clients) might be even more challenging or
even impossible. In short, wrapper applications do not look like a
robust approach for application transition.
4. Description of Transition Scenarios and Guidelines
Once the IPv6 network is deployed, applications supporting IPv6 can
use IPv6 network services to establish IPv6 connections. However,
upgrading every node to IPv6 at the same time is not feasible, and
transition from IPv4 to IPv6 will be a gradual process.
Dual-stack nodes provide one solution to maintaining IPv4
compatibility in unicast communications. In this section we will
analyze different application transition scenarios (as introduced in
section 2) and guidelines for maintaining interoperability between
applications running in different types of nodes.
Note that the first two cases, IPv4-only and IPv6-only applications,
are not interesting in the longer term; only few applications are
inherently IPv4- or IPv6-specific, and should work with both
protocols without having to care about which one is being used.
4.1. IPv4 Applications in a Dual-Stack Node
In this scenario, the IPv6 protocol is added in a node, but IPv6-
capable applications aren’t yet available or installed. Although the
node implements the dual stack, IPv4 applications can only manage
IPv4 communications and accept/establish connections from/to nodes
that implement an IPv4 stack.
To allow an application to communicate with other nodes using IPv6,
the first priority is to port applications to IPv6.
In some cases (e.g., when no source code is available), existing IPv4
applications can work if the Bump-in-the-Stack [BIS] or Bump-in-the-
API [BIA] mechanism is installed in the node. We strongly recommend
that application developers not use these mechanisms when application
source code is available. Also, they should not be used as an excuse
not to port software or to delay porting.
When [BIA] or [BIS] is used, the problem described in section 3.2
arises - (the IPv4 client in a [BIS]/[BIA] node tries to connect to
an IPv4 server in a dual stack system). However, one can rely on the
[BIA]/[BIS] mechanism, which should cycle through all the addresses
instead of applications.
[BIS] and [BIA] do not work with all kinds of applications - in
particular, with applications that exchange IP addresses as
application data (e.g., FTP). These mechanisms provide IPv4
temporary addresses to the applications and locally make a
translation between IPv4 and IPv6 communication. Therefore, these
IPv4 temporary addresses are only valid in the node scope.
4.2. IPv6 Applications in a Dual-Stack Node
As we have seen in the previous section, applications should be
ported to IPv6. The easiest way to port an IPv4 application is to
substitute the old IPv4 API references with the new IPv6 APIs with
one-to-one mapping. This way the application will be IPv6-only.
This IPv6-only source code cannot work in IPv4-only nodes, so the old
IPv4 application should be maintained in these nodes. This
necessitates having two similar applications working with different
protocol versions, depending on the node they are running (e.g.,
telnet and telnet6). This case is undesirable, as maintaining two
versions of the same source code per application could be difficult.
This approach would also cause problems for users having to select
which version of the application to use, as described in section 3.3.
Most implementations of dual stack allow IPv6-only applications to
interoperate with both IPv4 and IPv6 nodes. IPv4 packets going to
IPv6 applications on a dual-stack node reach their destination
because their addresses are mapped by using IPv4-mapped IPv6
addresses: the IPv6 address ::FFFF:x.y.z.w represents the IPv4
address x.y.z.w.
+----------------------------------------------+
| +------------------------------------------+ |
| | | |
| | IPv6-only applications | |
| | | |
| +------------------------------------------+ |
| | |
| +------------------------------------------+ |
| | | |
| | TCP / UDP / others (SCTP, DCCP, etc.) | |
| | | |
| +------------------------------------------+ |
| IPv4-mapped | | IPv6 |
| IPv6 addresses | | addresses |
| +--------------------+ +-------------------+ |
| | IPv4 | | IPv6 | |
| +--------------------+ +-------------------+ |
| IPv4 | | |
| addresses | | |
+--------------|-----------------|-------------+
| |
IPv4 packets IPv6 packets
We will analyze the behaviour of IPv6-applications that exchange IPv4
packets with IPv4 applications by using the client/server model. We
consider the default case to be when the IPV6_V6ONLY socket option
has not been set. In these dual-stack nodes, this default behavior
allows a limited amount of IPv4 communication using the IPv4-mapped
IPv6 addresses.
IPv6-only server:
When an IPv4 client application sends data to an IPv6-only
server application running on a dual-stack node by using the
wildcard address, the IPv4 client address is interpreted as the
IPv4-mapped IPv6 address in the dual-stack node. This allows
the IPv6 application to manage the communication. The IPv6
server will use this mapped address as if it were a regular
IPv6 address, and a usual IPv6 connection. However, IPv4
packets will be exchanged between the nodes. Kernels with dual
stack properly interpret IPv4-mapped IPv6 addresses as IPv4
ones, and vice versa.
IPv6-only client:
IPv6-only client applications in a dual-stack node will not
receive IPv4-mapped addresses from the hostname resolution API
functions unless a special hint, AI_V4MAPPED, is given. If it
is, the IPv6 client will use the returned mapped address as if
it were a regular IPv6 address, and a usual IPv6 connection.
However, IPv4 packets will be exchanged between applications.
Respectively, with IPV6_V6ONLY set, an IPv6-only server application
will only communicate with IPv6 nodes, and an IPv6-only client only
with IPv6 servers, as the mapped addresses have been disabled. This
option could be useful if applications use new IPv6 features such as
Flow Label. If communication with IPv4 is needed, either IPV6_V6ONLY
must not be used, or dual-stack applications must be used, as
described in section 4.3.
Some implementations of dual-stack do not allow IPv4-mapped IPv6
addresses to be used for interoperability between IPv4 and IPv6
applications. In these cases, there are two ways to handle the
problem:
1. Deploy two different versions of the application (possibly
attached with ’6’ in the name).
2. Deploy just one application supporting both protocol versions
as described in the next section.
The first method is not recommended because of a significant number
of problems associated with selecting the right applications. These
problems are described in sections 3.2 and 3.3.
Therefore, there are two distinct cases to consider when writing one
application to support both protocols:
1. Whether the application can (or should) support both IPv4 and
IPv6 through IPv4-mapped IPv6 addresses or the applications