INTERNET DRAFT Myung-Ki Shin
Expires: December 2003 Yong-Guen Hong
ETRI
Jun-ichiro itojun Hagino
IIJ
Pekka Savola
CSC/FUNET
Eva M. Castro
GSYC/URJC
June 2003
Application Aspects of IPv6 Transition
<draft-shin-v6ops-application-transition-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsolete by other documents
at anytime. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The document specifies application aspects of IPv6 transition. As
IPv6 is deployed, the application developers and the administrators
will face several problems. This draft clarifies the problems and
considerations occurring in transition period between IPv4
applications and IPv6 applications. It also proposes guidelines
that help application developers understand how to develop IP
version-independent applications during the transition period.
Shin et al. Expires December 2003 [Page 1]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
Table of Contents:
1. Introduction .............................................. 2
2. Overview of IPv6 application transition ................... 3
3. Problems with IPv6 application transition ................. 4
3.1 Dual stack vs. application versions ...................... 4
3.2 DNS name resolution ...................................... 4
3.3 Application selection .................................... 4
4. Description of transition scenarios and guidelines ........ 5
4.1 IPv4 applications in a dual-stack node ................... 6
4.2 IPv6 applications in a dual-stack node ................... 6
4.3 IPv4/IPv6 applications in a dual stack node .............. 9
4.4 IPv4/IPv6 applications in an IPv4-only node .............. 9
5. Application porting considerations ........................10
5.1 Presentation format for an IP address ....................10
5.2 Transport layer API ..................................... 11
5.3 Name and address resolution ............................. 12
5.4 Specific IP dependencies ................................ 12
6. Developing IP version-independent applications ........... 13
6.1 IP version-independent structures ....................... 14
6.2 IP version-independent APIs ............................. 14
6.3 Iterated jobs for finding the working address ........... 18
7. Transition mechanism considerations ...................... 19
8. Security considerations .................................. 19
9. References ............................................... 20
Authors' Addresses .......................................... 21
1. Introduction
As IPv6 is introduced in the IPv4-based Internet, several general
issues when starting to use IPv6 in a predominant IPv4 world are
being discussed, such as routing, addressing, DNS, scenarios, etc.
One important key to a successful IPv6 transition is the
compatibility with the large installed base of IPv4 hosts and
routers. This issue had been already studied in [RFC 2893] and [RFC
2185]. In addition, various kinds of transition mechanisms have
been developed to migrate to IPv6 network. However, even if these
mechanisms are fully deployed, we still have problems occuring in
the transition period between IPv4 applications and IPv6
applications.
This document specifies application aspects of IPv6 transition. As
IPv6 networks are deployed and the network transition discussed, we
should also consider IPv6 application porting in a node.
[BIS] and [BIA] have been proposed as short-term solutions, but
these mechanisms should not be used when the application-specific
source code is available. Ultimately, application developers will
modify application programs to support both IPv4 and IPv6 (named,
IP version-independent program). During the transition period,
Shin et al. Expires December 2003 [Page 2]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
administrators may have various versions of an application (IPv4-
only, IPv6-only or one supporting both IPv4 and IPv6) in a node
(dual-stack or IPv4-only node).
This draft clarifies the problems and considerations occurring in
the transition period between IPv4 applications and IPv6
applications. It also proposes guidelines that help application
developers understand how to develop IP version-independent
applications during the transition period.
2. Overview of IPv6 application transition
The transition of an application can be classifed as follows:
+-------------------+
| appv4 | (appv4 - IPv4-only applications)
+-------------------+
| TCP / UDP |
+-------------------+
| IPv4 | IPv6 |
+-------------------+
Case 1. IPv4 applications in a dual-stack node
+-------------------+
| appv4 | appv6 | (appv6 - IPv6-only applications)
+-------------------+
| TCP / UDP |
+-------------------+
| IPv4 | IPv6 |
+-------------------+
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 |
+-------------------+
| IPv4 | IPv6 |
+-------------------+
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 |
+-------------------+
| IPv4 |
+-------------------+
Case 4. Applications supporting both IPv4 and IPv6
Shin et al. Expires December 2003 [Page 3]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
in an IPv4-only node
Figure 1. Overview of IPv6 Application Transition
Figure 1 shows the cases of IPv6 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 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 same applications for different
protocol versions (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 to ease support, the same applications may also
have to work when IPv6 is not used.
3. Problems with IPv6 application transition
As IPv6 is deployed, the application developers and the
administrators will face several problems.
3.1 Dual-stack vs. application versions
Considering the cases above, IPv4 and IPv6 protocol stack in a node
is likely to co-exist for a long time. During this period,
applications are expected to be able to handle IPv6 over some time
period, not at the same time as IPv6 protocol is introduced. That
is, operating system being dual stack does not mean having both
IPv4 and IPv6 applications. Therefore, application introduction may
be independent of protocol stacks in a node.
It is even probable that applications capable of both IPv4 and IPv6
will have to work properly IPv4-only nodes (whether IPv6 protocol
is completely disabled or there is no IPv6 connectivity at all).
3.2 DNS name resolution
Shin et al. Expires December 2003 [Page 4]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
The role of the DNS name resolver in a node is to get the list of
destination addresses. DNS queries and responses are sent using
IPv4 transport, even though IPv6 addresses are being resolved, or
using IPv6 transport. This issue has been already discussed in
[DNS].
The issue of DNS name resolving related to application transition
is that a client application can not know the version of peer
application by only doing a DNS name lookup. For example, if a
server application does not support IPv6 yet, but runs on a dual-
stack machine for other IPv6 services and this is listed with a
AAAA record in the DNS, the client application will fail to connect
to the server application, because there is a mis-match between the
DNS query result (i.e. IPv6 addresses) and a server application
version (i.e. IPv4).
It is bad practise to add a AAAA record for node that does not
support all the services using IPv6 (rather, a AAAA record for the
specific service name and address should be used), but the
application cannot depend on "good practise", and this must be
handled.
In consequence, the application has to try both protocol versions,
and if the first to try fails, detect the failure and try using the
other protocol version.
3.3 Application selection
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). Therefore, the users may be confused by their
various application versions, because they don't know the version
of peer application by DNS query results.
To avoid problems with mismatching DNS query results, it is
desirable to have hybrid applications, supporting both protocol
versions. Alternative approach is to have a "wrapper application"
which performs certain tasks (like figures out which protocol
version will be used) and calls the IPv4/IPv6-only applications as
necessary (these kind of "wrapper applications" only work for
certain kinds of, usually simple, applications). Nonetheless,
there should be some reasonable logic on how to perform application
selection.
4. Description of transition scenarios and guidelines
Once the IPv6 network is deployed, applications can use IPv6
network services and establish IPv6 connections. However,
upgrading every node to IPv6 at the same time is not feasible and
Shin et al. Expires December 2003 [Page 5]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
transition from IPv4 to IPv6 will be a gradual process.
Dual-stack nodes are one of the ways to maintain IPv4 compatibility
in unicast communications. In this section we will analyze
different transition scenarios and guidelines to maintain
interoperability between applications running in different type of
nodes.
4.1 IPv4 applications in a dual-stack node
This scenario happens if 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 IPv4 packets will be
exchanged. Then, IPv4 applications can only accept/establish
connections from/to nodes which implement IPv4 stack.
There could be some problems when an IPv4 client tries to connect
to an IPv4 server running at dual stack. At the client side, the
resolver can return all IP addresses of the server node, however
only IPv4 ones will be valid for the IPv4 client application. The
client application should be modified to cycle through all the
addresses and end up trying the IPv4 one.
In order to allow an application to communicate with other nodes
exchanging IPv6 packets, the first priority is to port applications
to IPv6. In some cases (e.g. no source code is available), existing
IPv4 applications can work if the [BIS] or [BIA] mechanism is
installed in the node. The main difference between them is, while
[BIS] is for systems with no IPv6 stack, [BIA] is for systems with
an IPv6 stack. Thus, [BIS] is not proper on installation in a
dual-stack node. These mechanisms translate between IPv4 and IPv6
communications. However, these mechanisms should not be used when
an application source code is available to prevent the mis-use of
them, for example, an excuse not to port software.
Considering the applicability of [BIA] and [BIS], it is good for
early adopters who do not have all applications handy, but not for
mainstream production usage. Besides, not all applications work
using these mechanisms, if applications exchange IP addresses as
application data, these mechanisms will not be able to solve the
problem.
When [BIA] or [BIS] is used, the same previous problem --the IPv4
client in a [BIS]/[BIA] node trying to connect to an IPv4 server in
a dual stack-- arises. In this case, not always we will be able to
use the same mechanism that before, since most cases the source
code will not be available. However, we can rely on [BIA]/[BIS]
mechanism, which should cycle through all the addresses instead of
applications.
Shin et al. Expires December 2003 [Page 6]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
4.2 IPv6 applications in a dual-stack node
As we have seen in the previous section, finally applications
should be ported to IPv6. The easiest way to port an IPv4
application is to substitute the old IPv4 API references by the
IPv6 new ones, one-to-one API mapping. Then, an IPv6-only source
code is obtained. This IPv6-only source code can not work in IPv4-
only nodes, so the old IPv4 application should be maintained in
these nodes. Then, we will get two same applications working with
different protocol versions, depending on the node they are running
(e.g., telnet and telnet6). This case is undesirable since
maintaining two versions of the same source code per application,
could be a difficult task.
Most implementations of dual stack allow IPv6-only applications
interoperate with IPv4 and IPv6 ones. IPv4 packets going to IPv6
applications on a dual-stack node, reach their destination because
their addresses are mapped to IPv6 ones using IPv4-mapped IPv6
addresses: from x.y.z.w IPv4 address the ::FFFF.x.y.z.w IPv4-mapped
IPv6 address is built.
+----------------------------------------------+
| +------------------------------------------+ |
| | | |
| | IPv6-only applications | |
| | | |
| +------------------------------------------+ |
| | |
| +------------------------------------------+ |
| | | |
| | TCP/UDP | |
| | | |
| +------------------------------------------+ |
| IPv4-mapped | | IPv6 |
| IPv6 addresses | | addresses |
| +--------------------+ +-------------------+ |
| | IPv4 | | IPv6 | |
| +--------------------+ +-------------------+ |
| IPv4 | | |
| adresses | | |
+--------------|-----------------|-------------+
| |
IPv4 packets IPv6 packets
When an IPv4 client application sends data to an IPv6-only server,
running on a dual-stack node using wildcard address, the IPv4
client address is translated to the IPv4-mapped IPv6 address in the
dual-stack node to allow IPv6 application to manage this
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 applications.
Shin et al. Expires December 2003 [Page 7]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
Kernels with dual stack properly translate IPv4-mapped IPv6
addresses to IPv4 ones and vice versa.
When an IPv6 client application, in a dual-stack node, sends data
to an IPv4 server application, the IPv6 client will get an IPv4-
mapped IPv6 address from the hostname resolution API functions. The
IPv6 client will use this special address as if it were a regular
IPv6 address, and a usual IPv6 connection. However, again IPv4
packets will be exchanged between applications.
The interoperability between IPv4 and IPv6 applications, using the
client/server communication model, provided by the dual-stack can
be summarized as follows:
+-------------------+-------------------+
| IPv4 server | IPv6 server |
+---------+---------+---------+---------+
| IPv4- | Dual | IPv6- | Dual |
| only | stack | only | stack |
| node | node | node | node |
+-------+---------+---------+---------+---------+---------+
| |IPv4-only| | | | IPv4 |
| |node | {IPv4} | IPv4 | -- | (mapped |
| | | | | | addr) |
|IPv4 |---------+---------+---------+---------+---------+
|client |Dual- | | | | IPv4 |
| |stack | IPv4 | IPv4 | -- | (mapped |
| |node | | | | addr) |
+-------+---------+---------+---------+---------+---------+
| |IPv6-only| | | | |
| |node | -- | -- | {IPv6} | IPv6 |
| | | | | | |
|IPv6 |---------+---------+---------+---------+---------+
|client |Dual- | IPv4 | IPv4 | | |
| |stack | (mapped | (mapped | IPv6 | IPv6 |
| |node | addr) | addr) | | |
+-------+---------+---------------------------------------+
Note : { } means that this combination is not needed
in this scenario.
The default behavior of IPv6 applications in these dual-stack nodes
allows the IPv4 communication using the IPv4-mapped IPv6 addresses.
However, it is possible IPv6 applications allow connections only
with IPv6 nodes (e.g. IPv6_ONLY socket option), so the
interoperability with IPv4 nodes is broken. This option could be
useful if applications use new IPv6 features, such as flowlabel.
There are other implementations of dual stack which do not use
IPv4-mapped IPv6 addresses to allow the interoperability between
IPv4 and IPv6 applications. Then, the two application versions
should run in the same dual stack node, with different names
(possibly attached with '6'). Simple application selection rule is
Shin et al. Expires December 2003 [Page 8]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
as follows:
rule 1 - default application selection is the application for
IPv6, only if IPv6 connectivity is provided.
rule 2 - if it fails, then the IPv4 application is tried.
4.3 IPv4/IPv6 applications in a dual stack node
Applications should be ported for both IPv4 and IPv6 support, named
dual applications or IP version-independent applications, and then
the existing IPv4 applications could be removed. Since we have an
only version of each application, the source code will be easy to
maintain and to modify.
This transition case is the most advisable. During IPv6 transition
period, applications supporting both IPv4 and IPv6 should be able
to communicate with other applications, irrespective of the
versions of the protocol stack or the application in the node. Dual
applications allow more interoperability between heterogeneous
applications and nodes.
If the source code is written in a protocol independent way,
neither IPv4 supposition nor IPv6, applications will be able to
communicate with any combination of application and type of node.
Applications should prefer IPv6 if the remote node and application
support it. However if IPv6 connections fail, dual applications
will automatically try IPv4 ones. The resolver returns a list of
valid addresses for the remote node and applications can iterate
through all, firstly trying IPv6 ones, until connection succeeds.
A more detail porting guideline will be described in section 6.
4.4 IPv4/IPv6 applications in an IPv4-only node
As the transition is likely to happen over a longer timeframe,
applications that have already been ported to support both IPv4 and
IPv6 may be run on IPv4-only nodes. This would typically be done to
avoid having to support two application versions for older and
newer operating systems, or to support the case that the user wants
to disable IPv6 for some reason.
Depending on how application/operating system support is done, some
may want to ignore this case, but usually no assumptions can be
made and applications should work in this scenario too.
An example is an application that issues a socket() command, first
trying AF_INET6 and then AF_INET. However, if the kernel does not
have IPv6 support, the call will result in an EPROTONOSUPPORT or
EAFNOSUPPORT error. Typically, if errors are encountered, this
Shin et al. Expires December 2003 [Page 9]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
leads to exiting the socket loop, and AF_INET6 will not even be
tried. The application will need to handle this case or build the
loop in such a way that errors are ignored until the last address
family.
So, this case is just an extension of the IPv4/IPv6 support in the
previous case, covering one relatively common but often ignored
case.
5. Application porting considerations
The minimum changes in IPv4 applications to work using IPv6 are
basically based on the different size and format of IPv4 and IPv6
addresses.
Applications have been developed with the assumption they would use
IPv4 as network protocol. This assumption is the responsible of
many IP dependencies through source code.
The following list summarizes the more common IP version
dependencies in applications:
a) Presentation format for an IP address: it is an ASCII string
which represents the IP address, dotted-decimal string
for IPv4 and hexadecimal string for IPv6.
b) Transport layer API: functions to establish communications
and to exchange information.
c) Name and address resolution: conversion functions between
hostnames and IP addresses, and vice versa.
d) Specific IP dependencies: more specific IP version
dependencies, such as: IP address selection,
application framing, storage of IP addresses.
Next, the problems with the previous IP version dependencies are
analyzed and some recommendations are given to modify the
application source code in a protocol independent way, which will
allow applications to work in both IPv4 and IPv6 nodes.
5.1 Presentation format for an IP address
Many applications use IP addresses to identify network nodes and to
establish connections to destination addresses. For instance, on
using the client/server model, clients usually need an IP address,
as an application parameter, to connect to a server. This IP
address is usually provided in the presentation format, as string.
There are two problems, when porting the presentation format for an
IP address: the allocated memory and the management of the
Shin et al. Expires December 2003 [Page 10]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
presentation format.
Usually, the allocated memory to contain an IPv4 address
representation as string is not enough to contain an IPv6 one.
Applications should be modified to prevent from overflowing the
buffer holding the presentation format for an IP address, larger in
IPv6.
IPv4 and IPv6 do not use the same presentation format. IPv4 uses
dot (.) to separate the four octets written in decimal notation and
IPv6 uses colon (:) to separate each pair of octets written in
hexadecimal notation. In order to support both, IPv4 and IPv6, the
management functions of presentation format, such as IP address
parsers, should be changed to be complaint with both formats.
A particular case of an IP address parser is presented when
managing the Uniform Resource Locators (URLs). Applications using
URLs, as Internet browsers, should accept the literal IP address
enclosed in brackets [RFC 2732]. For instance:
http://[IPv6Address]:80/index.html. This new format solves the
ambiguity with the colon character, since it is used in the IPv6
addresses as a separator between each pair of address octets and in
the IPv4 networks as a separator between the address and the
service port number.
The use of FQDNs instead of presentation format for IP addresses is
always preferable, since FQDNs keep the same format in IPv4 and
IPv6.
5.2 Transport layer API
Communication applications often include a transport module that
establishes communications. Usually, this module manages everything
related to communications and uses a transport layer API, typically
as a network library. When porting to IPv6 most changes should be
made in this application transport module, in order to be adapted
to the new IPv6 API.
As a general case, porting an existing application to IPv6 requires
to examine the following issues related to the API:
- Network information storage: IP address data structures.
The new structures must contain 128-bit IP addresses. The use of
generic address structures, which can store any address family,
is recommended.
Sometimes special addresses are hard-coded in the application
source; developers should pay attention to them in order to use
the new address format. Some of these special IP addresses are:
wildcard local, loopback and broadcast. IPv6 is not implementing
the broadcast addresses, so applications can use multicast
instead.
Shin et al. Expires December 2003 [Page 11]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
- Address conversion functions.
The address conversion functions convert binary address
representation to presentation format and vice versa. The new
conversion functions are prepared to the IPv6 address format.
- Communication API functions.
These functions manage communications. Their signatures are
defined based on generic socket address structure. Then, the
same functions are valid for IPv6. However, the IP address data
structures used when calling these functions require the
updates.
- Network configuration options.
They are used when configuring different communication models
for Input/Output (I/O) operations (blocking/nonblocking, I/O
multiplexing, etc) and should be translated to the IPv6 ones.
5.3 Name and address resolution
Applications usually call functions in a system library, known as
the resolver, to realize the name and address resolution. Since
these functions use IP address structures, which are protocol
dependent, not only the functions but also the structures must be
reviewed to support IPv6.
There are new resolution functions that provide protocol
independence for applications, since knowing the address family is
not required to carry out the resolution.
Resolution queries should not be constrained to one address family,
IPv4 or IPv6 addresses. For intance, when getting IP addresses for
a hostname, applications should ask for all configured IP addresses
to allow applications to communicate to every kind of node.
5.4 Specific IP dependencies
5.4.1 IP address selection
IPv6 promotes the configuration of multiple IP addresses per node,
which is a different model of IPv4; however applications only use a
destination/source pair for a communication. Choosing the right IP
source and destination addresses is a key factor that may determine
the route of IP datagrams.
Typically nodes, not applications, automatically solve the source
address selection. A node will choose the source address for a
communication following some rules of best choice, [RFC 3484], but
also allowing applications to make changes in the ordering rules.
When selecting the destination address, applications usually ask a
Shin et al. Expires December 2003 [Page 12]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
resolver for the destination IP address. The resolver returns a set
of valid IP addresses from a hostname. Applications should select
from this list which destination address to use. They may try each
element in the list until the communication succeeds.
5.4.2 Application framing
The Application Level Framing (ALF) architecture controls
mechanisms that traditionally fall within the transport layer.
Applications implementing ALF are often responsible for packetizing
data into Application Data Units (ADUs). The application problem
when using ALF is the ADU size selection to obtain better
performance.
Applications can use 1280 octets as data length. [RFC 2460]
specifies IPv6 requires that every link in the Internet have an
Maximum Transmission Unit (MTU) of 1280 octets or greater. However,
in order to get better performance ADU size should be calculated
based on the length of transmission unit of underlying protocols.
5.4.3 Storage of IP addresses
Some applications store IP addresses as information of remote
peers. For instance, one of the most popular ways to register
remote nodes in collaborative applications is based on using IP
addresses as registry keys.
Although the source code that stores IP addresses can be modified
to IPv6 following the previous basic porting recommendations, there
are some reasons why applications should not store IP addresses:
- IP addresses can change throughout the time, for instance
after a renumbering process.
- The same node can reach a destination host using different
source IP addresses, all of them configured in the source
network interface.
Instead of using IP addresses, applications should use FQDNs.
Hence, applications delegate the resolution of the IP addresses to
the name resolution system, which will return the associated IP
address at the moment of the query.
6. Developing IP version-independent applications
As we have seen before, dual applications working on IPv4 and IPv6
are recommended. These applications should avoid IP dependencies in
the source code. However if IP dependencies are required, one of
the best solutions is based on building a communication library
Shin et al. Expires December 2003 [Page 13]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
which provides an IP version independent API to applications and
hides all dependencies.
In order to get IP version independent source code, the following
developing guidelines should be considered.
6.1 IP version-independent structures
All of the memory structures and APIs should be IP version-
independent. In that sense, we should avoid struct in_addr and
in6_addr, and struct sockaddr_in and struct sockaddr_in6.
Suppose you pass an network address to some function, foo(). If you
use struct in_addr or struct in6_addr, you will end up with extra
parameter to indicate address family, as below:
struct in_addr in4addr;
struct in6_addr in6addr;
/* IPv4 case */
foo(&in4addr, AF_INET);
/* IPv6 case */
foo(&in6addr, AF_INET6);
This way the network address and address family is will not live
together, and leads to bunch of if/switch statement and mistakes in
programming. So, we should use struct sockaddr_storage like below.
struct sockaddr_storage ss;
int sslen;
/* AF independent! - use sockaddr when passing a pointer */
foo((struct sockaddr *)&ss);
/* if you need portability to Linux/Solaris,
you need to pass length explicitly */
foo((struct sockaddr *)&ss, sslen);
6.2 IP version-independent APIs
getaddrinfo() and getnameinfo() are new address independent variant
that hides every gory detail in name-to-address translation, or
vice versa. It implements functionalities for the following
functions:
gethostbyname()
gethostbyaddr()
getservbyname()
getservbyport()
These can perform DNS/hostname table lookup, though it can be
turned off if you want. getaddrinfo() can return multiple
addresses, if a host have multiple address with multiple address
Shin et al. Expires December 2003 [Page 14]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
families, as below:
localhost. IN A 127.0.0.1
IN AAAA ::1
It can query hostname as well as service name/port at once.
Therefore, we can bury all the gory details about initializing
sockaddr structure into library function.
As well, it is not preferred to hardcode AF-dependent knowledge
into the program. The construct like below should be avoided:
/* BAD EXAMPLE */
switch (sa->sa_family) {
case AF_INET:
salen = sizeof(struct sockaddr_in);
break;
}
Instead, we should use res->ai_addrlen returned by getaddrinfo().
The gethostbyname(), gethostbyaddr(), getservbyname(), and
getservbyport() are mainly used to get server and client sockets.
Following, we will see simple examples to create these sockets
using the net IPv6 resolution functions.
A simple TCP server socket at service name (or port number string)
SERVICE:
struct addrinfo hints, *res;
int error, sockfd;
memset(&hints, 0, sizeof(hints));
hints.ai_flags = AI_PASSIVE;
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
error = getaddrinfo(NULL, SERVICE, &hints, &res);
if (error != 0) {
/* handle getaddrinfo error */
}
sockfd = socket(res->family, res->ai_socktype, res->ai_protocol);
if (sockfd < 0) {
/* handle socket error */
}
if (bind(sockfd, res->ai_addr, res->ai_addrlen) < 0) {
/* handle bind error */
}
/* ... */
Shin et al. Expires December 2003 [Page 15]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
freeaddrinfo(res);
A simple TCP client socket connecting to a server which is running
at node name (or IP address presentation format) SERVER_NODE and
service name (or port number string) SERVICE:
struct addrinfo hints, *res;
int error, sockfd;
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
error = getaddrinfo(SERVER_NODE, SERVICE, &hints, &res);
if (error != 0) {
/* handle getaddrinfo error */
}
sockfd = socket(res->family, res->ai_socktype, res->ai_protocol);
if (sockfd < 0) {
/* handle socket error */
}
if (connect(sockfd, res->ai_addr, res->ai_addrlen) < 0 ) {
/* handle connect error */
}
/* ... */
freeaddrinfo(res);
In addition, we should consider the binary and presentation address
format conversion APIs. The following functions convert network
address structure in its presentation address format and vice
versa:
inet_ntop()
inet_pton()
Both are from the basic socket extensions for IPv6. Since these
functions are not protocol independent, we should write code for
the different address families.
a) Conversions from network address structure to presentation
format can be written:
struct sockaddr_storage ss;
char addrStr[ADDR_STRLEN];
/* fill ss structure */
switch (ss.ss_family) {
Shin et al. Expires December 2003 [Page 16]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
case AF_INET:
inet_ntop(ss.ss_family,
&((struct sockaddr_in *)&ss)->sin_addr,
addrStr,
sizeof(addrStr));
break;
case AF_INET6:
inet_ntop(ss.ss_family,
&((struct sockaddr_in6 *)&ss)->sin6_addr,
addrStr,
sizeof(addrStr));
break;
default:
/* handle unknown family */
}
Note, the destination buffer addrStr should be long enough to
contain the presentation address format: INET_ADDRSTRLEN for IPv4
and INET6_ADDRSTRLEN for IPv6. Then, ADDR_STRLEN should be at least
the maximum between them.
However, this conversion is protocol dependent. We can write the
same conversion using getnameinfo() in a protocol independent way.
struct sockaddr_storage ss;
char addrStr[ADDR_STRLEN];
char addrStr[SERV_STRLEN];
int error;
/* fill ss structure */
error = getnameinfo((struct sockaddr *)&ss, sizeof(ss),
addrStr, sizeof(addrStr),
servStr, sizeof(servStr),
NI_NUMERICHOST);
b) Conversions from presentation format to network address
structure can be written as follows:
struct sockaddr_storage ss;
struct sockaddr_in *sin;
struct sockaddr_in6 *sin6;
char addrStr[ADDR_STRLEN];
/* fill addrStr buffer and ss.ss_family */
switch (ss.ss_family) {
case AF_INET:
sin = (struct sockaddr_in *)&ss;
Shin et al. Expires December 2003 [Page 17]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
inet_pton(ss.ss_family,
addrStr,
(sockaddr *)&sin->sin_addr));
break;
case AF_INET6:
sin6 = (struct sockaddr_in6 *)&ss;
inet_pton(ss.ss_family,
addrStr,
(sockaddr *)&sin6->sin6_addr);
break;
default:
/* handle unknown family */
}
Note, the address family of the presentation format must be known.
This conversion may be also written in a protocol independent way
using getaddrinfo().
struct addrinfo hints, *res;
char addrStr[ADDR_STRLEN];
int error;
/* fill addrStr buffer */
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC;
error = getaddrinfo(addrStr, NULL, &hints, &res);
if (error != 0) {
/* handle getaddrinfo error */
}
/* res->ai_addr contains the network address structure */
/* ... */
freeaddrinfo(res);
6.3 Iterated jobs for finding the working address
In a client code, when multiple addresses are returned from
getaddrinfo(), we should try all of them until connection succeds.
When there exist failure on socket() or connect(), go on to next
address. That is, the client code should do iterated jobs (using
the other application out of addresses returned by the
getaddrinfo().
In addition, if something is wrong with the socket call because the
address family is not supported (i.e., in case of section 4.4),
Shin et al. Expires December 2003 [Page 18]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
developers should try the next address structure.
Then, the previous TCP client example should be written:
struct addrinfo hints, *res, *aip;
int sockfd, error, afNotSupp;
afNotSupp=AF_UNSPEC; /* overwrite the family not
supported in this machine */
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
error = getaddrinfo(SERVER_NODE, SERVICE, &hints, &res);
if (error != 0) {
/* handle getaddrinfo error */
}
for (aip=res; aip; aip=aip->ai_next) {
if (aip->ai_family == afNotSupp)
continue;
sockfd = socket(aip->ai_family,
aip->ai_socktype,
aip->ai_protocol);
if (sockfd < 0) {
switch errno {
case EAFNOSUPPORT:
/* handle unknown protocol errors */
afNotSupp=aip->ai_family;
break;
default:
/* handle other socket errors */
;
}
} else {
if (connect(sockfd, aip->ai_addr, aip->ai_addrlen) == 0)
break;
/* handle connect errors */
close(sockfd);
sockfd=-1;
}
}
if (sockfd > 0) {
/* socket connected to server address */
Shin et al. Expires December 2003 [Page 19]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
/* ... */
}
freeaddrinfo(res);
7. Transition mechanism considerations
Under [NAT-PT] mechanism, a pair of IPv6-only and IPv4-only
applications could be enough but one should note one special case
(NAT-PT prefix + IPv4 address) which one might be tempted to handle
differently. This is an IPv4 addresses, translated by NAT-PT DNS
ALG [DNS-ALG]. IPv6 applications, in general, must not be required
to distinguish "normal" and "NAT-PT translated" addresses: that
would be completely unscalable, and if such distinction must be
made, it must be done elsewhere (e.g. kernel, system libraries).
8. Security considerations
See the each security consideration section listed in section 9 -
Normative References. Each issue on application transtion is not
studied yet.
One particular point about application transition is how IPv4-
mapped IPv6-addresses are handled. The use in the API can be seen
as both a merit (easier application transition) and as a burden
(difficulty in ensuring whether the use was legimate) [V6MAPPED].
This may have to be considered in more detail.
9. References
Normative References
[RFC 2553] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic
Socket Interface Extensions for IPv6," RFC 2553, March
1999.
[RFC 3542] W. Stevens, M. Thomas, E. Nordmark, T. Jinmei, "Advanced
Sockets Application Program Interface (API) for IPv6,"
RFC 3542, May 2003.
[BIS] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts
using the "Bump-In-the-Stack" Technique (BIS)," RFC 2767,
February 2000.
[BIA] S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand,
"Dual Stack Hosts using "Bump-in-the-API" (BIA)," RFC
3338, October 2002.
[NAT-PT] G. Tsirtsis, P. Srisuresh, "Network Address Translation
Shin et al. Expires December 2003 [Page 20]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
- Protocol Translation (NAT-PT)," RFC 2766, February 2000.
Informative References
[RFC 2893] R Gilligan, E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers," RFC 2893, August 2000.
[RFC 2185] R. Callon, D. Haskin, "Routing Aspects Of IPv6
Transition," RFC 2185, September 1997.
[RFC 2460] S. Deering, R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification,", RFC 2460, December 1998.
[RFC 3484] R. Draves, "Default Address Selection for IPv6,"
RFC 3484, February 2003.
[RFC 2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal
IPv6 Addresses in URL's," RFC 2732, December 1999.
[DNS-ALG] A. Durand, "Issues with NAT-PT DNS ALG in RFC2766",
<draft-durand-natpt-dns-alg-issues-00.txt>,
February 2002, Work in Progress.
[DNS] A. Durand, J. Ihren, "IPv6 DNS transition issues,"
<draft-ietf-dnsop-ipv6-dns-issues-02.txt>, February 2003,
Work in Progress.
[AF-APP] Jun-ichiro itojun Hagino, "Implementing AF-independent
application", http://www.kame.net/newsletter/19980604/,
2001.
[V6MAPPED] Jun-ichiro itojun Hagino, "IPv4 mapped address
considered harmful", <draft-itojun-v6ops-v4mapped-
harmful-00.txt>, work-in-progress, Apr 2002.
Authors' Addresses
Myung-Ki Shin
ETRI PEC
161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea
Tel : +82 42 860 4847
Fax : +82 42 861 5404
E-mail : mkshin@pec.etri.re.kr
Yong-Guen Hong
ETRI PEC
161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea
Tel : +82 42 860 6447
Fax : +82 42 861 5404
E-mail : yghong@pec.etri.re.kr
Shin et al. Expires December 2003 [Page 21]
INTERNET-DRAFT Application Aspects of IPv6 Transition June 2003
Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc.
Jinbocho Mitsui Buildling, 1-105,
Kanda-Jinbocho, Chiyoda-ku,Tokyo 101-0051, JAPAN
Tel: +81-3-5205-6464
Fax: +81-3-5205-6465
E-mail: itojun@iijlab.net
Pekka Savola
CSC/FUNET
E-mail : psavola@funet.fi
Eva M. Castro
Universidad Rey Juan Carlos
Escuela Superior de Ciencias Experimentales y Tecnologia
Departamento de Informatica, Estadistica y Telematica
C/ Tulipan s/n - 28933 Mostoles - Madrid SPAIN
E-mail: eva@gsyc.escet.urjc.es
Shin et al. Expires December 2003 [Page 22]