WDIFF

draft-ietf-v6ops-application-transition-03.txt --> rfc4038.txt

v6ops

Network Working Group M-K. Shin (ed.)
INTERNET DRAFT Shin, Ed.
Request for Comments: 4038 ETRI/NIST
Expires: December 2004
Category: Informational Y-G. Hong
ETRI
J. Hagino
IIJ
P. Savola
CSC/FUNET
E. M. Castro
GSYC/URJC
June 2004
March 2005

Application Aspects of IPv6 Transition
<draft-ietf-v6ops-application-transition-03.txt>

Status of this This Memo

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668.

Internet-Drafts are working documents of

This memo provides information for the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum community. It does
not specify an Internet standard of six
months and may be updated, replaced, or obsoleted by other docu-
ments at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in
progress."

The list kind. Distribution of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. this
memo is unlimited.

This Internet-Draft will expire on December 2004. 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.

Shin

Shin, Ed., et al. Expires December 2004 Informational [Page 1]

INTERNET-DRAFT

RFC 4038 Application Aspects of IPv6 Transition June 2004 March 2005

Table of Contents: Contents

1. Introduction .............................................. ................................................. 3
2. Overview of IPv6 Application Transition ................... ...................... 3
3. Problems with IPv6 Application Transition ................. .................... 5
3.1
3.1. IPv6 support Support in the OS and applications are unrelated.... Applications Are Unrelated... 5
3.2
3.2. DNS does not indicate which Does Not Indicate Which IP version will be used ..... 5
3.3 Version Will Be Used .... 6
3.3. Supporting many versions Many Versions of an application is difficult ..6 Application Is Difficult. 6
4. Description of Transition Scenarios and Guidelines ........ 6
4.1 ........... 7
4.1. IPv4 Applications in a Dual-stack Dual-Stack Node .................. ................. 7
4.2
4.2. IPv6 Applications in a Dual-stack Dual-Stack Node .................. 7
4.3 ................. 8
4.3. IPv4/IPv6 Applications in a Dual-stack Dual-Stack Node .............10
4.4 ............ 11
4.4. IPv4/IPv6 Applications in an IPv4-only Node .............11 ............ 12
5. Application Porting Considerations ........................11
5.1 ........................... 12
5.1. Presentation Format for an IP address ...................12
5.2 Address .................. 13
5.2. Transport Layer API .....................................13
5.3 .................................... 14
5.3. Name and Address Resolution .............................14
5.4 ............................ 15
5.4. Specific IP Dependencies ............................... 14
5.4.1 16
5.4.1. IP Address Selection .................................14
5.4.2 ........................... 16
5.4.2. Application Framing ..................................15
5.4.3 ............................ 16
5.4.3. Storage of IP addresses ..............................15
5.5 ........................ 17
5.5. Multicast Applications ..................................16 ................................. 17
6. Developing IP version-independent Version - Independent Applications ............17
6.1 ............. 18
6.1. IP version-independent Structures .......................17
6.2 Version - Independent Structures..................... 18
6.2. IP version-independent APIs .............................18
6.2.1 Version - Independent APIs........................... 19
6.2.1. Example of Overly Simplistic TCP Server
Application ..19
6.2.2 .................................... 20
6.2.2. Example of Overly Simplistic TCP Client
Application ..20
6.2.3 .................................... 21
6.2.3. Binary/Presentation Format Conversion ................21
6.3 .......... 22
6.3. Iterated Jobs for Finding the Working Address ...........22
6.3.1 .......... 23
6.3.1. Example of TCP Server Application ....................22
6.3.2 .............. 23
6.3.2. Example of TCP Client Application ....................23 .............. 25
7. Transition Mechanism Considerations .......................24 .......................... 26
8. Security Considerations ...................................25 ...................................... 26
9. Acknowledgements .........................................25 Acknowledgments .............................................. 27
10. References ...............................................25
Authors' Addresses ...........................................27 ................................................... 27
Appendix A. Other Binary/Presentation Format Conversions .....28
A.1 ........ 30
A.1. Binary to Presentation using Using inet_ntop() ................28
A.2 ............... 30
A.2. Presentation to Binary using Using inet_pton() ................29

Shin ............... 31
Authors' Addresses ............................................... 32
Full Copyright Statement ......................................... 33

Shin, Ed., et al. Expires December 2004 Informational [Page 2]

INTERNET-DRAFT

RFC 4038 Application Aspects of IPv6 Transition June 2004 March 2005

1. Introduction

As IPv6 is introduced in the IPv4-based Internet, several general
issues arise will arise, such as routing, addressing, DNS, scenarios, etc.

One and scenarios.

An important key to a successful IPv6 transition is the compatibility
with the large installed base of IPv4 hosts and routers. This issue had been
has already been extensively studied, and
the work is still in progress. In particular,
[2893BIS] describes the basic transition mechanisms, mechanisms: dual-stack
deployment and tunneling. In addition, various Various other kinds of transition mechanisms have
been developed for the transition to an IPv6 network. However, these
transition mechanisms take no stance on whether applications support IPv6 or not.
IPv6.

This document specifies application aspects of IPv6 transition.
That is, two Two
inter-related topics are covered:

1. How different network transition techniques affect
applications, and what are the strategies for applications to support IPv6
and IPv4.

2. How to develop IPv6-capable or protocol-independent
applications ("application porting guidelines").

Applications will need to be modified to support IPv6 (and IPv4), guidelines") using one standard
APIs [RFC3493][RFC3542].

In the context of a number this document, the term "application" covers all
kinds of techniques described in sections 2-4.
Some guidelines to develop such application are then presented in
sections 5 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 classifed classified by using four
different cases (excluding the first case when there is no IPv6
support either in either the application or the operating system), as
follows: system):

Shin, Ed., et al. Informational [Page 3]

RFC 4038 Application Aspects of IPv6 Transition March 2005

Case 1. IPv4 applications in a dual-stack node

Shin et al. Expires December 2004 [Page 3]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004 node.

Case 2. IPv4-only applications and IPv6-only applications
in a dual-stack node node.

Case 3. Applications supporting both IPv4 and IPv6
in a dual-stack node node.

Case 4. Applications supporting both IPv4 and IPv6
in an IPv4-only node node.

Figure 1. Overview of Application Transition

Figure 1 shows the cases of application transition.

Shin, Ed., et al. Informational [Page 4]

RFC 4038 Application Aspects of IPv6 Transition March 2005

