Behave B. Huang Internet-Draft H. Deng Obsoletes: 2767 (if approved) China Mobile Intended status: Experimental T. Savolainen Expires: September 8, 2010 Nokia March 7, 2010 Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS) draft-huang-behave-rfc2767bis-02 Abstract This document describes the "Bump-In-the-Stack" (BIS) 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. Furthermore, this technology avoids need for unnecessary double protocol translation in the case where destination is dual-stack enabled. 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 will communicate directly with other hosts reachable with the different address family. In the case of IPv6 only network or IPv6 only destination, IPv4-originated communications have to be be translated into IPv6. In the scenario of single address family access network, but dual- stack destination, network based translation is always avoided. Technically, the BIS-enabled host resolves both IPv4 and IPv6 addresses of the destination and behaves according to received responses. Acknowledgement of previous work This document is an update to and directly derivative from Kazuaki TSUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI's [RFC2767], 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 three components 1. Supporting IPv6 only network connections 2. Extending ENR and address mapper to operate differently 3. Adding an alternative way to implement the ENR Huang, et al. Expires September 8, 2010 [Page 1] Internet-Draft Dual Stack Hosts using BIS March 2010 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 Dual Stack Hosts using BIS March 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Components . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Translator . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Extension Name Resolver (ENR) . . . . . . . . . . . . . . 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. Applicability and Limitations . . . . . . . . . . . . . . . . 12 5.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 12 6. ALG related . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. Normative References . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Implementation of ENR . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Huang, et al. Expires September 8, 2010 [Page 3] Internet-Draft Dual Stack Hosts using BIS March 2010 1. Introduction BIS [RFC2767]stated that there are few applications for IPv6 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. Meanwhile, there are scenarios where a dual stack host is connected to IPv6-only network but it is running IPv4-only applications, or a host is running IPv6- only applications while connected to IPv4-only network. BIS proposed a mechanism of dual stack hosts using the technique called "Bump-in-the-Stack" in the IP security area. The technique inserts modules, which snoop data flowing between a TCP/IPv4 module and network card driver modules and translate IPv4 into IPv6 and vice versa, into the hosts, and makes them self-translators. When they communicate with the other IPv6 hosts, pooled IPv4 addresses are assigned to the IPv6 hosts internally, but the IPv4 addresses never flow out from them. The network scenario specified in RFC2767 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. The opposite happens when the network is IPv4-only and application is IPv6-only capable. 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 communicate with IPv6 peers. If the network which host is connecting with is dual stack network, then host will behave as what RFC 2767 originally described. However, even in the dual stack access network case it can be that the destination peer is only reachable via single address family. In case there is a conflict between the address family supported by an application and the peer, BIS is needed. Since the translation is automatically carried out with the help of DNS protocol, most applications do not need to know whether the target hosts are IPv6 or IPv4 ones. That is, this allows hosts to communicate with other IPv6 hosts using existing IPv4 applications Huang, et al. Expires September 8, 2010 [Page 4] Internet-Draft Dual Stack Hosts using BIS March 2010 and other IPv4 hosts using existing IPv6 applications; thus it seems as if peers are always dual stack hosts with applications for both IPv4 and IPv6. This document uses terms defined in [RFC2460] , [RFC2893] , [RFC2767] and [RFC3338]. Huang, et al. Expires September 8, 2010 [Page 5] Internet-Draft Dual Stack Hosts using BIS March 2010 2. Components Dual stack hosts need applications, TCP/IP modules and addresses for both IPv4 and IPv6. The proposed hosts in this memo have 3 newly defined modules: a translator, an extension name resolver (ENR) and an address mapper. These hosts communicate with other IPv6 hosts using IPv4 application. Figure 1 illustrates the structure of the host in which new modules are installed. +-------------------------------------------------------------+ | +-------------------------------------------------------+ | | | IPv4 applications | | | +-------------------------------------------------------+ | | +-------------------------------------------------------+ | | | TCP/IPv4 | | | | +---------------------------------------------------+ | | | | +-----------+ +---------+ +---------------+ | | | | | extension | | address | | translator | | | | | | name | | mapper | +---------------+ | | | | | resolver | | | +---------------+ | | | | | | | | | IPv6 | | | +---+ +-----------+ +---------+ +---------------+ | | +-------------------------------------------------------+ | | | Network card drivers | | | +-------------------------------------------------------+ | +-------------------------------------------------------------+ +-------------------------------------------------------------+ | Network cards | +-------------------------------------------------------------+ Figure 1: Structure of the proposed dual stack host 2.1. Translator It translates IPv4 into IPv6 and vice versa using the IP conversion mechanism defined in SIIT [RFC2765]. When receiving IPv4 packets from IPv4 applications, translator converts IPv4 packet headers into IPv6 packet headers, then, if required, fragments the IPv6 packets (because header length of IPv6 is typically 20 bytes larger than that of IPv4), and sends them to IPv6 networks. When receiving IPv6 packets from the IPv6 networks, translator works symmetrically to the previous case, except that there is no need to fragment the packets. Huang, et al. Expires September 8, 2010 [Page 6] Internet-Draft Dual Stack Hosts using BIS March 2010 2.2. Extension Name Resolver (ENR) ENR returns always a "proper" answer in response to the IPv4 application's name resolution requests. In the case network does not return the IP address family application requested, the ENR will requests the address mapper to assign a local IP address corresponding to received IP address, and then synthesize 'A' record for the assigned IP address. E.g. in case of AAAA response is received while application asked for A, the address mapper will select a local IPv4 address, and ENR will synthesize 'A' record based on it. The application typically sends a query to a name server to resolve 'A' records for the target host name. ENR snoops the query, then, if required, creates another query to ensure both 'A' and 'AAAA' records are requested for the host name, and sends the queries to the DNS server. The following table illustrates ENR behaviour. The address application receives, and whether synthesis happens, is independent of the address families a host is actually provisioned with. Application | Network | ENR behaviour query | response | ------------+----------+--------------------- A | A | A | AAAA | A | A/AAAA | Figure 2: ENR behaviour illustration NOTE: This action is similar to that of the DNS64 in the network side, here it happens on the host. NOTE: An implementation option is to have ENR support in host's (stub) DNS resolver itself as described in [DNS64], in which case record synthesis is not needed and advanced functions such as DNSSEC are possible. If the ENR is implemented in BIS-module, same limitations arise as when DNS record synthesis is done on network. Anyway, it depends on the host to implement recursive DNS server by itself. 2.3. Address mapper Address mapper ("the mapper" later on ), maintains an IPv4 address pool in the case of dual stack network and IPv6 only network. The pool can consists of private IPv4 addresses. Also, mapper maintains a table consisting of pairs of these locally selected IPv4 addresses Huang, et al. Expires September 8, 2010 [Page 7] Internet-Draft Dual Stack Hosts using BIS March 2010 and a destinations's IPv6 addresses. When the extension name resolver or the translator 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 translator gets a socket API function call from the data received and there is not a mapping entry for the IPv6 source address. When the resolver or the translator 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 3: 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). Huang, et al. Expires September 8, 2010 [Page 8] Internet-Draft Dual Stack Hosts using BIS March 2010 (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. (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. Huang, et al. Expires September 8, 2010 [Page 9] Internet-Draft Dual Stack Hosts using BIS March 2010 3. Behavior Examples The mechanism of BIS 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 3 of [RFC2767] 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 3 of [RFC2767] 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 3 of [RFC2767]. If both the 'A' and 'AAAA' records are resolved, then there will be a little difference with section 3 of [RFC2767], 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 Dual Stack Hosts using BIS March 2010 4. Considerations This section considers some issues of the proposed dual stack hosts. 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 Dual Stack Hosts using BIS March 2010 5. Applicability and Limitations This section considers applicability and limitations of the proposed dual stack hosts. 5.1. Applicability The mechanism can be useful for people in the initial stages of IPv6 transition when significant percentage of applications are not yet modified into IPv6 realm. BIS can also help users who cannot upgrade their important legacy applications for any reason, such as due to lacking of maintenance support. The reason is that BIS allows hosts to communicate with IPv6 hosts using existing IPv4 applications, and that people can get connectivity for both IPv4 and IPv6 even if they do not have IPv6 applications. Furthermore, as protocol translation is supported also from IPv6 to IPv4, application developers can focus on implementing only IPv6 support. 5.2. Limitations BIS allows hosts to communicate with IPv6 enabled hosts using existing IPv4 applications, but this can not be applied to IPv4 applications which use special IPv4 options since it is impossible to translate IPv4 options into IPv6. Similarly it is impossible to translate any IPv6 option headers into IPv4, except for fragment headers and routing headers. So IPv6 inbound communication having the option headers may be rejected. But this kind of usage is not the majority of today's IP traffic. Huang, et al. Expires September 8, 2010 [Page 12] Internet-Draft Dual Stack Hosts using BIS March 2010 6. ALG related BIS host should only perform a minimum of ALG, especially for Host to Host Direct scenario to avoid complicated ALG design for various kind of appliation. ALG design is not encouraged for host based translation. It is out of scope of this document, and it will be handled in other document. Huang, et al. Expires September 8, 2010 [Page 13] Internet-Draft Dual Stack Hosts using BIS March 2010 7. 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 14] Internet-Draft Dual Stack Hosts using BIS March 2010 8. 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 15] Internet-Draft Dual Stack Hosts using BIS March 2010 9. 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 16] Internet-Draft Dual Stack Hosts using BIS 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 17] Internet-Draft Dual Stack Hosts using BIS 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 18]