draft-ietf-v6ops-application-transition-03.txt   rfc4038.txt 
v6ops Working Group M-K. Shin (ed.) Network Working Group M-K. Shin, Ed.
INTERNET DRAFT ETRI/NIST Request for Comments: 4038 ETRI/NIST
Expires: December 2004 Y-G. Hong Category: Informational Y-G. Hong
ETRI ETRI
J. Hagino J. Hagino
IIJ IIJ
P. Savola P. Savola
CSC/FUNET CSC/FUNET
E. M. Castro E. M. Castro
GSYC/URJC GSYC/URJC
June 2004 March 2005
Application Aspects of IPv6 Transition Application Aspects of IPv6 Transition
<draft-ietf-v6ops-application-transition-03.txt>
Status of 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 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 of six Status of This Memo
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 of current Internet-Drafts can be accessed at This memo provides information for the Internet community. It does
http://www.ietf.org/ietf/1id-abstracts.txt. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 2004. Copyright (C) The Internet Society (2005).
Abstract Abstract
As IPv6 networks are deployed and the network transition discussed, As IPv6 networks are deployed and the network transition is
one should also consider how to enable IPv6 support in applications discussed, one should also consider how to enable IPv6 support in
running on IPv6 hosts, and the best strategy to develop IP protocol applications running on IPv6 hosts, and the best strategy to develop
support in applications. This document specifies scenarios and IP protocol support in applications. This document specifies
aspects of application transition. It also proposes guidelines on scenarios and aspects of application transition. It also proposes
how to develop IP version-independent applications during the guidelines on how to develop IP version-independent applications
transition period. during the transition period.
Table of Contents: Table of Contents
1. Introduction .............................................. 3 1. Introduction ................................................. 3
2. Overview of IPv6 Application Transition ................... 3 2. Overview of IPv6 Application Transition ...................... 3
3. Problems with IPv6 Application Transition ................. 5 3. Problems with IPv6 Application Transition .................... 5
3.1 IPv6 support in the OS and applications are unrelated.... 5 3.1. IPv6 Support in the OS and Applications Are Unrelated... 5
3.2 DNS does not indicate which IP version will be used ..... 5 3.2. DNS Does Not Indicate Which IP Version Will Be Used .... 6
3.3 Supporting many versions of an application is difficult ..6 3.3. Supporting Many Versions of an Application Is Difficult. 6
4. Description of Transition Scenarios and Guidelines ........ 6 4. Description of Transition Scenarios and Guidelines ........... 7
4.1 IPv4 Applications in a Dual-stack Node .................. 7 4.1. IPv4 Applications in a Dual-Stack Node ................. 7
4.2 IPv6 Applications in a Dual-stack Node .................. 7 4.2. IPv6 Applications in a Dual-Stack Node ................. 8
4.3 IPv4/IPv6 Applications in a Dual-stack Node .............10 4.3. IPv4/IPv6 Applications in a Dual-Stack Node ............ 11
4.4 IPv4/IPv6 Applications in an IPv4-only Node .............11 4.4. IPv4/IPv6 Applications in an IPv4-only Node ............ 12
5. Application Porting Considerations ........................11 5. Application Porting Considerations ........................... 12
5.1 Presentation Format for an IP address ...................12 5.1. Presentation Format for an IP Address .................. 13
5.2 Transport Layer API .....................................13 5.2. Transport Layer API .................................... 14
5.3 Name and Address Resolution .............................14 5.3. Name and Address Resolution ............................ 15
5.4 Specific IP Dependencies ............................... 14 5.4. Specific IP Dependencies ............................... 16
5.4.1 IP Address Selection .................................14 5.4.1. IP Address Selection ........................... 16
5.4.2 Application Framing ..................................15 5.4.2. Application Framing ............................ 16
5.4.3 Storage of IP addresses ..............................15 5.4.3. Storage of IP addresses ........................ 17
5.5 Multicast Applications ..................................16 5.5. Multicast Applications ................................. 17
6. Developing IP version-independent Applications ............17 6. Developing IP Version - Independent Applications ............. 18
6.1 IP version-independent Structures .......................17 6.1. IP Version - Independent Structures..................... 18
6.2 IP version-independent APIs .............................18 6.2. IP Version - Independent APIs........................... 19
6.2.1 Example of Overly Simplistic TCP Server Application ..19 6.2.1. Example of Overly Simplistic TCP Server
6.2.2 Example of Overly Simplistic TCP Client Application ..20 Application .................................... 20
6.2.3 Binary/Presentation Format Conversion ................21 6.2.2. Example of Overly Simplistic TCP Client
6.3 Iterated Jobs for Finding the Working Address ...........22 Application .................................... 21
6.3.1 Example of TCP Server Application ....................22 6.2.3. Binary/Presentation Format Conversion .......... 22
6.3.2 Example of TCP Client Application ....................23 6.3. Iterated Jobs for Finding the Working Address .......... 23
7. Transition Mechanism Considerations .......................24 6.3.1. Example of TCP Server Application .............. 23
8. Security Considerations ...................................25 6.3.2. Example of TCP Client Application .............. 25
9. Acknowledgements .........................................25 7. Transition Mechanism Considerations .......................... 26
10. References ...............................................25 8. Security Considerations ...................................... 26
Authors' Addresses ...........................................27 9. Acknowledgments .............................................. 27
Appendix A. Other Binary/Presentation Format Conversions .....28 10. References ................................................... 27
A.1 Binary to Presentation using inet_ntop() ................28 Appendix A. Other Binary/Presentation Format Conversions ........ 30
A.2 Presentation to Binary using inet_pton() ................29 A.1. Binary to Presentation Using inet_ntop() ............... 30
A.2. Presentation to Binary Using inet_pton() ............... 31
Authors' Addresses ............................................... 32
Full Copyright Statement ......................................... 33
1. Introduction 1. Introduction
As IPv6 is introduced in the IPv4-based Internet, several general As IPv6 is introduced in the IPv4-based Internet, several general
issues arise such as routing, addressing, DNS, scenarios, etc. issues will arise, such as routing, addressing, DNS, and scenarios.
One important key to a successful IPv6 transition is the An important key to a successful IPv6 transition is compatibility
compatibility with the large installed base of IPv4 hosts and with the large installed base of IPv4 hosts and routers. This issue
routers. This issue had been already been extensively studied, and has already been extensively studied, and work is still in progress.
the work is still in progress. In particular, [2893BIS] describes [2893BIS] describes the basic transition mechanisms: dual-stack
the basic transition mechanisms, dual-stack deployment and deployment and tunneling. Various other kinds of mechanisms have
tunneling. In addition, various kinds of transition mechanisms been developed for the transition to an IPv6 network. However, these
have been developed for the transition to an IPv6 network. transition mechanisms take no stance on whether applications support
However, these transition mechanisms take no stance on whether IPv6.
applications support IPv6 or not.
This document specifies application aspects of IPv6 transition. This document specifies application aspects of IPv6 transition. Two
That is, two inter-related topics are covered: inter-related topics are covered:
1. How different network transition techniques affect 1. How different network transition techniques affect
applications, and what are the strategies for applications applications, and strategies for applications to support IPv6
to support IPv6 and IPv4. and IPv4.
2. How to develop IPv6-capable or protocol-independent 2. How to develop IPv6-capable or protocol-independent
applications ("application porting guidelines"). applications ("application porting guidelines") using standard
APIs [RFC3493][RFC3542].
Applications will need to be modified to support IPv6 (and IPv4), In the context of this document, the term "application" covers all
kinds of applications, but the focus is on those network applications
which have been developed using relatively low-level APIs (such as
the "C" language, using standard libraries). Many such applications
could be command-line driven, but that is not a requirement.
Applications will have to be modified to support IPv6 (and IPv4) by
using one of a number of techniques described in sections 2-4. using one of a number of techniques described in sections 2-4.
Some guidelines to develop such application are then presented in Guidelines for developing such applications are presented in sections
sections 5 and 6. 5 and 6.
2. Overview of IPv6 Application Transition 2. Overview of IPv6 Application Transition
The transition of an application can be classifed using four The transition of an application can be classified by using four
different cases (excluding the first case when there is no IPv6 different cases (excluding the first case when there is no IPv6
support either in the application or the operating system), as support in either the application or the operating system):
follows:
+-------------------+ +-------------------+
| appv4 | (appv4 - IPv4-only applications) | appv4 | (appv4 - IPv4-only applications)
+-------------------+ +-------------------+
| TCP / UDP / others| (transport protocols - TCP, UDP, | TCP / UDP / others| (transport protocols - TCP, UDP,
+-------------------+ SCTP, DCCP, etc.) +-------------------+ SCTP, DCCP, etc.)
| IPv4 | IPv6 | (IP protocols supported/enabled in the OS) | IPv4 | IPv6 | (IP protocols supported/enabled in the OS)
+-------------------+ +-------------------+
Case 1. IPv4 applications in a dual-stack node Case 1. IPv4 applications in a dual-stack node.
+-------------------+ (appv4 - IPv4-only applications) +-------------------+ (appv4 - IPv4-only applications)
| appv4 | appv6 | (appv6 - IPv6-only applications) | appv4 | appv6 | (appv6 - IPv6-only applications)
+-------------------+ +-------------------+
| TCP / UDP / others| (transport protocols - TCP, UDP, | TCP / UDP / others| (transport protocols - TCP, UDP,
+-------------------+ SCTP, DCCP, etc.) +-------------------+ SCTP, DCCP, etc.)
| IPv4 | IPv6 | (IP protocols supported/enabled in the OS) | IPv4 | IPv6 | (IP protocols supported/enabled in the OS)
+-------------------+ +-------------------+
Case 2. IPv4-only applications and IPv6-only applications Case 2. IPv4-only applications and IPv6-only applications
in a dual-stack node in a dual-stack node.
+-------------------+ +-------------------+
| appv4/v6 | (appv4/v6 - applications supporting | appv4/v6 | (appv4/v6 - applications supporting
+-------------------+ both IPv4 and IPv6) +-------------------+ both IPv4 and IPv6)
| TCP / UDP / others| (transport protocols - TCP, UDP, | TCP / UDP / others| (transport protocols - TCP, UDP,
+-------------------+ SCTP, DCCP, etc.) +-------------------+ SCTP, DCCP, etc.)
| IPv4 | IPv6 | (IP protocols supported/enabled in the OS) | IPv4 | IPv6 | (IP protocols supported/enabled in the OS)
+-------------------+ +-------------------+
Case 3. Applications supporting both IPv4 and IPv6 Case 3. Applications supporting both IPv4 and IPv6
in a dual-stack node in a dual-stack node.
+-------------------+ +-------------------+
| appv4/v6 | (appv4/v6 - applications supporting | appv4/v6 | (appv4/v6 - applications supporting
+-------------------+ both IPv4 and IPv6) +-------------------+ both IPv4 and IPv6)
| TCP / UDP / others| (transport protocols - TCP, UDP, | TCP / UDP / others| (transport protocols - TCP, UDP,
+-------------------+ SCTP, DCCP, etc.) +-------------------+ SCTP, DCCP, etc.)
| IPv4 | (IP protocols supported/enabled in the OS) | IPv4 | (IP protocols supported/enabled in the OS)
+-------------------+ +-------------------+
Case 4. Applications supporting both IPv4 and IPv6 Case 4. Applications supporting both IPv4 and IPv6
in an IPv4-only node in an IPv4-only node.
Figure 1. Overview of Application Transition Figure 1. Overview of Application Transition
Figure 1 shows the cases of application transition. Figure 1 shows the cases of application transition.
Case 1 : IPv4-only applications in a dual-stack node. Case 1 : IPv4-only applications in a dual-stack node.
IPv6 protocol is introduced in a node, but IPv6 protocol is introduced in a node, but
applications are not yet ported to support IPv6. applications are not yet ported to support IPv6.
Case 2 : IPv4-only applications and IPv6-only applications Case 2 : IPv4-only applications and IPv6-only applications
skipping to change at page 5, line 9 skipping to change at page 5, line 25
Case 3 : Applications supporting both IPv4 and IPv6 in a dual Case 3 : Applications supporting both IPv4 and IPv6 in a dual
stack node. stack node.
Applications are ported for both IPv4 and IPv6 support. Applications are ported for both IPv4 and IPv6 support.
Therefore, the existing IPv4 applications can be Therefore, the existing IPv4 applications can be
removed. removed.
Case 4 : Applications supporting both IPv4 and IPv6 in an Case 4 : Applications supporting both IPv4 and IPv6 in an
IPv4-only node. IPv4-only node.
Applications are ported for both IPv4 and IPv6 support, Applications are ported for both IPv4 and IPv6 support,
but the same applications may also have to work when but the same applications may also have to work when
IPv6 is not being used (e.g. disabled from the OS). IPv6 is not being used (e.g., disabled from the OS).
Note that this draft does not address DCCP and SCTP considerations The first two cases are not interesting in the longer term; only few
at this phase. applications are inherently IPv4- or IPv6-specific, and should work
with both protocols without having to care about which one is being
used.
3. Problems with IPv6 Application Transition 3. Problems with IPv6 Application Transition
There are several reasons why the transition period between IPv4 There are several reasons why the transition period between IPv4 and
and IPv6 applications may not be straightforward. These issues are IPv6 applications may not be straightforward. These issues are
described in this section. described in this section.
3.1 IPv6 support in the OS and applications are unrelated 3.1. IPv6 Support in the OS and Applications Are Unrelated
Considering the cases described in the previous section, IPv4 and Considering the cases described in the previous section, IPv4 and
IPv6 protocol stacks in a node is likely to co-exist for a long IPv6 protocol stacks are likely to co-exist in a node for a long
time. time.
Similarly, most applications are expected to be able to handle both Similarly, most applications are expected to be able to handle both
IPv4 and IPv6 during another, unrelated long time period. That is, IPv4 and IPv6 during another long period. A dual-stack operating
the operating system being dual stack does not mean having both system is not intended to have both IPv4 and IPv6 applications.
IPv4 and IPv6 applications. Therefore, IPv6-capable application Therefore, IPv6-capable application transition may be independent of
transition may be independent of protocol stacks in a node. protocol stacks in a node.
It is even probable that applications capable of both IPv4 and IPv6 Applications capable of both IPv4 and IPv6 will probably have to
will have to work properly in IPv4-only nodes (whether the IPv6 work properly in IPv4-only nodes (whether the IPv6 protocol is
protocol is completely disabled or there is no IPv6 connectivity at completely disabled or there is no IPv6 connectivity at all).
all).
3.2 DNS does not indicate which IP version will be used 3.2. DNS Does Not Indicate Which IP Version Will Be Used
The role of the DNS name resolver in a node is to get the list of In a node, the DNS name resolver gathers the list of destination
destination addresses. DNS queries and responses are sent using addresses. DNS queries and responses are sent by using either IPv4
either IPv4 or IPv6 to carry the queries, regardless of the or IPv6 to carry the queries, regardless of the protocol version of
protocol version of the data records [DNSTRANS]. the data records [DNSTRANS].
The issue of DNS name resolution related to application transition, The DNS name resolution issue related to application transition is
is that a client application can not be certain of the version of that by only doing a DNS name lookup a client application can not be
the peer application by only doing a DNS name lookup. For example, certain of the version of the peer application. For example, if a
if a server application does not support IPv6 yet, but runs on a server application does not support IPv6 yet but runs on a dual-stack
dual-stack machine for other IPv6 services, and this host is listed machine for other IPv6 services, and this host is listed with an AAAA
with a AAAA record in the DNS, the client application will fail to record in the DNS, the client application will fail to connect to the
connect to the server application. This is caused by a mis-match server application. This is caused by a mismatch between the DNS
between the DNS query result (i.e. IPv6 addresses) and a server query result (i.e., IPv6 addresses) and a server application version
application version (i.e. IPv4). (i.e., IPv4).
Using SRV records would avoid these problems. Unfortunately, they Using SRV records would avoid these problems. Unfortunately, they
are not sufficiently widely used to be applicable in most cases. are not used widely enough to be applicable in most cases. Hence an
Hence an operational technique is to use "service names" in the operational solution is to use "service names" in the DNS. If a node
DNS, that is, if a node is offering multiple services, but only offers multiple services, but only some of them over IPv6, a DNS name
some of them over IPv6, add a DNS name for each of these services may be added for each of these services or group of services (with
(with the associated A/AAAA records), not just a single name for the associated A/AAAA records), not just a single name for the
the whole node, also including the AAAA records. However, the physical machine, also including the AAAA records. However, the
applications cannot depend on such operational practices. applications cannot depend on this operational practice.
In consequence, the application should request all IP addresses The application should request all IP addresses without address
without address family constraints and try all the records returned family constraints and try all the records returned from the DNS, in
from the DNS, in some order, until a working address is found. In some order, until a working address is found. In particular, the
particular, the application has to be able to handle all IP application has to be able to handle all IP versions returned from
versions returned from the DNS. This issue is discussed in more the DNS. This issue is discussed in more detail in [DNSOPV6].
detail in [DNSOPV6].
3.3 Supporting many versions of an application is difficult 3.3. Supporting Many Versions of an Application is Difficult
During the application transition period, system administrators may During the application transition period, system administrators may
have various versions of the same application (an IPv4-only have various versions of the same application (an IPv4-only
application, an IPv6-only application, or an application supporting application, an IPv6-only application, or an application supporting
both IPv4 and IPv6). both IPv4 and IPv6).
Typically one cannot know which IP versions must be supported prior Typically one cannot know which IP versions must be supported prior
to doing a DNS lookup *and* trying (see section 3.2) the addresses to doing a DNS lookup *and* trying (see section 3.2) the addresses
returned. Therefore, the local users have a difficulty selecting returned. Therefore if multiple versions of the same application are
the right application version supporting the exact IP version available, the local users have difficulty selecting the right
required if multiple versions of the same application are version supporting the exact IP version required.
available.
To avoid problems with one application not supporting the specified To avoid problems with one application not supporting the specified
protocol version, it is desirable to have hybrid applications protocol version, it is desirable to have hybrid applications
supporting both of the protocol versions. supporting both.
One could argue that an alternative approach for local client An alternative approach for local client applications could be to
applications could be to have a "wrapper application" which have a "wrapper application" that performs certain tasks (such as
performs certain tasks (like figures out which protocol version figuring out which protocol version will be used) and calls the
will be used) and calls the IPv4/IPv6-only applications as IPv4/IPv6-only applications as necessary. This application would
necessary. In other words, such applications would perform perform connection establishment (or similar tasks) and pass the
connection establishment (or similar), and pass the opened socket opened socket to another application. However, as applications such
to the other application. However, as these applications would as this would have to do more than just perform a DNS lookup or
have to do more than just perform a DNS lookup or figure out the determine the literal IP address given, they will become complex --
literal IP address given, they will get complex -- likely much more likely much more so than a hybrid application. Furthermore, writing
complex than writing a hybrid application. Furthermore, "wrapping" "wrapping" applications that perform complex operations with IP
applications which perform complex operations with IP addresses addresses (such as FTP clients) might be even more challenging or
(like FTP clients) might be even more challenging or even even impossible. In short, wrapper applications do not look like a
impossible. In summary, wrapper applications does not look like a
robust approach for application transition. robust approach for application transition.
4. Description of Transition Scenarios and Guidelines 4. Description of Transition Scenarios and Guidelines
Once the IPv6 network is deployed, applications supporting IPv6 can Once the IPv6 network is deployed, applications supporting IPv6 can
use IPv6 network services and establish IPv6 connections. However, use IPv6 network services to establish IPv6 connections. However,
upgrading every node to IPv6 at the same time is not feasible and upgrading every node to IPv6 at the same time is not feasible, and
transition from IPv4 to IPv6 will be a gradual process. transition from IPv4 to IPv6 will be a gradual process.
Dual-stack nodes are one of the ways to maintain IPv4 compatibility Dual-stack nodes provide one solution to maintaining IPv4
in unicast communications. In this section we will analyze compatibility in unicast communications. In this section we will
different application transition scenarios (as introduced in analyze different application transition scenarios (as introduced in
section 2) and guidelines to maintain interoperability between section 2) and guidelines for maintaining interoperability between
applications running in different types of nodes. applications running in different types of nodes.
4.1 IPv4 Applications in a Dual-stack Node 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.
This scenario happens if the IPv6 protocol is added in a node but 4.1. IPv4 Applications in a Dual-Stack Node
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
accept/establish connections from/to nodes which implement an IPv4
stack.
In order to allow an application to communicate with other nodes In this scenario, the IPv6 protocol is added in a node, but IPv6-
using IPv6, the first priority is to port applications to IPv6. capable applications aren't yet available or installed. Although the
node implements the dual stack, IPv4 applications can only manage
IPv4 communications and accept/establish connections from/to nodes
that implement an IPv4 stack.
In some cases (e.g. no source code is available), existing IPv4 To allow an application to communicate with other nodes using IPv6,
applications can work if the Bump-in-the-Stack [BIS] or Bump-in- the first priority is to port applications to IPv6.
the-API [BIA] mechanism is installed in the node. We strongly
recommend that application developers sould not use these In some cases (e.g., when no source code is available), existing IPv4
mechanisms when application source code is available. Also, it applications can work if the Bump-in-the-Stack [BIS] or Bump-in-the-
should not be used as an excuse not to port software or delay API [BIA] mechanism is installed in the node. We strongly recommend
porting. that application developers not use these mechanisms when application
source code is available. Also, they should not be used as an excuse
not to port software or to delay porting.
When [BIA] or [BIS] is used, the problem described in section 3.2 When [BIA] or [BIS] is used, the problem described in section 3.2
--the IPv4 client in a [BIS]/[BIA] node trying to connect to an arises - (the IPv4 client in a [BIS]/[BIA] node tries to connect to
IPv4 server in a dual stack system-- arises. However, one can rely an IPv4 server in a dual stack system). However, one can rely on the
on the [BIA]/[BIS] mechanism, which should cycle through all the [BIA]/[BIS] mechanism, which should cycle through all the addresses
addresses instead of applications. instead of applications.
[BIS] or [BIA] does not work with all kinds of applications. In [BIS] and [BIA] do not work with all kinds of applications - in
particular, the applications which exchange IP addresses as particular, with applications that exchange IP addresses as
application data (e.g., FTP). These mechanisms provide IPv4 application data (e.g., FTP). These mechanisms provide IPv4
temporary addresses to the applications and locally make a temporary addresses to the applications and locally make a
translation between IPv4 and IPv6 communication. Hence, these IPv4 translation between IPv4 and IPv6 communication. Therefore, these
temporary addresses are only valid in the node scope." IPv4 temporary addresses are only valid in the node scope.
4.2 IPv6 Applications in a Dual-stack Node 4.2. IPv6 Applications in a Dual-Stack Node
As we have seen in the previous section, applications should be As we have seen in the previous section, applications should be
ported to IPv6. The easiest way to port an IPv4 application is to ported to IPv6. The easiest way to port an IPv4 application is to
substitute the old IPv4 API references with the new IPv6 APIs with substitute the old IPv4 API references with the new IPv6 APIs with
one-to-one mapping. This way the application will be IPv6-only. one-to-one mapping. This way the application will be IPv6-only.
This IPv6-only source code can not work in IPv4-only nodes, so the This IPv6-only source code cannot work in IPv4-only nodes, so the old
old IPv4 application should be maintained in these nodes. Then, we IPv4 application should be maintained in these nodes. This
will get two similar applications working with different protocol necessitates having two similar applications working with different
versions, depending on the node they are running (e.g., telnet and protocol versions, depending on the node they are running (e.g.,
telnet6). This case is undesirable since maintaining two versions telnet and telnet6). This case is undesirable, as maintaining two
of the same source code per application could be a difficult task. versions of the same source code per application could be difficult.
In addition, this approach would cause problems for the users when This approach would also cause problems for users having to select
having to select which version of the application to use, as which version of the application to use, as described in section 3.3.
described in section 3.3.
Most implementations of dual stack allow IPv6-only applications to Most implementations of dual stack allow IPv6-only applications to
interoperate with both IPv4 and IPv6 nodes. IPv4 packets going to interoperate with both IPv4 and IPv6 nodes. IPv4 packets going to
IPv6 applications on a dual-stack node reach their destination IPv6 applications on a dual-stack node reach their destination
because their addresses are mapped to IPv6 ones using IPv4-mapped because their addresses are mapped by using IPv4-mapped IPv6
IPv6 addresses: the IPv6 address ::FFFF:x.y.z.w represents the IPv4 addresses: the IPv6 address ::FFFF:x.y.z.w represents the IPv4
address x.y.z.w. address x.y.z.w.
+----------------------------------------------+ +----------------------------------------------+
| +------------------------------------------+ | | +------------------------------------------+ |
| | | | | | | |
| | IPv6-only applications | | | | IPv6-only applications | |
| | | | | | | |
| +------------------------------------------+ | | +------------------------------------------+ |
| | | | | |
| +------------------------------------------+ | | +------------------------------------------+ |
| | | | | | | |
| | TCP / UDP / others (SCTP, DCCP, etc.) | | | | TCP / UDP / others (SCTP, DCCP, etc.) | |
| | | | | | | |
| +------------------------------------------+ | | +------------------------------------------+ |
| IPv4-mapped | | IPv6 | | IPv4-mapped | | IPv6 |
| IPv6 addresses | | addresses | | IPv6 addresses | | addresses |
| +--------------------+ +-------------------+ | | +--------------------+ +-------------------+ |
| | IPv4 | | IPv6 | | | | IPv4 | | IPv6 | |
| +--------------------+ +-------------------+ | | +--------------------+ +-------------------+ |
| IPv4 | | | | IPv4 | | |
| adresses | | | | addresses | | |
+--------------|-----------------|-------------+ +--------------|-----------------|-------------+
| | | |
IPv4 packets IPv6 packets IPv4 packets IPv6 packets
We will analyze the behaviour of IPv6-applications which exchange We will analyze the behaviour of IPv6-applications that exchange IPv4
IPv4 packets with IPv4 applications using the client/server model. packets with IPv4 applications by using the client/server model. We
We consider the default case when the IPV6_V6ONLY socket option has consider the default case to be when the IPV6_V6ONLY socket option
not been set. This default behavior of IPv6 applications in these has not been set. In these dual-stack nodes, this default behavior
dual-stack nodes allows a limited amount of IPv4 communication allows a limited amount of IPv4 communication using the IPv4-mapped
using the IPv4-mapped IPv6 addresses. IPv6 addresses.
IPv6-only server: IPv6-only server:
When an IPv4 client application sends data to an When an IPv4 client application sends data to an IPv6-only
IPv6-only server application running on a dual-stack server application running on a dual-stack node by using the
node using the wildcard address, the IPv4 client address wildcard address, the IPv4 client address is interpreted as the
is interpreted as the IPv4-mapped IPv6 address in the IPv4-mapped IPv6 address in the dual-stack node. This allows
dual-stack node. This allows the IPv6 application to the IPv6 application to manage the communication. The IPv6
manage the communication. The IPv6 server will use this server will use this mapped address as if it were a regular
mapped address as if it were a regular IPv6 address, and IPv6 address, and a usual IPv6 connection. However, IPv4
a usual IPv6 connection. However, IPv4 packets will be packets will be exchanged between the nodes. Kernels with dual
exchanged between the nodes. Kernels with dual stack stack properly interpret IPv4-mapped IPv6 addresses as IPv4
properly interpret IPv4-mapped IPv6 addresses as IPv4 ones, and vice versa.
ones and vice versa.
IPv6-only client: IPv6-only client:
IPv6-only client applications in a dual-stack node will IPv6-only client applications in a dual-stack node will not
not get IPv4-mapped addresses from the hostname receive IPv4-mapped addresses from the hostname resolution API
resolution API functions unless a special hint, functions unless a special hint, AI_V4MAPPED, is given. If it
AI_V4MAPPED, is given. If given, the IPv6 client will is, the IPv6 client will use the returned mapped address as if
use the returned mapped address as if it were a regular it were a regular IPv6 address, and a usual IPv6 connection.
IPv6 address, and a usual IPv6 connection. However, again However, IPv4 packets will be exchanged between applications.
IPv4 packets will be exchanged between applications.
Respectively, with IPV6_V6ONLY set, an IPv6-only server application Respectively, with IPV6_V6ONLY set, an IPv6-only server application
will only communicate with IPv6 nodes, and an IPv6-only client with will only communicate with IPv6 nodes, and an IPv6-only client only
IPv6 servers, as the mapped addresses have been disabled. This with IPv6 servers, as the mapped addresses have been disabled. This
option could be useful if applications use new IPv6 features, such option could be useful if applications use new IPv6 features such as
as Flow Label. If communication with IPv4 is needed, either Flow Label. If communication with IPv4 is needed, either IPV6_V6ONLY
IPV6_V6ONLY must not be used, or dual-stack applications be used, must not be used, or dual-stack applications must be used, as
as described in section 4.3. described in section 4.3.
There are some implementations of dual-stack which do not allow Some implementations of dual-stack do not allow IPv4-mapped IPv6
IPv4-mapped IPv6 addresses to be used for interoperability between addresses to be used for interoperability between IPv4 and IPv6
IPv4 and IPv6 applications. In that case, there are two ways to applications. In these cases, there are two ways to handle the
handle the problem: problem:
1. deploy two different versions of the application (possibly 1. Deploy two different versions of the application (possibly
attached with '6' in the name), or attached with '6' in the name).
2. deploy just one application supporting both protocol versions 2. Deploy just one application supporting both protocol versions
as described in the next section. as described in the next section.
The first method is not recommended because of a significant amount The first method is not recommended because of a significant number
of problems associated with selecting the right applications. This of problems associated with selecting the right applications. These
problems are described in sections 3.2 and 3.3. problems are described in sections 3.2 and 3.3.
Therefore, there are actually two distinct cases to consider when Therefore, there are two distinct cases to consider when writing one
writing one application to support both protocols: application to support both protocols:
1. whether the application can (or should) support both IPv4 1. Whether the application can (or should) support both IPv4 and
and IPv6 through IPv4-mapped IPv6 addresses, or should the IPv6 through IPv4-mapped IPv6 addresses or the applications
applications support both explicitly (see section 4.3), and should support both explicitly (see section 4.3), and
2. whether the systems where the applications are used support 2. Whether the systems in which the applications are used support
IPv6 at all or not (see section 4.4). IPv6 (see section 4.4).
Note that some systems will disable (by default) support for Note that some systems will disable (by default) support for internal
internal IPv4-mapped IPv6 addresses. The security concerns IPv4-mapped IPv6 addresses. The security concerns regarding these
regarding IPv4-mapped IPv6 addresses on the wire are legitimate but are legitimate, but disabling them internally breaks one transition
disabling it internally breaks one transition mechanism for server mechanism for server applications originally written to bind() and
applications which were originally written to bind() and listen() listen() to a single socket by using a wildcard address. This forces
to a single socket using a wildcard address. This forces the the software developer to rewrite the daemon to create two separate
software developer to rewrite the daemon to create 2 separate sockets, one for IPv4 only and the other for IPv6 only, and then to
sockets, one for IPv4 only and the other for IPv6 only, and then use select(). However, mapping-enabling of IPv4 addresses on any
use select(). However, enabling mapping of IPv4 addresses on any particular system is controlled by the OS owner and not necessarily
particular system is controlled by the OS owner and not by a developer. This complicates developers' work, as they now have
necessarilly by a developer. This complicates the developer's work to rewrite the daemon network code to handle both environments, even
as he now has to rewrite the daemon network code to handle both for the same OS.
environments, even for the same OS.
4.3 IPv4/IPv6 Applications in a Dual-stack Node 4.3. IPv4/IPv6 Applications in a Dual-Stack Node
Applications should be ported to support both IPv4 and IPv6; such Applications should be ported to support both IPv4 and IPv6. Over
applications are sometimes called IP version-independent time, the existing IPv4-only applications could be removed. As we
applications. After that, the existing IPv4-only applications have only one version of each application, the source code will
could be removed. Since we have only one version of each typically be easy to maintain and to modify, and there are no
application, the source code will be typically easy to maintain and problems managing which application to select for which
to modify, and there are no problems managing which application to communication.
select for which communication.
This transition case is the most advisable. During the IPv6 This transition case is the most advisable. During the IPv6
transition period applications supporting both IPv4 and IPv6 should transition period, applications supporting both IPv4 and IPv6 should
be able to communicate with other applications, irrespective of the be able to communicate with other applications, irrespective of the
versions of the protocol stack or the application in the node. version of the protocol stack or the application in the node. Dual
Dual applications allow more interoperability between heterogeneous applications allow more interoperability between heterogeneous
applications and nodes. applications and nodes.
If the source code is written in a protocol-independent way, If the source code is written in a protocol-independent way, without
without dependencies on either IPv4 or IPv6, applications will be dependencies on either IPv4 or IPv6, applications will be able to
able to communicate with any combination of applications and types communicate with any combination of applications and types of nodes.
of nodes.
Implementations typically by-default prefer IPv6 if the remote node Implementations typically prefer IPv6 by default if the remote node
and application support it. However, if IPv6 connections fail, and application support it. However, if IPv6 connections fail,
version-independent applications will automatically try IPv4 ones. version-independent applications will automatically try IPv4 ones.
The resolver returns a list of valid addresses for the remote node The resolver returns a list of valid addresses for the remote node,
and applications can iterate through all of them until connection and applications can iterate through all of them until connection
succeeds. succeeds.
Applications writers should be aware of this typical by-default Application writers should be aware of this protocol ordering, which
ordering, but the applications themselves typically need not be is typically the default, but the applications themselves usually
aware of the the local protocol ordering [RFC 3484]. need not be [RFC3484].
If the source code is written in a protocol-dependent way, the If the source code is written in a protocol-dependent way, the
application will support IPv4 and IPv6 explicitly using 2 separate application will support IPv4 and IPv6 explicitly by using two
sockets. Note that there are some differences in bind() separate sockets. Note that there are some differences in bind()
implementation, whether you can first bind to the IPv6, and then implementation - that is, in whether one can first bind to IPv6
IPv4, wildcard addresses. It can be a pain to write applications wildcard addresses, and then to those for IPv4. Writing applications
that cope with this. If IPV6_V6ONLY is implemented, this becomes that cope with this can be a pain. Implementing IPV6_V6ONLY
simpler. The reason the IPv4 wildcard bind fails on some systems is simplifies this. The IPv4 wildcard bind fails on some systems
that the IPv4 address space is embedded into IPv6 address space because the IPv4 address space is embedded into IPv6 address space
when using IPv4-mapped IPv6 addresses. when IPv4-mapped IPv6 addresses are used.
A more detailed porting guideline is described in section 6. A more detailed porting guideline is described in section 6.
4.4. IPv4/IPv6 Applications in an IPv4-only Node 4.4. IPv4/IPv6 Applications in an IPv4-Only Node
As the transition is likely to happen over a longer timeframe, As the transition is likely to take place over a longer time frame,
applications that have already been ported to support both IPv4 and applications already ported to support both IPv4 and IPv6 may be run
IPv6 may be run on IPv4-only nodes. This would typically be done to on IPv4-only nodes. This would typically be done to avoid supporting
avoid having to support two application versions for older and two application versions for older and newer operating systems, or to
newer operating systems, or to support the case that the user wants support a case in which the user wants to disable IPv6 for some
to disable IPv6 for some reason. reason.
The most important case is the application support on systems where The most important case is the application support on systems where
IPv6 support can be dynamically enabled or disabled by the users. IPv6 support can be dynamically enabled or disabled by the users.
Applications on such a system should be able to handle the Applications on such a system should be able to handle a situation
situation where IPv6 would not be enabled. The secondary scenario IPv6 would not be enabled. Another scenario is when an application
is when an application could be deployed on older systems which do is deployed on older systems that do not support IPv6 at all (even
not support IPv6 at all (even the basic getaddrinfo etc. APIs). In the basic APIs such as getaddrinfo). In this case, the application
that case the application designer has to make a case-by-case designer has to make a case-by-case judgment call as to whether it
judgement call whether it makes sense to have compile-time toggle makes sense to have compile-time toggle between an older and a newer
between an older and newer API (having to support both in the API (having to support both in the code), or whether to provide
code), or whether to provide getaddrinfo etc. function support on getaddrinfo etc. function support on older platforms as part of the
older platforms as part of the application libraries. application libraries.
Depending on how application/operating system support is done, some Depending on application/operating system support, some may want to
may want to ignore this case, but usually no assumptions can be ignore this case, but usually no assumptions can be made, and
made and applications should also work in this scenario. applications should also work in this scenario.
An example is an application that issues a socket() command, first An example is an application that issues a socket() command, first
trying AF_INET6 and then AF_INET. However, if the kernel does not trying AF_INET6 and then AF_INET. However, if the kernel does not
have IPv6 support, the call will result in an EPROTONOSUPPORT or have IPv6 support, the call will result in an EPROTONOSUPPORT or
EAFNOSUPPORT error. Typically, encountering errors like these leads EAFNOSUPPORT error. Typically, errors like these lead to exiting the
to exiting the socket loop, and AF_INET will not even be tried. socket loop, and AF_INET will not even be tried. The application
The application will need to handle this case or build the loop in will need to handle this case or build the loop so that errors are
such a way that errors are ignored until the last address family. ignored until the last address family.
So, this case is just an extension of the IPv4/IPv6 support in the This case is just an extension of the IPv4/IPv6 support in the
previous case, covering one relatively common but often ignored previous case, covering one relatively common but often-ignored case.
case.
5. Application Porting Considerations 5. Application Porting Considerations
The minimum changes to IPv4 applications to work with IPv6 are The minimum changes for IPv4 applications to work with IPv6 are based
based on the different size and format of IPv4 and IPv6 addresses. on the different size and format of IPv4 and IPv6 addresses.
Applications have been developed with the assumption they would use Applications have been developed with IPv4 network protocol in mind.
IPv4 as their network protocol. This assumption results in many IP This assumption has resulted in many IP dependencies through source
dependencies through source code. code.
The following list summarizes the more common IP version The following list summarizes the more common IP version dependencies
dependencies in applications: in applications:
a) Presentation format for an IP address: it is an ASCII string a) Presentation format for an IP address: An ASCII string that
which represents the IP address, dotted-decimal string represents the IP address, a dotted-decimal string for IPv4,
for IPv4 and hexadecimal string for IPv6. and a hexadecimal string for IPv6.
b) Transport layer API: functions to establish communications b) Transport layer API: Functions to establish communications and
and to exchange information. to exchange information.
c) Name and address resolution: conversion functions between c) Name and address resolution: Conversion functions between
hostnames and IP addresses, and vice versa. hostnames and IP addresses.
d) Specific IP dependencies: more specific IP version d) Specific IP dependencies: More specific IP version
dependencies, such as: IP address selection, dependencies, such as IP address selection, application
application framing, storage of IP addresses. framing, and storage of IP addresses.
e) Multicast applications: one must find the IPv6 equivalents to e) Multicast applications: One must find the IPv6 equivalents to
the IPv4 multicast addresses, and use the right socket the IPv4 multicast addresses and use the right socket
configuration options. configuration options.
In the following subsections, the problems with the aforementioned The following subsections describe the problems with the
IP version dependencies are analyzed. Although application source aforementioned IP version dependencies. Although application source
code can be ported to IPv6 with minimum changes related to IP code can be ported to IPv6 with minimum changes related to IP
addresses, some recommendations are given to modify the source code addresses, some recommendations are given to modify the source code
in a protocol independent way, which will allow applications to in a protocol-independent way, which will allow applications to work
work using both IPv4 and IPv6. with both IPv4 and IPv6.
5.1 Presentation Format for an IP Address 5.1. Presentation Format for an IP Address
Many applications use IP addresses to identify network nodes and to Many applications use IP addresses to identify network nodes and to
establish connections to destination addresses. For instance, using establish connections to destination addresses. For instance, using
the client/server model, clients usually need an IP address as an the client/server model, clients usually need an IP address as an
application parameter to connect to a server. This IP address is application parameter to connect to a server. This IP address is
usually provided in the presentation format, as a string. There usually provided in the presentation format, as a string. There are
are two problems, when porting the presentation format for an IP two problems when porting the presentation format for an IP address:
address: the allocated memory and the management of the the allocated memory and the management of the presentation format.
presentation format.
Usually, the allocated memory to contain an IPv4 address Usually, the memory allocated to contain an IPv4 address
representation as a string is unable to contain an IPv6 address. representation as a string is unable to contain an IPv6 address.
Applications should be modified to prevent buffer overflows made Applications should be modified to prevent buffer overflows made
possible by the larger IPv6 address. possible by the larger IPv6 address.
IPv4 and IPv6 do not use the same presentation format. IPv4 uses a IPv4 and IPv6 do not use the same presentation format. IPv4 uses a
dot (.) to separate the four octets written in decimal notation and dot (.) to separate the four octets written in decimal notation, and
IPv6 uses a colon (:) to separate each pair of octets written in IPv6 uses a colon (:) to separate each pair of octets written in
hexadecimal notation [RFC 3513]. In cases where it one must be hexadecimal notation [RFC3513]. In cases where one must be able to
able to specify e.g., port numbers with the address (see below), it specify, for example, port numbers with the address (see below), it
may be desirable to require placing the address inside the square may be desirable to require placing the address inside the square
brackets [TextRep]. brackets [TextRep].
A particular problem with IP address parsers comes when the input A particular problem with IP address parsers comes when the input is
is actually a combination of IP address and port number. With IPv4 actually a combination of IP address and port number. With IPv4
these are often coupled with a colon such as "192.0.2.1:80". these are often coupled with a colon; for example, "192.0.2.1:80".
However, such an approach would be ambiguous with IPv6 as colons However, this approach would be ambiguous with IPv6, as colons are
are already used to structure the address. already used to structure the address.
Therefore, the IP address parsers which take the port number Therefore, the IP address parsers that take the port number separated
separated with a colon should represent IPv6 addresses somehow. with a colon should distinguish IPv6 addresses somehow. One way is
One way is to enclose the address in brackets, as is done with to enclose the address in brackets, as is done with Uniform Resource
Uniform Resource Locators (URLs) [RFC 2732], like Locators (URLs) [RFC2732]; for example, http://[2001:db8::1]:80.
http://[2001:db8::1]:80.
Some applications also need to specify IPv6 prefixes and lengths; Some applications also need to specify IPv6 prefixes and lengths:
the prefix length should be inserted outside of the square The prefix length should be inserted outside of the square brackets,
brackets, if used, like [2001:db8::]/64 or 2001:db8::/64 -- not for if used; for example, [2001:db8::]/64 or 2001:db8::/64 and not
example [2001:db8::/64]. Note that prefix/length notation is [2001:db8::/64]. Note that prefix/length notation is syntactically
syntactically indistinguishable from a legal URI; therefore the indistinguishable from a legal URI; therefore, the prefix/length
prefix/length notation must not be used when it isn't clear from notation must not be used when it isn't clear from the context that
the context that it's used to specify the prefix and length and it's used to specify the prefix and length and not, for example, a
not e.g., a URI. URI.
In some specific cases, it may be necessary to give a zone In some specific cases, it may be necessary to give a zone identifier
identifier as part of the address, like fe80::1%eth0. In general, as part of the address; for example, fe80::1%eth0. In general,
applications should not need to parse these identifiers. applications should not need to parse these identifiers.
The IP address parsers should support enclosing the IPv6 address in The IP address parsers should support enclosing the IPv6 address in
brackets even when it's not used in conjunction with a port number, brackets, even when the address is not used in conjunction with a
but requiring that the user always gives a literal IP address port number. Requiring that the user always give a literal IP
enclosed in brackets is not recommended. address enclosed in brackets is not recommended.
One should note that some applications may also represent IPv6 Note that some applications may also represent IPv6 address literals
address literals differently; for example, SMTP [RFC 2821] uses differently; for example, SMTP [RFC2821] uses [IPv6:2001:db8::1].
[IPv6:2001:db8::1].
Note that the use of address literals is strongly discouraged for Note that the use of address literals is strongly discouraged for
general purpose direct input to the applications; host names and general-purpose direct input to the applications. Host names and DNS
DNS should be used instead. should be used instead.
5.2 Transport Layer API 5.2. Transport Layer API
Communication applications often include a transport module that Communication applications often include a transport module that
establishes communications. Usually this module manages everything establishes communications. Usually this module manages everything
related to communications and uses a transport layer API, typically related to communications and uses a transport-layer API, typically
as a network library. When porting an application to IPv6, most as a network library. When an application is ported to IPv6, most
changes should be made in this application transport module in changes should be made in this application transport module in order
order to be adapted to the new IPv6 API. to be adapted to the new IPv6 API.
In the general case, porting an existing application to IPv6 In the general case, porting an existing application to IPv6 requires
requires an examination of the following issues related to the API: an examination of the following issues related to the API:
- Network information storage: IP address data structures. - Network Information Storage: IP address Data Structures
The new structures must contain 128-bit IP addresses. The use of The new structures must contain 128-bit IP addresses. The use
generic address structures, which can store any address family, of generic address structures, which can store any address
is recommended. family, is recommended.
Sometimes special addresses are hard-coded in the application Sometimes special addresses are hard-coded in the application
source code; developers should pay attention to them in order to source code. Developers should pay attention to these in order
use the new address format. Some of these special IP addresses to use the new address format. Some of these special IP
are: wildcard local, loopback and broadcast. IPv6 does not have addresses are wildcard local, loopback, and broadcast. IPv6
the broadcast addresses, so applications can use multicast does not have the broadcast addresses, so applications can use
instead. multicast instead.
- Address conversion functions. - Address Conversion Functions
The address conversion functions convert the binary address The address conversion functions convert the binary address
representation to the presentation format and vice versa. The representation to the presentation format and vice versa. The
new conversion functions are specified to the IPv6 address new conversion functions are specified to the IPv6 address
format. format.
- Communication API functions. - Communication API Functions
These functions manage communications. Their signatures are These functions manage communications. Their signatures are
defined based on a generic socket address structure. The defined based on a generic socket address structure. The same
same functions are valid for IPv6, however, the IP address data functions are valid for IPv6; however, the IP address data
structures used when calling these functions require the structures used when calling these functions require the
updates. updates.
- Network configuration options. - Network Configuration Options
They are used when configuring different communication models These are used when different communication models are
for Input/Output (I/O) operations (blocking/nonblocking, I/O configured for Input/Output (I/O) operations
multiplexing, etc.) and should be translated to the IPv6 ones. (blocking/nonblocking, I/O multiplexing, etc.) and should be
translated for IPv6.
5.3 Name and Address Resolution 5.3. Name and Address Resolution
From the application point of view, the 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 is a system-independent process. An application calls functions in a
a system library, the resolver, which is linked into the system library, the resolver, which is linked into the application
application when this is built. However, these functions use IP when it is built. However, these functions use IP address
address structures, which are protocol dependent, and must be structures, that are protocol dependent and must be reviewed to
reviewed to support the new IPv6 resolution calls. support the new IPv6 resolution calls.
There are two basic resolution functions. The first function With IPv6, there are two new basic resolution functions,
returns a list of all configured IP addresses for a hostname. These getaddrinfo() and getnameinfo(). The first returns a list of all
queries can be constrained to one protocol family, for instance configured IP addresses for a hostname. These queries can be
only IPv4 or only IPv6 addresses. However, the recommendation is constrained to one protocol family; for instance, only IPv4 or only
that all configured IP addresses should be obtained to allow IPv6 addresses. However, it is recommended that all configured IP
applications to work with every kind of node. And the second addresses be obtained to allow applications to work with every kind
function returns the hostname associated to an IP address. of node. The second function returns the hostname associated to an
IP address.
5.4 Specific IP Dependencies 5.4. Specific IP Dependencies
5.4.1 IP Address Selection 5.4.1. IP Address Selection
IPv6 promotes the configuration of multiple IP addresses per node, Unlike the IPv4 model, IPv6 promotes the configuration of multiple IP
which is a difference when compared with the IPv4 model; however addresses per node, however, applications only use a
applications only use a destination/source pair for a destination/source pair for a communication. Choosing the right IP
communication. Choosing the right IP source and destination source and destination addresses is a key factor that may determine
addresses is a key factor that may determine the route of IP the route of IP datagrams.
datagrams.
Typically nodes, not applications, automatically solve the source Typically, nodes, not applications, automatically solve the source
address selection. A node will choose the source address for a address selection. A node will choose the source address for a
communication following some rules of best choice, [RFC 3484], but communication following some rules of best choice, per [RFC3484], but
also allowing applications to make changes in the ordering rules. will also allow applications to make changes in the ordering rules.
When selecting the destination address, applications usually ask a When selecting the destination address, applications usually ask a
resolver for the destination IP address. The resolver returns a set resolver for the destination IP address. The resolver returns a set
of valid IP addresses from a hostname. Unless applications have a of valid IP addresses from a hostname. Unless applications have a
specific reason to select any particular destination address, they specific reason to select any particular destination address, they
should just try each element in the list until the communication should try each element in the list until the communication succeeds.
succeeds.
In some cases, the application may need to specify its source In some cases, the application may need to specify its source
address. Then the destination address selection process picks the address. The destination address selection process picks the best
best destination for the source address (instead of picking the destination for the source address (instead of picking the best
best source address for the chosen destination address). Note that source address for the chosen destination address). Note that if it
there may be an increase in complexity for IP-version independent is not yet known which protocol will be used for communication there
applications which have to specify the source address (especially may be an increase in complexity for IP version - independent
for client applications; fortunately, specifying the source address applications that have to specify the source address (especially for
is not typically required), if it is not yet known which protocol client applications. Fortunately, specifying the source address is
will be used for communication. not typically required).
5.4.2 Application Framing 5.4.2. Application Framing
The Application Level Framing (ALF) architecture controls The Application Level Framing (ALF) architecture controls mechanisms
mechanisms that traditionally fall within the transport layer. that traditionally fall within the transport layer. Applications
Applications implementing ALF are often responsible for packetizing implementing ALF are often responsible for packetizing data into
data into Application Data Units (ADUs). The application problem Application Data Units (ADUs). The application problem with ALF
when using ALF is the ADU size selection to obtain better arrives from the ADU size selection to obtain better performance.
performance.
Application framing is typically needed by applications using Applications using connectionless protocols (such as UDP) typically
connectionless protocols (such as UDP). Such applications have need application framing. These applications have three choices: (1)
three choices: (1) to use packet sizes no larger than IPv6 IPv6 to use packet sizes no larger than the IPv6 minimum Maximum
minimum Maximum Transmission Unit (MTU) of 1280 bytes [RFC2460], Transmission Unit (MTU) of 1280 bytes [RFC2460], (2) to use any
(2) to use whatever packet sizes but force IPv6 packet sizes, but to force IPv6 fragmentation/reassembly when
fragmentation/reassembly when necessary, or (3) to optimize the necessary, or (3) to optimize the packet size and avoid unnecessary
packet size and avoid unnecessary fragmentation/reassembly, guess fragmentation/reassembly, and to guess or find out the optimal packet
or find out the optimal packet sizes which can be sent and sizes that can be sent and received, end-to-end, on the network.
received, end-to-end, on the network. This memo takes no stance on This memo takes no stance on that approach is best.
which approach to adopt.
Note that the most optimal ALF depends on dynamic factors such as 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 Path MTU or whether IPv4 or IPv6 is being used (due to different
header sizes, possible IPv6-in-IPv4 tunneling overhead, etc.). header sizes, possible IPv6-in-IPv4 tunneling overhead, etc.). These
These have to be taken into consideration when implementing factors have to be taken into consideration when application framing
application framing. is implemented.
5.4.3 Storage of IP Addresses 5.4.3. Storage of IP Addresses
Some applications store IP addresses as information of remote Some applications store IP addresses as remote peer information. For
peers. For instance, one of the most popular ways to register instance, one of the most popular ways to register remote nodes in
remote nodes in collaborative applications is based on using IP collaborative applications uses IP addresses as registry keys.
addresses as registry keys.
Although the source code that stores IP addresses can be modified Although the source code that stores IP addresses can be modified to
to IPv6 following the previous basic porting recommendations, there IPv6 by following the previous basic porting recommendations,
are some reasons why applications should not store IP addresses: applications should not store IP addresses for the following reasons:
- IP addresses can change throughout time, for instance - IP addresses can change throughout time; for instance, after a
after a renumbering process. renumbering process.
- The same node can reach a destination host using different - The same node can reach a destination host using different IP
IP addresses, possibly with a different protocol version. addresses, possibly with a different protocol version.
When possible, applications should store names such as FQDNs, or When possible, applications should store names such as FQDNs or other
other protocol-independent identities instead of storing addresses. protocol-independent identities instead of addresses. In this case
In this case applications are only bound to specific addresses at applications are only bound to specific addresses at run time, or for
run time, or for the duration of a cache lifetime. Other types of the duration of a cache lifetime. Other types of applications, such
applications, such as massive peer to peer systems with their own as massive peer-to-peer systems with their own rendezvous and
rendezvous and discovery mechanisms, may need to cache addresses discovery mechanisms, may need to cache addresses for performance
for performance reasons, but cached addresses should not be treated reasons, but cached addresses should not be treated as permanent,
as permanent, reliable information. In highly dynamic networks any reliable information. In highly dynamic networks, any form of name
form of name resolution may be impossible, and here again addresses resolution may be impossible, and here again addresses must be
must be cached. cached.
5.5 Multicast Applications 5.5. Multicast Applications
There is an additional problem in porting multicast applications. There is an additional problem in porting multicast applications.
When using multicast facilities some changes must be carried out to When multicast facilities are used some changes must be carried out
support IPv6. First, applications must change the IPv4 multicast to support IPv6. First, applications must change the IPv4 multicast
addresses to IPv6 ones, and second, the socket configuration addresses to IPv6 ones, and second, the socket configuration options
options must be changed. must be changed.
All the IPv6 multicast addresses encode scope; the scope was only All IPv6 multicast addresses encode scope; the scope was only
implicit in IPv4 (with multicast groups in 239/8). Also, while a implicit in IPv4 (with multicast groups in 239/8). Also, although a
large number of application-specific multicast addresses have been large number of application-specific multicast addresses have been
assigned with IPv4, this has been (luckily enough) avoided in IPv6. assigned with IPv4, this has been (luckily enough) avoided with IPv6.
So, there are no direct equivalents for all the multicast So there are no direct equivalents for all the multicast addresses.
addresses. For link-local multicast, it's possible to pick almost For link-local multicast, it's possible to pick almost anything
anything within the link-local scope. The global groups could use within the link-local scope. The global groups could use unicast
unicast-prefix-based addresses [RFC 3306]. All in all, this may prefix - based addresses [RFC3306]. All in all, this may force the
force the application developers to write more protocol dependent application developers to write more protocol-dependent code.
code.
Another problem is/has been that IPv6 multicast does not yet have a Another problem is that IPv6 multicast does not yet have a
standardized mechanism for traditional Any Source Multicast for standardized mechanism for traditional Any Source Multicast for
Interdomain multicast. The models for Any Source Multicast (ASM) Interdomain multicast. The models for Any Source Multicast (ASM) or
or Source-Specific Multicast (SSM) are generally similar between Source-Specific Multicast (SSM) are generally similar between IPv4
IPv4 and IPv6, but it is possible that PIM-SSM will become more and IPv6, but it is possible that PIM-SSM will become more widely
widely deployed in IPv6 due to its simpler architecture. deployed in IPv6 due to its simpler architecture.
So, it might be beneficial to port the applications to use SSM It might be beneficial to port the applications to use SSM semantics,
semantics, requiring off-band source discovery mechanisms and the requiring off-band source discovery mechanisms and a different API
use of a different API [RFC 3678]. Inter-domain ASM service is [RFC3678]. Inter-domain ASM service is available only through a
available only through a method embedding the Rendezvous Point method embedding the Rendezvous Point address in the multicast
address in the multicast address [Embed-RP]. address [Embed-RP].
Another generic problem for multiparty conferencing applications, Another generic problem with multiparty conferencing applications,
which is similar to the issues with peer-to-peer applications, is similar to the issues with peer-to-peer applications, is that all
that all the users of the session must use the same protocol users of the session must use the same protocol version (IPv4 or
version (IPv4 or IPv6), or some form of proxies or translators must IPv6), or some form of proxy or translator (e.g., [MUL-GW]).
be used (e.g., [MUL-GW]).
6. Developing IP version-independent Applications 6. Developing IP Version - Independent Applications
As we have seen before, dual applications working with both IPv4 As stated, dual applications working with both IPv4 and IPv6 are
and IPv6 are recommended. These applications should avoid IP recommended. These applications should avoid IP dependencies in the
dependencies in the source code. However, if IP dependencies are source code. However, if IP dependencies are required, one of the
required, one of the best solutions is based on building a better solutions would be to build a communication library that
communication library which provides an IP version independent API provides an IP version - independent API to applications and that
to applications and hides all dependencies. hides all dependencies.
In order to develop IP version independent applications, the To develop IP version - independent applications, the following
following guidelines should be considered. guidelines should be considered.
6.1 IP version-independent Structures 6.1. IP Version - Independent Structures
All of the memory structures and APIs should be IP version- All memory structures and APIs should be IP version-independent. One
independent. In that sense, one should avoid structs in_addr, should avoid structs in_addr, in6_addr, sockaddr_in, and
in6_addr, sockaddr_in and sockaddr_in6. sockaddr_in6.
Suppose you pass a network address to some function, foo(). If you Suppose a network address is passed to some function, foo(). If one
use struct in_addr or struct in6_addr, you will end up with an uses struct in_addr or struct in6_addr, results an extra parameter to
extra parameter to indicate address family, as below: indicate address family, as below:
struct in_addr in4addr; struct in_addr in4addr;
struct in6_addr in6addr; struct in6_addr in6addr;
/* IPv4 case */ /* IPv4 case */
foo(&in4addr, AF_INET); foo(&in4addr, AF_INET);
/* IPv6 case */ /* IPv6 case */
foo(&in6addr, AF_INET6); foo(&in6addr, AF_INET6);
However, this leads to duplicated code and having to consider each This leads to duplicated code and having to consider each scenario
scenario from both perspectives independently; this is difficult to from both perspectives independently, which is difficult to maintain.
maintain. So, we should use struct sockaddr_storage like below. So we should use struct sockaddr_storage, as below:
struct sockaddr_storage ss; struct sockaddr_storage ss;
int sslen; int sslen;
/* AF independent! - use sockaddr when passing a pointer */ /* AF independent! - use sockaddr when passing a pointer */
/* note: it's typically necessary to also pass the length /* note: it's typically necessary to also pass the length
explicitly */ explicitly */
foo((struct sockaddr *)&ss, sslen); foo((struct sockaddr *)&ss, sslen);
6.2 IP version-independent APIs 6.2. IP Version - Independent APIs
getaddrinfo() and getnameinfo() are new address independent The new address independent variants getaddrinfo() and getnameinfo()
variants that hide the gory details of name-to-address and address- hide the gory details of name-to-address and address-to-name
to-name translations. They implement functionalities of the translations. They implement functionalities of the following
following functions: functions:
gethostbyname() gethostbyname()
gethostbyaddr() gethostbyaddr()
getservbyname() getservbyname()
getservbyport() getservbyport()
They also obsolete the functionality of gethostbyname2(), defined They also obsolete the functionality of gethostbyname2(), defined in
in [RFC2133]. [RFC2133].
These can perform hostname/address and service name/port lookups, The new variants can perform hostname/address and service name/port
though the features can be turned off if desirable. Getaddrinfo() lookups, though the features can be turned off, if desired.
can return multiple addresses, as below: Getaddrinfo() can return multiple addresses, as below:
localhost. IN A 127.0.0.1 localhost. IN A 127.0.0.1
IN A 127.0.0.2 IN A 127.0.0.2
IN AAAA ::1 IN AAAA ::1
In this example, if IPv6 is preferred, getaddrinfo returns first In this example, if IPv6 is preferred, getaddrinfo first returns ::1;
::1, and then both 127.0.0.1 and 127.0.0.2 is in a random order. then both 127.0.0.1 and 127.0.0.2 are in a random order.
Getaddrinfo() and getnameinfo() can query hostname as well as Getaddrinfo() and getnameinfo() can query hostname and service
service name/port at once. name/port at once.
It is not preferred to hardcode AF-dependent knowledge into the Hardcoding AF-dependent knowledge is not preferred in the program.
program. The construct like below should be avoided: Constructs such as that below should be avoided:
/* BAD EXAMPLE */ /* BAD EXAMPLE */
switch (sa->sa_family) { switch (sa->sa_family) {
case AF_INET: case AF_INET:
salen = sizeof(struct sockaddr_in); salen = sizeof(struct sockaddr_in);
break; break;
} }
Instead, we should use the ai_addrlen member of the addrinfo Instead, we should use the ai_addrlen member of the addrinfo
structure, as returned by getaddrinfo(). structure, as returned by getaddrinfo().
The gethostbyname(), gethostbyaddr(), getservbyname(), and The gethostbyname(), gethostbyaddr(), getservbyname(), and
getservbyport() are mainly used to get server and client sockets. getservbyport() are mainly used to get server and client sockets. In
Following, we will see simple examples to create these sockets the following sections, we will see simple examples creating these
using the new IPv6 resolution functions. sockets by using the new IPv6 resolution functions.
6.2.1 Example of Overly Simplistic TCP Server Application 6.2.1. Example of Overly Simplistic TCP Server Application
A simple TCP server socket at service name (or port number string) A simple TCP server socket at service name (or port number string)
SERVICE: SERVICE:
/* /*
* BAD EXAMPLE: does not implement the getaddrinfo loop as * BAD EXAMPLE: does not implement the getaddrinfo loop as
* specified in 6.3. This may result in one of the following: * specified in 6.3. This may result in one of the following:
* - an IPv6 server, listening at the wildcard address, * - an IPv6 server, listening at the wildcard address,
* allowing IPv4 addresses through IPv4-mapped IPv6 addresses. * allowing IPv4 addresses through IPv4-mapped IPv6 addresses.
* - an IPv4 server, if IPv6 is not enabled, * - an IPv4 server, if IPv6 is not enabled,
skipping to change at page 20, line 4 skipping to change at page 21, line 16
sockfd = socket(res->family, res->ai_socktype, res->ai_protocol); sockfd = socket(res->family, res->ai_socktype, res->ai_protocol);
if (sockfd < 0) { if (sockfd < 0) {
/* handle socket error */ /* handle socket error */
} }
if (bind(sockfd, res->ai_addr, res->ai_addrlen) < 0) { if (bind(sockfd, res->ai_addr, res->ai_addrlen) < 0) {
/* handle bind error */ /* handle bind error */
} }
/* ... */ /* ... */
freeaddrinfo(res); freeaddrinfo(res);
6.2.2 Example of Overly Simplistic TCP Client Application 6.2.2. Example of Overly Simplistic TCP Client Application
A simple TCP client socket connecting to a server which is running A simple TCP client socket connecting to a server running at node
at node name (or IP address presentation format) SERVER_NODE and name (or IP address presentation format) SERVER_NODE and service name
service name (or port number string) SERVICE: (or port number string) SERVICE follows:
/* /*
* BAD EXAMPLE: does not implement the getaddrinfo loop as * BAD EXAMPLE: does not implement the getaddrinfo loop as
* specified in 6.3. This may result in one of the following: * specified in 6.3. This may result in one of the following:
* - an IPv4 connection to an IPv4 destination, * - an IPv4 connection to an IPv4 destination,
* - an IPv6 connection to an IPv6 destination, * - an IPv6 connection to an IPv6 destination,
* - an attempt to try to reach an IPv6 destination (if AAAA * - an attempt to try to reach an IPv6 destination (if AAAA
* record found), but failing -- without fallbacks -- because: * record found), but failing -- without fallbacks -- because:
* o getaddrinfo supports IPv6 but the system does not * o getaddrinfo supports IPv6 but the system does not
* o IPv6 routing doesn't exist, so falling back to e.g. TCP * o IPv6 routing doesn't exist, so falling back to e.g., TCP
* timeouts * timeouts
* o IPv6 server reached, but service not IPv6-enabled or * o IPv6 server reached, but service not IPv6-enabled or
* firewalled away * firewalled away
* - if the first destination is not reached, there is no * - if the first destination is not reached, there is no
* fallback to the next records * fallback to the next records
*/ */
struct addrinfo hints, *res; struct addrinfo hints, *res;
int error, sockfd; int error, sockfd;
memset(&hints, 0, sizeof(hints)); memset(&hints, 0, sizeof(hints));
skipping to change at page 21, line 5 skipping to change at page 22, line 17
} }
if (connect(sockfd, res->ai_addr, res->ai_addrlen) < 0 ) { if (connect(sockfd, res->ai_addr, res->ai_addrlen) < 0 ) {
/* handle connect error */ /* handle connect error */
} }
/* ... */ /* ... */
freeaddrinfo(res); freeaddrinfo(res);
6.2.3 Binary/Presentation Format Conversion 6.2.3. Binary/Presentation Format Conversion
In addition, we should consider the binary and presentation address We should consider the binary and presentation address format
format conversion APIs. The following functions convert network conversion APIs. The following functions convert network address
address structure in its presentation address format and vice structure in its presentation address format and vice versa:
versa:
inet_ntop() inet_ntop()
inet_pton() inet_pton()
Both are from the basic socket extensions for IPv6. However, these Both are from the basic socket extensions for IPv6. However, these
conversion functions are protocol-dependent; instead it is better conversion functions are protocol-dependent. It is better to use
to use getnameinfo()/getaddrinfo() as follows (inet_pton and getnameinfo()/getaddrinfo() (inet_pton and inet_ntop equivalents are
inet_ntop equivalents are described in Appendix A). described in Appendix A).
Conversion from network address structure to presentation format Conversion from network address structure to presentation format can
can be written: be written as follows:
struct sockaddr_storage ss; struct sockaddr_storage ss;
char addrStr[INET6_ADDRSTRLEN]; char addrStr[INET6_ADDRSTRLEN];
char servStr[NI_MAXSERV]; char servStr[NI_MAXSERV];
int error; int error;
/* fill ss structure */ /* fill ss structure */
error = getnameinfo((struct sockaddr *)&ss, sizeof(ss), error = getnameinfo((struct sockaddr *)&ss, sizeof(ss),
addrStr, sizeof(addrStr), addrStr, sizeof(addrStr),
servStr, sizeof(servStr), servStr, sizeof(servStr),
NI_NUMERICHOST); NI_NUMERICHOST);
Conversions from presentation format to network address structure can
Conversions from presentation format to network address structure be written as follows:
can be written as follows:
struct addrinfo hints, *res; struct addrinfo hints, *res;
char addrStr[INET6_ADDRSTRLEN]; char addrStr[INET6_ADDRSTRLEN];
int error; int error;
/* fill addrStr buffer */ /* fill addrStr buffer */
memset(&hints, 0, sizeof(hints)); memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC; hints.ai_family = AF_UNSPEC;
error = getaddrinfo(addrStr, NULL, &hints, &res); error = getaddrinfo(addrStr, NULL, &hints, &res);
if (error != 0) { if (error != 0) {
/* handle getaddrinfo error */ /* handle getaddrinfo error */
} }
/* res->ai_addr contains the network address structure */ /* res->ai_addr contains the network address structure */
/* ... */ /* ... */
freeaddrinfo(res); freeaddrinfo(res);
6.3 Iterated Jobs for Finding the Working Address 6.3. Iterated Jobs for Finding the Working Address
In a client code, when multiple addresses are returned from In a client code, when multiple addresses are returned from
getaddrinfo(), we should try all of them until connection succeeds. getaddrinfo(), we should try all of them until connection succeeds.
When a failure occurs with socket(), connect(), bind(), or some When a failure occurs with socket(), connect(), bind(), or some other
other function, the code should go on to try the next address. function, the code should go on to try the next address.
In addition, if something is wrong with the socket call because the 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), address family is not supported (i.e., in case of section 4.4),
applications should try the next address structure. applications should try the next address structure.
Note: in the following examples, the socket() return value error Note: In the following examples, the socket() return value error
handling could be simplied by substituting special checking of handling could be simplified by always continuing on with the socket
specific error numbers by always continuing on with the socket loop instead of performing special checking of specific error
loop. numbers.
6.3.1 Example of TCP Server Application 6.3.1. Example of TCP Server Application
The previous example TCP server example should be written: The previous TCP server example should be written as follows:
#define MAXSOCK 2 #define MAXSOCK 2
struct addrinfo hints, *res; struct addrinfo hints, *res;
int error, sockfd[MAXSOCK], nsock=0; int error, sockfd[MAXSOCK], nsock=0;
memset(&hints, 0, sizeof(hints)); memset(&hints, 0, sizeof(hints));
hints.ai_flags = AI_PASSIVE; hints.ai_flags = AI_PASSIVE;
hints.ai_family = AF_UNSPEC; hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM; hints.ai_socktype = SOCK_STREAM;
skipping to change at page 23, line 40 skipping to change at page 25, line 16
close(sockfd[nsock]); close(sockfd[nsock]);
continue; continue;
} }
} }
nsock++; nsock++;
} }
freeaddrinfo(res); freeaddrinfo(res);
/* check that we were able to obtain the sockets */ /* check that we were able to obtain the sockets */
6.3.2 Example of TCP Client Application 6.3.2. Example of TCP Client Application
The previous TCP client example should be written: The previous TCP client example should be written as follows:
struct addrinfo hints, *res, *aip; struct addrinfo hints, *res, *aip;
int sockfd, error; int sockfd, error;
memset(&hints, 0, sizeof(hints)); memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC; hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM; hints.ai_socktype = SOCK_STREAM;
error = getaddrinfo(SERVER_NODE, SERVICE, &hints, &res); error = getaddrinfo(SERVER_NODE, SERVICE, &hints, &res);
if (error != 0) { if (error != 0) {
skipping to change at page 24, line 51 skipping to change at page 26, line 31
if (sockfd > 0) { if (sockfd > 0) {
/* socket connected to server address */ /* socket connected to server address */
/* ... */ /* ... */
} }
freeaddrinfo(res); freeaddrinfo(res);
7. Transition Mechanism Considerations 7. Transition Mechanism Considerations
A mechanism, [NAT-PT], introduces a special set of addresses, The mechanism [NAT-PT] introduces a special set of addresses, formed
formed of NAT-PT prefix and an IPv4 address; this refers to IPv4 of an NAT-PT prefix and an IPv4 address these refer to IPv4 addresses
addresses, translated by NAT-PT DNS-ALG. In some cases, one might translated by NAT-PT DNS-ALG. In some cases, one might be tempted to
be tempted to handle these differently. handle these differently.
However, IPv6 applications must not be required to distinguish However, IPv6 applications must not be required to distinguish
"normal" and "NAT-PT translated" addresses (or any other kind of "normal" and "NAT-PT translated" addresses (or any other kind of
special addresses, including the IPv4-mapped IPv6-addresses): that special addresses, including the IPv4-mapped IPv6 addresses): This
would be completely impractical, and if such distinction must be would be completely impractical, and if the distinction must be made,
made, it must be done elsewhere (e.g. kernel, system libraries). it must be done elsewhere (e.g., kernel, system libraries).
8. Security Considerations 8. Security Considerations
There are a number of security considerations with IPv6 transition There are a number of security considerations for IPv6 transition,
but those are outside the scope of this memo. but those are outside the scope of this memo.
To ensure the availability and robustness of the service even when To ensure the availability and robustness of the service even when
transitioning to IPv6, this memo described a number of ways to make transitioning to IPv6, this memo describes a number of ways to make
applications more resistant to failures by cycling through applications more resistant to failures by cycling through addresses
addresses until a working one is found. Doing this properly is until a working one is found. Doing this properly is critical to
critical to avoid unavailability and loss of service. maintain availability and to avoid loss of service.
One particular point about application transition is how A special consideration about application transition is how IPv4-
IPv4-mapped IPv6 addresses are handled. The use in the API can be mapped IPv6 addresses are handled. The use in the API can be seen
seen as both a merit (easier application transition) and as a both as a merit (easier application transition) and as a burden
burden (difficulty in ensuring whether the use was legimate) Note (difficulty in ensuring whether the use was legitimate). Note that
that some systems will disable (by default) support for internal some systems will disable (by default) support for internal IPv4-
IPv4-mapped IPv6 addresses. The security concerns regarding mapped IPv6 addresses. The security concerns regarding these on the
IPv4-mapped IPv6 addresses on the wire are legitimate but disabling wire are legitimate, but disabling it internally breaks one
it internally breaks one transition mechanism for server transition mechanism for server applications originally written to
applications which were originally written to bind() and listen() bind() and listen() to a single socket by using a wildcard address
to a single socket using a wildcard address [V6MAPPED]. This [V6MAPPED]. This should be considered in more detail when
should be considered in more detail when designing applications. applications are designed.
9. Acknowledgements 9. Acknowledgments
Some of guidelines for development of IP version-independent Some of guidelines for development of IP version-independent
applications (section 6) were first brought up by [AF-APP]. Other applications (section 6) were first brought up by [AF-APP]. Other
work to document application porting guidelines has also been in work to document application porting guidelines has also been in
progress, for example [IP-GGF] and [PRT]. We would like to thank progress; for example, [IP-GGF] and [PRT]. We would like to thank
the members of the the v6ops working group and the application area the members of the v6ops working group and the application area for
for helpful comments. Special thanks are due to Brian E. helpful comments. Special thanks are due to Brian E. Carpenter,
Carpenter, Antonio Querubin, Stig Venaas, Chirayu Patel, Jordi Antonio Querubin, Stig Venaas, Chirayu Patel, Jordi Palet, and Jason
Palet, and Jason Lin for extensive review of this document. We Lin for extensive review of this document. We acknowledge Ron Pike
acknowledge Ron Pike for proofreading the document. for proofreading the document.
10. References 10. References
Normative References 10.1. Normative References
[RFC 3493] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Socket Interface Extensions for IPv6," RFC 3493, February Stevens, "Basic Socket Interface Extensions for IPv6",
2003. RFC 3493, February 2003.
[RFC 3542] W. Stevens, M. Thomas, E. Nordmark, T. Jinmei, "Advanced [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
Sockets Application Program Interface (API) for IPv6," "Advanced Sockets Application Program Interface (API) for
RFC 3542, May 2003. IPv6", RFC 3542, May 2003.
[BIS] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts [BIS] Tsuchiya, K., Higuchi, H., and Y. Atarashi, "Dual Stack
using the "Bump-In-the-Stack" Technique (BIS)," RFC 2767, Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC
February 2000. 2767, February 2000.
[BIA] S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand, [BIA] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A.
"Dual Stack Hosts using "Bump-in-the-API" (BIA)," RFC Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)",
3338, October 2002. RFC 3338, October 2002.
[RFC 2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification," RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC 3484] R. Draves, "Default Address Selection for IPv6," [RFC3484] Draves, R., "Default Address Selection for Internet
RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC 3513] R. Hinden, S. Deering, "Internet Protocol Version 6 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture," RFC 3513, April 2003. (IPv6) Addressing Architecture", RFC 3513, April 2003.
Informative References 10.2. Informative References
[2893BIS] E. Nordmark, R. E. Gilligan, "Basic Transition Mechanisms [2893BIS] Nordmark, E. and R. E. Gilligan, "Basic Transition
for IPv6 Hosts and Routers," <draft-ietf-v6ops-mech-v2- Mechanisms for IPv6 Hosts and Routers", Work in Progress,
03.txt>, June 2004, Work-in-progress. June 2004.
[RFC 2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal [RFC2133] Gilligan, R., Thomson, S., Bound, J., and W. Stevens,
IPv6 Addresses in URL's," RFC 2732, December 1999. "Basic Socket Interface Extensions for IPv6", RFC 2133,
April 1997.
[RFC 2821] J. Klensin, "Simple Mail Transfer Protocol," RFC 2821, [RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for
Literal IPv6 Addresses in URL's", RFC 2732, December
1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[TextRep] A. Main, "Textual Representation of IPv4 and IPv6 [TextRep] Main, A., "Textual Representation of IPv4 and IPv6
Addresses," <draft-main-ipaddr-text-rep-01.txt>, Oct 2003, Addresses", Work in Progress, October 2003.
Work in Progress.
[NAT-PT] G. Tsirtsis, P. Srisuresh, "Network Address Translation [NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address
- Protocol Translation (NAT-PT)," RFC 2766, February 2000. Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[DNSTRANS] A. Durand, J. Ihren, "DNS IPv6 transport operational [DNSTRANS] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
guidelines," <draft-ietf-dnsop-ipv6-transport-guidelines- Guidelines", BCP 91, RFC 3901, September 2004.
02.txt>, March 2004, Work in Progress.
[DNSOPV6] A. Durand, J. Ihren, P. Savola, "Operational Considerations [DNSOPV6] Durand, A., Ihren, J. and P. Savola, "Operational
and Issues with IPv6 DNS," <draft-ietf-dnsop-ipv6-dns- Considerations and Issues with IPv6 DNS", Work in
issues-07.txt>, May 2004, Work in Progress. Progress, May 2004.
[AF-APP] J. Hagino, "Implementing AF-independent application", [AF-APP] Hagino, J., "Implementing AF-independent application",
http://www.kame.net/newsletter/19980604/, 2001. http://www.kame.net/newsletter/19980604/, 2001.
[V6MAPPED] J. Hagino, "IPv4 mapped address considered harmful", [V6MAPPED] Hagino, J., "IPv4 mapped address considered harmful",
<draft-itojun-v6ops-v4mapped-harmful-02.txt>, Apr 2002, Work in Progress, April 2002.
Work in Progress.
[IP-GGF] T. Chown, J. Bound, S. Jiang, P. O'Hanlon, "Guidelines for
IP version independence in GGF specifications," Global
Grid Forum(GGF) Documentation, September 2003, Work in
Progress.
[Embed-RP] P. Savola, B. Haberman, "Embedding the Address of RP in
IPv6 Multicast Address," <draft-ietf-mboned-embeddedrp-
00.txt>, October 2003, Work in Progress.
[RFC 3306] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses," RFC 3306, August 2002.
[RFC 3678] D. Thaler, B. Fenner, B. Quinn, "Socket Interface
Extensions for Multicast Source Filters, RFC 3678, January
2004.
[MUL-GW] S. Venaas, "An IPv4 - IPv6 multicast gateway," <draft-
venaas-mboned-v4v6mcastgw-00.txt>, February 2003,
Work in Progress.
[PRT] E. M. Castro, "Programming guidelines on transition to
IPv6, LONG project, January 2003.
Authors' Addresses [IP-GGF] Chown, T., Bound, J., Jiang, S. and P. O'Hanlon,
"Guidelines for IP version independence in GGF
specifications", Global Grid Forum(GGF) Documentation,
work in Progress, September 2003.
Myung-Ki Shin [Embed-RP] Savola, P. and B. Haberman, "Embedding the Rendezvous
ETRI/NIST Point (RP) Address in an IPv6 Multicast Address", RFC
820 West Diamond Avenue 3956, November 2004.
Gaithersburg, MD 20899, USA
Tel : +1 301 975-3613
Fax : +1 301 590-0932
E-mail : mshin@nist.gov
Yong-Guen Hong [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
ETRI PEC Multicast Addresses", RFC 3306, August 2002.
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 [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
Research Laboratory, Internet Initiative Japan Inc. Extensions for Multicast Source Filters, RFC 3678,
Takebashi Yasuda Bldg., January 2004.
3-13 Kanda Nishiki-cho,
Chiyoda-ku,Tokyo 101-0054, JAPAN
Tel: +81-3-5259-6350
Fax: +81-3-5259-6351
E-mail: itojun@iijlab.net
Pekka Savola [MUL-GW] Venaas, S., "An IPv4 - IPv6 multicast gateway", Work in
CSC/FUNET Progress, February 2003.
Espoo, Finland
E-mail: psavola@funet.fi
Eva M. Castro [PRT] Castro, E. M., "Programming guidelines on transition to
Rey Juan Carlos University (URJC) IPv6 LONG project", Work in Progress, January 2003.
Departamento de Informatica, Estadistica y Telematica
C/Tulipan s/n
28933 Madrid - SPAIN
E-mail: eva@gsyc.escet.urjc.es
Appendix A. Other binary/Presentation Format Conversions Appendix A. Other Binary/Presentation Format Conversions
Section 6.2.3 described the preferred way of performing Section 6.2.3 describes the preferred way to perform
binary/presentation format conversions; these can also be done binary/presentation format conversions; these can also be done by
using inet_pton() and inet_ntop() by writing protocol-dependent using inet_pton() and inet_ntop() and by writing protocol-dependent
code. This is not recommended, but provided here for reference and code. This approach is not recommended, but it is provided here for
comparison. reference and comparison.
Note that inet_ntop()/inet_pton() lose the scope identifier (if Note that inet_ntop()/inet_pton() lose the scope identifier (if used,
used e.g. with link-local addresses) in the conversions, contrary e.g., with link-local addresses) in the conversions, contrary to the
to the getaddrinfo()/getnameinfo() functions. getaddrinfo()/getnameinfo() functions.
A.1 Binary to Presentation using inet_ntop() A.1. Binary to Presentation Using inet_ntop()
Conversions from network address structure to presentation format Conversions from network address structure to presentation format can
can be written: be written as follows:
struct sockaddr_storage ss; struct sockaddr_storage ss;
char addrStr[INET6_ADDRSTRLEN]; char addrStr[INET6_ADDRSTRLEN];
/* fill ss structure */ /* fill ss structure */
switch (ss.ss_family) { switch (ss.ss_family) {
case AF_INET: case AF_INET:
inet_ntop(ss.ss_family, inet_ntop(ss.ss_family,
skipping to change at page 29, line 13 skipping to change at page 30, line 48
&((struct sockaddr_in6 *)&ss)->sin6_addr, &((struct sockaddr_in6 *)&ss)->sin6_addr,
addrStr, addrStr,
sizeof(addrStr)); sizeof(addrStr));
break; break;
default: default:
/* handle unknown family */ /* handle unknown family */
} }
Note, the destination buffer addrStr should be long enough to Note that, the destination buffer addrStr should be long enough to
contain the presentation address format: INET_ADDRSTRLEN for IPv4 contain the presentation address format: INET_ADDRSTRLEN for IPv4 and
and INET6_ADDRSTRLEN for IPv6. Since INET6_ADDRSTRLEN is longer INET6_ADDRSTRLEN for IPv6. As INET6_ADDRSTRLEN is longer than
than INET_ADDRSTRLEN, the first one is used as the destination INET_ADDRSTRLEN, the first one is used as the destination buffer
buffer length. length.
A.2 Presentation to Binary using inet_pton() A.2. Presentation to Binary Using inet_pton()
Conversions from presentation format to network address structure Conversions from presentation format to network address structure can
can be written as follows: be written as follows:
struct sockaddr_storage ss; struct sockaddr_storage ss;
struct sockaddr_in *sin; struct sockaddr_in *sin;
struct sockaddr_in6 *sin6; struct sockaddr_in6 *sin6;
char addrStr[INET6_ADDRSTRLEN]; char addrStr[INET6_ADDRSTRLEN];
/* fill addrStr buffer and ss.ss_family */ /* fill addrStr buffer and ss.ss_family */
switch (ss.ss_family) { switch (ss.ss_family) {
case AF_INET: case AF_INET:
skipping to change at page 29, line 50 skipping to change at page 31, line 36
sin6 = (struct sockaddr_in6 *)&ss; sin6 = (struct sockaddr_in6 *)&ss;
inet_pton(ss.ss_family, inet_pton(ss.ss_family,
addrStr, addrStr,
(sockaddr *)&sin6->sin6_addr); (sockaddr *)&sin6->sin6_addr);
break; break;
default: default:
/* handle unknown family */ /* handle unknown family */
} }
Note, the address family of the presentation format must be known. Note that, the address family of the presentation format must be
known.
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
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity Acknowledgement
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 Statement
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
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/