draft-ietf-v6ops-application-transition-01.txt   draft-ietf-v6ops-application-transition-02.txt 
v6ops Working Group M-K. Shin (ed.) v6ops Working Group M-K. Shin (ed.)
INTERNET DRAFT Y-G. Hong INTERNET DRAFT Y-G. Hong
Expires: August 2004 ETRI Expires: September 2004 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
February 2004 March 2004
Application Aspects of IPv6 Transition Application Aspects of IPv6 Transition
<draft-ietf-v6ops-application-transition-01.txt> <draft-ietf-v6ops-application-transition-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and working groups. Note that other Task Force (IETF), its areas, and working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 8 skipping to change at page 2, line 8
one should also consider how to enable IPv6 support in applications one should also consider how to enable IPv6 support in applications
running on IPv6 hosts, and the best strategy to develop IP protocol running on IPv6 hosts, and the best strategy to develop IP protocol
support in applications. This document specifies scenarios and support in applications. This document specifies scenarios and
aspects of application transition. It also proposes guidelines on aspects of application transition. It also proposes guidelines on
how to develop IP version-independent applications during the how to develop IP version-independent applications during the
transition period. 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 the IP version will be used . 5 3.2 DNS does not indicate which IP version will be used ..... 5
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 ........ 6
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 .................. 7
4.3 IPv4/IPv6 applications in a dual stack node ............. 9 4.3 IPv4/IPv6 Applications in a Dual-stack Node .............10
4.4 IPv4/IPv6 applications in an IPv4-only node .............10 4.4 IPv4/IPv6 Applications in an IPv4-only Node .............11
5. Application porting considerations ........................10 5. Application Porting Considerations ........................11
5.1 Presentation format for an IP address ...................11 5.1 Presentation Format for an IP address ...................12
5.2 Transport layer API .....................................12 5.2 Transport Layer API .....................................13
5.3 Name and address resolution .............................13 5.3 Name and Address Resolution .............................14
5.4 Specific IP dependencies ............................... 13 5.4 Specific IP Dependencies ............................... 14
5.4.1 IP address selection .................................13 5.4.1 IP Address Selection .................................14
5.4.2 Application framing ..................................13 5.4.2 Application Framing ..................................15
5.4.3 Storage of IP addresses ..............................14 5.4.3 Storage of IP addresses ..............................15
5.5 Multicast applications ..................................15 5.5 Multicast Applications ..................................16
6. Developing IP version-independent applications ............16 6. Developing IP version-independent Applications ............17
6.1 IP version-independent structures .......................16 6.1 IP version-independent Structures .......................17
6.2 IP version-independent APIs .............................17 6.2 IP version-independent APIs .............................17
6.2.1 Example of overly simplistic TCP server application ..18 6.2.1 Example of Overly Simplistic TCP Server Application ..18
6.2.2 Example of overly simplistic TCP client application ..18 6.2.2 Example of Overly Simplistic TCP Client Application ..19
6.2.3 Binary/presentation format conversion ................19 6.2.3 Binary/Presentation Format Conversion ................20
6.3 Iterated jobs for finding the working address ...........20 6.3 Iterated Jobs for Finding the Working Address ...........21
6.3.1 Example of TCP server application ....................20 6.3.1 Example of TCP Server Application ....................21
6.3.2 Example of TCP client application ....................21 6.3.2 Example of TCP Client Application ....................24
7. Transition mechanism considerations .......................23 7. Transition Mechanism Considerations .......................24
8. Security considerations ...................................23 8. Security Considerations ...................................24
9. Acknowledgements .........................................23 9. Acknowledgements .........................................25
10. References ...............................................23 10. References ...............................................25
Authors' addresses ...........................................25 Authors' Addresses ...........................................27
Appendix A. Binary/presentation format conversions ...........26 Appendix A. Other Binary/Presentation Format Conversions .....27
A.1 Network address to presentation format ..................26 A.1 Binary to Presentation using inet_ntop() ................28
A.2 Presentation format to network address ..................28 A.2 Presentation to Binary using inet_pton() ................28
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 arise such as routing, addressing, DNS, scenarios, etc.
One important key to a successful IPv6 transition is the One important key to a successful IPv6 transition is the
compatibility with the large installed base of IPv4 hosts and compatibility with the large installed base of IPv4 hosts and
routers. This issue had been already been extensively studied, and routers. This issue had been already been extensively studied, and
the work is still in progress. In particular, [2893BIS] describes the work is still in progress. In particular, [2893BIS] describes
the basic transition mechanisms, dual-stack deployment and the basic transition mechanisms, dual-stack deployment and
tunneling. In addition, various kinds of transition mechanisms tunneling. In addition, various kinds of transition mechanisms
have been developed to migrate to IPv6 network. However, these have been developed for the transition to an IPv6 network.
transition mechanisms take no stance on whether applications However, these transition mechanisms take no stance on whether
support IPv6 or not. applications support IPv6 or not.
This document specifies application aspects of IPv6 transition. This document specifies application aspects of IPv6 transition.
That is, two inter-related topics are covered: That is, two 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 what are the strategies for applications
to support IPv6 and IPv4. to support IPv6 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").
Applications will need to be modified to support IPv6 (and IPv4), Applications will need to be modified to support IPv6 (and IPv4),
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 Some guidelines to develop such application are then presented in
sections 5 and 6. sections 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 classifed 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 either in the application or the operating system), as
follows: 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,
skipping to change at page 4, line 43 skipping to change at page 4, line 43
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 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
in a dual-stack node. in a dual-stack node.
Applications are ported for IPv6-only. Therefore Applications are ported for IPv6-only. Therefore
there are two similar applications, one for each there are two similar applications, one for each
protocol version (e.g., ping and ping6). protocol version (e.g., ping and ping6).
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.
skipping to change at page 5, line 14 skipping to change at page 5, line 14
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 Note that this draft does not address DCCP and SCTP considerations
at this phase. at this phase.
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 IPv6 applications may not be straightforward. These issues are and 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 in a node is likely to co-exist for a long
time. time.
skipping to change at page 5, line 37 skipping to change at page 5, line 37
IPv4 and IPv6 during another, unrelated long time period. That is, IPv4 and IPv6 during another, unrelated long time period. That is,
the operating system being dual stack does not mean having both the operating system being dual stack does not mean having both
IPv4 and IPv6 applications. Therefore, IPv6-capable application IPv4 and IPv6 applications. Therefore, IPv6-capable application
transition may be independent of protocol stacks in a node. transition may be independent of protocol stacks in a node.
It is even probable that applications capable of both IPv4 and IPv6 It is even probable that applications capable of both IPv4 and IPv6
will have to work properly in IPv4-only nodes (whether the IPv6 will have to work properly in IPv4-only nodes (whether the IPv6
protocol is completely disabled or there is no IPv6 connectivity at protocol is completely disabled or there is no IPv6 connectivity at
all). all).
3.2 DNS does not indicate which the 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 The role of the DNS name resolver in a node is to get the list of
destination addresses. DNS queries and responses are sent using destination addresses. DNS queries and responses are sent using
either IPv4 or IPv6 to carry the queries, regardless of the either IPv4 or IPv6 to carry the queries, regardless of the
protocol version of the data records [DNSTRANS]. protocol version of the data records [DNSTRANS].
The issue of DNS name resolution related to application transition, The issue of DNS name resolution related to application transition,
is that a client application can not be certain of the version of is that a client application can not be certain of the version of
the peer application by only doing a DNS name lookup. For example, the peer application by only doing a DNS name lookup. For example,
if a server application does not support IPv6 yet, but runs on a if a server application does not support IPv6 yet, but runs on a
dual-stack machine for other IPv6 services, and this is listed with dual-stack machine for other IPv6 services, and this host is listed
an AAAA record in the DNS, the client application will fail to with a AAAA record in the DNS, the client application will fail to
connect to the server application. This is caused by a mis-match connect to the server application. This is caused by a mis-match
between the DNS query result (i.e. IPv6 addresses) and a server between the DNS query result (i.e. IPv6 addresses) and a server
application version (i.e. IPv4). application version (i.e. IPv4).
It is bad practise to add an AAAA record for a node that does not It is bad practise to add an AAAA record for a node that does not
support all the services using IPv6 (rather, an AAAA record for the support all the services using IPv6 (rather, an AAAA record for the
specific service name and address should be used). However, the specific service name and address should be used). However, the
application cannot depend on "good practise", and this must be application cannot depend on "good practise", and this must be
handled. handled.
In consequence, the application should request all IP addresses In consequence, the application should request all IP addresses
without address family constraints and try all the records returned without address family constraints and try all the records returned
from the DNS, in some order, until a working address is found. In from the DNS, in some order, until a working address is found. In
particular, the application has to be able to handle all IP particular, the application has to be able to handle all IP
versions returned from the DNS. versions returned from the DNS. This issue is discussed in more
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
skipping to change at page 6, line 37 skipping to change at page 6, line 38
right application version supporting the exact IP version required right application version supporting the exact IP version required
if multiple versions of the same application are available. if multiple versions of the same application are 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 of the protocol versions.
An alternative approach is to have a "wrapper application" which An alternative approach is to have a "wrapper application" which
performs certain tasks (like figures out which protocol version performs certain tasks (like figures out which protocol version
will be used) and calls the IPv4/IPv6-only applications as will be used) and calls the IPv4/IPv6-only applications as
necessary. However, these wrapper applications will actually necessary. However, these wrapper applications will actually have
probably have to do more than just perform a DNS lookup or figure to do more than just perform a DNS lookup or figure out the literal
out the literal IP address given. Thus, they may get complex, and IP address given. Thus, they may get complex, and only work for
only work for certain kinds of, usually simple, applications. certain kinds of, usually simple, applications.
Nonetheless, there should be some reasonable logic to enable the Nonetheless, there should be some reasonable logic to enable the
users to use the applications with any supported protocol version; users to use the applications with any supported protocol version;
the users should not have to select from various versions of the users should not have to select from various versions of
applications, some supporting only IPv4, others only IPv6, and yet applications, some supporting only IPv4, others only IPv6, and yet
some both versions by themselves. some both versions by themselves.
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 and 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 are one of the ways to maintain IPv4 compatibility
in unicast communications. In this section we will analyze in unicast communications. In this section we will analyze
different application transition scenarios (as introduced in different application transition scenarios (as introduced in
section 2) and guidelines to maintain interoperability between section 2) and guidelines to maintain 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 4.1 IPv4 Applications in a Dual-stack Node
This scenario happens if the IPv6 protocol is added in a node but This scenario happens if the IPv6 protocol is added in a node but
IPv6-capable applications aren't yet available or installed. IPv6-capable applications aren't yet available or installed.
Although the node implements the dual stack, IPv4 applications can Although the node implements the dual stack, IPv4 applications can
only manage IPv4 communications. Then, IPv4 applications can only only manage IPv4 communications. Then, IPv4 applications can only
accept/establish connections from/to nodes which implement an IPv4 accept/establish connections from/to nodes which implement an IPv4
stack. stack.
In order to allow an application to communicate with other nodes In order to allow an application to communicate with other nodes
using IPv6, the first priority is to port applications to IPv6. using IPv6, the first priority is to port applications to IPv6.
In some cases (e.g. no source code is available), existing IPv4 In some cases (e.g. no source code is available), existing IPv4
applications can work if the [BIS] or [BIA] mechanism is installed applications can work if the [BIS] or [BIA] mechanism is installed
in the node. However, these mechanisms should not be used when in the node. However, these mechanisms should not be used when
application source code is available to prevent their mis-use, for application source code is available to prevent their mis-use, for
example, as an excuse not to port software. example, as an excuse not to port software.
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
becomes an issue --the IPv4 client in a [BIS]/[BIA] node trying to --the IPv4 client in a [BIS]/[BIA] node trying to connect to an
connect to an IPv4 server in a dual stack system-- arises. However, IPv4 server in a dual stack system-- arises. However, one can rely
one can rely on the [BIA]/[BIS] mechanism, which should cycle on the [BIA]/[BIS] mechanism, which should cycle through all the
through all the addresses instead of applications. addresses instead of applications.
[BIS] or [BIA] does not work with all kinds of applications. In [BIS] or [BIA] does not work with all kinds of applications. In
particular, the applications which exchange IP addresses as particular, the applications which 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. Hence, these IPv4
temporary addresses are only valid in the node scope." 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 one-to-one substitute the old IPv4 API references with the new IPv6 APIs with
API mapping. This way the application will be IPv6-only. This one-to-one mapping. This way the application will be IPv6-only.
IPv6-only source code can not work in IPv4-only nodes, so the old This IPv6-only source code can not work in IPv4-only nodes, so the
IPv4 application should be maintained in these nodes. Then, we will old IPv4 application should be maintained in these nodes. Then, we
get two similar applications working with different protocol will get two similar applications working with different protocol
versions, depending on the node they are running (e.g., telnet and versions, depending on the node they are running (e.g., telnet and
telnet6). This case is undesirable since maintaining two versions telnet6). This case is undesirable since maintaining two versions
of the same source code per application, could be a difficult task. of the same source code per application could be a difficult task.
In addition, this approach would cause problems for the users when In addition, this approach would cause problems for the users when
having to select which version of the application to use, as having to select 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 to IPv6 ones using IPv4-mapped
IPv6 addresses: the IPv6 address ::FFFF:x.y.z.w represents the IPv4 IPv6 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 | |
| | | | | | | |
| +------------------------------------------+ | | +------------------------------------------+ |
skipping to change at page 9, line 19 skipping to change at page 9, line 19
resolution API functions unless a special hint, resolution API functions unless a special hint,
AI_V4MAPPED, is given. If given, the IPv6 client will AI_V4MAPPED, is given. If given, the IPv6 client will
use the returned mapped address as if it were a regular use the returned mapped address as if it were a regular
IPv6 address, and a usual IPv6 connection. However, again IPv6 address, and a usual IPv6 connection. However, again
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 with
IPv6 servers, as the mapped addresses have been disabled. This 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 flowlabel. If communication with IPv4 is needed, either as Flow Label. If communication with IPv4 is needed, either
IPV6_V6ONLY must not be used, or dual-stack applications be used, IPV6_V6ONLY must not be used, or dual-stack applications be used,
as described in section 4.3. as described in section 4.3.
There are some implementations of dual-stack which do not allow There are some implementations of dual-stack which do not allow
IPv4-mapped IPv6 addresses to be used for interoperability between IPv4-mapped IPv6 addresses to be used for interoperability between
IPv4 and IPv6 applications. In that case, there are two ways to IPv4 and IPv6 applications. In that case, there are two ways to
handle the problem: handle the 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), or
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 amount
of problems associated with selecting the right applications.This of problems associated with selecting the right applications.This
scenario is 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 actually two distinct cases to consider when
writing one application to support both protocols: writing one 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 IPv6 through IPv4-mapped IPv6 addresses, or should the and IPv6 through IPv4-mapped IPv6 addresses, or should the
applications support both explicitly (see section 4.3), and applications support both explicitly (see section 4.3), and
2. whether the systems where the applications are used support 2. whether the systems where the applications are used support
IPv6 at all or not (see section 4.4). IPv6 at all or not (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 IPv4-mapped IPv6 addresses. The security concerns internal IPv4-mapped IPv6 addresses. The security concerns
regarding IPv4-mapped IPv6 addresses on the wire are legitimate but regarding IPv4-mapped IPv6 addresses on the wire are legitimate but
disabling it internally breaks one transition mechanism for server disabling it internally breaks one transition mechanism for server
apps which were originally written to bind and listen to a single applications which were originally written to bind() and listen()
socket using a wildcard address. This forces the software developer to a single socket using a wildcard address. This forces the
to rewrite the daemon to create 2 separate sockets, one for IPv4 software developer to rewrite the daemon to create 2 separate
only and the other for IPv6 only, and then use select(). However, sockets, one for IPv4 only and the other for IPv6 only, and then
enabling mapping of IPv4 addresses on any particular system is use select(). However, enabling mapping of IPv4 addresses on any
controlled by the OS owner and not necessarilly by a developer. particular system is controlled by the OS owner and not
This complicates the developer's work as he now has to rewrite the necessarilly by a developer. This complicates the developer's work
daemon network code to handle both environments, even for the same as he now has to rewrite the daemon network code to handle both
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; such
applications are sometimes called IP version-independent applications are sometimes called IP version-independent
applications. After that, the existing IPv4-only applications applications. After that, the existing IPv4-only applications
could be removed. Since we have only one version of each could be removed. Since we have only one version of each
application, the source code will be typically easy to maintain and application, the source code will be typically easy to maintain and
to modify, and there are no problems managing which application to to modify, and there are no problems managing which application to
select for which purpose. 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. versions of the protocol stack or the application in the node.
Dual applications allow more interoperability between heterogeneous Dual 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 dependencies on either IPv4 or IPv6, applications will be without dependencies on either IPv4 or IPv6, applications will be
able to communicate with any combination of applications and types able to communicate with any combination of applications and types
of nodes. of nodes.
Implementations typically by-default prefer IPv6 if the remote node Implementations typically by-default prefer IPv6 if the remote node
and application support it. However, if IPv6 connections fail, and application support it. However, if IPv6 connections fail,
dual applications will automatically try IPv4 ones. The resolver version-independent applications will automatically try IPv4 ones.
returns a list of valid addresses for the remote node and The resolver returns a list of valid addresses for the remote node
applications can iterate through all, first trying IPv6 ones, until and applications can iterate through all of them until connection
connection succeeds. succeeds.
Applications writers should be aware of this typical by-default Applications writers should be aware of this typical by-default
ordering, but the applications themselves typically need not be ordering, but the applications themselves typically need not be
aware of the the local protocol ordering [RFC 3484]. aware of the the local protocol ordering [RFC 3484].
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 suport IPv4 and IPv6 explicitly using 2 separate application will support IPv4 and IPv6 explicitly using 2 separate
sockets. Note that there are some differences in bind() sockets. Note that there are some differences in bind()
implementation, whether you can first bind to the IPv6 wildcard implementation, whether you can first bind to the IPv6, and then
address, and then the IPv4. It can be a pain to write applications IPv4, wildcard addresses. It can be a pain to write applications
that cope with this. If IPV6_V6ONLY is implemented, this becomes that cope with this. If IPV6_V6ONLY is implemented, this becomes
simpler. The reason the IPv4 wildcard bind fails on some systems is simpler. The reason the IPv4 wildcard bind fails on some systems is
that the IPv4 address space is embedded into IPv6 address space that the IPv4 address space is embedded into IPv6 address space
when using IPv4-mapped IPv6 addresses. when using IPv4-mapped IPv6 addresses.
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 happen over a longer timeframe,
applications that have already been ported to support both IPv4 and applications that have already been ported to support both IPv4 and
IPv6 may be run on IPv4-only nodes. This would typically be done to IPv6 may be run on IPv4-only nodes. This would typically be done to
avoid having to support two application versions for older and avoid having to support two application versions for older and
newer operating systems, or to support the case that the user wants newer operating systems, or to support the case that the user wants
to disable IPv6 for some reason. to disable IPv6 for some reason.
Depending on how application/operating system support is done, some Depending on how application/operating system support is done, some
may want to ignore this case, but usually no assumptions can be may want to ignore this case, but usually no assumptions can be
skipping to change at page 11, line 30 skipping to change at page 11, line 30
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, encountering errors like these leads
to exiting the socket loop, and AF_INET will not even be tried. to exiting the socket loop, and AF_INET will not even be tried.
The application will need to handle this case or build the loop in The application will need to handle this case or build the loop in
such a way that errors are ignored until the last address family. such a way that errors are ignored until the last address family.
So, this case is just an extension of the IPv4/IPv6 support in the So, 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 to IPv4 applications to work with IPv6 are
based on the different size and format of IPv4 and IPv6 addresses. based 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 the assumption they would use
IPv4 as their network protocol. This assumption results in many IP IPv4 as their network protocol. This assumption results in many IP
dependencies through source code. dependencies through source code.
The following list summarizes the more common IP version The following list summarizes the more common IP version
dependencies in applications: dependencies in applications:
skipping to change at page 12, line 16 skipping to change at page 12, line 16
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 In the following subsections, the problems with the aforementioned
IP version dependencies are analyzed. Although application source IP version dependencies are analyzed. 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 using both IPv4 and IPv6. work using 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 two problems, when porting the presentation format for an IP are two problems, when porting the presentation format for an IP
address: the allocated memory and the management of the address: the allocated memory and the management of the
presentation format. presentation format.
skipping to change at page 13, line 14 skipping to change at page 13, line 14
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 as part of the address, like fe80::1%eth0. In general, identifier as part of the address, like 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 it's not used in conjunction with a port number,
but requiring that the user always gives a literal IP address but requiring that the user always gives a literal IP address
enclosed in brackets is not recommended. enclosed in brackets is not recommended.
There is an another consideration on IPv6 address literals in SMTP One should note that some applications may also represent IPv6
commands [RFC 2821], i.e., [IPv6: 2001:db8::1]. address literals differently; for example, SMTP [RFC 2821] uses
[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 should be used instead. DNS 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 porting an application to IPv6, most
changes should be made in this application transport module in changes should be made in this application transport module in
order to be adapted to the new IPv6 API. order 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 an examination of the following issues related to the API: requires an examination of the following issues related to the API:
skipping to change at page 13, line 37 skipping to change at page 13, line 38
changes should be made in this application transport module in changes should be made in this application transport module in
order to be adapted to the new IPv6 API. order 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 an examination of the following issues related to the API: requires 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 of
generic address structures, which can store any address family, generic address structures, which can store any address family,
is recommended. is recommended.
Sometimes special addresses are hard-coded in the application Sometimes special addresses are hard-coded in the application
source; developers should pay attention to them in order to use source code; developers should pay attention to them in order to
the new address format. Some of these special IP addresses are: use the new address format. Some of these special IP addresses
wildcard local, loopback and broadcast. IPv6 does not have are: wildcard local, loopback and broadcast. IPv6 does not have
the broadcast addresses, so applications can use multicast the broadcast addresses, so applications can use multicast
instead. 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 functions are valid for IPv6, however, the IP address data same 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 They are used when configuring different communication models
for Input/Output (I/O) operations (blocking/nonblocking, I/O for Input/Output (I/O) operations (blocking/nonblocking, I/O
multiplexing, etc) and should be translated to the IPv6 ones. multiplexing, etc.) and should be translated to the IPv6 ones.
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 system library, the resolver, which is linked into the a system library, the resolver, which is linked into the
application when this is built. However, these functions use IP application when this is built. However, these functions use IP
address structures, which are protocol dependent, and must be address structures, which are protocol dependent, and must be
reviewed to support the new IPv6 resolution calls. reviewed to support the new IPv6 resolution calls.
There are two basic resolution functions. The first function There are two basic resolution functions. The first function
returns a list of all configured IP addresses for a hostname. These returns a list of all configured IP addresses for a hostname. These
queries can be constrained to one protocol family, for instance queries can be constrained to one protocol family, for instance
only IPv4 or only IPv6 addresses. However, the recommendation is only IPv4 or only IPv6 addresses. However, the recommendation is
that all configured IP addresses should be obtained to allow that all configured IP addresses should be obtained to allow
applications to work with every kind of node. And the second applications to work with every kind of node. And the second
function returns the hostname associated to an IP address. function returns the hostname associated to an IP address.
5.4.1 IP address selection 5.4. Specific IP Dependencies
5.4.1 IP Address Selection
IPv6 promotes the configuration of multiple IP addresses per node, IPv6 promotes the configuration of multiple IP addresses per node,
which is a difference when compared with the IPv4 model; however which is a difference when compared with the IPv4 model; however
applications only use a destination/source pair for a applications only use a destination/source pair for a
communication. Choosing the right IP source and destination communication. Choosing the right IP source and destination
addresses is a key factor that may determine the route of IP addresses is a key factor that may determine 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, [RFC 3484], but
also allowing applications to make changes in the ordering rules. also allowing 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 just try each element in the list until the communication
succeeds. succeeds.
5.4.2 Application framing In some cases, the application may need to specify its source
address. Then the destination address selection process picks the
best destination for the source address (instead of picking the
best source address for the chosen destination address). Note that
there may be an increase in complexity for IP-version independent
applications which have to specify the source address (especially
for client applications; fortunately, specifying the source address
is not typically required), if it is not yet known which protocol
will be used for communication.
5.4.2 Application Framing
The Application Level Framing (ALF) architecture controls The Application Level Framing (ALF) architecture controls
mechanisms that traditionally fall within the transport layer. mechanisms that traditionally fall within the transport layer.
Applications implementing ALF are often responsible for packetizing Applications implementing ALF are often responsible for packetizing
data into Application Data Units (ADUs). The application problem data into Application Data Units (ADUs). The application problem
when using ALF is the ADU size selection to obtain better when using ALF is the ADU size selection to obtain better
performance. performance.
Application framing is typically needed by applications using Application framing is typically needed by applications using
connectionless protocols (such as UDP). The application will have connectionless protocols (such as UDP). The application will have
to know, or be able to detect, the packet sizes which can be sent to know, or be able to detect, the packet sizes which can be sent
and received, end-to-end, on the network. and received, end-to-end, on the network.
Applications can use 1280 octets as a data length. [RFC 2460] Applications can use 1280 octets as a data length: every IPv6 link
specifies an IPv6 requirement that every link in the Internet have must have a Maximum Transmission Unit (MTU) of 1280 octets or
a Maximum Transmission Unit (MTU) of 1280 octets or greater. greater [RFC 2460]. However, in order to get better performance,
However, in order to get better performance, ADU size should be ADU size should be calculated based on the length of transmission
calculated based on the length of transmission unit of underlying unit of underlying protocols.
protocols.
FIXME: Application framing has relations e.g. with Path MTU Note that the most optimal ALF depends on dynamic factors such as
Discovery and application design which need to be analyzed better. Path MTU or whether IPv4 or IPv6 is being used (due to different
header sizes, possible IPv6-in-IPv4 tunneling overhead, etc.).
These have to be taken into consideration when implementing
application framing.
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 information of remote
peers. For instance, one of the most popular ways to register peers. For instance, one of the most popular ways to register
remote nodes in collaborative applications is based on using IP remote nodes in collaborative applications is based on using 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 IPv6 following the previous basic porting recommendations, there to IPv6 following the previous basic porting recommendations, there
are some reasons why applications should not store IP addresses: are some reasons why applications should not store IP addresses:
- IP addresses can change throughout time, for instance - IP addresses can change throughout time, for instance
after a renumbering process. after a renumbering process.
- The same node can reach a destination host using different - The same node can reach a destination host using different
IP addresses. IP addresses, possibly with a different protocol version.
When possible, applications should store names, such as FQDNs, When possible, applications should store names such as FQDNs, or
instead of storing addresses. In this case applications are only other protocol-independent identities instead of storing addresses.
bound to specific addresses at run time, or for the duration of a In this case applications are only bound to specific addresses at
cache lifetime. Other types of applications, such as massive peer run time, or for the duration of a cache lifetime. Other types of
to peer systems with their own rendez-vous and discovery applications, such as massive peer to peer systems with their own
mechanisms, may need to cache addresses for performance reasons, rendezvous and discovery mechanisms, may need to cache addresses
but cached addresses should not be treated as permanent, reliable for performance reasons, but cached addresses should not be treated
information. In highly dynamic networks any form of name as permanent, reliable information. In highly dynamic networks any
resolution may be impossible, and here again addresses must be form of name resolution may be impossible, and here again addresses
cached. must be 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 using multicast facilities some changes must be carried out to
support IPv6. First, applications must change the IPv4 multicast 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 must be changed. options must be changed.
All the IPv6 multicast addresses encode scope; the scope was only All the 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, while a
large number of application-specific multicast addresses have been large number of application-specific multicast addresses have been
skipping to change at page 16, line 23 skipping to change at page 16, line 40
addresses. For link-local multicast, it's possible to pick almost addresses. For link-local multicast, it's possible to pick almost
anything within the link-local scope. The global groups could use anything within the link-local scope. The global groups could use
unicast-prefix-based addresses [RFC 3306]. All in all, this may unicast-prefix-based addresses [RFC 3306]. All in all, this may
force the application developers to write more protocol dependent force the 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/has been 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 Source-Specific Multicast (SSM) are generally similar between or Source-Specific Multicast (SSM) are generally similar between
IPv4 and IPv6, but it is likely that PIM-SSM will become more IPv4 and IPv6, but it is possible that PIM-SSM will become more
widely deployed in IPv6 due to its simpler architecture. widely deployed in IPv6 due to its simpler architecture.
So, it might be beneficial to port the applications to use SSM So, it might be beneficial to port the applications to use SSM
semantics, requiring off-band source discovery mechanisms and the semantics, requiring off-band source discovery mechanisms and the
use of a different API [RFC 3678]. Inter-domain ASM service is use of a different API [RFC 3678]. Inter-domain ASM service is
available only through a method embedding the Rendezvous Point available only through a method embedding the Rendezvous Point
address in the multicast address [Embed-RP]. address in the multicast address [Embed-RP].
Another generic problem for multiparty conferencing applications, Another generic problem for multiparty conferencing applications,
which is similar to the issues with peer-to-peer applications, is which is similar to the issues with peer-to-peer applications, is
that all the users of the session must use the same protocol that all the users of the session must use the same protocol
version (IPv4 or IPv6), or some form of proxies or translators must version (IPv4 or IPv6), or some form of proxies or translators must
be used (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 we have seen before, dual applications working with both IPv4
and IPv6 are recommended. These applications should avoid IP and IPv6 are recommended. These applications should avoid IP
dependencies in the source code. However, if IP dependencies are dependencies in the source code. However, if IP dependencies are
required, one of the best solutions is based on building a required, one of the best solutions is based on building a
communication library which provides an IP version independent API communication library which provides an IP version independent API
to applications and hides all dependencies. to applications and hides all dependencies.
In order to develop IP version independent applications, the In order to develop IP version independent applications, the
following guidelines should be considered. following 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 of the memory structures and APIs should be IP version-
independent. In that sense, one should avoid structs in_addr, independent. In that sense, one should avoid structs in_addr,
in6_addr, sockaddr_in and sockaddr_in6. in6_addr, sockaddr_in and sockaddr_in6.
Suppose you pass a network address to some function, foo(). If you Suppose you pass a network address to some function, foo(). If you
use struct in_addr or struct in6_addr, you will end up with an use struct in_addr or struct in6_addr, you will end up with an
extra parameter to indicate address family, as below: extra parameter to indicate address family, as below:
struct in_addr in4addr; struct in_addr in4addr;
skipping to change at page 17, line 44 skipping to change at page 18, line 10
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 [RFC2133]. in [RFC2133].
These can perform hostname/address and service name/port lookups, These can perform hostname/address and service name/port lookups,
though the features can be turned off if desirable. getaddrinfo() though the features can be turned off if desirable. Getaddrinfo()
can return multiple addresses, as below: 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 returns first
::1, and then both 127.0.0.1 and 127.0.0.2 is in a random order. ::1, and then both 127.0.0.1 and 127.0.0.2 is in a random order.
Getaddrinfo() and getnameinfo() can query hostname as well as Getaddrinfo() and getnameinfo() can query hostname as well as
service name/port at once. service name/port at once.
As well, it is not preferred to hardcode AF-dependent knowledge It is not preferred to hardcode AF-dependent knowledge into the
into the program. The construct like below should be avoided: program. The construct like 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.
Following, we will see simple examples to create these sockets Following, we will see simple examples to create these sockets
using the new IPv6 resolution functions. 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,
* - an IPv6-only server, if IPv6 is enabled but IPv4-mapped IPv6 * - an IPv6-only server, if IPv6 is enabled but IPv4-mapped IPv6
* addresses are not used by default, or * addresses are not used by default, or
* - no server at all, if getaddrinfo supports IPv6, but the * - no server at all, if getaddrinfo supports IPv6, but the
* system doesn't, and socket(AF_INET6, ...) exists with an * system doesn't, and socket(AF_INET6, ...) exits with an
* error. * error.
*/ */
struct addrinfo hints, *res; struct addrinfo hints, *res;
int error, sockfd; int error, sockfd;
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 19, line 16 skipping to change at page 19, line 33
} }
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 which is running
at node name (or IP address presentation format) SERVER_NODE and at node name (or IP address presentation format) SERVER_NODE and
service name (or port number string) SERVICE: service name (or port number string) 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 IPv4 connection to the 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
skipping to change at page 20, line 11 skipping to change at page 20, line 28
} }
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 In addition, we should consider the binary and presentation address
format conversion APIs. The following functions convert network format conversion APIs. The following functions convert network
address structure in its presentation address format and vice address 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. Since these Both are from the basic socket extensions for IPv6. However, these
functions are not protocol independent, we should write code for conversion functions are protocol-dependent; instead it is better
the different address families. to use getnameinfo()/getaddrinfo() as follows (inet_pton and
inet_ntop equivalents are described in Appendix A).
A more detailed examples are described in appendix A. Conversion from network address structure to presentation format
can be written:
Note that inet_ntop()/inet_pton() lose the scope identifier (if struct sockaddr_storage ss;
used e.g. with link-local addresses) in the conversions, contrary char addrStr[INET6_ADDRSTRLEN];
to the getaddrinfo()/getnameinfo() functions. char servStr[NI_MAXSERV];
int error;
6.3 Iterated jobs for finding the working address /* fill ss structure */
error = getnameinfo((struct sockaddr *)&ss, sizeof(ss),
addrStr, sizeof(addrStr),
servStr, sizeof(servStr),
NI_NUMERICHOST);
Conversions from presentation format to network address structure
can be written as follows:
struct addrinfo hints, *res;
char addrStr[INET6_ADDRSTRLEN];
int error;
/* fill addrStr buffer */
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC;
error = getaddrinfo(addrStr, NULL, &hints, &res);
if (error != 0) {
/* handle getaddrinfo error */
}
/* res->ai_addr contains the network address structure */
/* ... */
freeaddrinfo(res);
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 succeds. 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 function, go on to try the next address. other 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 simplied by substituting special checking of
specific error numbers by always continuing on with the socket specific error numbers by always continuing on with the socket
loop. Whether this is a better idea should be considered in more loop.
detail.
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 example TCP server example should be written:
#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;
skipping to change at page 22, line 18 skipping to change at page 23, line 13
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:
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;
skipping to change at page 23, line 27 skipping to change at page 24, line 22
} }
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, A mechanism, [NAT-PT], introduces a special set of addresses,
formed of NAT-PT prefix and an IPv4 address; this refers to IPv4 formed of NAT-PT prefix and an IPv4 address; this refers to IPv4
addresses, translated by NAT-PT DNS-ALG. In some cases, one might addresses, translated by NAT-PT DNS-ALG. In some cases, one might
be tempted to handle these differently. be tempted to 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): that
would be completely unscalable, and if such distinction must be would be completely impractical, and if such distinction must be
made, it must be done elsewhere (e.g. kernel, system libraries). made, it must be done elsewhere (e.g. kernel, system libraries).
8. Security considerations 8. Security Considerations
A number of transition mechananisms define ways of constructing There are a number of security considerations with IPv6 transition
IPv6 adddresses using IPv4 addresses. There are a number of kinds but those are outside the scope of this memo.
of IPv4 addresses that require careful treatment due to know
security issues [TRANSEC]. To ensure the availability and robustness of the service even when
transitioning to IPv6, this memo described a number of ways to make
applications more resistant to failures by cycling through
addresses until a working one is found. Doing this properly is
critical to avoid unavailability and loss of service.
One particular point about application transition is how IPv4- One particular point about application transition is how IPv4-
mapped IPv6-addresses are handled. The use in the API can be seen mapped IPv6-addresses are handled. The use in the API can be seen
as both a merit (easier application transition) and as a burden as both a merit (easier application transition) and as a burden
(difficulty in ensuring whether the use was legimate) [V6MAPPED]. (difficulty in ensuring whether the use was legimate) [V6MAPPED].
This may have to be considered in more detail. This should be considered in more detail when designing
applications.
9. Acknowledgements 9. Acknowledgements
We would like to thank the members of the the v6ops working group Some of guidelines for development of IP version-independent
and the application area for helpful comments. Special thanks are applications (section 6) were first brought up by [AF-APP]. Other
due to Brian E. Carpenter, Antonio Querubin, Stig Venaas, and work to document application porting guidelines has also been in
Chirayu Patel for extensive review of this document. We acknowledge progress, for example [IP-GGF] and [PRT]. We would like to thank
Ron Pike for proofreading the document. the members of the the v6ops working group and the application area
for helpful comments. Special thanks are due to Brian E.
Carpenter, Antonio Querubin, Stig Venaas, Chirayu Patel, and Jordi
Palet for extensive review of this document. We acknowledge Ron
Pike for proofreading the document.
10. References 10. References
Normative References Normative References
[RFC 3493] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic [RFC 3493] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic
Socket Interface Extensions for IPv6," RFC 3493, February Socket Interface Extensions for IPv6," RFC 3493, February
2003. 2003.
[RFC 3542] W. Stevens, M. Thomas, E. Nordmark, T. Jinmei, "Advanced [RFC 3542] W. Stevens, M. Thomas, E. Nordmark, T. Jinmei, "Advanced
skipping to change at page 24, line 33 skipping to change at page 25, line 37
RFC 3542, May 2003. RFC 3542, May 2003.
[BIS] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts [BIS] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts
using the "Bump-In-the-Stack" Technique (BIS)," RFC 2767, using the "Bump-In-the-Stack" Technique (BIS)," RFC 2767,
February 2000. February 2000.
[BIA] S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand, [BIA] S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand,
"Dual Stack Hosts using "Bump-in-the-API" (BIA)," RFC "Dual Stack Hosts using "Bump-in-the-API" (BIA)," RFC
3338, October 2002. 3338, October 2002.
[2893BIS] E. Nordmark, "Transition Mechanisms for IPv6 Hosts and
Routers," <draft-ietf-v6ops-mech-v2-02.txt>, February 2003,
Work-in-progress.
[RFC 2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 [RFC 2460] S. Deering, 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," [RFC 3484] R. Draves, "Default Address Selection for IPv6,"
RFC 3484, February 2003. RFC 3484, February 2003.
Informative References Informative References
[2893BIS] E. Nordmark, R. E. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers," <draft-ietf-v6ops-mech-v2-
02.txt>, January 2004, Work-in-progress.
[RFC 2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal [RFC 2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal
IPv6 Addresses in URL's," RFC 2732, December 1999. IPv6 Addresses in URL's," RFC 2732, December 1999.
[RFC 2821] J. Klensin, "Simple Mail Transfer Protocol," RFC 2821, [RFC 2821] J. Klensin, "Simple Mail Transfer Protocol," RFC 2821,
April 2001. April 2001.
[TextRep] A. Main, "Textual Representation of IPv4 and IPv6 [TextRep] A. Main, "Textual Representation of IPv4 and IPv6
Addresses," <draft-main-ipaddr-text-rep-01.txt>, Oct 2003, Addresses," <draft-main-ipaddr-text-rep-01.txt>, Oct 2003,
Work in Progress. Work in Progress.
skipping to change at page 25, line 16 skipping to change at page 26, line 20
- Protocol Translation (NAT-PT)," RFC 2766, February 2000. - Protocol Translation (NAT-PT)," RFC 2766, February 2000.
[DNSTRANS] A. Durand, J. Ihren, "DNS IPv6 transport operational [DNSTRANS] A. Durand, J. Ihren, "DNS IPv6 transport operational
guidelines," <draft-ietf-dnsop-ipv6-transport-guidelines- guidelines," <draft-ietf-dnsop-ipv6-transport-guidelines-
00.txt>, June 2003, Work in Progress. 00.txt>, June 2003, Work in Progress.
[DNSOPV6] A. Durand, J. Ihren, P. Savola, "Operational Considerations [DNSOPV6] A. Durand, J. Ihren, P. Savola, "Operational Considerations
and Issues with IPv6 DNS," <draft-ietf-dnsop-ipv6-dns- and Issues with IPv6 DNS," <draft-ietf-dnsop-ipv6-dns-
issues-03.txt>, November 2003, Work in Progress. issues-03.txt>, November 2003, Work in Progress.
[AF-APP] Jun-ichiro itojun Hagino, "Implementing AF-independent [AF-APP] J. Hagino, "Implementing AF-independent application",
application", http://www.kame.net/newsletter/19980604/, http://www.kame.net/newsletter/19980604/, 2001.
2001.
[V6MAPPED] Jun-ichiro itojun Hagino, "IPv4 mapped address [V6MAPPED] J. Hagino, "IPv4 mapped address considered harmful",
considered harmful", <draft-itojun-v6ops-v4mapped- <draft-itojun-v6ops-v4mapped-harmful-00.txt>, Apr 2002,
harmful-00.txt>, Apr 2002, Work in Progress. Work in Progress.
[IP-GGF] T. Chown, J. Bound, S. Jiang, P. O'Hanlon, "Guidelines for [IP-GGF] T. Chown, J. Bound, S. Jiang, P. O'Hanlon, "Guidelines for
IP version independence in GGF specifications," Global IP version independence in GGF specifications," Global
Grid Forum(GGF) Documentation, September 2003, Work in Grid Forum(GGF) Documentation, September 2003, Work in
Progress. Progress.
[Embed-RP] P. Savola, B. Haberman, "Embedding the Address of RP in [Embed-RP] P. Savola, B. Haberman, "Embedding the Address of RP in
IPv6 Multicast Address," <draft-ietf-mboned-embeddedrp- IPv6 Multicast Address," <draft-ietf-mboned-embeddedrp-
00.txt>, October 2003, Work in Progress. 00.txt>, October 2003, Work in Progress.
skipping to change at page 25, line 44 skipping to change at page 26, line 47
Multicast Addresses," RFC 3306, August 2002. Multicast Addresses," RFC 3306, August 2002.
[RFC 3678] D. Thaler, B. Fenner, B. Quinn, "Socket Interface [RFC 3678] D. Thaler, B. Fenner, B. Quinn, "Socket Interface
Extensions for Multicast Source Filters, RFC 3678, January Extensions for Multicast Source Filters, RFC 3678, January
2004. 2004.
[MUL-GW] S. Venaas, "An IPv4 - IPv6 multicast gateway," <draft- [MUL-GW] S. Venaas, "An IPv4 - IPv6 multicast gateway," <draft-
venaas-mboned-v4v6mcastgw-00.txt>, February 2003, venaas-mboned-v4v6mcastgw-00.txt>, February 2003,
Work in Progress. Work in Progress.
[TRANSEC] R. Austein, "IPv6 transition security - problem [PRT] E. M. Castro, "Programming guidelines on transition to
statement from a workshop that never happened," IPv6, LONG project, January 2003.
a message on v6ops@ops.ietf.org list on 13 Aug 2003.
Authors' addresses Authors' Addresses
Myung-Ki Shin Myung-Ki Shin
ETRI PEC ETRI PEC
161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
Tel : +82 42 860 4847 Tel : +82 42 860 4847
Fax : +82 42 861 5404 Fax : +82 42 861 5404
E-mail : mkshin@pec.etri.re.kr E-mail : mkshin@pec.etri.re.kr
Yong-Guen Hong Yong-Guen Hong
ETRI PEC ETRI PEC
161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea 161 Gajeong-Dong, Yuseong-Gu, Daejeon 305-350, Korea
Tel : +82 42 860 6447 Tel : +82 42 860 6447
Fax : +82 42 861 5404 Fax : +82 42 861 5404
E-mail : yghong@pec.etri.re.kr E-mail : yghong@pec.etri.re.kr
Jun-ichiro itojun HAGINO Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc. Research Laboratory, Internet Initiative Japan Inc.
Takebashi Yasuda Bldg., Takebashi Yasuda Bldg.,
skipping to change at page 26, line 32 skipping to change at page 27, line 41
Espoo, Finland Espoo, Finland
E-mail: psavola@funet.fi E-mail: psavola@funet.fi
Eva M. Castro Eva M. Castro
Rey Juan Carlos University (URJC) Rey Juan Carlos University (URJC)
Departamento de Informatica, Estadistica y Telematica Departamento de Informatica, Estadistica y Telematica
C/Tulipan s/n C/Tulipan s/n
28933 Madrid - SPAIN 28933 Madrid - SPAIN
E-mail: eva@gsyc.escet.urjc.es E-mail: eva@gsyc.escet.urjc.es
Appendix A. Binary/presentation format conversions Appendix A. Other binary/Presentation Format Conversions
The following functions convert network address structure in its
presentation address format and vice versa:
inet_ntop()
inet_pton()
Both are from the basic socket extensions for IPv6. Since these Section 6.2.3 described the preferred way of performing
functions are not protocol independent, we should write code for binary/presentation format conversions; these can also be done
the different address families. using inet_pton() and inet_ntop() by writing protocol-dependent
code. This is not recommended, but provided here for reference and
comparison.
A more detailed examples are follows. Note that inet_ntop()/inet_pton() lose the scope identifier (if
used e.g. with link-local addresses) in the conversions, contrary
to the getaddrinfo()/getnameinfo() functions.
A.1 Network address to presentation format 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 be written: can be written:
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) {
skipping to change at page 27, line 38 skipping to change at page 28, line 42
default: default:
/* handle unknown family */ /* handle unknown family */
} }
Note, the destination buffer addrStr should be long enough to Note, 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 INET6_ADDRSTRLEN for IPv6. Since INET6_ADDRSTRLEN is longer and INET6_ADDRSTRLEN for IPv6. Since INET6_ADDRSTRLEN is longer
than INET_ADDRSTRLEN, the first one is used as the destination than INET_ADDRSTRLEN, the first one is used as the destination
buffer length. buffer length.
However, this conversion is protocol dependent. We can write the A.2 Presentation to Binary using inet_pton()
same conversion using getnameinfo() in a protocol independent way.
struct sockaddr_storage ss;
char addrStr[INET6_ADDRSTRLEN];
char servStr[NI_MAXSERV];
int error;
/* fill ss structure */
error = getnameinfo((struct sockaddr *)&ss, sizeof(ss),
addrStr, sizeof(addrStr),
servStr, sizeof(servStr),
NI_NUMERICHOST);
A.2 presentation format to network address
Conversions from presentation format to network address structure Conversions from presentation format to network address structure
can be written as follows: can 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 */
skipping to change at page 28, line 37 skipping to change at page 29, line 23
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, the address family of the presentation format must be known.
This conversion may be also written in a protocol independent way
using getaddrinfo().
struct addrinfo hints, *res;
char addrStr[INET6_ADDRSTRLEN];
int error;
/* fill addrStr buffer */
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC;
error = getaddrinfo(addrStr, NULL, &hints, &res);
if (error != 0) {
/* handle getaddrinfo error */
}
/* res->ai_addr contains the network address structure */
/* ... */
freeaddrinfo(res);
Intellectual Property Statement Intellectual Property Statement
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 or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 

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