Behave B. Huang Internet-Draft H. Deng Obsoletes: 3338 (if approved) China Mobile Intended status: Experimental T. Savolainen Expires: September 8, 2010 Nokia March 7, 2010 Dual Stack Hosts Using "Bump-in-the-API" (BIA) draft-huang-behave-rfc3338bis-02 Abstract This document describes the "Bump-In-the-API" (BIA) host based protocol translation mechanism that allows applications supporting only one IP address family to communicate with peers that are reachable or supporting only the other address family. This specification addresses scenarios where a host is provided dual stack or IPv6 only network connectivity. In the dual stack network case, single address family applications in the host sometime will communicate directly with other hosts using the different address family. In the case of IPv6 only network or IPv6 only destination, IPv4-originated communications have to be translated into IPv6. Technically, the BIA-enabled host resolves both A and AAAA addresses of the destination and behaves according to received responses. Acknowledgement of previous work This document is an update to and directly derivative from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and Erik Nordmark's [RFC3338], which similarly provides a dual stack host means to communicate with other IPv6 host using existing IPv4 appliations.The original document was a product of the NGTRANS working group. The changes in this document reflect four components 1. Supporting IPv6 only network connections 2. IPv4 address pool use private address 3. Extending ENR and address mapper to operate differently 4. Adding an alternative way to implement the ENR The goal of this mechanism is the same as that of the Bump-in-the- stack mechanism, but this mechanism provides the translation method between the IPv4 APIs and IPv6 APIs. Thus, the goal is simply Huang, et al. Expires September 8, 2010 [Page 1] Internet-Draft BIA March 2010 achieved without IP header translation. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its 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 obsoleted by other documents at any time. 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. This Internet-Draft will expire on September 8, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Huang, et al. Expires September 8, 2010 [Page 2] Internet-Draft BIA March 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Dual Stack Host Architecture Using BIA . . . . . . . . . . . . 6 2.1. Function Mapper . . . . . . . . . . . . . . . . . . . . . 6 2.2. Extension Name Resolver . . . . . . . . . . . . . . . . . 7 2.3. Address Mapper . . . . . . . . . . . . . . . . . . . . . . 7 3. Behavior Examples . . . . . . . . . . . . . . . . . . . . . . 10 3.1. dual stack network and IPv6 only peer . . . . . . . . . . 10 3.2. IPv6 only network and dual-stack peer . . . . . . . . . . 10 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. IPv4 Address Pool and Mapping Table . . . . . . . . . . . 11 4.2. Internally Assigned IPv4 or IPv6 Addresses . . . . . . . . 11 5. ALG related . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Implementation of ENR . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Huang, et al. Expires September 8, 2010 [Page 3] Internet-Draft BIA March 2010 1. Introduction [RFC3338] stated that there are few applications for IPv6 [RFC2460] as compared with IPv4 in which a great number of applications are available. In order to advance the transition smoothly, it is highly desirable to make the availability of IPv6 applications increase to the same level as IPv4. Unfortunately, however, this is expected to take a long time. BIA [RFC3338] proposed a mechanism of dual stack hosts using the technique called "Bump-in-the-API" in the IP security area. The technique inserts an API translator between the socket API module and the TCP/IP module in the dual stack hosts, so that it translates the IPv4 socket API function into IPv6 socket API function and vice versa. BIS [RFC2767] specifies a host translation mechanism using a technique called "Bump-in-the-Stack". It translates IPv4 into IPv6, and vice versa using the IP conversion mechanism defined in SIIT [RFC2765]. BIS allows hosts to communicate with other IPv6 hosts using existing IPv4 applications. However, this approach is to use a translator which is inserted between the TCP/IP module and network card driver, so that it has the same limitations as the SIIT based IP header translation methods. In addition, its implementation is dependent upon the network interface driver. 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 support communication between IPv4 applications and the target IPv6 hosts, pooled IPv4 addresses will be assigned through the extension name resolver in the API translator. But the those IPv4 addresses never flow out from them. The network scenario specified in [RFC3338] is a dual stack network. where IPv4 communication can be transported independently of IPv6. However, if the network provides only IPv6 transport, applications's IPv4 packets have to be translated into IPv6. This specification assumes that host knows it is connected with a dual stack network or IPv6-only network. The host learns that from layer 2 or from results of layer 3 IP address configuration mechanisms. If the network which host is connecting with is IPv6 only network, then host's IPv6 application will behave reguarly, and it's IPv4 application's packets have to be translated into IPv6 in order to Huang, et al. Expires September 8, 2010 [Page 4] Internet-Draft BIA March 2010 communicate with IPv6 applications. If the network which host is connecting with is dual stack network, then host will behave as what [RFC3338] originally described. The scenario where destination peer is not reachable with the address family a host is provisioned with is not covered by this document, as that requires network based protocol translation solution. However, the BIA technology can complement network based protocol translation . Moreover, since the translation is automatically carried out with the help of DNS protocol, most applications do not need to know whether target hosts are IPv6 or IPv4 ones. That is, this allows hosts to communicate with other IPv6 hosts using existing IPv4 applications ; thus it seems as if peers are always dual stack hosts with applications for both IPv4 and IPv6. 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 [RFC2119] . This document uses terms defined in [RFC2460] , [RFC2893] , [RFC2767] and [RFC3338]. Huang, et al. Expires September 8, 2010 [Page 5] Internet-Draft BIA March 2010 2. Dual Stack Host Architecture Using BIA Figure 1 shows the architecture of the host in which BIA is installed. +----------------------------------------------+ | +------------------------------------------+ | | | | | | | IPv4 applications | | | | | | | +------------------------------------------+ | | +------------------------------------------+ | | | Socket API (IPv4, IPv6) | | | +------------------------------------------+ | | +-[ API translator]------------------------+ | | | +-----------+ +---------+ +------------+ | | | | | Ext. Name | | Address | | Function | | | | | | Resolver | | Mapper | | Mapper | | | | | +-----------+ +---------+ +------------+ | | | +------------------------------------------+ | | +--------------------+ +-------------------+ | | | | | | | | | TCP(UDP)/IPv4 | | TCP(UDP)/IPv6 | | | | | | | | | +--------------------+ +-------------------+ | +----------------------------------------------+ Figure 1: Architecture of the dual stack host using BIA Dual stack hosts defined in RFC2893 [RFC2893] need applications, TCP/IP modules and addresses for both IPv4 and IPv6. The proposed hosts in this document have an API translator to communicate with other IPv6 hosts using existing IPv4 applications. The API translator consists of 3 modules, an extension name resolver, an address mapper and a function mapper. 2.1. Function Mapper It translates an IPv4 socket API function into an IPv6 socket API function, and vice versa. When detecting the IPv4 socket API functions from IPv4 applications, it intercepts the function call and invokes new IPv6 socket API functions which correspond to the IPv4 socket API functions. Those IPv6 API functions are used 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 in relation to Huang, et al. Expires September 8, 2010 [Page 6] Internet-Draft BIA March 2010 the previous case. 2.2. Extension Name Resolver It returns a proper answer in response to the IPv4 or IPv6 application's request. When an IPv4 application in an IPv6 only network tries to resolve names via the resolver library (e.g. gethostbyname()), BIA intercept the function call and instead call the IPv6 equivalent functions (e.g. getnameinfo()) that will resolve both A and AAAA records. If only AAAA record is available, it requests the address mapper to assign an IPv4 address corresponding to the IPv6 address, then creates the A record for the assigned IPv4 address, and returns the A record to the IPv4 application. If both A and AAAA record are available in the IPv6 only network, it doesn't requests the address mapper but directly send this A record and AAAA record to address mapper to store this relationship, then directly pass this A record to the IPv4 application. 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 pool. The pool can consists of private IPv4 addresses. When the extension 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 pool, and registers a new entry into the table dynamically. The registration occurs in the following 3 cases: (1) When the extension name resolver gets only an 'AAAA' record for the target host name in the dual stack or IPv6 only network and there is not a mapping entry for the IPv6 address. (2) When the extension name resolver gets both an 'A' record and an 'AAAA' record for the target host name in the IPv6 only network and there is not a mapping entry for the IPv6 address. But it doesn't need an IPv4 address out of the pool, just registers both IPv4 and IPv6 address from 'A' and 'AAAA' records into a new entry into the table. (3) 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 address. Huang, et al. Expires September 8, 2010 [Page 7] Internet-Draft BIA March 2010 When the resolver or the function mapper requests mapper to assign an IPv4 address corresponding to an IPv6 address, mapper, if required, selects and returns an IPv4 address out of the pool, and registers a new entry into the table dynamically. The following table describes how mappings are created into the table in each scenario : Mapping table | Access | Peer | Created entry for |link type | support| address mapping -------------------+-------------+------------------------------- (1) real IPv4 |IPv4 or DS | v4 | < no mapping needed > (2) real IPv6 |IPv6 or DS | v6 | < no mapping needed > (3) real IPv4 |IPv6 | v4 & v6| real IPv4 -> real IPv6 (4) real IPv6 |IPv4 | v4 & v6| real IPv6 -> real IPv4 (5) local IPv4 |IPv6 or DS | v6 | local IPv4 -> real IPv6 (6) local IPv6 |IPv4 or DS | v4 | local IPv6 -> real IPv4 (7) real IPv4 |IPv6 | v4 | out of scope (8) real IPv6 |IPv4 | v6 | out of scope Figure 2: Address Mapper's mapping table illustration Below are examples for all eight scenarios: (1) When the resolver gets an 'A' reply for application's 'A' query on access network supporting IPv4, there is no need to create mapping (or just stub mapping real IPv4 -> real IPv4). (2) When the resolver gets an 'AAAA' reply for application's 'AAAA' query on access network supporting IPv6, there is no need to create mapping (or just stub mapping real IPv6 -> real IPv6). (3) When the resolver gets both 'A' and 'AAAA' replies for application's 'A' query on IPv6-only access, there shall be mapping for real IPv4 to real IPv6. (4) When the resolver gets both 'A' and 'AAAA' replies for application's 'AAAA' query on IPv4-only access, there shall be mapping for real IPv6 to real IPv4. (5) When the resolver gets only an 'AAAA' record for the target host name for application's 'A' request on IPv6 only or DS access network, a local IPv4 address will be given to application and mapping for local IPv4 address to real IPv6 address is created. (6) When the resolver gets only an 'A' record for the target host name for application's 'AAAA' request on IPv4 only or DS access network, a local IPv6 address will be given to application and mapping for local IPv6 address to real IPv4 address is created. Huang, et al. Expires September 8, 2010 [Page 8] Internet-Draft BIA March 2010 (7) When the resolver gets only an 'A' record for the target host name for application's 'A' request on IPv6 only access network, a double translation would be required and thus is out of the scope of this document. (8) When the resolver gets only an 'AAAA' record for the target host name for application's 'AAAA' request on IPv4 only access network, a double translation would be required and thus is out of the scope of this document. NOTE: There is only one exception. When initializing the table, mapper registers a pair of its own IPv4 address and IPv6 address into the table statically. NOTE: This is the same as that of the Address Mapper in [RFC2767]. Huang, et al. Expires September 8, 2010 [Page 9] Internet-Draft BIA March 2010 3. Behavior Examples The mechanism of BIA could be used in two type of network environments, the first is dual stack network and IPv6 only peer, the second is IPv6 only network and dual stack peer. ENR will behave according to different network environment. 3.1. dual stack network and IPv6 only peer There are several reasons to not upgrade IPv4 applications to support IPv6 such as charging, codec, lack of knowledge et al, and this is out of scope of this document. Section 4 of [RFC3338] already has stated in detail how this work, there are no need to modify anything here. 3.2. IPv6 only network and dual-stack peer When a dual stack server locates in the IPv6 only network, and not yet updated IPv4 applicaiton need to visit this server. This is the network scenario of IPv6 only and dual stack peer. There is the need to replace "host6" with "host46" in figure 2 of section 4 of [RFC3338] because the peer host is dual stack. If only 'AAAA' records is resolved, so the ENR need to request the address mapper to allocate any IPv4 addresses from its pool, it's the same as the section 4 of [RFC3338]. If both the 'A' and 'AAAA' records are resolved, then there will be a little difference with section 4 of [RFC3338], the ENR does not need to request one IPv4 address from address mapper which is corresponding to the IPv6 address. on the contrarary, ENR will store the mapping between received destination's IPv4 and IPv6 addresses which are from 'A' and 'AAAA' records. After that, the ENR will return 'A' record to the application as is. Huang, et al. Expires September 8, 2010 [Page 10] Internet-Draft BIA March 2010 4. Considerations Other considerations in [RFC3338] are still the same, here only clarify the section of IPv4 Address Pool and Mapping Table and Internally Assigned IPv4 or IPv6 Addresses to support private IPv4 address. 4.1. IPv4 Address Pool and Mapping Table The address pool consists of the private IPv4 addresses. This pool can be implemented at different granularity in the node e.g., a single pool per node, or at some finer granularity such as per user or per process. However, if a number of IPv4 applications communicate with IPv6 hosts or IPv6 applications communicate with IPv4 hosts, the available address spaces will be exhausted. As a result, it will be impossible for IPv4 applications to communicate with IPv6 nodes. It requires smart management techniques for address pool. For example, it is desirable for the mapper to free the oldest entry and reuse the IPv4 address or IPv6 address for creating a new entry. This issues is the same as [BIS]. In case of a per-node address mapping table, it MAY cause a larger risk of running out of address. 4.2. Internally Assigned IPv4 or IPv6 Addresses The IPv4 addresses, which are internally assigned to IPv6 target hosts out of the pool, are the private IPv4 addresses. IPv4 addresses, which are internally assigned to IPv6 target hosts out of the spool, never flow out from the host, and so do not negatively affect other hosts. Huang, et al. Expires September 8, 2010 [Page 11] Internet-Draft BIA March 2010 5. ALG related BIA host should only perform a minimum of ALG to avoid complicated ALG design for various kind of appliation such as FTP, RTSP et al. ALG design is not encouraged for host based translation. It is out of scope of this document. Huang, et al. Expires September 8, 2010 [Page 12] Internet-Draft BIA March 2010 6. Security Considerations This is the same as the [RFC3338], newly added function doesn't bring new threat to the host based translation. Huang, et al. Expires September 8, 2010 [Page 13] Internet-Draft BIA March 2010 7. Acknowledgments The author thanks the discussion from Gang Chen, Dapeng Liu, Bo Zhou, Hong Liu, Tao Sun, Zhen Cao, Feng Cao et al. in the development of this document. The efforts of Suresh Krishnan, Mohamed Boucadair, Yiu L. Lee, James Woodyatt, Lorenzo Colitti, Qibo Niu, Pierrick Seite, Dean Cheng, Christian Vogt, Jan M. Melen in reviewing this document are gratefully acknowledged. Advice from Dan Wing, Dave Thaler and Magnus Westerlund are greatly appreciated Huang, et al. Expires September 8, 2010 [Page 14] Internet-Draft BIA March 2010 8. Normative References [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000. [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [RFC3338] 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. Huang, et al. Expires September 8, 2010 [Page 15] Internet-Draft BIA March 2010 Appendix A. Implementation of ENR It's not necessarily implment the ENR in the kernel level, but just implement it as the user space by set the default DNS server to 127.0.0.1, then IPv4 application could always send DNS query to the localhost, then ENR will send both A and AAAA query to the actual DNS server. So ENR will keep the real DNS server address. Huang, et al. Expires September 8, 2010 [Page 16] Internet-Draft BIA March 2010 Authors' Addresses Bill Huang China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: bill.huang@chinamobile.com Hui Deng China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: denghui02@gmail.com Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 TAMPERE Finland Email: teemu.savolainen@nokia.com Huang, et al. Expires September 8, 2010 [Page 17]