Case 1 : 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 : 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 : 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.

Shin et al. Expires December 2004 [Page 4]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004

Case 4 : 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. (e.g., disabled from the OS).

Note that this draft does

The first two cases are not address DCCP interesting in the longer term; only few
applications are inherently IPv4- or IPv6-specific, and SCTP considerations
at this phase. 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

3.1. IPv6 support Support in the OS and applications are unrelated Applications Are Unrelated

Considering the cases described in the previous section, IPv4 and
IPv6 protocol stacks in a node is 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, unrelated another long time period. That is,
the A dual-stack operating
system being dual stack does is not mean having intended to have both IPv4 and IPv6 applications.
Therefore, IPv6-capable application transition may be independent of
protocol stacks in a node.

It is even probable that applications

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

Shin, Ed., et al. Informational [Page 5]

RFC 4038 Application Aspects of IPv6 Transition March 2005

3.2. DNS does not indicate which Does Not Indicate Which IP version will be used

The role of Version Will Be Used

In a node, the DNS name resolver in a node is to get 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 issue of DNS name resolution issue related to application transition, transition is
that by only doing a DNS name lookup a client application can not be
certain of the version of the peer application by only doing a DNS name lookup. application. For example, if a
server application does not support IPv6 yet, yet but runs on a dual-stack
machine for other IPv6 services, and this host is listed with a an AAAA
record in the DNS, the client application will fail to connect to the
server application. This is caused by a mis-match mismatch between the DNS
query result (i.e. (i.e., IPv6 addresses) and a server application version (i.e.
(i.e., IPv4).

Shin et al. Expires December 2004 [Page 5]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004

Using SRV records would avoid these problems. Unfortunately, they
are not sufficiently widely used widely enough to be applicable in most cases. Hence an
operational technique solution is to use "service names" in the
DNS, that is, if DNS. If a node is offering
offers multiple services, but only some of them over IPv6, add 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 whole node,
physical machine, also including the AAAA records. However, the
applications cannot depend on such this operational practices.

In consequence, the 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

3.3. Supporting many versions Many Versions of an application Application is difficult 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, Therefore if multiple versions of the same application are
available, the local users have a difficulty selecting the right application
version supporting the exact IP version
required if multiple versions required.

Shin, Ed., et al. Informational [Page 6]

RFC 4038 Application Aspects of the same application are
available. IPv6 Transition March 2005

To avoid problems with one application not supporting the specified
protocol version, it is desirable to have hybrid applications
supporting both of the protocol versions.

One could argue that an both.

An alternative approach for local client applications could be to
have a "wrapper application" which that performs certain tasks (like figures (such as
figuring out which protocol version will be used) and calls the
IPv4/IPv6-only applications as necessary. In other words, such applications This application would
perform connection establishment (or similar), similar tasks) and pass the
opened socket to the other another application. However, as these applications such
as this would have to do more than just perform a DNS lookup or figure out
determine the literal IP address given, they will get become complex --
likely much more
complex so than writing a hybrid application. Furthermore, writing
"wrapping" applications which that perform complex operations with IP
addresses
(like (such as FTP clients) might be even more challenging or
even impossible. In summary, short, wrapper applications does do not look like a
robust approach for application transition.

Shin et al. Expires December 2004 [Page 6]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004

4. Description of Transition Scenarios and Guidelines

Once the IPv6 network is deployed, applications supporting IPv6 can
use IPv6 network services and to establish IPv6 connections. However,
upgrading every node to IPv6 at the same time is not feasible feasible, and
transition from IPv4 to IPv6 will be a gradual process.

Dual-stack nodes are provide one of the ways solution to maintain maintaining IPv4
compatibility in unicast communications. In this section we will
analyze different application transition scenarios (as introduced in
section 2) and guidelines to maintain for maintaining interoperability between
applications running in different types of nodes.

4.1

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 Dual-Stack Node

This scenario happens if

In this scenario, the IPv6 protocol is added in a node node, but
IPv6-capable IPv6-
capable applications aren't yet available or installed. Although the
node implements the dual stack, IPv4 applications can only manage
IPv4 communications. Then, IPv4 applications can only communications and accept/establish connections from/to nodes which
that implement an IPv4 stack.

In order to

To allow an application to communicate with other nodes using IPv6,
the first priority is to port applications to IPv6.

Shin, Ed., et al. Informational [Page 7]

RFC 4038 Application Aspects of IPv6 Transition March 2005

In some cases (e.g. (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 Bump-in-the-
API [BIA] mechanism is installed in the node. We strongly recommend
that application developers sould not use these mechanisms when application
source code is available. Also, it 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
--the
arises - (the IPv4 client in a [BIS]/[BIA] node trying tries to connect to
an IPv4 server in a dual stack system-- arises. system). However, one can rely on the
[BIA]/[BIS] mechanism, which should cycle through all the addresses
instead of applications.

[BIS] or and [BIA] does do not work with all kinds of applications. In applications - in
particular, the with applications which 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. Hence, Therefore, these
IPv4 temporary addresses are only valid in the node scope."

4.2 scope.

4.2. IPv6 Applications in a Dual-stack 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

Shin et al. Expires December 2004 [Page 7]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004
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 can not cannot work in IPv4-only nodes, so the old
IPv4 application should be maintained in these nodes. Then, we
will get 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 since undesirable, as maintaining two
versions of the same source code per application could be a difficult task.
In addition, this difficult.
This approach would also cause problems for the users when 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 to IPv6 ones by using IPv4-mapped IPv6
addresses: the IPv6 address ::FFFF:x.y.z.w represents the IPv4
address x.y.z.w.

Shin, Ed., et al. Informational [Page 8]

RFC 4038 Application Aspects of IPv6 Transition March 2005

+----------------------------------------------+
| +------------------------------------------+ |
| | | |
| | IPv6-only applications | |
| | | |
| +------------------------------------------+ |
| | |
| +------------------------------------------+ |
| | | |
| | TCP / UDP / others (SCTP, DCCP, etc.) | |
| | | |
| +------------------------------------------+ |
| IPv4-mapped | | IPv6 |
| IPv6 addresses | | addresses |
| +--------------------+ +-------------------+ |
| | IPv4 | | IPv6 | |
| +--------------------+ +-------------------+ |
| IPv4 | | |
| adresses addresses | | |
+--------------|-----------------|-------------+
| |
IPv4 packets IPv6 packets

We will analyze the behaviour of IPv6-applications which 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. This default behavior of IPv6 applications in In these dual-stack nodes 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

Shin et al. Expires December 2004 [Page 8]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004 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
ones, and vice versa.

IPv6-only client:
IPv6-only client applications in a dual-stack node will not get
receive IPv4-mapped addresses from the hostname resolution API
functions unless a special hint, AI_V4MAPPED, is given. If given, it

Shin, Ed., et al. Informational [Page 9]

RFC 4038 Application Aspects of IPv6 Transition March 2005

is, the IPv6 client will use the returned mapped address as if
it were a regular IPv6 address, and a usual IPv6 connection.
However, again 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, 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.

There are some

Some implementations of dual-stack which do not allow IPv4-mapped IPv6
addresses to be used for interoperability between IPv4 and IPv6
applications. In that case, these cases, there are two ways to handle the
problem:

1. deploy Deploy two different versions of the application (possibly
attached with '6' in the name), or name).

2. deploy Deploy just one application supporting both protocol versions
as described in the next section.

The first method is not recommended because of a significant amount number
of problems associated with selecting the right applications. This These
problems are described in sections 3.2 and 3.3.

Therefore, there are actually two distinct cases to consider when writing one
application to support both protocols:

1. whether Whether the application can (or should) support both IPv4 and
IPv6 through IPv4-mapped IPv6 addresses, addresses or should the applications
should support both explicitly (see section 4.3), and

2. whether Whether the systems where in which the applications are used support
IPv6 at all or not (see section 4.4).

Shin et al. Expires December 2004 [Page 9]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004

Note that some systems will disable (by default) support for internal
IPv4-mapped IPv6 addresses. The security concerns regarding IPv4-mapped IPv6 addresses on the wire these
are legitimate legitimate, but disabling it them internally breaks one transition
mechanism for server applications which were originally written to bind() and
listen() to a single socket by using a wildcard address. This forces
the software developer to rewrite the daemon to create 2 two separate
sockets, one for IPv4 only and the other for IPv6 only, and then to
use select(). However, enabling mapping mapping-enabling of IPv4 addresses on any
particular system is controlled by the OS owner and not
necessarilly necessarily

Shin, Ed., et al. Informational [Page 10]

RFC 4038 Application Aspects of IPv6 Transition March 2005

by a developer. This complicates the developer's work developers' work, as he they now has have
to rewrite the daemon network code to handle both environments, even
for the same OS.

4.3

4.3. IPv4/IPv6 Applications in a Dual-stack Dual-Stack Node

Applications should be ported to support both IPv4 and IPv6; such
applications are sometimes called IP version-independent
applications. After that, IPv6. Over
time, the existing IPv4-only applications could be removed. Since As we
have only one version of each application, the source code will be
typically be easy to maintain and to modify, and there are no
problems managing which application to select for which
communication.

This transition case is the most advisable. During the IPv6
transition period period, applications supporting both IPv4 and IPv6 should
be able to communicate with other applications, irrespective of the
versions
version 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, without
dependencies on either IPv4 or IPv6, applications will be able to
communicate with any combination of applications and types of nodes.

Implementations typically by-default prefer IPv6 by default if the remote node
and application support it. However, if IPv6 connections fail,
version-independent applications will automatically try IPv4 ones.
The resolver returns a list of valid addresses for the remote node node,
and applications can iterate through all of them until connection
succeeds.

Applications

Application writers should be aware of this typical by-default protocol ordering, which
is typically the default, but the applications themselves typically usually
need not be
aware of the the local protocol ordering [RFC 3484]. [RFC3484].

If the source code is written in a protocol-dependent way, the
application will support IPv4 and IPv6 explicitly by using 2 two
separate sockets. Note that there are some differences in bind()
implementation,
implementation - that is, in whether you one can first bind to the IPv6, and then

Shin et al. Expires December 2004 [Page 10]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004

IPv4,
wildcard addresses. It can be a pain addresses, and then to write those for IPv4. Writing applications
that cope with this. If IPV6_V6ONLY is implemented, this becomes
simpler. can be a pain. Implementing IPV6_V6ONLY
simplifies this. The reason the IPv4 wildcard bind fails on some systems is
that
because the IPv4 address space is embedded into IPv6 address space
when using IPv4-mapped IPv6 addresses. addresses are used.

A more detailed porting guideline is described in section 6.

Shin, Ed., et al. Informational [Page 11]

RFC 4038 Application Aspects of IPv6 Transition March 2005

4.4. IPv4/IPv6 Applications in an IPv4-only IPv4-Only Node

As the transition is likely to happen take place over a longer timeframe, time frame,
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 supporting
two application versions for older and newer operating systems, or to
support the a case that in which the user wants to disable IPv6 for some
reason.

The most important case is the application support on systems where
IPv6 support can be dynamically enabled or disabled by the users.
Applications on such a system should be able to handle the a situation where
IPv6 would not be enabled. The secondary Another scenario is when an application could be
is deployed on older systems which that do not support IPv6 at all (even
the basic getaddrinfo etc. APIs). APIs such as getaddrinfo). In
that case this case, the application
designer has to make a case-by-case
judgement judgment call as to whether it
makes sense to have compile-time toggle between an older and a newer
API (having to support both in the code), or whether to provide
getaddrinfo etc. function support on older platforms as part of the
application libraries.

Depending on how application/operating system support is done, support, some may want to
ignore this case, but usually no assumptions can be
made made, and
applications should also work in this scenario.

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, encountering errors like these leads lead to exiting the
socket loop, and AF_INET will not even be tried. The application
will need to handle this case or build the loop in
such a way so that errors are
ignored until the last address family.

So, this

This case is just an extension of the IPv4/IPv6 support in the
previous case, covering one relatively common but often ignored often-ignored case.

5. Application Porting Considerations

The minimum changes to for IPv4 applications to work with IPv6 are based
on the different size and format of IPv4 and IPv6 addresses.

Shin et al. Expires December 2004 [Page 11]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004

Applications have been developed with the assumption they would use IPv4 as their network protocol. protocol in mind.
This assumption results has resulted in many IP dependencies through source
code.

The following list summarizes the more common IP version dependencies
in applications:

Shin, Ed., et al. Informational [Page 12]

RFC 4038 Application Aspects of IPv6 Transition March 2005

a) Presentation format for an IP address: it is an An ASCII string
which that
represents the IP address, a dotted-decimal string for IPv4 IPv4,
and a hexadecimal string for IPv6.

b) Transport layer API: functions Functions to establish communications and
to exchange information.

c) Name and address resolution: conversion Conversion functions between
hostnames and IP addresses, and vice versa. addresses.

