INTERNET DRAFT Myung-Ki Shin Expires: August 2002 Yong-Guen Hong Sookyoung Jeny Lee Joo-Chul Lee Yong-Jin Kim ETRI February 2002 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 IPv6 is deployed, there are some problems that the application developers and the administrators face. This draft clarifies the problems occurred in transition periods between IPv4 applications and IPv6 applications. It also propose guidelines to implement and choose the suitable application under the various transition environments. 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 1.1 Terminology .............................................. 2 2. Overview of IPv6 application transition ................... 3 Shin et al. Expires August 2002 [Page 1] INTERNET-DRAFT Application Aspects of IPv6 Transition February 2002 3. Problems with IPv6 application transition ................. 4 3.1 Dual stack vs. application versions ...................... 4 3.2 DNS name resolution ..................................... 4 3.3 Application selection ................................... 4 4. Description of the guidelines ............................. 5 4.1 An IPv4 application over dual stack ...................... 5 4.2 Mixed an IPv4 application and an IPv6 application ........ 6 4.3 An application supporting both IPv4 and IPv6 ............. 6 5. Ngtrans mechanism considerations .......................... 6 6. Security considerations ................................... 7 7. Acknowledgments ........................................... 7 8. References ................................................ 7 Appendix ..................................................... 8 Authors' Addresses .......................................... 12 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], [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 node, 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 developers will modify application programs to support both IPv4 and IPv6. During the periods, administrators may have various versions of an application (IPv4 native, IPv6 native or both IPv4 and IPv6 support) in a node. This draft clarifies the problems occurred in transition periods between IPv4 applications and IPv6 applications. It also propose guidelines to implement and choose the suitable application under the various transition environments. 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. Shin et al. Expires August 2002 [Page 2] INTERNET-DRAFT Application Aspects of IPv6 Transition February 2002 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. 2. Overview of IPv6 application transition When the IPv6 protocol is introduced in a node, the transition of an application can be classifed as follows : Figure 1 shows cases of IPv6 application transition. +-------------------+ | appv4 | (appv4 - an IPv4 application) +-------------------+ | TCP / UDP | +-------------------+ | IPv4 | IPv6 | +-------------------+ Case 1. An IPv4 application over dual stack +-------------------+ | appv4 | appv6 | (appv6 - an IPv6 native application) +-------------------+ | TCP / UDP | +-------------------+ | IPv4 | IPv6 | +-------------------+ Case 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 | +-------------------+ Case 3. An application supporting both IPv4 and IPv6 over dual stack Figure 1. Overview of IPv6 Application Transition Case 1 : An IPv4 application over dual stack. IPv6 protocol is introduced in a node, but an IPv6 application is not ported yet. Case 2 : An IPv4 application and an IPv6 native application over dual stack. An application is ported for IPv6 native. Therefore, Shin et al. Expires August 2002 [Page 3] INTERNET-DRAFT Application Aspects of IPv6 Transition February 2002 there are two same applications with different protocol versions (e.g., ping and ping6). Case 3 : An application supporting both IPv4 and IPv6 over dual stack. An application is ported for both IPv4 and IPv6 support. Therefore, the existing IPv4 application can be removed. 3. Problems with IPv6 application transition As IPv6 is deployed, there are some problems that the application developers and the administrators face. 3.1 Dual stack vs. application versions Considering the cases above, IPv4 protocol and IPv6 protocol stack in a node will co-exist for a long time. During this period, an IPv6 application may not be introduced with IPv6 protocol in a node at the same time. That is, dual stack does not mean having both IPv4 and IPv6 applications. Therefore, an application introduction may be independent on protocol stack in a node. 3.2 DNS name resolution The role of the DNS name resolver in a node 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 related to application transition is that a client application can not know the version of peer application only by DNS name resolution. For example, if a server application does not support IPv6 yet, but runs on a dual stack machine for other IPv6 services and this is listed with a AAAA record in the DNS server, a client application will fail to connect to the server application, because there is a mis-match between the DNS query result (i.e., IPv6 addresses) and a server application version(i.e., IPv4). 3.3 Application selection During the application transition periods, system administrators may have various versions of an same application (an IPv4 application, an IPv6 native application, and a both IPv4 and IPv6 support application). Therefore, the users are confused by their various application versions. because they don't know the version of peer application by DNS query results. If there is a both IPv4 and IPv6 support applications only on the system, there will be no problem on application selection. However, until all of Shin et al. Expires August 2002 [Page 4] INTERNET-DRAFT Application Aspects of IPv6 Transition February 2002 applications are ported like that, or as several versions of same applications exist for some reasons (it is easy to modify codes, there are still early versions of IPv6 applications, a source code is lost, etc), it is desirable to have simple rule for selecting applications so that the administrators can reason about and predict the behavior of their systems. 4. Description of the guidelines 4.1 An IPv4 application over dual stack The IPv6 protocol is already introduced in a node, 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. In order to allow a node to communicate with other IPv6 nodes 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 the 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 other IPv4 connections. A client application running [BIA] may has the issue mentioned in section 3.1 and 3.2. That is, a client node running BIA trying to contact a dual stack node on a port number that is only associated to an IPv4 application will fail. In order to solver the problem, there are 2 approaches. It may very well be application dependent. 1 - the client node should cycle through all the addresses and end up trying the IPv4 one. getaddrinfo() returns a list of addresses (tokens) to the application that cycles through the list. 2 - BIA SHOULD do the work. 4.2 Mixed an IPv4 application and an IPv6 application As an application is ported for IPv6 native, there can be two same applications with different protocol versions (e.g., ping and Shin et al. Expires August 2002 [Page 5] INTERNET-DRAFT Application Aspects of IPv6 Transition February 2002 ping6). In fact, this transition case is undesirable (the best solution is to go to case 3), but native IPv6 applications will exist for several reasons (easy to modify, early version of an IPv6 application, etc.). In the case, there are two same applications with different name (attached with '6'). Simple application selection rule is as follows : ruel 1 - default application selection is the application for IPv6, only if IPv6 routing is provided. rule 2 - if it fails, then the same IPv4 application is tried. 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 line. 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 case is advisable. During IPv6 transition periods, applications supporting both IPv4 and IPv6 should be able to communicate with an application in a node irrespective of the versions of the protocol stack or the application in the node with the node name. The applications assume that a node, 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 to create the connection with the host iteratively through all results from DNS queries. Ultimately, a well-behaved application SHOULD be able to communicate with a peer application in another node even though they don't know which type of application is supported in the node. For this, the application developers 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 (see Appendix). 5. Ngtrans mechanism considerations When various ngtrans mechanisms are applied, application developers Shin et al. Expires August 2002 [Page 6] INTERNET-DRAFT Application Aspects of IPv6 Transition February 2002 and administrators SHOULD know which mechanisms are the best in their nodes or whether there are operational issues on them. As well, they SHOULD know which effects occur to applications such as additional configurations. Basically, all of Ngtrans mechanisms SHOULD give transparency to applications on using them. Under [NAT-PT] mechanism, a pair of native IPv6 and native IPv4 application will be enough in the point of applications but, the IPv6 application SHOULD distinguish addresses (NAT-PT prefix+IPv4 address) translated by NAT-PT DNS ALG with normal IPv6 addresses [DNS-ALG]. In [DSTM] domains, an application SHOULD support both IPv4 and IPv6, because DSTM is not a mechanism for IPv6 only nodes. 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 [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 Shin et al. Expires August 2002 [Page 7] INTERNET-DRAFT Application Aspects of IPv6 Transition February 2002 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)" , February 2002, 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. [DNS-ALG] A. Durand, "Issues with NAT-PT DNS ALG in RFC2766", , February 2002, Work in Progress. [PORT-NET] Sun Microsystem, Inc. "Porting Networking Application to the IPv6 APIs, Solaris Version 8", 2001. [AF-APP] Jun-ichiro itojun Itoh, "Implementing AF-independent application", http://www.kame.net/newsletter/19980604/, 2001. Appendix Implementing an application supporting both IPv4 and IPv6 ([Y2K- SOFT],[PORT-NET] and [AF-APP]). Rule 1 - Modifying codes to support both IPv4 and IPv6. so called, AF-independent code. 1. Avoid IPv4 native or IPv6 native structures and APIs. o IPv4 native and IPv6 native structures IPv4 IPv6 ----------------------------------------- AF_INET/PF_INET AF_INET6/PF_INET6 AF_INET AF_INET6 struct sockaddr_in struct sockaddr_in6 Shin et al. Expires August 2002 [Page 8] INTERNET-DRAFT Application Aspects of IPv6 Transition February 2002 struct in_addr struct in6_addr o IPv4 native and IPv6 native APIs IPv4 IPv6 --------------------------------------- gethostbyname() getipnodebyname() gethostbyaddr() getipnodebyaddr() inet_addr() inet_pton() inet_ntoa() inet_ntop() 2. Instead, use structures and APIs supporting both IPv4 and IPv6. o struct sockaddr_storage struc sockaddr_storage { u_char ss_len; u_char ss_family; u_char padding[128-2]; } o getaddrinfo() and getnameinfo() Rule 2 - Trying all addresses for finding working address. 1. Compare operation sequences. 2. Do iterated jobs ('for' or 'while' statement) for finding the working address used by the other application out of addresses returned by the getaddrinfo(). Example 1 (IPv4 native client code) and example 2 (IPv6 naitive client code) SHOULD be modified to example 3. As well, example 4 IPv4 native server code) and example 5 (IPv6 naitive server code) SHOULD be modified to example 6. o example 1 (IPv4 native client code) int myconnect(char *hostname, int port) { sock = socket(AF_INET, SOCK_STREAM, 0); if (sock == -1) { /* Handle errors */ } hp = gethostbyname(hostname); if (hp == NULL || hp->h_addrtype != AF_INET || hp->h_length != 4) { /* Handle errors */ } sin.sin_family = AF_INET; sin.sin_port = htons(port); Shin et al. Expires August 2002 [Page 9] INTERNET-DRAFT Application Aspects of IPv6 Transition February 2002 (void) memcpy((void *)&sin.sin_addr, (void *)hp->h_addr, hp->h_length); sock = socket(AF_INET, SOCK_STREAM, 0); if (sock == -1) { /* Handle errors */ } if (connect(sock, (struct sockaddr *)&sin, sizeof (sin)) == -1) { /* Handle errors */ } return (sock); } o example 2 (IPv6 naitive client code) int myconnect2(char *hostname, int port) { sock = socket(AF_INET6, SOCK_STREAM, 0); if (sock == -1) { /* Handle errors */ } hp = getipnodebyname(hostname, AF_INET6, AI_DEFAULT, &errnum); if (hp == NULL) { /* Handle errors */ } bzero(&sin, sizeof (sin)); sin.sin6_family = hp->h_addrtype; sin.sin6_port = htons(port); (void) memcpy((void *)&sin.sin6_addr, (void *)hp->h_addr, hp->h_length); freehostent(hp); if (connect(sock, (struct sockaddr *)&sin, sizeof (sin)) == -1) { /* Handle errors */ } return (sock); } o example 3 (client code supporting both IPv4 and IPv6) int myconnect3(char *hostname, char *servicename) { /* Get host address. Any type of address will do. */ bzero(&hints, sizeof (hints)); hints.ai_socktype = SOCK_STREAM; error = getaddrinfo(hostname, servicename, &hints, &res); if (error != 0) { /* Handle errors */ } /* Try all returned addresses until one works */ for (aip = res; aip != NULL; aip = aip->ai_next) { sock = socket(aip->ai_family, aip->ai_socktype, aip->ai_protocol); if (sock == -1) { /* Handle errors */ } if (connect(sock, aip->ai_addr, aip->ai_addrlen) == -1) Shin et al. Expires August 2002 [Page 10] INTERNET-DRAFT Application Aspects of IPv6 Transition February 2002 { /* Handle errors */; continue; } break; } return (sock); } o example 4 (IPv4 native server code) int myserver(int port) { laddr.sin_family = AF_INET; laddr.sin_port = htons(port); laddr.sin_addr.s_addr = INADDR_ANY; sock = socket(AF_INET, SOCK_STREAM, 0); if (sock == -1) { /* Handle errors */ } sock_opt = 1; if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (void *)&sock_opt, sizeof (sock_opt)) == -1) { /* Handle errors */ } if (bind(sock, (struct sockaddr *)&laddr, sizeof (laddr)) == -1) { /* Handle errors */ } if (listen(sock, BACKLOG) == -1) { /* Handle errors */ } for (;;) { faddrlen = sizeof (faddr); new_sock = accept(sock, (struct sockaddr *)&faddr, &faddrlen); if (new_sock == -1) { if (errno != EINTR && errno != ECONNABORTED) { /* Handle errors */ } continue; } inet_ntoa(faddr.sin_addr), ntohs(faddr.sin_port)); do_work(new_sock);/* do some work */ } } o example 5 (IPv6 naitive server code) int myserver2(int port) { bzero(&laddr, sizeof (laddr)); laddr.sin6_family = AF_INET6; laddr.sin6_port = htons(port); laddr.sin6_addr = in6addr_any; /* structure assignment */ sock = socket(AF_INET6, SOCK_STREAM, 0); if (sock == -1) Shin et al. Expires August 2002 [Page 11] INTERNET-DRAFT Application Aspects of IPv6 Transition February 2002 { /* Handle errors */ } sock_opt = 1; if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (void *)&sock_opt, sizeof (sock_opt)) == -1) { /* Handle errors */ } if (bind(sock, (struct sockaddr *)&laddr, sizeof (laddr)) == -1) { /* Handle errors */ } if (listen(sock, BACKLOG) == -1) { /* Handle errors */ } for (;;) { faddrlen = sizeof (faddr); new_sock = accept(sock, (struct sockaddr *)&faddr, &faddrlen); if (new_sock == -1) { if (errno != EINTR && errno != ECONNABORTED) { /* Handle errors */ } continue; } do_work(new_sock);/* do some work */ } } o example 6 (server code supporting both IPv4 and IPv6) int myserver3(char *servicename) { struct sockaddr_storage faddr; /* Set up a socket to listen on for connections. */ bzero(&hints, sizeof (hints)); hints.ai_flags = AI_PASSIVE; hints.ai_socktype = SOCK_STREAM; error = getaddrinfo(NULL, servicename, &hints, &aip); if (error != 0) { /* Handle errors */ } sock = socket(aip->ai_family, aip->ai_socktype, aip->ai_protocol); if (sock == -1) { /* Handle errors */ } sock_opt = 1; if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (void *)&sock_opt, sizeof (sock_opt)) == -1) { /* Handle errors */ } if (bind(sock, aip->ai_addr, aip->ai_addrlen) == -1) { /* Handle errors */ } if (listen(sock, BACKLOG) == -1) { /* Handle errors */ } for (;;) { new_sock = accept(sock, (struct sockaddr *)&faddr, Shin et al. Expires August 2002 [Page 12] INTERNET-DRAFT Application Aspects of IPv6 Transition February 2002 &faddrlen); if (new_sock == -1) { if (errno != EINTR && errno != ECONNABORTED) { /* Handle errors */ } continue; } do_work(new_sock);/* do some work */ } } Authors' Addresses Myung-Ki Shin ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea Tel : +82 42 860 4847 Fax : +82 42 861 5404 E-mail : mkshin@pec.etri.re.kr Yong-Guen Hong ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea Tel : +82 42 860 6447 Fax : +82 42 861 5404 E-mail : yghong@pec.etri.re.kr Soo-Kyung Jeny Lee ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, 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-350, Korea Tel : +82 42 860 1021 Fax : +82 42 861 5404 Email : rune@pec.etri.re.kr Yong-Jin Kim ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea Tel : +82 42 860 6564 Fax : +82 42 861 5404 Email : yjkim@pec.etri.re.kr Shin et al. Expires August 2002 [Page 13]