doc: Add RFC documents

1 files changed, 1851 insertions, 0 deletions

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