d) Specific IP dependencies: more More specific IP version
dependencies, such as: as IP address selection, application
framing, and storage of IP addresses.

e) Multicast applications: one One must find the IPv6 equivalents to
the IPv4 multicast addresses, addresses and use the right socket
configuration options.

In the

The following subsections, subsections describe the problems with the
aforementioned IP version dependencies are analyzed. dependencies. Although application source
code can be ported to IPv6 with minimum changes related to IP
addresses, some recommendations are given to modify the source code
in a protocol independent protocol-independent way, which will allow applications to work using
with both IPv4 and IPv6.

5.1

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, 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 a string. There are
two problems, problems when porting the presentation format for an IP address:
the allocated memory and the management of the presentation format.

Usually, the allocated memory allocated to contain an IPv4 address
representation as a string is unable to contain an IPv6 address.
Applications should be modified to prevent buffer overflows made
possible by the larger IPv6 address.

IPv4 and IPv6 do not use the same presentation format. IPv4 uses a
dot (.) to separate the four octets written in decimal notation notation, and
IPv6 uses a colon (:) to separate each pair of octets written in

Shin et al. Expires December 2004 [Page 12]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004
hexadecimal notation [RFC 3513]. [RFC3513]. In cases where it one must be able to specify e.g.,
specify, for example, port numbers with the address (see below), it
may be desirable to require placing the address inside the square
brackets [TextRep].

