INTERNET DRAFT Myung-Ki Shin Expires: May 2002 Sookyoung Jeny Lee Joo-Chul Lee Yong-Jin Kim ETRI November 2001 Application Aspects of IPv6 Transition Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at anytime. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The document specifies application aspects of IPv6 transition. As we deploy IPv6 networks, we should consider IPv6 applications transition in a host, as well as network transition. This document clarifies the requirements we have in transition period between IPv4 applications and IPv6 applications, and also provides application programmers and/or users with guidelines to use applications without confusion, when various ngtrans mechanisms are applied. This document does not try to define any new protocol. The proposals contained in this document are based on the work of the Ngtrans working group. Table of Contents: 1. Introduction 2. Overview of IPv6 application transition Shin, Lee, Lee, Kim Expires May 2002 [Page 1] INTERNET-DRAFT Application Aspects of IPv6 Transition November 2001 3. Requirements of IPv6 application transition 4. Description of the guidelines 5. Summary 6. Security Considerations 7. Acknowledgments 8. References 1. Introduction As IPv6 is introduced in the IPv4 based Internet, Several general issues to start IPv6 networking in a predominant IPv4 world are being discussed, such as IPv6 routing, IPv6 addressing, DNS issues, etc. One important key to a successful IPv6 transition is the compatibility with the large installed base of IPv4 hosts and routers. This issue had been already studied in [TRANS-MECH] and [Routing]. In addition, various kinds of Ngtrans mechanisms have been developed to migrate to IPv6 network. ([NAT-PT],[SIIT],[6to4] [TRT],[DSTM], etc.) However, even if these mechanisms are fully deployed, we still have problems occured in transition period between IPv4 applications and IPv6 applications. This document specifies application aspects of IPv6 transition. As we deploy IPv6 networks, we should consider IPv6 applications transition in a host, as well as network transition. For short-term solutions [BIS] and [BIA] have been proposed, but these mechanisms SHOULD be used when an application-specific source code is not available. Ultimately, application programmers will modify application programs to support both IPv4 and IPv6. During the periods, users will have various versions of an application (IPv4 native, IPv6 native or both IPv4 and IPv6 support) in a host where dual stack and Ngtrans mechanisms are introduced. This document clarifies the requirements we have in transition period between IPv4 applications and IPv6 applications, and also provides application programmers and/or users with guidelines to modify or use applications without confusion, when various ngtrans mechanisms are applied. The document does not try to define any new protocol. The proposals contained in this document are based on the work of the Ngtrans working group. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Shin, Lee, Lee, Kim Expires May 2002 [Page 2] INTERNET-DRAFT Application Aspects of IPv6 Transition November 2001 2. Overview of IPv6 application transition When the IPv6 protocol is introduced in a host (IPv4/IPv6 dual stack or IPv6 native stack), the transition of an application can be summarized as follows : Figure 1 shows a roadmap of IPv6 application transition. +-------------------+ | appv4 | (appv4 - an IPv4 application) +-------------------+ | TCP / UDP | +-------------------+ | IPv4 | IPv6 | +-------------------+ step 1. An IPv4 application over dual stack +-------------------+ | appv4 | appv6 | (appv6 - an IPv6 native application) +-------------------+ | TCP / UDP | +-------------------+ | IPv4 | IPv6 | +-------------------+ step 2. An IPv4 application and an IPv6 native application over dual stack +-------------------+ | appv4/v6 | (appv4/v6 - an application supporting +-------------------+ both IPv4 and IPv6) | TCP / UDP | +-------------------+ | IPv4 | IPv6 | +-------------------+ step 3. An application supporting both IPv4 and IPv6 over dual stack +-------------------+ | appv6 | +-------------------+ | TCP / UDP | +-------------------+ | IPv6 | +-------------------+ step 4. An IPv6 native application over IPv6 native stack Figure 1. Overview of IPv6 Application Transition Shin, Lee, Lee, Kim Expires May 2002 [Page 3] INTERNET-DRAFT Application Aspects of IPv6 Transition November 2001 Step 1 : An IPv4 application over dual stack. IPv6 protocol is introduced in a host, but an application is not ported yet. Step 2 : An IPv4 application and an IPv6 native application over dual stack. The application is ported for IPv6 native. Therefore, there are two same applications with different protocol versions (e.g., ping and ping6). Step 3 : An application supporting both IPv4 and IPv6 over dual stack. The application is ported for both IPv4 and IPv6 support. Therefore, the existing IPv4 application is removed. Step 4 : An IPv6 native application over IPv6 native stack. IPv4 protocol is removed in a host. 3. Requirements of IPv6 application transition When we start to introduce IPv6 applications, we should consider several requirements we have in transition period between IPv4 applications and IPv6 applications. 3.1 Host protocol stack Considering scenarios above, IPv4 protoccol and IPv6 protocol stack in a host will co-exist for an extended period. During this period, an IPv6 application will not be introduced with IPv6 protocol in a host at the same time. Also, an IPv6 application will be introduced in a host, regardless of the same IPv4 application existence. That is, dual protocol stack does not mean having both IPv4 and IPv6 applications as well as both IPv4 and IPv6 global addresses. In addition, dual protocol stack does not mean supporting both IPv4 and IPv6 routing. Therefore, application programmers and/or users SHOULD know their application-specific requirements according to their host protocol stack. 3.2 Ngtrans mechanisms Recently, many Ngtrans mechanisms have been introduced in a host. When various ngtrans mechanisms are applied, application programmers and/or users SHOULD know which mechanisms are the best in their hosts. As well, they SHOULD know which effects occur to applications, when the mechanisms are installed in their hosts. For examples, if an existing application which does not support IPv6 wants to connet to other IPv6 applications without any code modifications, [BIA] can be a good solution. Also, under [NAT-PT] mechanism, when IPv6 hosts try to connect to IPv4 hosts in other Shin, Lee, Lee, Kim Expires May 2002 [Page 4] INTERNET-DRAFT Application Aspects of IPv6 Transition November 2001 networks, IPv6 native applications are suitable for application requirements. however, in [DSTM] domain, applications supporting both IPv4 and IPv6 will be much better. 3.3 DNS name resolving The role of the DNS name resolver in a host is to get the list of destination addresses. Recently, the DNS query and response traffic are sent by using IPv4, even though IPv6 addresses are being resolved, or by using IPv6 native. This issue have been already discussed in [DNS]. The issue of DNS name resolving in a host is related to the default address selection algorithm [DEFAULT]. In order to implement name resolving in a program code, the best way is to use getaddrinfo() API [SOCK-EXT]. This requirement on socket API extensions will be discussed in section 3.4. Implementations of getaddrinfo() SHOULD use the destination address selection algorithm specified in [DEFAULT] to sort the list of IPv6 and IPv4 addresses that they return. Besides, if an existing IPv4 appilcation is used in a host where [BIA] is installed an extended name resolver supporting [DEFAULT] in [BIA] SHOULD be required. 3.4 Socket API extensions During the IPv6 transition periods, IPv6 application programmers have had various kinds of socket APIs for IPv6 stack such as gethostbyname2(), getipnodebyname(), and getaddrinfo(), each of whose has different features [SOCK-EXT]. Therefore, when application programmers try to implement an application, they will use a proper API considering the kind of Ngtrans mechanisms as well as the version of the operating system on which the applicaion will run. Ultimately, a well-behaved application should be able to communicate with a peer application in another host even though they don't know which type of application is supported in the host. For this, the application programmers SHOULD do iterated jobs for finding the working address used by the other application out of addresses returned by the API, getaddrinfo() which supports the IPv4 and IPv6 DNS query results simultaneously. 4. Description of the guidelines 4.1 An IPv4 application over dual stack The IPv6 protocol is already introduced in a host, but an application for it is not ported yet. It means an application is not yet available on IPv6 or the application for which source code is not available or lost. Shin, Lee, Lee, Kim Expires May 2002 [Page 5] INTERNET-DRAFT Application Aspects of IPv6 Transition November 2001 In order to allow a host to communicate with other IPv6 hosts using existing IPv4 applications, [BIA] SHOULD be installed in the host. The main difference between [BIS] and [BIA] is that while BIS is for systems with no IPv6 stack, BIA is for systems with an IPv6 stack. However, [BIA] SHOULD be used only when an application source code is not available to prevent the mis-use of [BIA], for example, an excuse not to port software. Considering applicability of [BIA], it's good for early adopters who do not have all applications handy, but not for mainstream production usage. In addition, [BIA] SHOULD not affect possible IPv4 connection. For example, if a server application you are using supports does not support IPv6 yet, but runs on a machine that support other IPv6 services and this is listed with a AAAA record in the DNS, a client IPv4 application using [BIA] will fail to connect to the server application, because there is a mis-match between DNS query result (i.e., IPv6 addresses) and a server application version(i.e., IPv4). A solution is to try all the addresses listed in the DNS and just not fail after the first attempt. [BIA] SHOULD support this solution by extending the extended name resolver in [BIA]. client +---------------+ | appv4 | server +---------------+ +---------------+ | BIA | | appv4 | +---------------+ +---------------+ | TCP / UDP | | TCP / UDP | +---------------+ +---------------+ | IPv4 | IPv6 | | IPv4 | IPv6 | +---------------+ +---------------+ | | 1. IPv6 - fail | | | +--------------------------------|-->+ +---------------------------------------->+ 2. IPv4 - success Figure 2. [BIA] - name resolver extensions In addition, if an IPv4 application wants to connect other IPv4 applications in other IPv4 networks and there is no IPv4 routing in their network, [DSTM] can be a good solution. 4.2 Mixed IPv4 application and IPv6 application As an application is ported for IPv6 native, there can be two same applications with different protocol versions (e.g., ping and ping6). Shin, Lee, Lee, Kim Expires May 2002 [Page 6] INTERNET-DRAFT Application Aspects of IPv6 Transition November 2001 In fact, this transition step is undesirable (the best solution is to go to step 3), but native IPv6 applications will exist for several reasons (easy to modify, early version of IPv6 application, etc.). During this period, the requirements discussed in section 3 SHOULD be considered more carefully. In this step, there are two same applications with different name (attached with '6'). Simple application selection method is as follows : Default application selection is one for IPv6, only if IPv6 routing is provided. If it fails, then the same IPv4 application is tried. In this step, various Ngtrnas mechanisms will be deployed. [NAT-PT] can be the best solution considering applications' applicability only for communication between IPv6 hosts and IPv4 hosts . Under the [NAT-PT] scenarios, a pair of native IPv6 and native IPv4 application will be enough in the point of applications. Even IPv6 native applications, the DNS query and response traffic can be sent by using IPv4. If an [DEFAULT] implementation is not configurable, or if an [DEFAULT] implementation has not been configured, then the default policy table specified in [DEFAULT] SHOULD be used. Native IPv6 application programs can be converted easily from the existing same IPv4 applications by means of one to one API mapping. For examples, native IPv6 applications will be implemented using gethostbyname2(), getipnodebyname(), or getaddrinfo(), instead of gethostbyname() for IPv4. Theoretically, there will be no change of the number of code lines. However, a lot of Ngtrans mechanisms can not be used under native IPv6 applications, except for [NAT- PT], etc. As well, they can not satisfy the requirement 3.3 and 3.4 fully. 4.3 An application supporting both IPv4 and IPv6 As an application is ported for both IPv4 and IPv6 support, the existing IPv4 application is removed. This transition step is advisable. [DSTM]-like mechanism will be good solution in this step. At this time, the [DEFAUT] algorithm is very important for an application supporting both IPv4 and IPv6 to choose a proper address. During IPv6 transition periods, applications supporting both IPv4 and IPv6 should be able to communicate with an application in a host irrespective of the versions of the protocol stack or the application in the host with the host name. The applications assume that a host, which the application want to communicate with, can have the various combinations of the protocol stacks and the applicaions. Under this assumption, the applicaions supporting both IPv4 and IPv6 SHOULD be ported to do the iterated job, which tries Shin, Lee, Lee, Kim Expires May 2002 [Page 7] INTERNET-DRAFT Application Aspects of IPv6 Transition November 2001 to create the connection with the host iteratively through all results from DNS queries. The following functions are the API list which should be rewritten to support both IPv4 and IPv6. The functions that the application uses to pass addresses into the system are: bind() connect() sendmsg() sendto() The functions that return an address from the system to an application are: accept() recvfrom() recvmsg() getpeername() getsockname() The functions that are related to socket options are : getsocketopt() setsocketopt() Most of the socket functions require a pointer to a socket address structure as an argument. Each IPv4 argument is mapped into corresponding an IPv6 argument[SOCK-EXT]. IPv4 new IPv6 ------------------------------------------------ AF_INET AF_INET6 sockaddr_in sockaddr_in6 gethostbyname() getaddrinfo() gethostbyaddr() getnameinfo() inet_ntoa()/inet_addr() inet_pton()/inet_ntop() INADDR_ANY in6addr_any As well, raw sockets for IPv4 and IPv6 should be intercepted. The following is an example code [Y2K-SOFT] for applications supporting both IPv4 and IPv6. int connect( char *host, char *service ) { struct addrinfo *res, *aip, hints; int error, s = -1; Shin, Lee, Lee, Kim Expires May 2002 [Page 8] INTERNET-DRAFT Application Aspects of IPv6 Transition November 2001 bzero( &hints, sizeof(hints) ); hints.ai_flags = AI_ADDRCONFIG; hints.ai_socktype = SOCK_STREAM; error = getaddrinfo( host, service, &hints, &res ); if( error != 0 ) { /* Handle errors */} /* The iterated job through DNS results */ for( api = res; aip != NULL; aip = aip->ai_next ) { s = socket( api->ai_family, aip->ai_socketype, aip->ai_protocol ); if( s == -1 ) continue; if( connect( s, aip->ai_addr, aip->ai_addrlen ) == -1 ) { (void)close(s);s = -1; continue; } } freeaddrinfo( res ); return( s ); } Application programmers, who want to support both IPv4 and IPv6 simultaneouly, SHOULD implement the iterated function like the for statement above using the DNS results, res, obtained from getaddrinfo(). 5. Summary Table 1. Guideline table bewteen the steps and the requirements. (In this draft version -00, we consider [DSTM], [NAT-PT] and [BIA] as Ngtans mechanisms) --------+-------------------+------------------------------- | Req 3.1 | Req 3.2 --------+-------------------+------------------------------- Step 1 | appv4 - | comm. with appv6 -> [BIA] | v4/v6 stack | comm. with appv4 & | | no v4 routing -> [DSTM] --------+-------------------+------------------------------- Step 2 | appv6 - | comm. with appv4 & | v4/v6 stack | no v4 routing -> [NAT-PT] --------+-------------------+------------------------------- Step 3 | appv4/v6 - | comm. with appv4 & | v4/v6 stack | no v4 routing -> [NAT-PT] or | | [DSTM] --------+-------------------+------------------------------- Shin, Lee, Lee, Kim Expires May 2002 [Page 9] INTERNET-DRAFT Application Aspects of IPv6 Transition November 2001 (cont.) --------+--------------------------+----------------------------- | Req 3.3 | Req 3.4 --------+--------------------------+----------------------------- Step 1 | v4 transport/v6 transport| not applicable | Extended name resolver | eg, gethostbyname() | supporting [DEFAULT] | --------+--------------------------+----------------------------- Step 2 | v4 transport/v6 transport| APIs conversions, 1:1 | [DEFAULT] - default | eg, gethostbyname2() or | policy table | getipnodebyname() --------+--------------------------+----------------------------- Step 3 | v4 transport/v6 transport| APIs conversions + semantics | [DEFAULT] -implementation| eg, getaddrinfo() + | | to do the iterated job | | with all responses --------+--------------------------+----------------------------- 6. Security Considerations See the each security consideration section listed in section 8 - References. 7. Acknowledgments Authors would like to acknowledge the idea sharing contributions by Erik Nordmark (nordmark@sun.com). 8. References [TANS-MECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [Routing] R. Callon, D. Haskin, "Routing Aspects Of IPv6 Transition", RFC 2185, September 1997. [NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000. [6to4] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001 [TRT] J. Hagino, K. Yamamoto, "An IPv6-to-IPv4 transport relay translator, RFC 3142, June 2001 Shin, Lee, Lee, Kim Expires May 2002 [Page 10] INTERNET-DRAFT Application Aspects of IPv6 Transition November 2001 [DSTM] Jim Bound et al., Dual Stack Transition Mechanism (DSTM), , February 2001, Work in Progress. [BIS] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000. [BIA] Seungyun Lee et al, "Dual Stack Hosts using "Bump-in-the -API" (BIA)" , November 2001, Work in Progress. [DEFAULT] Richard Draves, "Default Address Selection for IPv6", , September, 2001, Work in Progress. [SOCK-EXT] R. Gilligan, S. Thomson, J. Bound and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC2553, March 1999. [DNS] A. Durand, "NGtrans IPv6 DNS operational requirements and roadmap", , September, 2001, Work in Progress. [Y2K-SOFT] Erik Nordmark, "IPv6: Another Y2K for Software", IPv4 to IPv6 Migration, IPv6 Summit, September 2001. Authors Addresses Myung-Ki Shin ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-600, Korea Tel : +82 42 860 4847 Fax : +82 42 861 5404 E-mail : mkshin@pec.etri.re.kr Soo-Kyung Jeny Lee ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-600, Korea Tel : +82 42 860 1725 Fax : +82 42 861 5404 Email : jenylee@pec.etri.re.kr Joo-Chul Lee 161 Kajong-Dong, Yusong-Gu, Taejon 305-600, Korea Tel : +82 42 860 1021 Fax : +82 42 861 5404 Email : rune@pec.etri.re.kr Shin, Lee, Lee, Kim Expires May 2002 [Page 11] INTERNET-DRAFT Application Aspects of IPv6 Transition November 2001 Yong-Jin Kim ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-600, Korea Tel : +82 42 860 6564 Fax : +82 42 861 5404 Email : yjkim@pec.etri.re.kr Shin, Lee, Lee, Kim Expires May 2002 [Page 12]