INTERNET DRAFT Seungyun Lee Expires: August 2001 Myung-Ki Shin Yong-Jin Kim ETRI Erik Nordmark Alain Durand Sun Microsystems February 2001 Dual Stack Hosts using "Bump-in-the-API" (BIA) 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 ocuments at anytime. It is inappropriate to use Internet Drafts as eference 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 This document specifies a mechanism of dual stack hosts using the technique called "Bump-in-the-API" which allows for the hosts to communicate with other IPv6 hosts using existing IPv4 applications. The goal of this mechanism is the same as the Bump-in-the-stack mechanism [BIS], but this mechanism provides the translation method between the IPv4 APIs and IPv6 APIs. So that the goal is achieved simply without IP header translation. 1. Introduction RFC2767 [BIS] specifies a host translation mechanism using the technique called "Bump-in-the-Stack". It translates IPv4 into IPv6 and vice versa using the IP conversion mechanism defined in [SIIT]. The BIS allows the hosts to communicate with other IPv6 hosts using existing IPv4 applicat- ions. However, this approach is to use an API translator which is Lee,Shin,Kim,Erik,Durand Expires August 2001 [Page 1] INTERNET-DRAFT Dual stack host using "Bump-in-the-API" (BIA) February 2001 inserted between TCP/IP module and network card driver, so that it has the same limitations that the [SIIT] based IP header translation methods have. In addition, its implemetation is dependent on the network interface driver. This document specifies a new mechanism of dual stack hosts named the Bump-in-the-API(BIA) technique. The BIA technique inserts an API translator between the socket API module and the TCP/IP module in the dual stack hosts and translates the IPv4 socket API function into IPv6 socket API function and vice versa. With this mechanism, the translation can be simplified without IP header translation. For the BIA, the dual stack host assumes that there exists both TCP(UDP)/IPv4 and TCP(UDP)/IPv6 stacks on the hosts. When IPv4 applications on the dual stack communicate with other IPv6 hosts, the API translator detects the socket API functions from IPv4 applications and invokes the IPv6 socket API functions to communicate with the IPv6 hosts and vice versa. In order to communicate between IPv4 applications and the target IPv6 hosts, pooled IPv4 addresses will be assigned through the name resolver in the API translator. In addition, this document uses terms defined in [IPv6],[TRANS-MECH] and [BIS]. 2. Dual Stack Host Architecture Figure 1 shows the architecture of the host in which the BIA is installed. +----------------------------------------------+ | +------------------------------------------+ | | | | | | | IPv4 applications | | | | | | | +------------------------------------------+ | | +------------------------------------------+ | | | Socket API (IPv4, IPv6) | | | +------------------------------------------+ | | +-[ API Translator]------------------------+ | | | +-----------+ +---------+ +------------+ | | | | | Name | | Address | | Function | | | | | | Resolver | | Mapper | | Mapper | | | | | +-----------+ +---------+ +------------+ | | | +------------------------------------------+ | | +--------------------+ +-------------------+ | | | | | | | | | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | | | | | | | | | +--------------------+ +-------------------+ | +----------------------------------------------+ Figure 1 Architecture of the dual stack host Lee,Shin,Kim,Erik,Durand Expires August 2001 [Page 2] INTERNET-DRAFT Dual stack host using "Bump-in-the-API" (BIA) February 2001 Dual stack hosts defined in RFC1933 [TRANS-MECH] need applications, TCP/IP modules and addresses for both IPv4 and IPv6. The proposed hosts in this document have 'API Translator' to communicate with other IPv6 host using existing IPv4 applications. The API translator consists of 3 modules, a name resolver, an address mapper and a function mapper. 2.1 Function Mapper It translates IPv4 socket API function into IPv6 socket API function and vice versa. When detecting the IPv4 socket API functions from IPv4 applications, it intercepts the function call and then invokes new IPv6 socket API function which corresponds to the IPv4 socket API function to communicate with the target IPv6 hosts. When detecting the IPv6 socket API functions from the data received from the IPv6 hosts, it works symmetrically to the previous case. 2.2 Name Resolver It returns a proper answer in response to the IPv4 application's request. When the IPv4 application sends a query to a name server with 'A' records, it detects the query, then creates another query to resolve both 'A' and 'AAAA' records for the host name, and sends the query to the server. If only the 'AAAA' record is available, it requests the address mapper to assign and IPv4 address corresponding to the IPv6 address, then creates the 'A' record for the assigned IPv4 address, and returns the 'A' record to the application. NOTE: This action is the same to that of the Extension Name Resolver in [BIS]. 2.3 Address Mapper It internally maintains a table of the pairs of an IPv4 address and an IPv6 address. The IPv4 addresses are assigned from an IPv4 address spool. It uses the unassigned IPv4 addresses (e.g., 0.0.0.0 ~ 0.0.0.255). When the name resolver or the function mapper requests it to assign an IPv4 address corresponding to an IPv6 address, it selects and returns an IPv4 address out of the spool, and registers a new entry into the table dynamically. The registration occurs in the following 2 cases : (1) When the name resolver gets only an 'AAAA' record for the target host name and there is not a mapping entry for the IPv6 address. (2) When the function mapper gets a socket API function call from the data received and there is not a mapping entry for the IPv6 source Lee,Shin,Kim,Erik,Durand Expires August 2001 [Page 3] INTERNET-DRAFT Dual stack host using "Bump-in-the-API" (BIA) February 2001 address. NOTE: This is the same to that of the address mapper in [BIS]. 3. Behavior Examples This section describes behaviors of the proposed dual stack host called "dual stack," which communicates with an IPv6 host called "host6" using an IPv4 application. 3.1 Originator behavior This subsection describes the behavior when the "dual stack" sends a data to "host6". When the IPv6 application sends a DNS query to its name server, the name resolver intercept the query and then creates a new query to resolve both 'A' and 'AAAA' records. In this case, only the 'AAAA' record is resolved, so the name resolver requests the address mapper to assign an IPv4 address corresponding to the IPv6 address. The name resolver creates an 'A' record for the assigned IPv4 address and returns it to the IPv4 applications. In order for the IPv4 application to send IPv4 packets to host6, it calls the IPv4 socket API function. The function mapper detects the socket API function from the application. If the result is from the IPv6 applications, it skips the translation. In case of IPv4 applications, it requires a IPv6 address to invoke the IPv6 socket API function, thus the function mapper requests the IPv6 address to the address mapper. The address mapper selects an IPv4 address from the table and returns the destination IPv6 address. Using this IPv6 address, the function mapper invokes a IPv6 socket API function correspon- ding to the IPv4 socket API function. When the function mapper receives the IPv6 function call,it requests the IPv4 address to address mapper in order to translate the IPv6 socket API function into IPv4 socket API function. Then the function mapper invokes the socket API function for the IPv4 applications. Lee,Shin,Kim,Erik,Durand Expires August 2001 [Page 4] INTERNET-DRAFT Dual stack host using "Bump-in-the-API" (BIA) February 2001 The following figure illustrates the behavior described above: "dual stack" "host6" IPv4 Socket | [ API Translator ] | TCP(UDP)/IP Name appli- API |Name Address Function| (v6/v4) Server cation |Resolver Mapper Mapper | | | | | | | | | <> | | | | | | | | | | | |--------|------->| Query of 'A' records for host6. | | | | | | | | | | | | |--------|--------|---------|--------------|------>| | | | Query of 'A' records and 'AAAA' for host6 | | | | | | | | | | | |<-------|--------|---------|--------------|-------| | | | Reply only with 'AAAA' record. | | | | | | | | | | | |<> | | | | | | | | | | |+++++++>| Request one IPv4 address | | | | | Corresponding to the IPv6 address. | | | | | | | | | | |<> | | | | | | | | | | |<+++++++| Reply with the IPv4 address. | | | | | | | | | | |<> | | | | | | | |<------ | Reply with the 'A' record. | | | | | | | | | Figure 2 Behavior of the originator (1/2) Lee,Shin,Kim,Erik,Durand Expires August 2001 [Page 5] INTERNET-DRAFT Dual stack host using "Bump-in-the-API" (BIA) February 2001 "dual stack" "host6" IPv4 Socket | [ API Translator ] | TCP(UDP)/IP appli- API |Name Address Function| (v6/v4) cation |Resolver Mapper Mapper | | | | | | | | <> | | | | | | | | | | |========|========|========|=======>| An IPv4 Socket API function Call | | | | | | | | | | |<+++++++| Request IPv6 addresses| | | | | | corresponding to the | | | | | | IPv4 addresses. | | | | | | | | | | | |+++++++>| Reply with the IPv6 addresses. | | | | | | | | | | | |<> | | | | | | | | An IPv6 Socket API function call.|=========|=============>| | | | | | | | | | | | |<> | | | | | | | | | An IPv6 Socket API function call.|<========|==============| | | | | | | | | | | | |<> | | | | | | | | | | |<+++++++| Request IPv4 addresses| | | | | | corresponding to the | | | | | | IPv4 addresses. | | | | | | | | | | | |+++++++>| Reply with the IPv6 addresses. | | | | | | | |<=======|========|========|========| An IPv4 Socket function call. | | | | | | | Figure 2 Behavior of the originator (2/2) In this figure, the meanings of arrows are as follows : ---> A DNS message for name resolving which is occurred by the applications and the name resolver in the API translator. +++> An IPv4 address request to and reply from the address mapper for the name resolver and the function mapper. ===> A data flow by Socket API function which is occurred by the applications and the function mapper in the API translator. 3.2 Recipient behavior This subsection describes the recipient behavior of "dual stack". The communication is triggered by "host6". Lee,Shin,Kim,Erik,Durand Expires August 2001 [Page 6] INTERNET-DRAFT Dual stack host using "Bump-in-the-API" (BIA) February 2001 The "host6" resolves the address of "dual stack" with 'AAAA' records through its name server, and then sends an IPv6 packets to the "dual stack". The IPv6 packet reaches the "dual stack" and then function mapper detects it. The function mapper requests the IPv4 address to address mapper in order to invoke the IPv4 socket API function to communicate with for IPv4 application. Then the function mapper invokes the corresponding IPv4 socket API function for the IPv4 applications corresponding to the IPv6 functions. The following figure illustrates the behavior described above: "dual stack" "host6" IPv4 Socket | [ API Translator ] | TCP(UDP)/IP appli- API |Name Address Function| (v6/v4) cation |Resolver Mapper Mapper | | | | | | | | <> | | | | | | | | | | | An IPv6 Socket function call.|<========|==============| | | | | | | | | | | |<+++++++| Request IPv4 addresses| | | | | | corresponding to the IPv6 | | | | | IPv6 addresses. | | | | | | | | | | | |+++++++>| Reply with the IPv4 addresses. | | | | | | | | | | | |<> | | | | | | | |<=======|========|========|========| An IPv4 function call | | | | | | | | <> | | | | | | | | | | |========|========|========|=======>| An IPv4 function call | | | | | | | | | | | | |<> | | | | | | | | | | |<+++++++| Request IPv6 addresses| | | | | | corresponding to the IPv4 | | | | | addresses. | | | | | | | | | | | |+++++++>| Reply with the IPv6 addresses. | | | | | | | | An IPv6 Socket function call.|=========|=============>| | | | | | | | Figure 3 Behavior of Receiving data from IPv6 host Lee,Shin,Kim,Erik,Durand Expires August 2001 [Page 7] INTERNET-DRAFT Dual stack host using "Bump-in-the-API" (BIA) February 2001 4. Considerations 4.1 Socket API conversion IPv4 socket API functions are translated into semantically the same IPv6 socket API functions and vice versa. Also, in order to translate ICMP messages, it it required to convert the message type at socket layer properly. NOTE: Basically, the IPv4 socket API functions do not have full compatibi- lity with IPv6 since the IPv6 has new advanced features. 4.2 IPv4 address spool and mapping table The address spool consists of the unassigned IPv4 addresses. However if a number of IPv4 applications communicate with IPv6 hosts, the available address spaces will be exhausted, as a result it will be impossible to assign for IPv6 hosts. So it requires smart management techniques for address mapping table. For example, it is desirable to the oldest entry and re-use the the IPv4 address for creating a new entry. 4.3 Internally assigned IPv4 addresses The IPv4 addresses, which are internally assigned to IPv6 target hosts out of the spool, are the unassigned IPv4 addresses. So there is no potential collision with another use of the private address space when the IPv4 address flows out from the host. 4.4 Implementation Issues Some operating systems support the pre-load library functions, so it is easy to implement the API translator by using it. For example, user can replace all existing socket API functions with user-defined socket API functions which translate the socket API function. In this case, every IPv4 application has their own translation library using pre-load library which will be bound into the application before execution dynamically. The other operating systems support the user-define layered protocol, so it allows a user to develop the additional protocols and allows to put them in the existing protocol stack. In this case, the API translator can be implemented as a layered protocol module. In the above two approaches, it assumes that there exists both TCP(UDP)/IPv4 and TCP(UDP)/IPv6 stacks and there is no need to modify or to add a new TCP-UDP/IPv6 stack. 5. Applicability and Limitations Lee,Shin,Kim,Erik,Durand Expires August 2001 [Page 8] INTERNET-DRAFT Dual stack host using "Bump-in-the-API" (BIA) February 2001 5.1 Applicability The main purposes of this mechanism are the same to BIS [BIS]. It makes IPv4 applications to communicate with IPv6 hosts without any modification of IPv4 applications. And it can also get connectivity for both IPv4 and IPv6. Since it uses the API level translation, the translation is more simple than the IP packet level translation. Also, it is possible to translate system independency through the socket level translation if the socket API can be supported at the same level on the IPv4 and IPv6. 5.2 Limitations The proposed mechanism support for only unicast communications. If it can support the multicast functions, some other additional functionalities must be considered in the function mapper module. 6. Security Considerations Security considerationa are mostly the same as [BIS]. 7. References [TRANS-MECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996. [SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000. [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [NAT] Kjeld B. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994. [IPV4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [PRIVATE] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. Lee,Shin,Kim,Erik,Durand Expires August 2001 [Page 9] INTERNET-DRAFT Dual stack host using "Bump-in-the-API" (BIA) February 2001 [BIS] K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000. Authors Addresses Seungyun Lee ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-600, Korea Tel : +82 42 860 5508 Fax : +82 42 861 5404 Email : syl@pec.etri.re.kr Myung-Ki Shin ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-600, Korea Tel : +82 42 860 4847 Fax : +82 42 861 5404 Email : mkshin@pec.etri.re.kr 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 Alain Durand Sun Microsystems 901 San Antonio Road UMPK 17-202 Palo Alto, CA 94303-4900, USA Tel : +1 650 786 7503 Fax : +1 650 786 5896 Email : Alain.Durand@sun.com Erik Nordmark Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303, USA Tel : +1 650 786 5166 Fax : +1 650 786 5896 Email : nordmark@sun.com Lee,Shin,Kim,Erik,Durand Expires August 2001 [Page 10]