Shin, Ed., et al. Informational [Page 13]

RFC 4038 Application Aspects of IPv6 Transition March 2005

A particular problem with IP address parsers comes when the input is
actually a combination of IP address and port number. With IPv4
these are often coupled with a colon such as colon; for example, "192.0.2.1:80".
However, such an this approach would be ambiguous with IPv6 IPv6, as colons are
already used to structure the address.

Therefore, the IP address parsers which that take the port number separated
with a colon should represent distinguish IPv6 addresses somehow. One way is
to enclose the address in brackets, as is done with Uniform Resource
Locators (URLs) [RFC 2732], like [RFC2732]; for example, http://[2001:db8::1]:80.

Some applications also need to specify IPv6 prefixes and lengths;
the lengths:
The prefix length should be inserted outside of the square brackets,
if used, like used; for example, [2001:db8::]/64 or 2001:db8::/64 -- and not for
example
[2001:db8::/64]. Note that prefix/length notation is syntactically
indistinguishable from a legal URI; therefore therefore, the prefix/length
notation must not be used when it isn't clear from the context that
it's used to specify the prefix and length and
not e.g., not, for example, a
URI.

In some specific cases, it may be necessary to give a zone identifier
as part of the address, like address; for example, fe80::1%eth0. In general,
applications should not need to parse these identifiers.

The IP address parsers should support enclosing the IPv6 address in
brackets
brackets, even when it's the address is not used in conjunction with a
port number,
but requiring number. Requiring that the user always gives give a literal IP
address enclosed in brackets is not recommended.

One should note

Note that some applications may also represent IPv6 address literals
differently; for example, SMTP [RFC 2821] [RFC2821] uses [IPv6:2001:db8::1].

Note that the use of address literals is strongly discouraged for
general purpose
general-purpose direct input to the applications; host applications. Host names and DNS
should be used instead.

5.2

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 transport-layer API, typically
as a network library. When porting an application is ported to IPv6, most
changes should be made in this application transport module in order
to be adapted to the new IPv6 API.

Shin

Shin, Ed., et al. Expires December 2004 Informational [Page 13]

INTERNET-DRAFT 14]

RFC 4038 Application Aspects of IPv6 Transition June 2004 March 2005

In the general case, porting an existing application to IPv6 requires
an examination of the following issues related to the API:

- Network information storage: Information Storage: IP address data structures. 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 code; developers code. Developers should pay attention to them these in order
to use the new address format. Some of these special IP
addresses
are: are wildcard local, loopback loopback, and broadcast. IPv6
does not have the broadcast addresses, so applications can use
multicast instead.

- Address conversion functions. Conversion Functions
The address conversion functions convert the binary address
representation to the presentation format and vice versa. The
new conversion functions are specified to the IPv6 address
format.

- Communication API functions. Functions
These functions manage communications. Their signatures are
defined based on a generic socket address structure. The same
functions are valid for IPv6, IPv6; however, the IP address data
structures used when calling these functions require the
updates.

- Network configuration options.
They Configuration Options
These are used when configuring different communication models are
configured for Input/Output (I/O) operations
(blocking/nonblocking, I/O multiplexing, etc.) and should be
translated to the IPv6 ones.

5.3 for IPv6.

5.3. Name and Address Resolution

From the application point of view, the name and address resolution
is a system-independent process. An application calls functions in a
system library, the resolver, which is linked into the application
when this it is built. However, these functions use IP address
structures, which that are protocol dependent, dependent and must be reviewed to
support the new IPv6 resolution calls.

There

With IPv6, there are two new basic resolution functions. The functions,
getaddrinfo() and getnameinfo(). The first function returns a list of all
configured IP addresses for a hostname. These queries can be
constrained to one protocol family, family; for instance instance, only IPv4 or only

Shin, Ed., et al. Informational [Page 15]

RFC 4038 Application Aspects of IPv6 Transition March 2005

IPv6 addresses. However, the recommendation it is recommended that all configured IP
addresses should be obtained to allow applications to work with every kind
of node. And the The second function returns the hostname associated to an
IP address.

Shin et al. Expires December 2004 [Page 14]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004

5.4

5.4. Specific IP Dependencies

5.4.1

5.4.1. IP Address Selection

Unlike the IPv4 model, IPv6 promotes the configuration of multiple IP
addresses per node,
which is a difference when compared with the IPv4 model; however 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

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], per [RFC3484], but
will also allowing allow applications to make changes in the ordering rules.

When selecting the destination address, applications usually ask a
resolver for the destination IP address. The resolver returns a set
of valid IP addresses from a hostname. Unless applications have a
specific reason to select any particular destination address, they
should just try each element in the list until the communication succeeds.

