Network Working Group B. Huang Internet-Draft H. Deng Intended status: Standards Track China Mobile Expires: August 23, 2010 February 19, 2010 Prefix NAT: Host based IPv6 translation draft-huang-behave-pnat-01 Abstract IPv4 migrating to IPv6 is a network layer's issue, it is not easy to mandate all the applications in the host to change in the first place, the network layer may have to have a solution to support the conventional IPv4 appliations during the IPv6 migration such as in the dual stack or IPv6 only network, especially when multiple applications need to be supported. This document describes a mechanism for providing a host-based IPv6 translation technology which could guarantee IPv4 application backward compatibility. Applications need not necessarily to understand what the network connection and the destination's IP family type are. A well-known prefix could be used when the destination is public IPv4 Internet's address. 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 23, 2010. Copyright Notice Huang & Deng Expires August 23, 2010 [Page 1] Internet-Draft PNAT February 2010 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Network Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Network Scenario of PNAT44COM . . . . . . . . . . . . . . 5 2.2. Network Scenarios of PNAT46COM . . . . . . . . . . . . . . 6 2.3. Network Scenario of PNAT64COM . . . . . . . . . . . . . . 7 2.4. A usage example scenario . . . . . . . . . . . . . . . . . 8 3. The modules of the PNAT host . . . . . . . . . . . . . . . . . 9 4. Operation of PNAT host . . . . . . . . . . . . . . . . . . . . 10 5. Signaling procedure of PNAT44COM . . . . . . . . . . . . . . . 14 5.1. Through PNAT64 GW(464) . . . . . . . . . . . . . . . . . . 14 5.2. Host to Host Direct(4664) . . . . . . . . . . . . . . . . 16 6. Operation of PNAT64 Gateway . . . . . . . . . . . . . . . . . 19 7. ALG related . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 11. Normative References . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Implementation of ENR . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Huang & Deng Expires August 23, 2010 [Page 2] Internet-Draft PNAT February 2010 1. Introduction IETF has several host based translation solutions such as BIA [RFC3338], BIS [RFC2767], and v4-mapped prefix [RFC3493]. BIA and BIS haven't been widely supported and also both of them don't have any description regarding how they could run in IPv6 or IPv4 only network, it also not touch IPv6 application. BIAbis [BIAbis] and BISbis [BISbis] have been proposed to overcome those limitations. [RFC3493] has been implemented by the major OSs, but it don't have the detail description about each different scenarios. This document assume the host which already support host based translation mechanism such as BIAbis or BISbis is called PNAT host for the purpose of simple description. Host based translation itself could work in the IPv6, IPv4 or dual stack network, but it will behave differently when it connect to each different network. Furthermore BIA(BIAbis) could transparently communicate with BIS(BISbis), but they have different implementation requirement. BIA(BIAbis) may need update the network stack of kernel, BIS(BISbis) could be implemented just by updating the driver. Either of them will rely on extended name resolver which could also be implemented in the user plane. Recently, more and more operators have customized their terminal (mobile or fixed) which makes it feasible to do PNAT implementation, sometime it could be the kernel level support like BIA(BIAbis), sometime it could be just user plane like BIS(BISbis). Application-layer developers are not familiar with network-layer technologies, and they are hesitating to migrate their well-developed applications to support IPv6. It's also not easy for them to change their experienced network interface API to support dual stack API. Even many legacy applications might be upgradable to IPv6, but it takes time and may not be cost effective. Considering such real situation, this document proposes a host-based IPv6 translation PNAT(Prefix NAT) solution which extend BIA and BIS solution to guarantee the IPv4 or IPv6 applications in the two hosts communicate with each other directly through host based translation technologies, or by together with a network translator such as NAT64[NAT64]. Huang & Deng Expires August 23, 2010 [Page 3] Internet-Draft PNAT February 2010 2. Network Scenarios PNAT host could run in both dual stack and IPv6-only network, depending on the operator policy, there are four cases that the PNAT host get address assignment from the network 1. Only IPv6 address/prefix is assigned (IPv6 only network) 2. IPv6 address/prefix or public IPv4 address are assigned (Dual Stack Network) 3. IPv6 address/prefix or private IPv4 address are assigned (Dual Stack Network) 4. IPv6 address/prefix or IANA special IPv4 address are assigned (Dual Stack Network) PNAT64 Gateway will be needed when the destination is public IPv4 only address. PNAT host will operate not only based on returned AAAA or A record, but also rely on the upper layer application which IP family it supports. If we put a PNAT host into the network, there will be various kind of network environment (v6 only, dual stack or v4 only) and peer hosts (v4 only, v6 only or dual stack applications). Based on the different IP family type of the peer applications, we define four different scenarios: PNAT44COM, PNAT46COM, PNAT64COM and PNAT66COM. For PNAT66COM, it is just a normal IPv6 to IPv6 communication, so this document will not give the detail description again. Huang & Deng Expires August 23, 2010 [Page 4] Internet-Draft PNAT February 2010 2.1. Network Scenario of PNAT44COM +----------------------------------+ +----------------------+ |IPv6 only network, | | IPv4 Internet | |or dual stack Network | | | | | | | | 6 only 4/6 P | | | | +--------+ +--------+ | | | | | H4 | | H3 | | | | | +--------+ +--------+ | | | | \ | | | | | \ +--------+ | | | | +----+ \ | Access | +-------+ |+----------+ +-----+ | | | H1 |------- | Router |-- | PNAT64|----|| Internet |--| H2 | | | +----+ +--------+ +-------+ |+----------+ +-----+ | | 4/6 P | | | | 4 only | | +--------+ | | +--------+ | | | DNS | | | | DNS | | | +--------+ | | +--------+ | | | | | +----------------------------------+ +----------------------+ Figure 1: Network Scenario of PNAT44COM In Figure 1, H1/H3 are two dual stack PNAT hosts located in an IPv6 site, H2 is an IPv4 host reachable in the IPv4 Internet, H4 is an IPv6 only host which don't implement PNAT, access router will allocate an IPv6 prefix or IPv4 address (if dual stack network) to the H1/H3 host, DNS server is just regular DNS server here which support both AAAA and A records query. The PNAT64 is used for IPv6- IPv4 translation. PNAT44COM communication: In the case of the IPv6 only network, when a v4 application on the H1/H3 needs to communicate with a v4 application on the H2 [PNAT464], or when a v4 applicaition on the H1 needs to communicate with an v4 application on the H3 [PNAT4664]. In the case of the dual stack network, PNAT is assigned an IANA special IPv4 address, that means that there is overlapped IPv4 address between the PNAT hosts, so there will be no A record from PNAT host. If we prefer v6 to v4, then PNAT464 is still a valid scenario as well; and PNAT4664 is also a valid scenario if there are v4 only applications or both side v4 applications haven't been upgraded to v6. This document in the following section will explain the detail of signaling procedure of PNAT464 and PNAT4664. Huang & Deng Expires August 23, 2010 [Page 5] Internet-Draft PNAT February 2010 2.2. Network Scenarios of PNAT46COM +----------------------------------+ |IPv6 only network, | |or dual stack Network | | | | 6 only 4/6 P | | +--------+ +--------+ | | | H4 | | H3 | | | +--------+ +--------+ | | \ | | | \ +--------+ | | +----+ \ | Access | | | | H1 |------- | Router | | | +----+ +--------+ | | 4/6 P | | | +--------+ | | | DNS | | | +--------+ | | | +----------------------------------+ Figure 2: Network Scenario for PNAT46COM PNAT46COM communication: In the case of the IPv6 only network, when a v4 application on the H1 needs to communicate with a dual stack application on the H3 or v6 only application on the H4. In the case of the dual stack network, PNAT is assigned an IANA special IPv4 address, that means that there is overlapped IPv4 address between the PNAT hosts, so when a v4 application on the H1 needs to communicate with a dual stack applications on the H3 or v6 only application on the H4, it also need translation in the PNAT host. BIAbis [BIAbis] and BISbis [BISbis] have already covered the detail description about PNAT46COM. So this document will not explain the detail again. Huang & Deng Expires August 23, 2010 [Page 6] Internet-Draft PNAT February 2010 2.3. Network Scenario of PNAT64COM +----------------------------------+ +----------------------+ |IPv6 only network, | | IPv4 Internet | |or dual stack Network | | | | | | | | 6 only 4/6 P | | | | +--------+ +--------+ | | | | | H4 | | H3 | | | | | +--------+ +--------+ | | | | \ | | | | | \ +--------+ | | | | +----+ \ | Access | +-------+ |+----------+ +-----+ | | | H1 |------- | Router |-- | PNAT64|----|| Internet |--| H2 | | | +----+ +--------+ +-------+ |+----------+ +-----+ | | 4/6 P | | | | 4 only | | +--------+ | | +--------+ | | | DNS | | | | DNS | | | +--------+ | | +--------+ | | | | | +----------------------------------+ +----------------------+ Figure 3: Network Scenario of PNAT64COM PNAT64COM communication: In the case of the IPv6 only network, when a v6 application on the H1 needs to communicate with a v4 application on the H2 or a v4 application on the H3. There are several reasons that v4 applications might not be upgraded such as codec, charging or knowledge limitation et al. In the case of the dual stack network, when a v6 only application on the H1 needs to communicate with a v4 application on the H2 or a v4 application on the H3. BIAbis [BIAbis] and BISbis [BISbis] have already covered the detail description about PNAT64COM within the same network. So this document will not explain the detail again. For the v4 application on the H2, there will be quite similar with NAT64, the difference would be DNS64 will be equal to ENR inside the PNAT host, so NAT64 need not communicate with DNS64, PNAT would be compatible with NAT64. Huang & Deng Expires August 23, 2010 [Page 7] Internet-Draft PNAT February 2010 2.4. A usage example scenario --------------------------- \/ / \ ||LTE / \/ \ || / ||LTE \ || + || -+ +---------+ |+---------+ | || | | AP + GW | ||v4 Server|--| +-------------+ | +---------+ |+---------+ | | Home Router | | eNodeB | | | AAAA [DNS] | | |+---------+ |----| | | ||v6 Server|--| |v4 only app. | | |+---------+ | |v6 only app. | | Y Y Y | | |DS app. | | | | | |+---------+ | +-------------+ | +--+ +--+ +--+ ||DS Server|--| Y | |v4| |v6| |DS| |+---------+ | +--+ | +--+ +--+ +--+ | | |UE4 | UE1 UE2 UE3 | +--+ | +----------------------------------+ Figure 4: Host to host communication In this figure, Home Router has been connected to eNodeB of mobile network by LTE modem. There will be v4 only , v6 only, and dual stack applications on this home router. There are three public mobile nodes: UE1, UE2, UE3 connecting with mobile network based on LTE technology as well. The UE4 stay at home is also connecting with home router based on WiFI. The eNodeB has mobile access point (AP) and is connected with IP GW in the backend. All private or IANA special IPv4 addresses and IPv6 prefixes of Home Router, UE1,UE2, and UE3 have been assigned from GW behind of eNodeB. If UE1/2/3 want to visit the Home Router, the only choice is based on IPv6 other than IPv4, there are various kind of applications existed today, so there will be different network scenarios such as PNAT44COM, PNAT46COM, PNAT64COM and PNAT66COM. Huang & Deng Expires August 23, 2010 [Page 8] Internet-Draft PNAT February 2010 3. The modules of the PNAT host PNAT host could be either enhanced BIA [RFC3338] or BIS [RFC2767] to support multiple scenarios such as IPv6 only and dual stack network. The updated drafts BIAbis [BIAbis] and BISbis [BISbis] have the detail description about three modules inside the PNAT host. Both of them have Extension Name Resolver (ENR) and Address Mapper, additionally BIAbis has a Function Mapper and BISbis has a Translator. IPv4 application in the host isn't aware of network IP family type that it is attached to. It will continue to call IPv4 socket API. PNAT inside the host will help to hide those information from the applicaitons. Huang & Deng Expires August 23, 2010 [Page 9] Internet-Draft PNAT February 2010 4. Operation of PNAT host As the figure 1 depicted, there are various kind of address assignment, network connection and IP families, PNAT will behave based on the collected information. And this make PNAT could support multiple sceanrios simutanesouly, and this is the strong point of PNAT proposal. We assume the network connection will be the same as the address assignment, if there is IPv4 only address assgined to the PNAT host, then the current network connection is IPv4 only network; and if there is IPv6 only adress/prefix assigned to the PNAT host, then the current network connection is IPv6 only network; and if there are both IPv4 (whatever public, private, or faked) and IPv6 address/ prefix assigned, then the current network connection is dual stack network. The implementation of PNAT inside the host could identify that the current application is IPv4, IPv6, or dual stack applications based on DNS socket call intercepted by ENR. ENR is always live even PNAT doesn't do v4v6 or v6v4 translation. It means that normal v4v4 and v6v6 communication can also rely on NER without any mistake. ENR will always intercept the applications calling for DNS resolver. Whatever applications supporting IP family is, ENR will record that DNS call and send both AAAA and A record to the DNS server. PNAT host will use network assigned IPv6 prefix/address as it's source IPv6 address and will use WKP for it's destination IPv6 address if considering compatible with NAT64. Anyhow PNAT could use network assigned IPv6 prefix as well, in that case, it could support public IPv4 address or private IPv4 address, and PNAT64 GW need to understand this IPv6 prefix as well. 0 127 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PREFIX64 | all 0/1 | IPv4 addr | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 5: PNAT Destination IPv6 address PREFIX64 would better be shorter as much as possible, such as 16/24/32 bits. Bit 65 to 96 should be designated to all zero or all one depends on IPv4 address is private or public address. All IP devices between PNAT client and PNAT64 GW should support it or at least know how to route it to PNAT64 GW. Huang & Deng Expires August 23, 2010 [Page 10] Internet-Draft PNAT February 2010 below figure explain how PNAT behave based on the three considerations: Source applicaiton, Network connection and Peer. The abbreviation of the below figure are: S. App. Query = Source Application Query DNS record Type Net. Type = Network Connection Type Peer Type = Peer DNS return value type ENR resp. to App. = ENR response to Application Fun. Map/Trans. = function Mapper / Translator Syn. AAAA = Synthesized AAAA record Mapping A = Mapping A record PNAT type = PNAT44COM / PNAT46COM / PNAT64COM / PNAT66COM PNAT64 need? = PNAT64 Gateway is needed? (Integrate with NAT44) Huang & Deng Expires August 23, 2010 [Page 11] Internet-Draft PNAT February 2010 +---------+------+--------+-----------+---------+------+-------+ | S. App. | Net. | Peer | ENR resp. | Fun. Map| PNAT | PNAT64| | Query | Type | Type | to App. | /Trans. | Type | need? | +---------+------+--------+-----------+---------+------+-------+ | A | v4 | A | A | no need | no | no | | A | v4 | AAAA | --- this case doesn't exist --- | | A | v4 | A/AAAA | A | no need | no | no | | A | v6 | A | A | v4-v6 | 44 | yes | | A | v6 | AAAA | Mapping A | v4-v6 | 46 | no | | A | v6 | A/AAAA | A | v4-v6 | 46 | no | | A | v4v6 | A | A | no need | no | no | | A | v4v6 | AAAA | Mapping A | v4-v6 | 46 | no | | A | v4v6 | A/AAAA | A | no need | no | no | | AAAA | v4 | A | Syn. AAAA | v6-v4 | 64 | no | | AAAA | v4 | AAAA | --- this case doesn't exist --- | | AAAA | v4 | A/AAAA | AAAA | v6-v4 | 64 | no | | AAAA | v6 | A | Syn. AAAA | no need | no | NAT64 | | AAAA | v6 | AAAA | AAAA | no need | no | no | | AAAA | v6 | A/AAAA | AAAA | no need | no | no | | AAAA | v4v6 | A | Syn. AAAA | no need | no | NAT64 | | AAAA | v4v6 | AAAA | AAAA | no need | no | no | | AAAA | v4v6 | A/AAAA | AAAA | no need | no | no | | A/AAAA | v4 | A | A | no need | no | no | | A/AAAA | v4 | AAAA | --- this case doesn't exist --- | | A/AAAA | v4 | A/AAAA | A | no need | no | no | | A/AAAA | v6 | A | Syn. AAAA | no need | no | NAT64 | | A/AAAA | v6 | AAAA | AAAA | no need | no | no | | A/AAAA | v6 | A/AAAA | AAAA | no need | no | no | | A/AAAA | v4v6 | A | A | no need | no | no | | A/AAAA | v4v6 | AAAA | AAAA | no need | no | no | | A/AAAA | v4v6 | A/AAAA | AAAA | no need | no | no | +---------+------+--------+-----------+---------+------+-------+ Figure 6: PNAT Operation based on the source application And if we sort the table based on the network connection: In the scenario of IPv4 only network connection it only need v6-v4 translation; In the scenario of IPv6 only network connection it need support v4-v6 translation, PNAT and NAT64; In the scenario of dual stack network connection, it will only have one case about NAT64; Huang & Deng Expires August 23, 2010 [Page 12] Internet-Draft PNAT February 2010 +---------+------+--------+-----------+---------+------+-------+ | S. App. | Net. | Peer | ENR resp. | Fun. Map| PNAT | PNAT64| | Query | Type | Type | to App. | /Trans. | Type | need? | +---------+------+--------+-----------+---------+------+-------+ | A | v4 | A | A | no need | no | no | | A | v4 | AAAA | --- this case doesn't exist --- | | A | v4 | A/AAAA | A | no need | no | no | | AAAA | v4 | A | Syn. AAAA | v6-v4 | 64 | no | | AAAA | v4 | AAAA | --- this case doesn't exist --- | | AAAA | v4 | A/AAAA | AAAA | v6-v4 | 64 | no | | A/AAAA | v4 | A | A | no need | no | no | | A/AAAA | v4 | AAAA | --- this case doesn't exist --- | | A/AAAA | v4 | A/AAAA | A | no need | no | no | | A | v6 | A | A | v4-v6 | 44 | yes | | A | v6 | AAAA | Mapping A | v4-v6 | 46 | no | | A | v6 | A/AAAA | A | v4-v6 | 46 | no | | AAAA | v6 | A | Syn. AAAA | no need | no | NAT64 | | AAAA | v6 | AAAA | AAAA | no need | no | no | | AAAA | v6 | A/AAAA | AAAA | no need | no | no | | A/AAAA | v6 | A | Syn. AAAA | no need | no | NAT64 | | A/AAAA | v6 | AAAA | AAAA | no need | no | no | | A/AAAA | v6 | A/AAAA | AAAA | no need | no | no | | A | v4v6 | A | A | no need | no | no | | A | v4v6 | AAAA | Mapping A | v4-v6 | 46 | no | | A | v4v6 | A/AAAA | A | no need | no | no | | AAAA | v4v6 | A | Syn. AAAA | no need | no | NAT64 | | AAAA | v4v6 | AAAA | AAAA | no need | no | no | | AAAA | v4v6 | A/AAAA | AAAA | no need | no | no | | A/AAAA | v4v6 | A | A | no need | no | no | | A/AAAA | v4v6 | AAAA | AAAA | no need | no | no | | A/AAAA | v4v6 | A/AAAA | AAAA | no need | no | no | +---------+------+--------+-----------+---------+------+-------+ Figure 7: PNAT Operation based on the network connection Huang & Deng Expires August 23, 2010 [Page 13] Internet-Draft PNAT February 2010 5. Signaling procedure of PNAT44COM Based on the section of network scenarios, PNAT44COM could be divided into two categories: Through PNAT64 GW and Host to Host Direct. The difference of them would be what kind of DNS resolver returned, there will be only A record returned in the case of Through PNAT64 GW, and there will be AAAA or A/AAAA record returned in the case of Host to host communication. The detail signaling procedure will be explained in detail in the below section. 5.1. Through PNAT64 GW(464) The call flow is shown below. The modules of the host have been divided into two parts: v4 Application and PNAT modules; PNAT modules include ENR, Address Mapper, Function Mapper(BIAbis) and Translator (BISbis). And PNAT64 is sitting between two v4 Applications. +-----------------------------------+ |(Host Side) | |v4 Appl [ ENR Address Mapper ]| DNS Access PNAT64 v4 peer |ication [ F. M. /Translator]| Server Router Application +-----------------------------------+ | | Address Request | | | | (0) | --------------------------->| | | | RA/DHCPv6 v6 Prefix+DNS+PNAT64(WKP) | | | (1) | <----------------------------| | | | A | | | | | | (2) |------->| | | | | | | | | | | | | | | send both A/AAAA | | | | (3) | |------------------------>| | | | | A | | | | (4) | |<------------------------| | | | | A | | | | | | (5) |<-------| | | | | | (6) | |----------->| | | | | | | WKP+Dest.IP | | | | | Packet 4 | | | | | (7) |-------------------->| | | | | | | |S:Assigned v6 D: WKP+Dest.IP | | (8) | | |---------------------------->| | (9) | | | | | NAT64 State | (10)| | | | | |----->| (11)| | | | | |<-----| (12)| | |<----------------------------| | | Packet 4 | | | | | (13)|<--------------------| | | | | Huang & Deng Expires August 23, 2010 [Page 14] Internet-Draft PNAT February 2010 Figure 8: Signaling procedure of Through PNAT64 GW(464) (0) The host requests the basic configuration such as IP address and DNS server. (1) The network assigns IPv6 prefix by RS/RA message, and DNS Server address to the host.(The internal IPv4 address used by the application could be either an unused IPv4 address or IANA assigned special IPv4 address like DS-Lite.) This internal IPv4 address could be assigned from network in the dual stack network, or self-generated in the IPv6 only network. For PNAT64 prefix, it could be WKP or even assigned from the network. (2) When IPv4 application would like to start the communication with the peer application, it sends name resolver by invoking gethostbyname call. (3) ENR inside the PNAT host will intercept this call, and create both A and AAA and send to the DNS server. (4) In this scenario, DNS server will only response a A record back. (5) ENR will forward this A record to the v4 application. (6) Meanwhile ENR will notify Address Mapper, Address Mapper will generate an mapping entry about this session: S. address: IANA special v4 address --> Assigned IPv6 address D. address: Destination v4 address(A) --> WKP+v4 address(A) (7) v4 application starts sending IPv4 packet to Function Mapper in the case of BIAbis or Translator in the case of BISbis. (8) Function Mapper or Translator will intercept this and translate the source address to the assigned IPv6 address and the destination address to the WKP+v4 address, then send out the IPv6 packet. (9) NAT64 will translate those IPv6 packet into the IPv4 packet. (10) PNAT64 forwards the IPv4 packet to the peer IPv4 node. (11) The peer IPv4 sends a response IPv4 packet to PNAT64. (12) This packet is received by a PNAT64 which forwards the translated IPv6 packet back to the host based on the source IPv6 address. (13) Function mapper or Translator will intercept those packet, and Huang & Deng Expires August 23, 2010 [Page 15] Internet-Draft PNAT February 2010 translate the source and destination address based on the Address Mapper, then those IPv4 packet is forwarded back to the IPv4 application. 5.2. Host to Host Direct(4664) The call flow is shown below. The modules of the both PNAT host have been divided into two parts: v4 Application and PNAT modules; PNAT modules include ENR, Address Mapper, Function Mapper(BIAbis) and Translator (BISbis). And there will be no PNAT64 sitting between two PNAT hosts. From the source PNAT host side, the communication is the same as PNAT46COM. And the other side is more like PNAT46COM. There are two kind of possibilities for the peer PNAT host side, one is that Peer has only AAAA record, the other is that Peer has both A and AAAA records. PNAT host normally has both IANA assigned special IPv4 address and network assigned IPv6 address, then only AAAA record could be possible. Sometimes PNAT host has been assigned another public IPv4 address as well, then it could support both A and AAAA records. Principally, PNAT can support overlapped IPv4 address but with different AAAA record, normally, it is impossible to advertise IANA assigned IPv4 address for the A record in the Internet. Huang & Deng Expires August 23, 2010 [Page 16] Internet-Draft PNAT February 2010 +-----------------------------------+ +---------------+ |(Host Side) | |(Peer Side) | |v4 Appl [ ENR Address Mapper ]| DNS Access|PNAT v4 peer | |ication [ F. M. /Translator]| Server Router| Application| +-----------------------------------+ +---------------+ | | Address Request | | | | (0) | --------------------------->| | | | RA/DHCPv6 v6 Prefix+DNS | | | (1) | <----------------------------| | | | A | | | | | | (2) |------->| | | | | | | | | | | | | | | send both A/AAAA | | | | (3) | |------------------------>| | | | | AAAA or A/AAAA | | | | (4) | |<------------------------| | | | (5) | |----------->| | | | | | | A<-AAAA | | | | | | A | | | | | | (6) |<-------| | | | | | | Packet 4 | | | | | (7) |-------------------->| | | | | | | | S:Assigned v6 D: v6(AAAA) | | (8) | | |---------------------------->| | (9) | | | | | PNAT | (10)| | | | | |----->| (11)| | | | | |<-----| (12)| | |<----------------------------| | | Packet 4 | | | | | (13)|<--------------------| | | | | Figure 9: Signaling procedure of Host to Host Direct(4664) (0) The host requests the basic configuration such as IP address and DNS server. (1) The network assigns IPv6 prefix by RS/RA message, and DNS Server address to the host.(The IPv4 address used by the application could be either a unused IPv4 address or IANA assigned special IPv4 address like DS-Lite. (2) When IPv4 application would like to start the communication with the peer application, it sends name resolver by invoking gethostbyname call. (3) ENR inside the PNAT host will intercept this call, and create both A and AAA and send to the DNS server. Huang & Deng Expires August 23, 2010 [Page 17] Internet-Draft PNAT February 2010 (4) In this scenario, DNS server will response a AAAA or A/AAAA record back. (5) Meanwhile ENR will communicate with from the Address Mapper, if there is no A record returned, Address Mapper will generate a A record for this session and generate an entry for this session: S. address: IANA special v4 address --> Assigned IPv6 address D. address: Mapped v4 address --> Destination IPv6 address (6) ENR will forward this A record to the v4 application. (7) v4 application starts sending IPv4 packet to Function Mapper in the case of BIAbis or Translator in the case of BISbis. (8) Function Mapper or Translator will intercept this and translate the source address to the assigned IPv6 address and the destination address to the destination IPv6 address, then send out the IPv6 packet. (9) The IPv6 packet will be directly forwarded to the peer PNAT host, PNAT in the peer side will translate those IPv6 packet into the IPv4 packet. (10) PNAT modules in the peer host forwards the IPv4 packet to the peer IPv4 node. (11) The peer IPv4 sends a response IPv4 packet to PNAT modules. (12) This packet is received by a PNAT modules which forwards the translated IPv6 packet back to the host based on the source IPv6 address. (13) Function mapper or Translator will intercept those packet, and translate the source and destination address based on the Address Mapper, then those IPv4 packet is forwarded back to the IPv4 application. Detail received side is the same as updated drafts BIAbis [BIAbis] and BISbis [BISbis]. If the network is IPv6 only, then both side hosts should support PNAT. All the PNAT host will be able to communicate with each other through it's AAAA IPv6 address. and all kinds of applications such as v4 only, v6 only or dual stack inside the PNAT host would be possiblly reachable. Huang & Deng Expires August 23, 2010 [Page 18] Internet-Draft PNAT February 2010 6. Operation of PNAT64 Gateway PNAT64 is compatible with NAT64 if both WKP and network assigned IPv6 prefix are used, but PNAT64 need not communicate with DNS64, PNAT has ENR module inside the host which does similar thing to DNS64. If PNAT use network assigned prefix other than WKP, then when PNAT64 GW receives a IPv6 packet, it will translate the destination address same as the regular NAT64 by remove prefix firstly, After that, PNAT64 will analyze its source address, there are 3 possibilities for the last 32 bit of the source IPv6 address: public IPv4 address, private IPv4 address, or normal IPv6 address. If the 65-96 bit is all zero, and the last 32 bits is a private IPv4 address, then it is the scenario of PNAT44COM, PNAT64 will act as the normal NAT64 procedure. If the 65-96 bit is all one, and the last 32 bits is a public IPv4 address, then it is the scenario of PNAT44COM, PNAT64 will simply get rid of prefix, record the relationship between public IPv4 address and IPv6 prefix, and send out the packet. If the 65-96 bit is neither all zero nor all one, then it is the scenario of PNAT64COM, PNAT64 will act as the normal NAT64 procedure. When PNAT64 receives a DNS IPv6 packet, it will not do DNS ALG, it will only translate IPv6 header to IPv4 header, then forward it to IPv4 DNS server. Huang & Deng Expires August 23, 2010 [Page 19] Internet-Draft PNAT February 2010 7. ALG related In the case of 464 of PNAT44COM, ALG will be the normal 4-4 ALG which is same as ALG for today's NAT44. In the case of 4664 of PNAT44COM, IP address inside the payload is not encouraged for the communication. It is out of scope of this document, and it will be handled in other document like [PNAT-ALG]. In the case of PNAT64COM, ALG will be the same as today's NAT64. Anyhow IP address inside the payload is also not encouraged for the communication. It is out of scope of this document, and it will be handled in other document like [PNAT-ALG]. In the case of PNAT46COM, IP address inside the payload is also not encouraged for the communication, otherwise it will make ALG inside the host. ALG is out of scope of this document, and it will be handled in other document like [PNAT-ALG]. PNAT66COM will operate as the normal v6 to v6 communication, it may not have ALG issue without NAT66 support. PNAT host should only perform a minimum of ALG, especially for Host to Host Direct scenario. Huang & Deng Expires August 23, 2010 [Page 20] Internet-Draft PNAT February 2010 8. Security Considerations It needs to be further identified. Huang & Deng Expires August 23, 2010 [Page 21] Internet-Draft PNAT February 2010 9. IANA Consideration This document makes no requests to IANA. Huang & Deng Expires August 23, 2010 [Page 22] Internet-Draft PNAT February 2010 10. Acknowledgments The author thanks the discussion from Feng Cao, Gang Chen, Dapeng Liu, Bo Zhou, Hong Liu, Tao Sun, Zhen Cao, et al. in the development of this document. The efforts of Teemu Savolainen, Mohamed Boucadair, Yiu L. Lee, James Woodyatt, Lorenzo Colitti, Qibo Niu, Pierrick Seite, Dean Cheng, Suresh Krishnan, 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 & Deng Expires August 23, 2010 [Page 23] Internet-Draft PNAT February 2010 11. Normative References [BIAbis] Huang, Bill., "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", draft-huang-behave-rfc3338bis-01 (work in progress). [BISbis] Huang, Bill., "Dual Stack Hosts using the "Bump-In-the- Stack" Technique (BIS)", draft-huang-behave-rfc2767bis-01 (work in progress). [DS-Lite] Durand, A., "Dual-stack lite broadband deployments post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite-00 (work in progress), March 2009. [NAT64] Bagnulo, M., "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-bagnulo-behave-nat64-03.txt (work in progress), March 2009. [PNAT-ALG] Wing, D., "Concerns with IPv4 Applications Accessing IPv6 Servers (NAT46)", draft-wing-behave-v4app-v6server-01 (work in progress), February 2010. [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 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. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. Huang & Deng Expires August 23, 2010 [Page 24] Internet-Draft PNAT February 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 & Deng Expires August 23, 2010 [Page 25] Internet-Draft PNAT 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 Huang & Deng Expires August 23, 2010 [Page 26]