summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4038.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4038.txt')
-rw-r--r--doc/rfc/rfc4038.txt1851
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]
+