Behave B. Huang Internet-Draft H. Deng Obsoletes: 2767 (if approved) China Mobile Intended status: Experimental T. Savolainen Expires: April 21, 2010 Nokia October 18, 2009 Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS) draft-huang-behave-rfc2767bis-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 April 21, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Huang, et al. Expires April 21, 2010 [Page 1] RFC 2767bis Dual Stack Hosts using BIS September 2009 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 same 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 3. Supporting Well Known Prefix Huang, et al. Expires April 21, 2010 [Page 2] RFC 2767bis Dual Stack Hosts using BIS September 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Translator . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Extension Name Resolver (ENR) . . . . . . . . . . . . . . . 6 2.3 Address mapper . . . . . . . . . . . . . . . . . . . . . . . 7 3. Action Examples -- dual stack network and IPv6 only peer . . . . 9 3.1 Originator behavior . . . . . . . . . . . . . . . . . . . . 9 3.2 Recipient behavior . . . . . . . . . . . . . . . . . . . . 12 4. Action Examples -- IPv6 only network and dual-stack peer . . . 14 4.1 Originator behavior . . . . . . . . . . . . . . . . . . . 14 4.2 Recipient behavior . . . . . . . . . . . . . . . . . . . . 18 5. Action Examples -- IPv4 only network and IPv4 only peer . . . 18 5.1 Originator behavior . . . . . . . . . . . . . . . . . . . 18 5.2 Recipient behavior . . . . . . . . . . . . . . . . . . . . 22 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1 IP conversion . . . . . . . . . . . . . . . . . . . . . . 24 6.2 IPv4 address pool and mapping table . . . . . . . . . . . 24 6.3 Internally assigned IPv4 addresses . . . . . . . . . . . . 25 6.4 Well Known Prefix Support . . . . . . . . . . . . . . . . 25 7. Applicability and Limitations . . . . . . . . . . . . . . . . 25 7.1 Applicability . . . . . . . . . . . . . . . . . . . . . . 25 7.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction RFC2767 [RFC2767] stated that there are few applications for IPv6 [IPV6] as compared with IPv4 [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. RFC2767 proposed a mechanism of dual stack hosts using the technique called "Bump-in-the-Stack" [BUMP] 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- Huang, et al. Expires April 21, 2010 [Page 3] RFC 2767bis Dual Stack Hosts using BIS September 2009 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. The obvious scenario where a destination peer is not reachable with the address family a host is provisioned with, but supports same address family application is using, is not covered by this document, as that requires additional network based protocol translation solution - i.e. double translation. However, the BIS technology can complement network based protocol translation such as [NAT64] and [PNAT]. Moreover, since the translation is automatically carried out with 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 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 memo uses the words defined in [IPV4], [IPV6], and [TRANS-MECH]. Huang, et al. Expires April 21, 2010 [Page 4] RFC 2767bis Dual Stack Hosts using BIS September 2009 2. Components Dual stack hosts defined in RFC4213 [TRANS-MECH] 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 Huang, et al. Expires April 21, 2010 [Page 5] RFC 2767bis Dual Stack Hosts using BIS September 2009 2.1 Translator It translates IPv4 into IPv6 and vice versa using the IP conversion mechanism defined in [SIIT] and [SIIT-NEW]. 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. When receiving IPv6 packets from IPv6 applications, 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 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. Huang, et al. Expires April 21, 2010 [Page 6] RFC 2767bis Dual Stack Hosts using BIS September 2009 Application | Network | ENR behaviour query | response | ------------+----------+--------------------- A | A | A | AAAA | AAAA | AAAA | AAAA | A | Table 1 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 [RFC1918]. 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 well known prefix (WKP) 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)): Huang, et al. Expires April 21, 2010 [Page 7] RFC 2767bis Dual Stack Hosts using BIS September 2009 Mapping table | Access link | Peer | Created entry for | type | support | address mapping -------------------+-------------+--------------------------------------- (1) real IPv4 | IPv4 or DS | v4 | (2) real IPv6 | IPv6 or DS | v6 | (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 Table 2. 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). (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 Huang, et al. Expires April 21, 2010 [Page 8] RFC 2767bis Dual Stack Hosts using BIS September 2009 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. 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. Huang, et al. Expires April 21, 2010 [Page 9] RFC 2767bis Dual Stack Hosts using BIS September 2009 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 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. Huang, et al. Expires April 21, 2010 [Page 10] RFC 2767bis Dual Stack Hosts using BIS September 2009 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 2 Action of the originator (1/2) Huang, et al. Expires April 21, 2010 [Page 11] RFC 2767bis Dual Stack Hosts using BIS September 2009 "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 2 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. Huang, et al. Expires April 21, 2010 [Page 12] RFC 2767bis Dual Stack Hosts using BIS September 2009 The mapper checks its mapping table with each of them and finds a 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. Huang, et al. Expires April 21, 2010 [Page 13] RFC 2767bis Dual Stack Hosts using BIS September 2009 The following diagram illustrates the action described above: "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 3 Action of the recipient 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." Huang, et al. Expires April 21, 2010 [Page 14] RFC 2767bis Dual Stack Hosts using BIS September 2009 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. Huang, et al. Expires April 21, 2010 [Page 15] RFC 2767bis Dual Stack Hosts using BIS September 2009 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." 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. Huang, et al. Expires April 21, 2010 [Page 16] RFC 2767bis Dual Stack Hosts using BIS September 2009 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 4 Action of the originator (1/2) Huang, et al. Expires April 21, 2010 [Page 17] RFC 2767bis Dual Stack Hosts using BIS September 2009 "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 4 Action of the originator (2/2) 4.2 Recipient behavior The recipient behaviour is exactly the same as in 3.2. 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." Huang, et al. Expires April 21, 2010 [Page 18] RFC 2767bis Dual Stack Hosts using BIS September 2009 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. Huang, et al. Expires April 21, 2010 [Page 19] RFC 2767bis Dual Stack Hosts using BIS September 2009 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. 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. Huang, et al. Expires April 21, 2010 [Page 20] RFC 2767bis Dual Stack Hosts using BIS September 2009 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 6 Action of the originator (1/2) Huang, et al. Expires April 21, 2010 [Page 21] RFC 2767bis Dual Stack Hosts using BIS September 2009 "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 6 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. Huang, et al. Expires April 21, 2010 [Page 22] RFC 2767bis Dual Stack Hosts using BIS September 2009 The mapper checks its mapping table with each of them and finds a 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. Huang, et al. Expires April 21, 2010 [Page 23] RFC 2767bis Dual Stack Hosts using BIS September 2009 The following diagram illustrates the action described above: "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 7 Action of the recipient 6. Considerations This section considers some issues of the proposed dual stack hosts. 6.1 IP conversion In common with NAT [RFC3022], IP protocol translation has to translate IP addresses embedded in application layer protocols, such as FTP [RFC959]. Translation of all such applications is a difficult problem. 6.2 IPv4 address pool and mapping table Huang, et al. Expires April 21, 2010 [Page 24] RFC 2767bis Dual Stack Hosts using BIS September 2009 The pool, for example, consists of private addresses [RFC1918]. So a large address space can be used for the spool. Nonetheless, IPv4 addresses in the spool will be exhausted and cannot be assigned to IPv6 target hosts, if the host communicates with a great number of other IPv6 hosts and the mapper never frees entries registered into the mapping table once. To solve the problem, for example, it is desirable for the mapper to free the oldest entry in the mapping table and re-use the IPv4 address for creating a new entry. 6.3 Internally assigned 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. 6.4 Well Known Prefix Support The address mapper shall use the same WKP as will be allocated by IETF/IANA for [ADDRFORMAT]. 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 lack 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. Note that BIS can also work in conjunction with a complete IPv6 stack. People can communicate with both IPv4 hosts and IPv6 hosts using IPv4 applications via the mechanism, and can also communicate with IPv6 hosts using IPv6 applications via the complete IPv6 stack. Furthermore, as protocol translation is supported also from IPv6 to IPv4, application developers can focus on implementing only IPv6 support. 7.2 Limitations Huang, et al. Expires April 21, 2010 [Page 25] RFC 2767bis Dual Stack Hosts using BIS September 2009 The mechanism is valid only for unicast communication, but invalid for multicast communication. Multicast communication needs another mechanism. 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. The BIS does not support the scenario where access network supports only the different address family to what both an application and related server support. In such a case double translation is required. The BIS can be used as component in such as setup. Huang, et al. Expires April 21, 2010 [Page 26] RFC 2767bis Dual Stack Hosts using BIS September 2009 In common with NAT [RFC3022], IP conversion needs to translate IP addresses embedded in application layer protocols, which are typically found in FTP [RFC959]. So it is hard to translate all such applications completely. However, this limitation is common for all address and protocol translators. It may be impossible, without transport layer encapsulation, for the hosts using BIS to utilize the security above network layer, since the data may carry IP addresses. Finally, BIS does not work well with secure DNS if only the extension name resolver is used. If the host's DNS resolver is updated, then also DNSSEC can work. 8. 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. 9. References [SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000. [SIIT-NEW] Li, X., Bao, C., Baker, F., "IP/ICMP Translation Algorithm", draft-ietf-behave-v6v4-xlate-01, September 2009, work-in-progress [IPV4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. Huang, et al. Expires April 21, 2010 [Page 27] RFC 2767bis Dual Stack Hosts using BIS September 2009 [RFC3022] Srisuresh, P., Egevang, K., "Traditional IP Network Address Translator (Traditional NAT)", RFC3022, January 2001. [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [TRANS-MECH] E. Nordmark and Gilligan, R., "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [BUMP] D.A. Wagner and S.M. Bellovin, "A Bump in the Stack Encryptor for MS-DOS Systems", The 1996 Symposium on Network and Distributed Systems Security (SNDSS'96) Proceedings. [NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC2767] Tsuchiya, K., Higuchi, H. and Atarashi, Y., "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000. [DNS64] Bagnulo, M., Sullivan, A., Matthews, P., van Beijnum, I., "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", draft- ietf-behave-dns64-00, July 2009, work-in-progress [ADDRFORMAT] Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., Li, X., "IPv6 Addressing of IPv4/IPv6 Translators", draft- ietf-behave-address-format-00, August 2009, work-in- progress [NAT64] Bagnulo, M., Matthews, P., van Beijnum, I., "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate- stateful-01, July 2009, work-in-progress [PNAT] Huang, B., Deng, H., "Prefix NAT: Host based IPv6 translation", draft-huang-pnat-host-ipv6-01, July 2009, work-in-progress Huang, et al. Expires April 21, 2010 [Page 28] RFC 2767bis Dual Stack Hosts using BIS September 2009 10. 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. 11. 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 April 21, 2010 [Page 29]