In some cases, the application may need to specify its source
address. Then the The destination address selection process picks the best
destination for the source address (instead of picking the best
source address for the chosen destination address). Note that if it
is not yet known which protocol will be used for communication there
may be an increase in complexity for IP-version IP version - independent
applications which that have to specify the source address (especially for
client applications; fortunately, applications. Fortunately, specifying the source address is
not typically required), if it is not yet known which protocol
will be used for communication.

5.4.2 required).

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 with ALF is
arrives from the ADU size selection to obtain better performance.

Application framing is typically needed by applications

Applications using connectionless protocols (such as UDP). Such UDP) typically
need application framing. These applications have three choices: (1)
to use packet sizes no larger than IPv6 the IPv6 minimum Maximum
Transmission Unit (MTU) of 1280 bytes [RFC2460], (2) to use whatever any

Shin, Ed., et al. Informational [Page 16]

RFC 4038 Application Aspects of IPv6 Transition March 2005

packet sizes sizes, but to force IPv6 fragmentation/reassembly when
necessary, or (3) to optimize the packet size and avoid unnecessary
fragmentation/reassembly, and to guess or find out the optimal packet
sizes which that can be sent and

Shin et al. Expires December 2004 [Page 15]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004 received, end-to-end, on the network.
This memo takes no stance on
which that approach to adopt. is best.

Note that the most optimal ALF depends on dynamic factors such as
Path MTU or whether IPv4 or IPv6 is being used (due to different
header sizes, possible IPv6-in-IPv4 tunneling overhead, etc.). These
factors have to be taken into consideration when implementing application framing.

5.4.3 framing
is implemented.

5.4.3. Storage of IP Addresses

Some applications store IP addresses as information of remote
peers. peer information. For
instance, one of the most popular ways to register remote nodes in
collaborative applications is based on using uses IP addresses as registry keys.

Although the source code that stores IP addresses can be modified to
IPv6 by following the previous basic porting recommendations, there
are some reasons why
applications should not store IP addresses: addresses for the following reasons:

- IP addresses can change throughout time, time; for instance instance, after a
renumbering process.

- The same node can reach a destination host using different IP
addresses, possibly with a different protocol version.

When possible, applications should store names such as FQDNs, FQDNs or other
protocol-independent identities instead of storing addresses. In this case
applications are only bound to specific addresses at run time, or for
the duration of a cache lifetime. Other types of applications, such
as massive peer to peer peer-to-peer systems with their own rendezvous and
discovery mechanisms, may need to cache addresses for performance
reasons, but cached addresses should not be treated as permanent,
reliable information. In highly dynamic networks networks, any form of name
resolution may be impossible, and here again addresses must be
cached.

5.5

5.5. Multicast Applications

There is an additional problem in porting multicast applications.
When using multicast facilities are used some changes must be carried out
to support IPv6. First, applications must change the IPv4 multicast
addresses to IPv6 ones, and second, the socket configuration options
must be changed.

Shin, Ed., et al. Informational [Page 17]

RFC 4038 Application Aspects of IPv6 Transition March 2005

All the IPv6 multicast addresses encode scope; the scope was only
implicit in IPv4 (with multicast groups in 239/8). Also, while although a
large number of application-specific multicast addresses have been
assigned with IPv4, this has been (luckily enough) avoided in with IPv6.
So,
So there are no direct equivalents for all the multicast

Shin et al. Expires December 2004 [Page 16]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004 addresses.
For link-local multicast, it's possible to pick almost anything
within the link-local scope. The global groups could use
unicast-prefix-based unicast
prefix - based addresses [RFC 3306]. [RFC3306]. All in all, this may force the
application developers to write more protocol dependent protocol-dependent code.

Another problem is/has been is that IPv6 multicast does not yet have a
standardized mechanism for traditional Any Source Multicast for
Interdomain multicast. The models for Any Source Multicast (ASM) or
Source-Specific Multicast (SSM) are generally similar between IPv4
and IPv6, but it is possible that PIM-SSM will become more widely
deployed in IPv6 due to its simpler architecture.

So, it

It might be beneficial to port the applications to use SSM semantics,
requiring off-band source discovery mechanisms and the
use of a different API [RFC 3678].
[RFC3678]. Inter-domain ASM service is available only through a
method embedding the Rendezvous Point address in the multicast
address [Embed-RP].

Another generic problem for with multiparty conferencing applications,
which is
similar to the issues with peer-to-peer applications, is that all the
users of the session must use the same protocol version (IPv4 or
IPv6), or some form of proxies proxy or translators must
be used translator (e.g., [MUL-GW]).

6. Developing IP version-independent Version - Independent Applications

As we have seen before, stated, dual applications working with both 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
better solutions is based on building would be to build a communication library which that
provides an IP version - independent API to applications and that
hides all dependencies.

In order to

To develop IP version - independent applications, the following
guidelines should be considered.

6.1

6.1. IP version-independent Version - Independent Structures

All of the memory structures and APIs should be IP version-
independent. In that sense, one version-independent. One
should avoid structs in_addr, in6_addr, sockaddr_in sockaddr_in, and
sockaddr_in6.

Shin, Ed., et al. Informational [Page 18]

RFC 4038 Application Aspects of IPv6 Transition March 2005

Suppose you pass a network address is passed to some function, foo(). If you
use one
uses struct in_addr or struct in6_addr, you will end up with results an extra parameter to
indicate address family, as below:

struct in_addr in4addr;
struct in6_addr in6addr;
/* IPv4 case */

Shin et al. Expires December 2004 [Page 17]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004
foo(&in4addr, AF_INET);
/* IPv6 case */
foo(&in6addr, AF_INET6);

However, this

This leads to duplicated code and having to consider each scenario
from both perspectives independently; this independently, which is difficult to maintain. So,
So we should use struct sockaddr_storage like below. sockaddr_storage, as below:

struct sockaddr_storage ss;
int sslen;
/* AF independent! - use sockaddr when passing a pointer */
/* note: it's typically necessary to also pass the length
explicitly */
foo((struct sockaddr *)&ss, sslen);

6.2

6.2. IP version-independent Version - Independent APIs

getaddrinfo() and getnameinfo() are

The new address independent variants that getaddrinfo() and getnameinfo()
hide the gory details of name-to-address and address-
to-name address-to-name
translations. They implement functionalities of the following
functions:

gethostbyname()
gethostbyaddr()
getservbyname()
getservbyport()

They also obsolete the functionality of gethostbyname2(), defined in
[RFC2133].

These

