Behave B. Huang Internet-Draft H. Deng Obsoletes: 2767 (if approved) China Mobile Intended status: Experimental T. Savolainen Expires: August 21, 2010 Nokia February 17, 2010 Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS) draft-huang-behave-rfc2767bis-01 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, IPv6 only or IPv4 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. IPv6 communications may have to translated similarly to IPv4. 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. Supporting IPv4 only network connections Huang, et al. Expires August 21, 2010 [Page 1] Internet-Draft Dual Stack Hosts using BIS February 2010 3. Supporting dual stack network connections with 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 August 21, 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 August 21, 2010 [Page 2] Internet-Draft Dual Stack Hosts using BIS February 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 . . . . . . . . . . . . . . . . . . . . . . 8 3. Action Examples -- dual stack network and IPv6 only peer . . . 10 3.1. Originator behavior . . . . . . . . . . . . . . . . . . . 10 3.2. Recipient behavior . . . . . . . . . . . . . . . . . . . . 12 4. Action Examples -- IPv6 only network and dual-stack peer . . . 15 4.1. Originator behavior . . . . . . . . . . . . . . . . . . . 15 4.2. Recipient behavior . . . . . . . . . . . . . . . . . . . . 17 5. Action Examples -- IPv4 only network and IPv4 only peer . . . 18 5.1. Originator behavior . . . . . . . . . . . . . . . . . . . 18 5.2. Recipient behavior . . . . . . . . . . . . . . . . . . . . 20 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. IP conversion . . . . . . . . . . . . . . . . . . . . . . 23 6.2. IPv4 or IPv6 Address Pool and Mapping Table . . . . . . . 23 6.3. Internally Assigned IPv4 or IPv6 Addresses . . . . . . . . 23 7. Applicability and Limitations . . . . . . . . . . . . . . . . 24 7.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 24 7.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 24 8. ALG related . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 11. Normative References . . . . . . . . . . . . . . . . . . . . . 28 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Huang, et al. Expires August 21, 2010 [Page 3] Internet-Draft Dual Stack Hosts using BIS February 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, IPv6-only network or IPv4-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 IPv4 only network, then host's IPv4 application will behave regularly, and it's IPv6 application's packets have to be translated into IPv4 packets. 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. Huang, et al. Expires August 21, 2010 [Page 4] Internet-Draft Dual Stack Hosts using BIS February 2010 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 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 August 21, 2010 [Page 5] Internet-Draft Dual Stack Hosts using BIS February 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 and IPv4 hosts using IPv6 application. Figure 1 illustrates the structure of the host in which new modules are installed. +----------------------------------------------------------------+ | +---------------------------+ +---------------------------+ | | | IPv4 applications | | IPv6 applications | | | +---------------------------+ +---------------------------+ | | +---------------------------+ +---------------------------+ | | | TCP/IPv4 | | TCP/IPv6 | | | | +-----------------------+ +----------------------+ | | | | | +-----------+ +---------------+ +---------+ | | | | | | | Extension | | translator | | address | | | | | | | | Name | +---------------+ | mapper | | | | | | | | Resolver | +------+ +------+ | | | | | | | | | | | IPv6 | | IPv4 | | | | | | | +---+ +-----------+ +------+ +------+ +---------+ +----+ | | +----------------------------------------------------------+ | | | 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 in the IPv6 only network, 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. When receiving IPv6 packets from IPv6 applications in the IPv4 only Huang, et al. Expires August 21, 2010 [Page 6] Internet-Draft Dual Stack Hosts using BIS February 2010 network, translator converts IPv6 packet headers into IPv4 packet headers, but doesn't do fragmentation as packet size is decreased, and sends packets to IPv4 networks. When receiving IPv4 packets from the IPv4 networks, it works symmetrically to the previous case. (NOTE: for packet received from network, if there is unsolicited IPv4 1500 byte packet coming from the network, which needs to be translated into IPv6 inside a host, then there is a need to fragment the packets) 2.2. Extension Name Resolver (ENR) ENR returns always a "proper" answer in response to the IPv4 and IPv6 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' or 'AAAA' 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', 'AAAA', or both, 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 | AAAA | AAAA | AAAA | A | 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 Huang, et al. Expires August 21, 2010 [Page 7] Internet-Draft Dual Stack Hosts using BIS February 2010 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 and a destinations' IPv6 addresses. In the case of dual-stack networks and IPv4 only networks, mapper creates locally used IPv6 addresses by concatenation of IPv6 prefix and destination's IPv4 address. The mapper maintains a table consisting of pairs of local IPv6 addresseses and destinations' IPv4 addresses. When the resolver or the translator requests mapper to assign an IPv4 address corresponding to an IPv6 address or assign an IPv6 address corresponding to an IPv4 address, mapper, if required, selects and returns an IPv4 address out of the pool, or concatenated IPv6 address, and registers a new entry into the table dynamically. The following table describes how mappings are created into the table in each scenario (note that the scenario of destination not supporting the same address family host is provisioned with, and where network based translation assistance would be needed, is shown in the table for the sake of completeness only (7 & 8)): 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 | real IPv4 -> synthetic IPv6 (8) real IPv6 |IPv4 | v6 | real IPv6 -> synthetic IPv4 Figure 3: Address Mapper's mapping table illustration Below are example for all six 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 August 21, 2010 [Page 8] Internet-Draft Dual Stack Hosts using BIS February 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 August 21, 2010 [Page 9] Internet-Draft Dual Stack Hosts using BIS February 2010 3. Action Examples -- dual stack network and IPv6 only peer This section describes action of the proposed dual stack host called "dual stack," which communicates with an IPv6 peer called "host6" using an IPv4 application on dual stack network. 3.1. Originator behavior This subsection describes the originator behavior of "dual stack." The communication is triggered by "dual stack." The application sends a query to its name server to resolve 'A' records for "host6." The resolver snoops the query, then creates another query for 'AAAA' to resolve both 'A' and 'AAAA' records for the host name, and sends it to the server. In this case, only the 'AAAA' record is resolved, so the resolver requests the mapper to assign an IPv4 address corresponding to the IPv6 address. NOTE: In the case of communication with an IPv4 host, the 'A' record is resolved and then the resolver returns it to the application as is. There is no need for the IP conversion as shown later. The mapper selects an IPv4 address out of the pool and returns it to the ENR. The ENR creates the 'A' record for the assigned IPv4 address and returns it to the application. NOTE: See subsection 6.3 about the influence on other hosts caused by an IPv4 address assigned here. The application sends an IPv4 packet to "host6." The IPv4 packet reaches the translator. The translator tries to translate the IPv4 packet into an IPv6 packet but does not know how to translate the IPv4 destination address and the IPv4 source address. So the translator requests the mapper to provide mapping entries for them. The mapper checks its mapping table and finds entries for each of them, and then returns the IPv6 destination address and the IPv6 source address to the translator. NOTE: The mapper will register its own IPv4 address and IPv6 address into the table beforehand. See subsection 2.3. Huang, et al. Expires August 21, 2010 [Page 10] Internet-Draft Dual Stack Hosts using BIS February 2010 The translator translates the IPv4 packet into an IPv6 packet and then fragments the IPv6 packet if necessary and sends it to an IPv6 network. The IPv6 packet reaches "host6." Then "host6" sends a new IPv6 packet to "dual stack." The IPv6 packet reaches the translator in "dual stack." The translator gets mapping entries for the IPv6 destination address and the IPv6 source address from the mapper in the same way as before. Then the translator translates the IPv6 packet into an IPv4 packet and tosses it up to the application. The following diagram illustrates the action described above: "dual stack" "host6" IPv4 TCP/ extension address translator IPv6 appli- IPv4 name mapper cation resolver | | | | | | | <> | | | | | | | | | |------|------>| Query of 'A' records for "host6". | Name | | | | | | | Server | | |---------|-------|-----------|---------|--->| | | | 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 4: Action of the originator (1/2) Huang, et al. Expires August 21, 2010 [Page 11] Internet-Draft Dual Stack Hosts using BIS February 2010 "dual stack" "host6" IPv4 TCP/ extension address translator IPv6 appli- IPv4 name mapper cation resolver | | | | | | | <>| | | | | | | | | | |======|=======|=========|======>| An IPv4 packet. | | | | | | | | | | | |<------| Request IPv6 addresses | | | | | corresponding to the IPv4 | | | | | addresses. | | | | | | | | | | | |------>| Reply with the IPv6| | | | | | addresses. | | | | | | | | | | | | |<> | | | | | | | | | |An IPv6 packet. |===========|========>| | | | | | | | | | | | <> | | | | | | | | | | |An IPv6 packet. |<==========|=========| | | | | | | | | | | | |<> | | | | | | | |<=====|=======|=========|=======| An IPv4 packet. | | | | | | | | Figure 5: Action of the originator (2/2) 3.2. Recipient behavior This subsection describes the recipient behavior of "dual stack." The communication is triggered by "host6." "host6" resolves the 'AAAA' record for "dual stack" through its name server, and then sends an IPv6 packet to the IPv6 address. The IPv6 packet reaches the translator in "dual stack." The translator tries to translate the IPv6 packet into an IPv4 packet but does not know how to translate the IPv6 destination address and the IPv6 source address. So the translator requests the mapper to provide mapping entries for them. The mapper checks its mapping table with each of them and finds a Huang, et al. Expires August 21, 2010 [Page 12] Internet-Draft Dual Stack Hosts using BIS February 2010 mapping entry for the IPv6 destination address. NOTE: The mapper will register its own IPv4 address and IPv6 address into the table beforehand. See subsection 2.3. But there is not a mapping entry for the IPv6 source address, so the mapper selects an IPv4 address out of the pool for it, and then returns the IPv4 destination address and the IPv4 source address to the translator. NOTE: See subsection 6.3 about the influence on other hosts caused by an IPv4 address assigned here. The translator translates the IPv6 packet into an IPv4 packet and tosses it up to the application. The application sends a new IPv4 packet to "host6." The following behavior is the same as that described in subsection 3.1. The following diagram illustrates the action described above: Huang, et al. Expires August 21, 2010 [Page 13] Internet-Draft Dual Stack Hosts using BIS February 2010 "dual stack" "host6" IPv4 TCP/ extension address translator IPv6 appli- IPv4 name mapper cation resolver | | | | | | | <> | | | | | | | | | | | | |An IPv6 packet. |<==========|=========| | | | | | | | | | | |<------| Request IPv4 addresses | | | | | corresponding to the IPv6 | | | | | addresses. | | | | | | | | | | | |------>| Reply with the IPv4| | | | | | addresses. | | | | | | | | | | | | |<> | | | | | | | |<=====|=======|=========|=======| An IPv4 packet. | | | | | | | | <> | | | | | | | | | |======|=======|=========|======>| An IPv4 packet. | | | | | | | | | | | | |<> | | | | | | | | | |An IPv6 packet. |===========|========>| | | | | | | | Figure 6: Action of the recipient Huang, et al. Expires August 21, 2010 [Page 14] Internet-Draft Dual Stack Hosts using BIS February 2010 4. Action Examples -- IPv6 only network and dual-stack peer This section describes action of the proposed dual stack host called "dual stack," which communicates with an dual stack peer called "host46" using an IPv4 only application while provisioned only with IPv6 network connectivity. 4.1. Originator behavior This subsection describes the originator behavior of "dual stack." The communication is triggered by "dual stack." The application sends a query to its name server to resolve 'A' records for "host46." The resolver snoops the query, then creates another query for 'AAAA' to resolve both 'A' and 'AAAA' records for the host name, and sends it to the server. In this case, both the 'A' and 'AAAA' records are resolved, so the resolver does not need to request the mapper to allocate any IPv4 addresses from its pool, but only to store mapping between received destination's IPv4 and IPv6 addresses. In this case of communication with an dual-stack host, the 'A' record is also resolved and the resolver can return it to the application as is. The application sends an IPv4 packet to "host46." The IPv4 packet reaches the translator. The translator tries to translate the IPv4 packet into an IPv6 packet but does not know how to translate the IPv4 destination address and the IPv4 source address. So the translator requests the mapper to provide mapping entries for them. The mapper checks its mapping table and finds entries for each of them, and then returns the IPv6 destination address and the IPv6 source address to the translator. NOTE: The mapper will register its own IPv4 address and IPv6 address into the table beforehand. See subsection 2.3. The translator translates the IPv4 packet into an IPv6 packet then fragments the IPv6 packet if necessary and sends it to an IPv6 network. The IPv6 packet reaches "host46." Then "host46" sends a new IPv6 packet to "dual stack." Huang, et al. Expires August 21, 2010 [Page 15] Internet-Draft Dual Stack Hosts using BIS February 2010 The IPv6 packet reaches the translator in "dual stack." The translator gets mapping entries for the IPv6 destination address and the IPv6 source address from the mapper in the same way as before. Then the translator translates the IPv6 packet into an IPv4 packet and tosses it up to the application. The following diagram illustrates the action described above: "dual stack" "host46" IPv4 TCP/ extension address translator IPv6 appli- IPv4 name mapper cation resolver | | | | | | | <> | | | | | | | | | |------|----->| Query of 'A' records for "host46". | Name | | | | | | | Server | | |---------|-------|-----------|---------|--->| | | | Query of 'A' records and 'AAAA' for "host46" | | | | | | | | | | |<--------|-------|-----------|---------|----| | | | Reply with 'A' and 'AAAA' records. | | | | | | | | | | |<> | | | | | | | | | |-------->|Request mapping of received IPv4 address | | | |corresponding to the received IPv6 address. | | | | | | | |<-----|------| Reply with the 'A' record. | | | | | | | | | Figure 7: Action of the originator (1/2) Huang, et al. Expires August 21, 2010 [Page 16] Internet-Draft Dual Stack Hosts using BIS February 2010 "dual stack" "host46" IPv4 TCP/ extension address translator IPv6 appli- IPv4 name mapper cation resolver | | | | | | | <>| | | | | | | | | | |======|=======|=========|======>| An IPv4 packet. | | | | | | | | | | | |<------| Request IPv6 addresses | | | | | corresponding to the IPv4 | | | | | addresses. | | | | | | | | | | | |------>| Reply with the IPv6| | | | | | addresses. | | | | | | | | | | | | |<> | | | | | | | | | |An IPv6 packet. |===========|========>| | | | | | | | | | | | <> | | | | | | | | | | |An IPv6 packet. |<==========|=========| | | | | | | | | | | | |<> | | | | | | | |<=====|=======|=========|=======| An IPv4 packet. | | | | | | | | Figure 8: Action of the originator (2/2) 4.2. Recipient behavior The recipient behaviour is exactly the same as in 3.2. Huang, et al. Expires August 21, 2010 [Page 17] Internet-Draft Dual Stack Hosts using BIS February 2010 5. Action Examples -- IPv4 only network and IPv4 only peer This section describes action of the proposed dual stack host called "dual stack," which communicates with an IPv4 peer called "host4" using an IPv6 application. 5.1. Originator behavior This subsection describes the originator behavior of "dual stack." The communication is triggered by "dual stack." The application sends a query to its name server to resolve 'AAAA' records for "host4." The resolver snoops the query, then creates another query for 'A' to resolve both 'A' and 'AAAA' records for the host name, and sends it to the server. In this case, only the 'A' record is resolved, so the resolver requests the mapper to assign an IPv6 address corresponding to the IPv4 address. NOTE: In the case of communication with a dual-stack host, the 'AAAA' record is also resolved and then the resolver returns it to the application as is. The mapper will create mapping between the IPv4 and IPv6 addresses similarly as in in 4.1. The mapper concatenates IPv6 WKP with the resolved IPv4 address and returns it to the resolver. The resolver creates the 'AAAA' record for the assigned IPv6 address and returns it to the application. NOTE: See subsection 6.3 about the influence on other hosts caused by an IPv6 address assigned here. The application sends an IPv6 packet to "host4." The IPv6 packet reaches the translator. The translator tries to translate the IPv6 packet into an IPv4 packet but does not know how to translate the IPv6 destination address and the IPv6 source address. So the translator requests the mapper to provide mapping entries for them. The mapper checks its mapping table and finds entries for each of them, and then returns the IPv4 destination address and the IPv4 source address to the translator. NOTE: The mapper will register its own IPv4 address and IPv6 address into the table beforehand. See subsection 2.3. Huang, et al. Expires August 21, 2010 [Page 18] Internet-Draft Dual Stack Hosts using BIS February 2010 The translator translates the IPv6 packet into an IPv4 packet and sends it to an IPv4 network. The IPv4 packet reaches "host4." Then "host4" sends a new IPv4 packet to "dual stack." The IPv4 packet reaches the translator in "dual stack." The translator gets mapping entries for the IPv4 destination address and the IPv4 source address from the mapper in the same way as before. Then the translator translates the IPv4 packet into an IPv6 packet and tosses it up to the application. The following diagram illustrates the action described above: "dual stack" "host4" IPv6 TCP/ extension address translator IPv4 appli- IPv6 name mapper cation resolver | | | | | | | <> | | | | | | | | | |------|------>| Query of 'AAAA' records for "host4". | Name | | | | | | | Server | | |---------|-------|-----------|---------|--->| | | | Query of 'A' records and 'AAAA' for "host4" | | | | | | | | | | |<--------|-------|-----------|---------|----| | | | Reply only with 'A' record. | | | | | | | | | | |<> | | | | | | | | | | |-------->| Request one IPv6 address | | | | | corresponding to the IPv4 address. | | | | | | | | | | |<> | | | | | | | | | | |<--------| Reply with the IPv6 address. | | | | | | | | | |<> | | | | | | | |<-----|-------|Reply with the 'AAAAA' record| | | | | | | | | Figure 9: Action of the originator (1/2) Huang, et al. Expires August 21, 2010 [Page 19] Internet-Draft Dual Stack Hosts using BIS February 2010 "dual stack" "host4" IPv6 TCP/ extension address translator IPv4 appli- IPv6 name mapper cation resolver | | | | | | | <>| | | | | | | | | | |======|=======|=========|======>| An IPv6 packet. | | | | | | | | | | | |<------| Request IPv4 addresses | | | | | corresponding to the IPv6 | | | | | addresses. | | | | | | | | | | | |------>| Reply with the IPv4| | | | | | addresses. | | | | | | | | | | | | |<> | | | | | | | | | |An IPv4 packet. |===========|========>| | | | | | | | | | | | <> | | | | | | | | | | |An IPv4 packet. |<==========|=========| | | | | | | | | | | | |<> | | | | | | | |<=====|=======|=========|=======| An IPv6 packet. | | | | | | | | Figure 10: Action of the originator (2/2) 5.2. Recipient behavior This subsection describes the recipient behavior of "dual stack." The communication is triggered by "host4." "host4" resolves the 'A' record for "dual stack" through its name server, and then sends an IPv4 packet to the IPv4 address. The IPv4 packet reaches the translator in "dual stack." The translator tries to translate the IPv4 packet into an IPv6 packet but does not know how to translate the IPv4 destination address and the IPv4 source address. So the translator requests the mapper to provide mapping entries for them. The mapper checks its mapping table with each of them and finds a Huang, et al. Expires August 21, 2010 [Page 20] Internet-Draft Dual Stack Hosts using BIS February 2010 mapping entry for the IPv4 destination address. NOTE: The mapper will register its own IPv4 address and IPv6 address into the table beforehand. See subsection 2.3. But there is not a mapping entry for the IPv4 source address, so the mapper concatenates IPv6 WKP with the IPv4 source address and then returns the IPv6 destination address and the IPv6 source address to the translator. NOTE: See subsection 6.3 about the influence on other hosts caused by an IPv6 address assigned here. The translator translates the IPv4 packet into an IPv6 packet and tosses it up to the application. The application sends a new IPv6 packet to "host4." The following behavior is similar as described in subsection 3.1. The following diagram illustrates the action described above: Huang, et al. Expires August 21, 2010 [Page 21] Internet-Draft Dual Stack Hosts using BIS February 2010 "dual stack" "host4" IPv6 TCP/ extension address translator IPv4 appli- IPv6 name mapper cation resolver | | | | | | | <> | | | | | | | | | | | | |An IPv4 packet. |<==========|=========| | | | | | | | | | | |<------| Request IPv6 addresses | | | | | corresponding to the IPv4 | | | | | addresses. | | | | | | | | | | | |------>| Reply with the IPv6| | | | | | addresses. | | | | | | | | | | | | |<> | | | | | | | |<=====|=======|=========|=======| An IPv6 packet. | | | | | | | | <> | | | | | | | | | |======|=======|=========|======>| An IPv6 packet. | | | | | | | | | | | | |<> | | | | | | | | | |An IPv4 packet. |===========|========>| | | | | | | | Figure 11: Action of the recipient Huang, et al. Expires August 21, 2010 [Page 22] Internet-Draft Dual Stack Hosts using BIS February 2010 6. Considerations This section considers some issues of the proposed dual stack hosts. 6.1. IP conversion In common with NAT, IP protocol translation has to translate IP addresses embedded in application layer protocols, such as FTP. Translation of all such applications is a difficult problem. 6.2. IPv4 or IPv6 Address Pool and Mapping Table The address pool consists of the unassigned IPv4 addresses or internal IPv6 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 or IPv6 applications to communicate with IPv4 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. 6.3. Internally Assigned IPv4 or IPv6 Addresses The IPv4 addresses, which are internally assigned to IPv6 target hosts out of the pool, are the unassigned IPv4 addresses (e.g., 0.0.0.1 ~ 0.255.255.255). There is no potential collision with another use of the private address space when the IPv4 address flows out from the host. The IPv6 addresses, which are internally assigned to IPv4 target hosts out of the pool, are the special IPv6 addresses (It need IANA's consideration). There is no potential collision with another use of thosee address space when the IPv6 address flows out from the host. Huang, et al. Expires August 21, 2010 [Page 23] Internet-Draft Dual Stack Hosts using BIS February 2010 7. Applicability and Limitations This section considers applicability and limitations of the proposed dual stack hosts. 7.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. 7.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 August 21, 2010 [Page 24] Internet-Draft Dual Stack Hosts using BIS February 2010 8. ALG related BIA 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 like [PNAT-ALG]. Huang, et al. Expires August 21, 2010 [Page 25] Internet-Draft Dual Stack Hosts using BIS February 2010 9. 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. Huang, et al. Expires August 21, 2010 [Page 26] Internet-Draft Dual Stack Hosts using BIS February 2010 10. Security Considerations This section considers security of the proposed dual stack hosts. The hosts can utilize the security of all layers like ordinary IPv4 communication when they communicate with IPv4 hosts using IPv4 applications via the mechanism. Likewise they can utilize the security of all layers like ordinary IPv6 communication when they communicate with IPv6 hosts using IPv6 applications via the complete IPv6 stack. However, unfortunately, they can not utilize the security above network layer when they communicate with IPv6 hosts using IPv4 applications via the mechanism. The reason is that when the protocol data with which IP addresses are embedded is encrypted, or when the protocol data is encrypted using IP addresses as keys, it is impossible for the mechanism to translate the IPv4 data into IPv6 and vice versa. Therefore it is highly desirable to upgrade to the applications modified into IPv6 for utilizing the security at communication with IPv6 hosts. Huang, et al. Expires August 21, 2010 [Page 27] Internet-Draft Dual Stack Hosts using BIS February 2010 11. Normative References [ADDRFORMAT] Huitema, C., "IPv6 Addressing of IPv4/IPv6 Translators", draft-ietf-behave-address-format-00 (work in progress), Aug 2009. [DNS64] Bagnulo, M., "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-dns64-00 (work in progress), July 2009. [NAT64] Bagnulo, M., "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-01 (work in progress), July. 2009. [PNAT] Huang, Bill., "Prefix NAT: Host based IPv6 translation", draft-huang-pnat-host-ipv6-03 (work in progress). [PNAT-ALG] Wing, D., "Concerns with IPv4 Applications Accessing IPv6 Servers (NAT46)", draft-wing-behave-v4app-v6server-01 (work in progress), February 2010. [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 August 21, 2010 [Page 28] Internet-Draft Dual Stack Hosts using BIS February 2010 Appendix A. Acknowledgements The authors gratefully acknowledge the many helpful advice from Dan Wing and Dave Thaler for intiating this work, thanks mailing list discussion from Mohamed Boucadair, Yiu L. Lee, James Woodyatt, Lorenzo Colitti, Qibo Niu, Lin Xiao, and Pierrick Seite. Contributions from Gang Chen, Bo Zhou, Dapeng Liu,Hong Liu, Tao Sun et al. in the development of this document. Advice from Dan Wing, Dave Thaler and Magnus Westerlund are greatly appreciated Huang, et al. Expires August 21, 2010 [Page 29] Internet-Draft Dual Stack Hosts using BIS February 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 August 21, 2010 [Page 30]