INTERNET DRAFT Myung-Ki Shin Expires: April 2003 Yong-Guen Hong ETRI Jun-ichiro itojun HAGINO IIJ Pekka Savola CSC/FUNET October 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, the application developers and the administrators will face several problems. This draft clarifies the problems occurring in transition period between IPv4 applications and IPv6 applications. It also proposes guidelines that help application developers understand how to develop IP version-independent applications during the transition period. Table of Contents: 1. Introduction .............................................. 2 1.1 Terminology .............................................. 3 2. Overview of IPv6 application transition ................... 3 3. Problems with IPv6 application transition ................. 4 Shin et al. Expires April 2003 [Page 1] INTERNET-DRAFT Application Aspects of IPv6 Transition October 2002 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 IPv4 applications in a dual stack node ................... 5 4.2 Separate IPv4 and IPv6 applications in a dual stack node . 6 4.3 IPv4/IPv6 applications in a dual stack node .............. 6 4.4 IPv4/IPv6 applications in an IPv4-only node .............. 7 5. Transition mechanism considerations ....................... 8 6. Open Issues ............................................... 8 7. Security considerations ................................... 8 8. Acknowledgments ........................................... 8 9. References ................................................ 8 Appendix .................................................... 10 Authors' Addresses .......................................... 14 1. Introduction As IPv6 is introduced in the IPv4-based Internet, several general issues when starting to use IPv6 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 transition mechanisms have been developed to migrate to IPv6 network ([NAT-PT], [SIIT], [6to4], [DSTM], etc.) However, even if these mechanisms are fully deployed, we still have problems occuring in the transition period between IPv4 applications and IPv6 applications. This document specifies application aspects of IPv6 transition. As IPv6 networks are deployed and the network transition discussed, we should also consider IPv6 application transition in a node. [BIS] and [BIA] have been proposed as short-term solutions, but these mechanisms SHOULD NOT be used when the application-specific source code is available. Ultimately, application developers will modify application programs to support both IPv4 and IPv6 (IP version-independent program). During the transition period, administrators may have various versions of an application (IPv4- only, IPv6-only or one supporting both IPv4 and IPv6) in a node. This draft clarifies the problems occurring in the transition period between IPv4 applications and IPv6 applications. It also proposes guidelines that help application developers understand how to develop IP version-independent applications during transition the period. Shin et al. Expires April 2003 [Page 2] INTERNET-DRAFT Application Aspects of IPv6 Transition October 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 [RFC 2119]. 2. Overview of IPv6 application transition The transition of an application can be classifed as follows: +-------------------+ | appv4 | (appv4 - IPv4-only applications) +-------------------+ | TCP / UDP | +-------------------+ | IPv4 | IPv6 | +-------------------+ Case 1. IPv4 applications in a dual stack node +-------------------+ | appv4 | appv6 | (appv6 - IPv6-only applications) +-------------------+ | TCP / UDP | +-------------------+ | IPv4 | IPv6 | +-------------------+ 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 | +-------------------+ | IPv4 | IPv6 | +-------------------+ 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 | +-------------------+ | IPv4 | +-------------------+ Case 4. Applications supporting both IPv4 and IPv6 in an IPv4-only node Figure 1. Overview of IPv6 Application Transition Shin et al. Expires April 2003 [Page 3] INTERNET-DRAFT Application Aspects of IPv6 Transition October 2002 Figure 1 shows the cases of IPv6 application transition. Case 1 : IPv4-only applications in a dual-stack node. IPv6 protocol is introduced in a node, but applications are not yet ported to 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 same applications for different protocol versions (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 to ease support, the same applications may also have to work when IPv6 is not used. 3. Problems with IPv6 application transition As IPv6 is deployed, the application developers and the administrators will face several problems. 3.1 Dual stack vs. application versions Considering the cases above, IPv4 and IPv6 protocol stack in a node is likely to co-exist for a long time. During this period, applications are expected to be able to handle IPv6 over some time period, not at the same time as IPv6 protocol is introduced. That is, operating system being dual stack does not mean having both IPv4 and IPv6 applications. Therefore, application introduction may be independent of protocol stacks in a node. It is even probable that applications capable of both IPv4 and IPv6 will have to work properly IPv4-only nodes (whether IPv6 protocol is completely disabled or there is no IPv6 connectivity at all). 3.2 DNS name resolution The role of the DNS name resolver in a node is to get the list of destination addresses. DNS queries and responses are sent using IPv4 transport, even though IPv6 addresses are being resolved, or Shin et al. Expires April 2003 [Page 4] INTERNET-DRAFT Application Aspects of IPv6 Transition October 2002 using IPv6 transport. This issue has 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 by only doing a DNS name lookup. 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, the 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). It is bad practise to add an AAAA record for node that does not support all the services using IPv6 (rather, a AAAA record for the specific service name and address should be used), but the application cannot depend on "good practise", and this must be handled. In consequence, the application has to try both protocol versions, and if the first to try fails, detect the failure and try using the other protocol version. 3.3 Application selection 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). Therefore, the users may be confused by their various application versions, because they don't know the version of peer application by DNS query results. To avoid problems with mismatching DNS query results, it is desirable to have hybrid applications, supporting both protocol versions. Alternative approach is to have a "wrapper application" which performs certain tasks (like figures out which protocol version will be used) and calls the IPv4/IPv6-only applications as necessary (these kind of "wrapper applications" only work for certain kinds of, usually simple, applications). Nonetheless, there should be some reasonable logic on how to perform application selection. 4. Description of the guidelines 4.1 IPv4 applications in a dual-stack node This scenario happens if IPv6 protocol is added in a node but IPv6-capable applications aren't yet available or installed. In order to allow an application to communicate with other IPv6 Shin et al. Expires April 2003 [Page 5] INTERNET-DRAFT Application Aspects of IPv6 Transition October 2002 nodes, the first priority is to convert the applications to use IPv6. In some cases (e.g. no source code), one may have to manage with existing IPv4 applications: then [BIA] can be installed in the node. 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 NOT be used only when an application source code is 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. A client application running [BIA] may have the issues mentioned in section 3.1 and 3.2. That is, if a client node running BIA tries to contact a dual stack node on a port number that is only associated to an IPv4 application, the attempt will fail. In order to solve 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 Separate IPv4 and IPv6 applications in a dual-stack node As applications are converted to IPv6-only, there can be two same applications with different protocol versions (e.g., ping and ping6). In fact, this transition case is undesirable (the best solution is to go to case 3), but IPv6-only applications will exist for several reasons (it is easy to modify, early version of an IPv6 application, etc.). In this case, there are two same applications with different names (possibly attached with '6'). Simple application selection rule is as follows : rule 1 - default application selection is the application for IPv6, only if IPv6 connectivity is provided. rule 2 - if it fails, then the IPv4 application is tried. IPv6-only application programs can be converted easily from the existing same IPv4 applications by means of one-to-one API mapping. For examples, IPv6-only applications will be implemented using Shin et al. Expires April 2003 [Page 6] INTERNET-DRAFT Application Aspects of IPv6 Transition October 2002 gethostbyname2(), getipnodebyname(), or getaddrinfo(), instead of gethostbyname() for IPv4. Note that with getipnodebyname() or gethostbyname2(), scoped IPv6 addresses can't be supported. See the appendix for more information. 4.3 IPv4/IPv6 applications in a dual stack node As applications are ported for both IPv4 and IPv6 support, the existing IPv4 applications are 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 wants to communicate with, can have various combinations of the protocol stacks and the applicaions. Under this assumption, the applications supporting both IPv4 and IPv6 SHOULD be ported to do the iterated job, which tries to create the connection with the node 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). 4.4. IPv4/IPv6 applications in an IPv4-only node As the transition is likely to happen over a longer timeframe, the applications that have already been ported to support both IPv4 and IPv6 may be run on IPv4-only nodes. This would typically be done to avoid having to support two application versions for older and newer operating systems, or to support the case that the user wants to disable IPv6 for some reason. Depending on how application/operating system support is done, some may want to ignore this case, but usually no assumptions can be made and applications should work in this scenario too. 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 a EPROTONOSUPPORT or EAFNOSUPPORT error. Typically, if errors are encountered, this leads 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 in such a way that errors are ignored until the last address Shin et al. Expires April 2003 [Page 7] INTERNET-DRAFT Application Aspects of IPv6 Transition October 2002 family. So, this case is just an extension of the IPv4/IPv6 support in the previous case, covering one relatively common but often ignored case. 5. Transition mechanism considerations Under [NAT-PT] mechanism, a pair of IPv6-only and IPv4-only applications could be enough but one should note one special case (NAT-PT prefix + IPv4 address) which one might be tempted to handle differently. This is an IPv4 addresses, translated by NAT-PT DNS ALG [DNS-ALG]. IPv6 applications, in general, MUST NOT be required to distinguish "normal" and "NAT-PT translated" addresses: that woould be completely unscalable, and if such distinction must be made, it must be done elsewhere (e.g. kernel, system libraries). 6. Open Issues Some, perhaps even all, RFC2119 keywords may have to be changed as this has not been intended as a normative reference. Examples should be replaced by very short working applications, as they are incomplete and difficult to understand. Should there be a case for IPv6-only nodes (note: this adds very little new if AF_INET6 is always tried first in hybrid apps). 7. Security considerations See the each security consideration section listed in section 9 - References. One particular point about application transition is how IPv4- mapped IPv6-addresses are handled. The use in the API can be seen as both a merit (easier application transition) and as a burden (difficulty in ensuring whether the use was legimate) [V6MAPPED]. This may have to be considered in more detail. 8. Acknowledgments Authors would like to acknowledge the idea sharing contributions by Erik Nordmark (nordmark@sun.com). 9. References Normative References Shin et al. Expires April 2003 [Page 8] INTERNET-DRAFT Application Aspects of IPv6 Transition October 2002 [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 [DSTM] Jim Bound et al., Dual Stack Transition Mechanism (DSTM), , July 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)", RFC 3338, October 2002. [SOCK-EXT] R. Gilligan, S. Thomson, J. Bound and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC2553, March 1999. [RFC 2119] Bradner S., Key words for use in RFCs to indicate Requirement Levels, RFC 2119, March 1997. Informative 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. [DEFAULT] Richard Draves, "Default Address Selection for IPv6", , September, 2001, Work in Progress. [DNS-ALG] A. Durand, "Issues with NAT-PT DNS ALG in RFC2766", , February 2002, Work in Progress. [DNS] A. Durand, J. Ihren, "NGtrans IPv6 DNS operational requir- ements and roadmap", , March, 2002, Work in Progress. [Y2K-SOFT] Erik Nordmark, "IPv6: Another Y2K for Software", IPv4 to IPv6 Migration, IPv6 Summit, September 2001. Shin et al. Expires April 2003 [Page 9] INTERNET-DRAFT Application Aspects of IPv6 Transition October 2002 [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. [V6MAPPED] Jun-ichiro itojun Hagino, "IPv4 mapped address considered harmful", , work-in-progress, Apr 2002. 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-only or IPv6-only structures and APIs. o IPv4-only and IPv6-only structures IPv4 IPv6 ----------------------------------------- AF_INET/PF_INET AF_INET6/PF_INET6 AF_INET AF_INET6 struct sockaddr_in struct sockaddr_in6 struct in_addr struct in6_addr o IPv4-only and IPv6-only 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 (Note: when porting software, one should be aware that some systems have "ss_len" member in the structure while others do not; there will be clarifications on this.) o getaddrinfo() and getnameinfo() Rule 2 - Trying all addresses for finding working address. Shin et al. Expires April 2003 [Page 10] INTERNET-DRAFT Application Aspects of IPv6 Transition October 2002 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-only client code) and example 2 (IPv6-only client code) should be modified to example 3. o example 1 (IPv4-only 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); (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-only 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); Shin et al. Expires April 2003 [Page 11] INTERNET-DRAFT Application Aspects of IPv6 Transition October 2002 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: in particular, note case 4.4 */; } if (connect(sock, aip->ai_addr, aip->ai_addrlen) == -1) { /* Handle errors */; continue; } break; } return (sock); } As well, example 4 IPv4-only server code) and example 5 (IPv6-only server code) should be modified to example 6. o example 4 (IPv4-only 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, Shin et al. Expires April 2003 [Page 12] INTERNET-DRAFT Application Aspects of IPv6 Transition October 2002 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-only 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) { /* 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 */ } Shin et al. Expires April 2003 [Page 13] INTERNET-DRAFT Application Aspects of IPv6 Transition October 2002 } 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: in particular, note case 4.4 */ } 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, &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 Shin et al. Expires April 2003 [Page 14] INTERNET-DRAFT Application Aspects of IPv6 Transition October 2002 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 Jun-ichiro itojun HAGINO Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku,Tokyo 101-0054, JAPAN Tel: +81-3-5259-6350 Fax: +81-3-5259-6351 E-mail: itojun@iijlab.net Pekka Savola CSC/FUNET E-mail : psavola@funet.fi Shin et al. Expires April 2003 [Page 15]