The new variants can perform hostname/address and service name/port
lookups, though the features can be turned off off, if desirable. desired.
Getaddrinfo() can return multiple addresses, as below:

localhost. IN A 127.0.0.1
IN A 127.0.0.2
IN AAAA ::1

In this example, if IPv6 is preferred, getaddrinfo returns first
::1, and returns ::1;
then both 127.0.0.1 and 127.0.0.2 is are in a random order.

Shin, Ed., et al. Informational [Page 19]

RFC 4038 Application Aspects of IPv6 Transition March 2005

Getaddrinfo() and getnameinfo() can query hostname as well as and service
name/port at once.

Hardcoding AF-dependent knowledge is not preferred to hardcode AF-dependent knowledge into in the program. The construct like
Constructs such as that below should be avoided:

/* BAD EXAMPLE */
switch (sa->sa_family) {
case AF_INET:
salen = sizeof(struct sockaddr_in);

Shin et al. Expires December 2004 [Page 18]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004
break;
}

Instead, we should use the ai_addrlen member of the addrinfo
structure, as returned by getaddrinfo().

The gethostbyname(), gethostbyaddr(), getservbyname(), and
getservbyport() are mainly used to get server and client sockets.
Following, In
the following sections, we will see simple examples to create creating these
sockets by using the new IPv6 resolution functions.

6.2.1

6.2.1. Example of Overly Simplistic TCP Server Application

A simple TCP server socket at service name (or port number string)
SERVICE:

/*
* BAD EXAMPLE: does not implement the getaddrinfo loop as
* specified in 6.3. This may result in one of the following:
* - an IPv6 server, listening at the wildcard address,
* allowing IPv4 addresses through IPv4-mapped IPv6 addresses.
* - an IPv4 server, if IPv6 is not enabled,
* - an IPv6-only server, if IPv6 is enabled but IPv4-mapped IPv6
* addresses are not used by default, or
* - no server at all, if getaddrinfo supports IPv6, but the
* system doesn't, and socket(AF_INET6, ...) exits with an
* error.
*/
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 */

Shin, Ed., et al. Informational [Page 20]

RFC 4038 Application Aspects of IPv6 Transition March 2005

}

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 2004 [Page 19]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004

freeaddrinfo(res);

6.2.2

6.2.2. Example of Overly Simplistic TCP Client Application

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: SERVICE follows:

/*
* BAD EXAMPLE: does not implement the getaddrinfo loop as
* specified in 6.3. This may result in one of the following:
* - an IPv4 connection to an IPv4 destination,
* - an IPv6 connection to an IPv6 destination,
* - an attempt to try to reach an IPv6 destination (if AAAA
* record found), but failing -- without fallbacks -- because:
* o getaddrinfo supports IPv6 but the system does not
* o IPv6 routing doesn't exist, so falling back to e.g. e.g., TCP
* timeouts
* o IPv6 server reached, but service not IPv6-enabled or
* firewalled away
* - if the first destination is not reached, there is no
* fallback to the next records
*/
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 */
}

Shin, Ed., et al. Informational [Page 21]

RFC 4038 Application Aspects of IPv6 Transition March 2005

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);

Shin et al. Expires December 2004 [Page 20]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004

6.2.3

6.2.3. Binary/Presentation Format Conversion

In addition, we

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. However, these
conversion functions are protocol-dependent; instead it protocol-dependent. It is better to use
getnameinfo()/getaddrinfo() as follows (inet_pton and inet_ntop equivalents are
described in Appendix A).

Conversion from network address structure to presentation format can
be written: written as follows:

struct sockaddr_storage ss;
char addrStr[INET6_ADDRSTRLEN];
char servStr[NI_MAXSERV];
int error;

/* fill ss structure */

error = getnameinfo((struct sockaddr *)&ss, sizeof(ss),
addrStr, sizeof(addrStr),
servStr, sizeof(servStr),
NI_NUMERICHOST);

Shin, Ed., et al. Informational [Page 22]

RFC 4038 Application Aspects of IPv6 Transition March 2005

Conversions from presentation format to network address structure can
be written as follows:

struct addrinfo hints, *res;
char addrStr[INET6_ADDRSTRLEN];
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);

Shin et al. Expires December 2004 [Page 21]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004

6.3

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 succeeds.
When a failure occurs with socket(), connect(), bind(), or some other
function, the code should go on to try the next address.

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),
applications should try the next address structure.

Note: in In the following examples, the socket() return value error
handling could be simplied by substituting special checking of
specific error numbers simplified by always continuing on with the socket
loop.

6.3.1
loop instead of performing special checking of specific error
numbers.

6.3.1. Example of TCP Server Application

The previous example TCP server example should be written: written as follows:

#define MAXSOCK 2
struct addrinfo hints, *res;
int error, sockfd[MAXSOCK], nsock=0;

memset(&hints, 0, sizeof(hints));
hints.ai_flags = AI_PASSIVE;
hints.ai_family = AF_UNSPEC;

Shin, Ed., et al. Informational [Page 23]

RFC 4038 Application Aspects of IPv6 Transition March 2005

hints.ai_socktype = SOCK_STREAM;

error = getaddrinfo(NULL, SERVICE, &hints, &res);
if (error != 0) {
/* handle getaddrinfo error */
}

for (aip=res; aip && nsock < MAXSOCK; aip=aip->ai_next) {
sockfd[nsock] = socket(aip->ai_family,
aip->ai_socktype,
aip->ai_protocol);

if (sockfd[nsock] < 0) {
switch errno {
case EAFNOSUPPORT:
case EPROTONOSUPPORT:
/*
* e.g., skip the errors until
* the last address family,
* see section 4.4.
*/
if (aip->ai_next)
continue;

Shin et al. Expires December 2004 [Page 22]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004

else {
/* handle unknown protocol errors */
break;
}
default:
/* handle other socket errors */
;
}

} else {
int on = 1;
/* optional: works better if dual-binding to wildcard
address */
if (aip->ai_family == AF_INET6) {
setsockopt(sockfd[nsock], IPPROTO_IPV6, IPV6_V6ONLY,
(char *)&on, sizeof(on));
/* errors are ignored */
}
if (bind(sockfd[nsock], aip->ai_addr,
aip->ai_addrlen) < 0 ) {
/* handle bind error */
close(sockfd[nsock]);
continue;
}
if (listen(sockfd[nsock], SOMAXCONN) < 0) {

Shin, Ed., et al. Informational [Page 24]

RFC 4038 Application Aspects of IPv6 Transition March 2005

if (listen(sockfd[nsock], SOMAXCONN) < 0) {
/* handle listen errors */
close(sockfd[nsock]);
continue;
}
}
nsock++;
}
freeaddrinfo(res);

/* check that we were able to obtain the sockets */

6.3.2

6.3.2. Example of TCP Client Application

The previous TCP client example should be written: written as follows:

struct addrinfo hints, *res, *aip;
int sockfd, error;

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 */
}

