GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc4038

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:
  1. 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.
  1. 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.
  1. 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.
  1. 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:
  1. IP addresses can change throughout time; for instance, after a

renumbering process.

  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4038.txt · Last modified: 2005/03/04 23:59 (external edit)