Network Working Group B. Huang Internet-Draft H. Deng Intended status: Standards Track China Mobile Expires: April 21, 2010 October 18, 2009 Prefix NAT: Host based IPv6 translation draft-huang-behave-pnat-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. This document is subject to BCP 78 and the IETF Trust's Legal Huang & Deng Expires April 21, 2010 [Page 1] Internet-Draft PNAT October 2009 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. Huang & Deng Expires April 21, 2010 [Page 2] Internet-Draft PNAT October 2009 Abstract Host based translation such as BIA, BIS could support conventional IPv4 applications talk with IPv6 applications in the dual stack network, and BIAbis and BISbis propose to extend this two solutions support IPv6 and IPv4 only network which consequently support IPv6 applications as well. This document describes a mechanism called "PNAT" which could 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Network Scenarios . . . . . . . . . . . . . . . . . . . . . . 5 3. Signaling procedure of PNAT44COM . . . . . . . . . . . . . . . 7 3.1. Signaling procedure of PNAT44COM Internet . . . . . . . . 7 3.2. Signaling procedure of PNAT44COM Network . . . . . . . . . 9 4. Signaling procedure of PNAT46COM . . . . . . . . . . . . . . . 11 5. Signaling procedure of PNAT64COM . . . . . . . . . . . . . . . 12 6. Signaling procedure of PNAT66COM Network . . . . . . . . . . . 15 7. Operation of PNAT64 Gateway . . . . . . . . . . . . . . . . . 17 8. Source and Destination address Consideration about PNAT . . . 18 9. Comparision with NAT64 . . . . . . . . . . . . . . . . . . . . 19 10. Roaming consideration of PNAT . . . . . . . . . . . . . . . . 20 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 12. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 14. Normative References . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Huang & Deng Expires April 21, 2010 [Page 3] Internet-Draft PNAT October 2009 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. One advantage of BIAbis or BISbis is that the developers could write IPv6 only applications because BIAbis BISbis would ensure the communication to IPv4. 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 April 21, 2010 [Page 4] Internet-Draft PNAT October 2009 2. Network Scenarios The network scenario PNAT going to support is shown in the figure 1: PNAT host is a dual stack host and which may have IPv4 or IPv6 application running over it, the network which it connect could be IPv4 only, IPv6 only, or dual stack network. PNAT host has implemented at least one host based translation mechanism like BIAbis or BISbis. This PNAT host (H1) need to communicate with the following node: H1 -- PNAT host. H2 -- IPv4 host which is running IPv4 application. H3 -- PNAT host. H4 -- IPv6 only host which don't implement PNAT. +----------------------------------+ +----------------------+ |IPv6 only network, | | IPv4 Internet | |or IPv4 only Network, | | | |or dual stack Network | | | | 6 only 4/6 P | | | | +--------+ +--------+ | | | | | H4 | | H3 | | | | | +--------+ +--------+ | | | | \ | | | | | \ +--------+ | | | | +----+ \ | Access | +-------+ |+----------+ +-----+ | | | H1 |------- | Router |-- | PNAT64|----|| Internet |--| H2 | | | +----+ +--------+ +-------+ |+----------+ +-----+ | | 4/6 P | | | | 4 only | | +--------+ | | +--------+ | | | DNSv4v6| | | | DNSv4 | | | +--------+ | | +--------+ | | AAAA/A | | A/AAAA | +----------------------------------+ +----------------------+ Figure 1: Network Scenario In Figure 1, DNSv4v6 is a dual stack DNS server which has both AAAA and A records, and DNSv4 locates in the IPv4 Internet. The PNAT64 is used for IPv4 Internet connection. There are four major scenarios PNAT would like to support simultaneously illustrated below, here network means two host stay in Huang & Deng Expires April 21, 2010 [Page 5] Internet-Draft PNAT October 2009 the same network, Internet means two host stay in the different network: PNAT44COM communication -- When a v4 application on the H1 needs to communicate with a v4 application on H2(Internet) or H3(network). H1 stay in the IPv6 only network. PNAT46COM communication -- When a v4 application on H1 needs to communicate with a v6 application on H3(network) or H4(network). H1 stay in the IPv6 only or dual stack network. PNAT64COM communication -- When a v6 application on H1 needs to communicate with a v4 application on H2(Internet) or H3(network). H1 stay in the IPv4 only, IPv6 only or dual stack network. PNAT66COM communication -- When a v6 application on H1 needs to communicate with a v6 application on H3(network) or H4(network). H1 stay in the IPv4 only network. There are other scenarios which BIA, BIS, BIAbis, and BISbis have already supported such as PNAT44COM communication in the IPv4 only and dual stack network, PNAT66COM communication in the IPv6 only and dual stack network. There are also many dual-stack appliations, in this case it could directly communicate with IPv4 and IPv6 only peers. Huang & Deng Expires April 21, 2010 [Page 6] Internet-Draft PNAT October 2009 3. Signaling procedure of PNAT44COM The scenario of the PNAT44COM could have two types: PNAT44COM Internet -- One host stay in the network, the peer host stay in the Internet. PNAT44COM Network -- Both two hosts stay in the same network. 3.1. Signaling procedure of PNAT44COM Internet Because the peer host stay in the Internet, so it need NAT64 for translating back to the IPv4, The call flow of the PNAT44COM Internet is shown below. +----------------------+ +-------------+ | (Host Side) | | (Peer Side) | | IPv4 Appl [ PNAT ] | DNS(4/6) Access PNAT64 | IPv4 Appl | | ication [Module] | Server Router GW | ication | +----------------------+ +-------------+ | | Address Request | | | (1) | |----------------------->| | | | DHCPv6[v6 Prefix + DNS]| | | (2) | |<-----------------------| | | | DNS4[A] | | | | | (3) |--------->| | | | | | |send A and AAAA | | | (4) | |----------->| | | | | |return A or AAAA | | | (5) | |<-----------| | | | | DNS4[A] | | | | | (6) |<---------| | | | | |Packet | | | | | (7) |--------->| | | | | | |D:(WKP/PNAT64 prefix+Dest.IPv4 | | (8) | |-------------------------------->| | (9) | | | | |--------->| (10) | | | | |<---------| (11) | |<--------------------------------| | |Packet | | | | | (12) |<---------| | | | | Figure 2: Signaling procedure of PNAT44COM Internet (1) The host requests the basic configuration such as IP address and DNS server. (2) The network access router assigns both IPv6 prefix and DNS Server Huang & Deng Expires April 21, 2010 [Page 7] Internet-Draft PNAT October 2009 address to the host, sometime PNAT64 prefix will also be assigned to the host. (3) IPv4 application would like to start the communication with the peer application, it sends name resolver by invoking gethostbyname call. (4) After the PNAT received this A record query, the PNAT module will make both A and AAAA record, then send this resolver request to the dual stack DNS server which has been detail described in the BIAbis and BISbis document. (5) The host may get A or AAAA record resolver result back from dual stack DNS server. (6) PNAT module will process this returned record according to the BIAbis or BISbis document, then send DNS4 query resolver back to the IPv4 application. (7) IPv4 application starts sending packet. (8) PNAT module processes it accordingly based on the BIAbis and BISbis document, then forwards them to the PNAT64 GW, PNAT module create the destination address by combine either WKP or PNAT64 prefix together with 32 bit IPv4 address. The source address will be network assigned IPv6 prefix concatenate with 32 bit all 1 or 0 and IPv4 address. IPv4 address could be any pre-defined IPv4 address for private IPv4 address, then 65-96 bit will be set to all 0, and this IPv4 address could be public IPv4 address if the operator could assign this address to the host, then 65-96 bit will be all 1. (9) Depending on the destination, in the case of PNAT44COM Internet, the host will translate the source IPv4 address to a network-assigned IPv6 prefix+32 bit all 0 + IPv4 private address or IPv6 prefix+32 bit all 1 + IPv4 public address, then forwards the IPv6 packet to PNAT64. PNAT64 will process the packet differently, if the IPv4 address is the private address. It will do like normal NAT64, but if the host gets a public IPv4 address, it will get rid of prefix only. This mechanism still is a stateful work, because PNAT64 has to record which IPv4 public address is matching to which IPv6 prefix. (In this case, ALG is not needed. But if it is private IPv4 address, then an ALG is still needed.) PNAT64 forwards the IPv4 packet to the peer IPv4 node. (10) The peer IPv4 sends a response IPv4 packet to PNAT64. (11) This packet is received by a PNAT64 which forwards the translated IPv6 packet back to the host based on the network-assigned Huang & Deng Expires April 21, 2010 [Page 8] Internet-Draft PNAT October 2009 IPv6 prefix, socket translation module translates IPv6 packet to IPv4 packet. (12) The IPv4 packet is forwarded back to the IPv4 application. 3.2. Signaling procedure of PNAT44COM Network Because the peer host stay in the Internet, so it need NAT64 for translating back to the IPv4, The call flow of the PNAT44COM Network is shown below. +----------------------+ +-------------+ | (Host Side) | | (Peer Side) | | IPv4 Appl [ PNAT ] | DNS(4/6) Access | IPv4 Appl | | ication [Module] | Server Router | ication | +----------------------+ +-------------+ | | Address Request | | (1) | |----------------------->| | | DHCPv6[v6 Prefix + DNS]| | (2) | |<-----------------------| | | DNS4[A] | | | | (3) |--------->| | | | | |send A and AAAA | | (4) | |----------->| | | | |return A andAAAA | | (5) | |<-----------| | | | DNS4[A] | | | | (6) |<---------| | | | |Packet | | | | (7) |--------->| | | | | |S: D: AAAA IPv6 address | | (8) | |----------------------------------->| | | | | | (9) | |<-----------------------------------| |Packet | | | | (10) |<---------| | | | Figure 3: Signaling procedure of PNAT44COM Network (1) The host requests the basic configuration such as IP address and DNS server. (2) The network access router assigns both IPv6 prefix and DNS Server address to the host. (3) IPv4 application would like to start the communication with the peer application, it sends name resolver by invoking gethostbyname call. Huang & Deng Expires April 21, 2010 [Page 9] Internet-Draft PNAT October 2009 (4) After the PNAT received this A record query, the PNAT module will make both A and AAAA record, then send this resolver request to the dual stack DNS server which has been detail described in the BIAbis and BISbis document. (5) The host may get A or AAAA record resolver result back from dual stack DNS server. (6) PNAT module will process this record according to the BIAbis or BISbis document, then send DNS4 query resolver back to the IPv4 application. (7) IPv4 application starts sending packet. (8) PNAT module processes it accordingly based on the BIAbis and BISbis document, then forwards them to the PNAT64 GW. (9) The peer IPv4 sends a response IPv4 packet to PNAT module. (10) The IPv4 packet is forwarded back to the IPv4 application. Huang & Deng Expires April 21, 2010 [Page 10] Internet-Draft PNAT October 2009 4. Signaling procedure of PNAT46COM Because the H1 either in the IPv6 only or dual stack network, it's IPv4 application may need to communicate with IPv6 application in the H3 or H4. Both these two cases have been covered by BIAbis or BISbis document. Huang & Deng Expires April 21, 2010 [Page 11] Internet-Draft PNAT October 2009 5. Signaling procedure of PNAT64COM When H1 stay in the IPv4 only or dual stack network, after the PNAT module received an A record, it will translate IPv4 into IPv4, then send them out as the regular BIAbis and BISbis does. When H1 stay in the IPv6 only network, there are two cases which H1 need to talk: H2 stay in IPv4 Internet and H3 stay in the IPv6 only network. In the case of H3 stay in the IPv6 only network, if the PNAT module in H1 received only an A record, this type of communication is not validate, it should report the wrong message to the IPv4 application. Only if the PNAT module receive both A and AAAA record, it will use the result of AAAA record, then IPv6 packet to H3 host, PNAT module in H3 host will translate IPv6 packet back to IPv4 packet. This also has been covered by BIAbis and BISbis document as well. In the case of H2 stay in the IPv4 only network, if the PNAT module in H1 received an A record, this indicate the peer host stay in the IPv4 only Internet, then PNAT module will rely on PNAT64 GW prefix to make the destination address. then send the IPv6 packet to the PNAT64 Gw. PNAT64 GW will translate those IPv6 packet to the IPv4 packet and send to the H2 host. The call flow of the PNAT64COM Internet is shown below. Huang & Deng Expires April 21, 2010 [Page 12] Internet-Draft PNAT October 2009 +----------------------+ +-------------+ | (Host Side) | | (Peer Side) | | IPv6 Appl [ PNAT ] | DNS(4/6) Access PNAT64 | IPv4 Appl | | ication [Module] | Server Router GW | ication | +----------------------+ +-------------+ | | Address Request | | | (1) | |----------------------->| | | | DHCPv6[v6 Prefix + DNS]| | | (2) | |<-----------------------| | | |DNS[AAAA] | | | | | (3) |--------->| | | | | | |send A and AAAA | | | (4) | |----------->| | | | | |return A | | | (5) | |<-----------| | | | |DNS[AAAA] | | | | | (6) |<---------| | | | | |Packet | | | | | (7) |--------->| | | | | | |S: D: AAAA IPv6 address | | | (8) | |-------------------------------->| | (9) | | | | |--------->| (10) | | | | |<---------| (11) | |<--------------------------------| | |Packet | | | | | (12) |<---------| | | | | Figure 4: Signaling procedure of PNAT64COM Internet (1) The host requests the basic configuration such as IP address and DNS server. (2) The network access router assigns both IPv6 prefix and DNS Server address to the host. (3) IPv6 application would like to start the communication with the peer application, it sends name resolver by invoking getaddrinfo call. (4) After the PNAT received this AAAA record query, the PNAT module will make both A and AAAA record, then send this resolver request to the dual stack DNS server which has been detail described in the BIAbis and BISbis document. (5) The host may get A record only resolver result back from dual stack DNS server. (6) PNAT module will process this record according to the BIAbis or Huang & Deng Expires April 21, 2010 [Page 13] Internet-Draft PNAT October 2009 BISbis document, then send DNS AAAA query resolver back to the IPv6 application. (7) IPv6 application starts sending packet. (8) PNAT module processes it accordingly based on the BIAbis and BISbis document, then forwards them to the PNAT64 GW, PNAT module create the destination address by combine either WKP or PNAT64 prefix together with 32 bit IPv4 address. The source address will be network assigned IPv6 prefix concatenate with 32 bit all 1 or 0 and IPv4 address. IPv4 address could be any pre-defined IPv4 address for private IPv4 address, then 65-96 bit will be set to all 0, and this IPv4 address could be public IPv4 address if the operator could assign this address to the host, then 65-96 bit will be all 1. (9) Depending on the destination, in the case of PNAT44COM, the host will translate the source IPv4 address to a network-assigned IPv6 prefix+32 all zero + IPv4 private address or IPv6 prefix+32 all one + IPv4 public address, then forwards the IPv6 packet to PNAT64. PNAT64 will process the packet differently, if the IPv4 address is the private address. It will do like normal NAT64, but if the host gets a public IPv4 address, it will get rid of prefix only. This mechanism still is a stateful work, because PNAT64 has to record which IPv4 public address is matching to which IPv6 prefix. (In this case, ALG is not needed. But if it is private IPv4 address, then an ALG is still needed.) PNAT64 forwards the IPv4 packet to the peer IPv4 node. (10) The peer IPv4 sends a response IPv4 packet to PNAT64. (11) This packet is received by a PNAT64 which forwards the translated IPv6 packet back to the host based on the network-assigned IPv6 prefix, PNAT module will send those packet to the IPv6 application. (12) The PNAT module will forward IPv6 packet back to the IPv6 application. Huang & Deng Expires April 21, 2010 [Page 14] Internet-Draft PNAT October 2009 6. Signaling procedure of PNAT66COM Network Because H1 stay in the IPv4 only network, it works like the combination PNAT64 and PNAT46, the call flow of the PNAT66COM Network is shown below. +----------------------+ +---------------------+ | (Host Side) | | (Peer Side) | | IPv6 Appl [ PNAT ] | DNS(4/6) Access | [ PNAT ] IPv6 Appl | | ication [Module] | Server Router | [Module] ication | +----------------------+ +---------------------+ | | Address Request | | | (1) | |----------------------->| | | | DHCPv6[DNS] | | | (2) | |<-----------------------| | | |DNS[AAAA] | | | | | (3) |--------->| | | | | | |send A and AAAA | | | (4) | |----------->| | | | | |return AAAA | | | (5) | |<-----------| | | | |DNS[AAAA] | | | | | (6) |<---------| | | | | |Packet | | | | | (7) |--------->| | | | | | |S: D: WKP+Dest.IP | v4 | | (8) | |----------------------------------->| v6 | (9) | | | | |-------->| | | | | | v6 | (10) | | | | v4 |<--------| (11) | |<-----------------------------------| | |Packet | | | | | (12) |<---------| | | | | Figure 5: Signaling procedure of PNAT66COM Network (1) The host requests the basic configuration such as IP address and DNS server. (2) The network access router assigns both IPv6 prefix and DNS Server address to the host. (3) IPv6 application would like to start the communication with the peer application, it sends name resolver by invoking getaddrinfo call. (4) After the PNAT received this AAAA record query, the PNAT module will make both A and AAAA record, then send this resolver request to Huang & Deng Expires April 21, 2010 [Page 15] Internet-Draft PNAT October 2009 the dual stack DNS server which has been detail described in the BIAbis and BISbis document. (5) The host may get A or AAAA record resolver result back from dual stack DNS server. (6) PNAT module will process this record according to the BIAbis or BISbis document, then send DNS4 query resolver back to the IPv4 application. (7) IPv6 application starts sending packet. (8) PNAT module processes it accordingly based on the BIAbis and BISbis document, then forwards them to the peer side. (9) The peer side PNAT module forward translate those packet into IPv6 packet, then forward to IPv6 applications. (10) The response IPv6 packet is forwarded to the PNAT module. (11) The PNAT module translate those IPv6 packet into IPv4 packet, then forward them back to source PNAT module. (12) PNAT module will translate them back to the IPv6 packet, then those IPv6 packets are forwarded back to the IPv6 application. Huang & Deng Expires April 21, 2010 [Page 16] Internet-Draft PNAT October 2009 7. Operation of PNAT64 Gateway When PNAT64 receives a IPv6 packet, it will decide based on the destination address firstly, if it is WKP prefix it could be judged that this is a translation operation. After that, PNAT64 will analyze its source address, there are 3 possibilities for the last 32 bit: 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 Internet, 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 Internet, 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 April 21, 2010 [Page 17] Internet-Draft PNAT October 2009 8. Source and Destination address Consideration about PNAT 0 127 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PREFIX64 | all 0/1 | IPv4 addr | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 6: Design of source address For the source address deisgn, bit 65 to 96 should be designated to all zero or all one depends on IPv4 address is private or public address. For the private IPv4 address, this could be any special IPv4 address. If the public IPv4 address has been used, then prefix 64 could be common for all IPv4 public address, because the whole identifier will be 128 bit IPv6 address, and public IPv4 addresses already have been used to diffrentiate the different IPv6 address. 0 127 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PREFIX64 | 0 | IPv4 addr | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 7: Design of destination address This destination address mean when PNAT module got A record, for normal IPv6 communication, regular IPv6 address will be used for destination address. For the peer host locating in the IPv4 Internet, then the destination address will be prefix concatenate with IPv4 address, this prefix could be 64 bit prefix or longer which could be either WKP or PNAT64 prefix. All IP devices between PNAT client and PNAT64 should support it or at least know how to route PNAT64's Prefix to PNAT64 GW. Huang & Deng Expires April 21, 2010 [Page 18] Internet-Draft PNAT October 2009 9. Comparision with NAT64 The major difference between PNAT and NAT64 will be listed below: PNAT64 doesn't rely on DNS64, PNAT module will give A record result back to the IPv4 application and AAAA record to the IPv6 application. PNAT64 will always send both A and AAAA record, but DNS64 behave differently. PNAT64 is targetting multiple scenarios, but NAT64 only give the solution for IPv6 only application visiting to IPv4 peer. Huang & Deng Expires April 21, 2010 [Page 19] Internet-Draft PNAT October 2009 10. Roaming consideration of PNAT Non-PNAT based IPv4/IPv6/Dual stack devices roam to PNAT based network: PNAT IPv4 only network: Don't need additional signaling, it works smoothly PNAT IPv6 only network: It's IPv6 application could work, but IPv4 application couldn't work, but this is a rare case, because if the oepartor deploy a IPv6 only network, he must consider some special APN for IPv4 access at least. PNAT Dual Stack network: Don't need additional signaling, it works smoothly PNAT based IPv6 devices roam to non-PNAT based IPv4/IPv6 network Don't need additional signaling, it works smoothly. Huang & Deng Expires April 21, 2010 [Page 20] Internet-Draft PNAT October 2009 11. Security Considerations It needs to be further identified. Huang & Deng Expires April 21, 2010 [Page 21] Internet-Draft PNAT October 2009 12. IANA Consideration This document makes no requests to IANA. Huang & Deng Expires April 21, 2010 [Page 22] Internet-Draft PNAT October 2009 13. Acknowledgments The author thanks the discussion from Gang Chen, Bo Zhou, Dapeng Liu, Hong Liu, Tao Sun, Teemu Savolainen, Sri Gundave, Suresh Krishnan et al. in the development of this document. The efforts of BARI, FAROOQ, Kalyani Bogineni, Mohamed Boucadair, Yiu L. Lee, Christian Vogt, Jan Melen, James Woodyatt, Lorenzo Colitti, Qibo Niu, Pierrick Seite, Dean Cheng in reviewing this document are gratefully acknowledged. The authors thanks Dan Wing and Dave Thaler's advice how to process this document. Huang & Deng Expires April 21, 2010 [Page 23] Internet-Draft PNAT October 2009 14. Normative References [BIAbis] Huang, Bill., "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", draft-huang-behave-rfc3338bis-00 (work in progress), Oct. 2009. [BISbis] Huang, Bill., "Dual Stack Hosts using the "Bump-In-the- Stack" Technique (BIS)", draft-huang-behave-rfc2767bis-00 (work in progress), Oct. 2009. [DS-Lite] Durand, A., "Dual-stack lite broadband deployments post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite-01 (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-02 (work in progress), Oct. 2009. [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 April 21, 2010 [Page 24] Internet-Draft PNAT October 2009 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 April 21, 2010 [Page 25]