Shin et al. Expires December 2004 [Page 23]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004

for (aip=res; aip; aip=aip->ai_next) {

sockfd = socket(aip->ai_family,
aip->ai_socktype,
aip->ai_protocol);

if (sockfd < 0) {
switch errno {
case EAFNOSUPPORT:
case EPROTONOSUPPORT:
/*
* e.g., skip the errors until
* the last address family,
* see section 4.4.
*/
if (aip->ai_next)
continue;
else {
/* handle unknown protocol errors */
break;

Shin, Ed., et al. Informational [Page 25]

RFC 4038 Application Aspects of IPv6 Transition March 2005

}

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 */

/* ... */
}

freeaddrinfo(res);

7. Transition Mechanism Considerations

A mechanism, [NAT-PT],

The mechanism [NAT-PT] introduces a special set of addresses, formed
of an NAT-PT prefix and an IPv4 address; this refers address these refer to IPv4
addresses, addresses
translated by NAT-PT DNS-ALG. In some cases, one might be tempted to
handle these differently.

Shin et al. Expires December 2004 [Page 24]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004

However, IPv6 applications must not be required to distinguish
"normal" and "NAT-PT translated" addresses (or any other kind of
special addresses, including the IPv4-mapped IPv6-addresses): that IPv6 addresses): This
would be completely impractical, and if such the distinction must be made,
it must be done elsewhere (e.g. (e.g., kernel, system libraries).

8. Security Considerations

There are a number of security considerations with for IPv6 transition transition,
but those are outside the scope of this memo.

To ensure the availability and robustness of the service even when
transitioning to IPv6, this memo described describes a number of ways to make
applications more resistant to failures by cycling through addresses
until a working one is found. Doing this properly is critical to avoid unavailability
maintain availability and to avoid loss of service.

One particular point

Shin, Ed., et al. Informational [Page 26]

RFC 4038 Application Aspects of IPv6 Transition March 2005

A special consideration about application transition is how
IPv4-mapped IPv4-
mapped IPv6 addresses are handled. The use in the API can be seen as
both as a merit (easier application transition) and as a burden
(difficulty in ensuring whether the use was legimate) legitimate). Note that
some systems will disable (by default) support for internal
IPv4-mapped IPv4-
mapped IPv6 addresses. The security concerns regarding
IPv4-mapped IPv6 addresses these on the
wire are legitimate legitimate, but disabling it internally breaks one
transition mechanism for server applications which were originally written to
bind() and listen() to a single socket by using a wildcard address
[V6MAPPED]. This should be considered in more detail when designing applications.
applications are designed.

9. Acknowledgements Acknowledgments

Some of guidelines for development of IP version-independent
applications (section 6) were first brought up by [AF-APP]. Other
work to document application porting guidelines has also been in
progress,
progress; for example example, [IP-GGF] and [PRT]. We would like to thank
the members of the the v6ops working group and the application area for
helpful comments. Special thanks are due to Brian E. Carpenter,
Antonio Querubin, Stig Venaas, Chirayu Patel, Jordi Palet, and Jason
Lin for extensive review of this document. We acknowledge Ron Pike
for proofreading the document.

10. References

10.1. Normative References

[RFC 3493] R.

[RFC3493] Gilligan, S. R., Thomson, J. S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6," IPv6",
RFC 3493, February 2003.

Shin et al. Expires December 2004 [Page 25]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004

[RFC 3542] W.

[RFC3542] Stevens, M. W., Thomas, E. M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API) for IPv6,"
IPv6", RFC 3542, May 2003.

[BIS] K. Tsuchiya, H. K., Higuchi, H., and Y. Atarashi, "Dual Stack
Hosts using the "Bump-In-the-Stack" Technique (BIS)," (BIS)", RFC
2767, February 2000.

[BIA] S. Lee, M-K. S., Shin, Y-J. M-K., Kim, E. Y-J., Nordmark, E., and A.
Durand, "Dual Stack Hosts using Using "Bump-in-the-API" (BIA)," (BIA)",
RFC 3338, October 2002.

[RFC 2460] S.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification," Specification", RFC 2460, December 1998.

[RFC 3484] R.

Shin, Ed., et al. Informational [Page 27]

RFC 4038 Application Aspects of IPv6 Transition March 2005

[RFC3484] Draves, R., "Default Address Selection for IPv6," Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.

[RFC 3513] R.

[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture," Architecture", RFC 3513, April 2003.

10.2. Informative References

[2893BIS] E. Nordmark, E. and R. E. Gilligan, "Basic Transition
Mechanisms for IPv6 Hosts and Routers," <draft-ietf-v6ops-mech-v2-
03.txt>, Routers", Work in Progress,
June 2004, Work-in-progress.

[RFC 2732] R. 2004.

[RFC2133] Gilligan, R., Thomson, S., Bound, J., and W. Stevens,
"Basic Socket Interface Extensions for IPv6", RFC 2133,
April 1997.

[RFC2732] Hinden, B. R., Carpenter, B., and L. Masinter, "Format for
Literal IPv6 Addresses in URL's," URL's", RFC 2732, December
1999.

[RFC 2821] J.

[RFC2821] Klensin, J., "Simple Mail Transfer Protocol," Protocol", RFC 2821,
April 2001.

[TextRep] A. Main, A., "Textual Representation of IPv4 and IPv6
Addresses," <draft-main-ipaddr-text-rep-01.txt>, Oct 2003,
Addresses", Work in Progress. Progress, October 2003.

[NAT-PT] G. Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)," (NAT-PT)", RFC 2766,
February 2000.

[DNSTRANS] A. Durand, A. and J. Ihren, "DNS IPv6 transport operational
guidelines," <draft-ietf-dnsop-ipv6-transport-guidelines-
02.txt>, March 2004, Work in Progress. Transport Operational
Guidelines", BCP 91, RFC 3901, September 2004.

[DNSOPV6] A. Durand, J. A., Ihren, J. and P. Savola, "Operational
Considerations and Issues with IPv6 DNS," <draft-ietf-dnsop-ipv6-dns-
issues-07.txt>, May 2004, DNS", Work in Progress.
Progress, May 2004.

[AF-APP] J. Hagino, J., "Implementing AF-independent application",
http://www.kame.net/newsletter/19980604/, 2001.

Shin et al. Expires December 2004 [Page 26]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004

[V6MAPPED] J. Hagino, J., "IPv4 mapped address considered harmful",
<draft-itojun-v6ops-v4mapped-harmful-02.txt>, Apr 2002,
Work in Progress. Progress, April 2002.

[IP-GGF] T. Chown, J. T., Bound, S. J., Jiang, S. and P. O'Hanlon,
"Guidelines for IP version independence in GGF specifications,"
specifications", Global Grid Forum(GGF) Documentation, September 2003, Work in
Progress.

[Embed-RP] P. Savola, B. Haberman, "Embedding the Address of RP
work in Progress, September 2003.

Shin, Ed., et al. Informational [Page 28]

RFC 4038 Application Aspects of IPv6 Multicast Address," <draft-ietf-mboned-embeddedrp-
00.txt>, October 2003, Work in Progress.

[RFC 3306] Transition March 2005

[Embed-RP] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", RFC
3956, November 2004.

[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses," Addresses", RFC 3306, August 2002.

[RFC 3678] D.

[RFC3678] Thaler, B. D., Fenner, B., and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters, RFC 3678,
January 2004.

[MUL-GW] S. Venaas, S., "An IPv4 - IPv6 multicast gateway," <draft-
venaas-mboned-v4v6mcastgw-00.txt>, February 2003, gateway", Work in Progress.
Progress, February 2003.

[PRT] E. M. Castro, E. M., "Programming guidelines on transition to
IPv6,
IPv6 LONG project, project", Work in Progress, January 2003.

Authors' Addresses

Myung-Ki Shin
ETRI/NIST
820 West Diamond Avenue
Gaithersburg, MD 20899, USA
Tel : +1 301 975-3613
Fax : +1 301 590-0932
E-mail : mshin@nist.gov

Yong-Guen Hong
ETRI PEC
161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
Tel : +82 42 860 6447
Fax : +82 42 861 5404
E-mail : yghong@pec.etri.re.kr

Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc.
Takebashi Yasuda Bldg.,
3-13 Kanda Nishiki-cho,
Chiyoda-ku,Tokyo 101-0054, JAPAN
Tel: +81-3-5259-6350

Shin

Shin, Ed., et al. Expires December 2004 Informational [Page 27]

INTERNET-DRAFT 29]

RFC 4038 Application Aspects of IPv6 Transition June 2004

Fax: +81-3-5259-6351
E-mail: itojun@iijlab.net

Pekka Savola
CSC/FUNET
Espoo, Finland
E-mail: psavola@funet.fi

Eva M. Castro
Rey Juan Carlos University (URJC)
Departamento de Informatica, Estadistica y Telematica
C/Tulipan s/n
28933 Madrid - SPAIN
E-mail: eva@gsyc.escet.urjc.es March 2005

Appendix A. Other binary/Presentation Binary/Presentation Format Conversions

Section 6.2.3 described describes the preferred way of performing to perform
binary/presentation format conversions; these can also be done by
using inet_pton() and inet_ntop() and by writing protocol-dependent
code. This approach is not recommended, but it is provided here for
reference and comparison.

Note that inet_ntop()/inet_pton() lose the scope identifier (if
used e.g. used,
e.g., with link-local addresses) in the conversions, contrary to the
getaddrinfo()/getnameinfo() functions.

A.1

A.1. Binary to Presentation using Using inet_ntop()

Conversions from network address structure to presentation format can
be written: written as follows:

struct sockaddr_storage ss;
char addrStr[INET6_ADDRSTRLEN];

/* fill ss structure */

switch (ss.ss_family) {

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,

Shin et al. Expires December 2004 [Page 28]

INTERNET-DRAFT Application Aspects of IPv6 Transition June 2004
addrStr,
sizeof(addrStr));

break;

default:
/* handle unknown family */
}

Note,

Note that, the destination buffer addrStr should be long enough to
contain the presentation address format: INET_ADDRSTRLEN for IPv4 and
INET6_ADDRSTRLEN for IPv6. Since As INET6_ADDRSTRLEN is longer than
INET_ADDRSTRLEN, the first one is used as the destination buffer
length.

A.2

Shin, Ed., et al. Informational [Page 30]

RFC 4038 Application Aspects of IPv6 Transition March 2005

A.2. Presentation to Binary using Using inet_pton()

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[INET6_ADDRSTRLEN];

/* fill addrStr buffer and ss.ss_family */

switch (ss.ss_family) {
case AF_INET:
sin = (struct sockaddr_in *)&ss;
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,

Note that, the address family of the presentation format must be
known.

Shin

Shin, Ed., et al. Expires December 2004 Informational [Page 29]

INTERNET-DRAFT 31]

RFC 4038 Application Aspects of IPv6 Transition June 2004

Intellectual Property Statement

Authors' Addresses

Myung-Ki Shin
ETRI/NIST
820 West Diamond Avenue
Gaithersburg, MD 20899, USA

Phone: +1 301 975-3613
Fax: +1 301 590-0932
EMail: mshin@nist.gov

Yong-Guen Hong
ETRI PEC
161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea

Phone: +82 42 860 6447
Fax: +82 42 861 5404
EMail: yghong@pec.etri.re.kr

Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc.
Takebashi Yasuda Bldg.,
3-13 Kanda Nishiki-cho,
Chiyoda-ku,Tokyo 101-0054, JAPAN

Phone: +81-3-5259-6350
Fax: +81-3-5259-6351
EMail: itojun@iijlab.net

Pekka Savola
CSC/FUNET
Espoo, Finland

EMail: psavola@funet.fi

Eva M. Castro
Rey Juan Carlos University (URJC)
Departamento de Informatica, Estadistica y Telematica
C/Tulipan s/n
28933 Madrid - SPAIN

EMail: eva@gsyc.escet.urjc.es

Shin, Ed., et al. Informational [Page 32]

RFC 4038 Application Aspects of IPv6 Transition March 2005

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.

Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.

Acknowledgment

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Shin

Shin, Ed., et al. Expires December 2004 Informational [Page 30] 33]

----