One document matched: draft-huang-pnat-host-ipv6-01.txt
Differences from draft-huang-pnat-host-ipv6-00.txt
Network Working Group B. Huang
Internet-Draft H. Deng
Intended status: Standards Track China Mobile
Expires: January 14, 2010 July 13, 2009
Prefix NAT: Host based IPv6 translation
draft-huang-pnat-host-ipv6-01
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 January 14, 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 January 14, 2010 [Page 1]
Internet-Draft PNAT July 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 January 14, 2010 [Page 2]
Internet-Draft PNAT July 2009
Abstract
IPv4 migrating to IPv6 is a network layer issue, it is not easy to
mandate the application in the host to change in the first place, the
network layer may have to have a solution to support conventional
IPv4 appliations in the IPv6 only network, especially when there are
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. A new
well known IPv6 prefix is used for the destination address
translation and network assigned prefix will be used for source
address translation.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Network Scenarios . . . . . . . . . . . . . . . . . . . . . . 5
3. PNAT module in the host . . . . . . . . . . . . . . . . . . . 6
4. Signaling procedure of PNAT . . . . . . . . . . . . . . . . . 8
5. Operation of PNAT64 Gateway . . . . . . . . . . . . . . . . . 12
6. Socket API Translation . . . . . . . . . . . . . . . . . . . . 13
7. Consideration about PNAT Well Known Prefix . . . . . . . . . . 14
8. Alternative: PNAT Header Translation . . . . . . . . . . . . . 15
8.1. PNAT Header Translation Host modules . . . . . . . . . . . 15
8.2. Signaling procedure of PNAT Header translation . . . . . . 16
9. Other scenarios: PNAT64COM, PNAT46COM, PNAT66COM . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 21
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
13. Normative References . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Huang & Deng Expires January 14, 2010 [Page 3]
Internet-Draft PNAT July 2009
1. Introduction
IETF has long time to not discuss host based IPv6 translation
technology even though there are already several solutions which have
been proposed before 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 IPv4
talk with IPv4 over an IPv6 only network; The mapping table in the
host seems quite complicated comparing with using well known prefix.
[RFC3493] has been implemented by the major OSs, but it is not fullly
fledged to support the translation.
IPv6 migration is a principally network issue, so upgrading the
applications from IPv4 to IPv6 is always lag-behind from the point
view of industrial chain. Especially, there are various kinds of new
applicatoins coming out. There are much more benefits to upgrade the
network layer to support IPv6 transition in the host especially when
there are more mature and multiple operator's level applications.
There are some scenarios where IPv6-only bear network exists since
it's not easy to guarantee dual stack everywhere. In the IPv6-only
network, how to make conventional IPv4 application continue to
communicate each other is one basic requirement from the people who
is developing the applications. Application layer developers are not
familiar with network layer technologies, they are hesitating to
migrate their well-developpd application to support IPv6. It's also
not easy for them to change their experienced network interface API
to support dual stack API. Under such scenario, this document
proposes host based IPv6 translation PNAT(Prefix NAT) solution which
could guarantee IPv4 application backward compatibility in the IPv6
only network. PNAT could be regarded as the integration of both IPv4
backward compatibility like DS-Lite and NAT64.
IPv4 application backward compatibility is one key requirement for
IPv6 migration, [DS-Lite] already achieved. Besides, PNAT has two
more considerations which hasn't been addressed by [DS-Lite]. The
first one is that PNAT could support v4v6 and v6v4 communication,
secondly, PNAT solutoin could avoid single point of failure.
Recently, more and more operators has customized the terminal (mobile
or fixed) which makes it feasible to do host based translation. It
may be cheaper to do it comparing with the application upgrade.
Huang & Deng Expires January 14, 2010 [Page 4]
Internet-Draft PNAT July 2009
2. Network Scenarios
During the deployment of IPv6-only network, depends on the operator
policy, the host could get public IPv4 address and IPv6 prefix
simultaneously, or sometime the host get private IPv4 address and
IPv6 prefix. In each different configuration, PNAT64 gateway knows
how to differentiate the public and private IPv4 address. Because
the host may communicate with both IPv4 and IPv6 peer node, so the
network will assign both DNSv4 and DNSv6 server address to the host.
+----------------------------------+ +--------------------+
|IPv6 site 4/6 | | IPv4 site |
| +--------+ | | |
| | H3 | | | |
| +--------+ | | |
| | | | |
| +--------+ | | |
| +----+ | Access | +-------+ |+----------+ +----+|
| | H1 |------- | Router |-- | PNAT64|----|| Internet |--| H2 ||
| +----+ +--------+ +-------+ |+----------+ +----+|
| 4/6 | | | | 4 |
| +--------+ | | +--------+ |
| | DNSv6 | | | | DNSv4 | |
| +--------+ | | +--------+ |
| AAAA/A | | A/AAAA |
+----------------------------------+ +--------------------+
Figure 1: Network Scenario
In Figure 1, H1 is the dual stack host located in the IPv6 site, H2
is IPv4 host reachable in the IPv4 Internet, access router may
allocate the IPv4 address and IPv6 prefix to the H1 host, DNSv6 which
have both AAAA and A record, and DNSv4 may also has A and AAAA
record. The PNAT64 is used for IPv6-IPv4 translation.
PNAT44COM communication: When v4 application in the H1 need to
communicate with v4 application in the H2.Or when v4 applicaiton in
the H1 need to communicate with v4 application in the H3.
PNAT46COM communication: When v4 application in the H1 need to
communicate with v6 application in the H3.
PNAT64COM communication: When v6 application in the H1 need to
communicate with v4 application in the H2.
PNAT66COM communication: When v6 application in the H1 need to
communicate with v6 application in the H3.
Huang & Deng Expires January 14, 2010 [Page 5]
Internet-Draft PNAT July 2009
3. PNAT module in the host
Inside the host, IPv4 to IPv6 translation including socket API and
DNS queries would be done firstly. The PNAT64 in the network will
translates them back to IPv4 and then forward them into the IPv4
network.
Figure 2 shows host PNAT IPv4/IPv6 translation module.
+----------------------------------------------+
| +------------------------------------------+ |
| | | |
| | IPv4 applications | |
| | | |
| +------------------------------------------+ |
| +-------------+ +-------------------------+ |
| | DNS4 | | Socket API (IPv4) | |
| +-------------+ +-------------------------+ |
| +------------------------------------------+ |
| |[Socket API translator] PNAT | |
| | Core socket functions | |
| | Address data structures | |
| | Name-to-address translation functions | |
| | Address conversion functions | |
| |[Well Known Prefix Support] | |
| +------------------------------------------+ |
| +-------------+ +-------------------------+ |
| | DNS6 | | Socket API (IPv6) | |
| +-------------+ +-------------------------+ |
| +------------------------------------------+ |
| | | |
| | TCP(UDP)/IPv6 | |
| | | |
| +------------------------------------------+ |
+----------------------------------------------+
Figure 2: Host IPv6 translation
Figure 2 shows modules inside H1, since it is IPv6 only bear
network,so the bottom layer is IPv6 stack. PNAT module will do
socket translation which is similar to BIA, one difference with BIA
is to use a well known prefix, other than maintaining internally a
table of the pairs of an IPv4 address and an IPv6 address. The other
difference is that PNAT use network assigned prefix as the source
address, but BIA use network assigned IPv6 address.
IPv4 application in the host isn't aware of that it is attached to
IPv6-only network, it will continue to call IPv4 socket API. PNAT
Huang & Deng Expires January 14, 2010 [Page 6]
Internet-Draft PNAT July 2009
inside the host will translate IPv4 socket API into IPv6 socket API.
The network assigned IPv6 prefix will be used for PNAT source address
translation and well known prefix will be used to concatenate the
destination IPv4 address into a IPv6 destination address.
DNS4 and DNS6 don't stand for any special module, in the context of
each memo each represents gethostbyname() in IPv4 and getaddrinfo()
in IPv6.
Huang & Deng Expires January 14, 2010 [Page 7]
Internet-Draft PNAT July 2009
4. Signaling procedure of PNAT
The call flow of the PNAT44COM is shown below. The modules of the
host have been divided into three parts: v4 application, Socket
Translation and Well Known Prefix. One clarification about DNS4/6
server is that DNS4 server will be located at the IPv4 network, and
DNS4/6 dual stack server will be located at the IPv6 network, because
of the space limitation, we only draw DNS4/6 in this figure.
Huang & Deng Expires January 14, 2010 [Page 8]
Internet-Draft PNAT July 2009
+-----------------------------------+
|(Host Side) |
|v4 Appl [ Socket Well Known ]| DNS(4/6) Access PNAT64 v4 peer
|ication [Translation Prefix(WKP)]| Server Router Application
+-----------------------------------+
| | Address Request | | | |
(0) | --------------------------->| | |
| DHCPv6(Outband) v6 Prefix +v4 addr+DNS4/6 | | |
(1) | <----------------------------| | |
| DNS4 | | | | | |
(2) |------->| | | | | |
| DNS4=>DNS6 | | | | |
| if DNS4 server | | | |
(3) | |----------->| | | | |
| | [WKP+ DNSv4] | | | |
(4) | |<-----------| | | | |
| | | | | | |
| |send both DNS4/6 Query | | | |
(5) | |------------------------>| | | |
| A/AAAA | | | |
(6) | |<------------------------| | | |
| DNS4 | | | | | |
(7) |<-------| | | | | |
|Socket4 | | | | | |
(8) |------->| | | | | |
| Socket4=>Socket6 | | | | |
(9) | |----------->| | | | |
| | WKP+Dest.IP | | | |
(10)| |<-----------| | | | |
| | | | | | |
| |S:Assigned v6 Prefix D: WKP+Dest.IP| | |
(11)| |----------------------------------------->| |
| | | | | NAT64 State |
(12)| | | | | |----->|
(13)| | | | | |<-----|
(14)| |<-----------------------------------------| |
| Socket6=>Socket4 | | | | |
|Socket4 | | | | | |
(15)|<-------| | | | | |
Figure 3: Signaling procedure of PNAT44COM
(0) The host requests the basic configuration such as IP address and
DNS server.
(1) The network assigns both IPv4 address(public or private) and IPv6
prefix, and DNSv4/v6 Server address to the host.(This private IPv4
address could be either a random IPv4 address or assigned by network
Huang & Deng Expires January 14, 2010 [Page 9]
Internet-Draft PNAT July 2009
side.
(2) IPv4 application would like to start the communication with the
peer application, it sends name resolver by invoking gethostbyname
call. Since PNAT host has already get both IPv4 and IPv6 DNS server,
so it need send A/AAAA record to IPv6 DNS server, and A record to
IPv4 DNS server. for IPv4 DNS server, it will continue call v4 socket
api, then do IPv4 header to IPv6 header translation later.
(3) if it is DNSv4 server address, it will use WKP to form a IPv6
address.
(4) Well known prefix process module send destination IPv6 address
back to socket translation module.
(5) The host send both DNSv4 and DNSv6 query to the DNSv4/v6 server.
PNAT will translate DNSv4 header to IPv6 header, PNAT64 on the
network side will translate v6 header back to v4 header, then send it
to DNSv4 server.
(6) The host may get A or AAAA record through PNAT64+DNSv4 server or
DNSv6 server.
(7) PNAT Socket translation will send DNS4 query resolver back to the
IPv4 application.
(8) IPv4 application start sending regular socket call to communicate
with the peer host, PNAT socket translation module translate this
socket call.
(9) In the case of PNAT44COM, the destination address is IPv4
address, socket translation module will forward this address to WKP
module, by adding WKP, the destination address will be changed to an
IPv6 address. The IPv6 source address will be network assigned
prefix plus IPv4 address.
(10) The formed IPv6 destination address will be sent back.
(11) Depends on the destination, in the case of PNAT44COM, the host
will translate the source IPv4 address to 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 get
public IPv4 address, it will get rid of prefix only. This mechanism
still is a stateful work, because PNAT64 have 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, then ALG is
Huang & Deng Expires January 14, 2010 [Page 10]
Internet-Draft PNAT July 2009
still needed.)
(12) PNAT64 forwards the IPv4 packet to the peer IPv4 node.
(13) The peer IPv4 sends a response IPv4 packet to PNAT64.
(14) This packet is received by a PNAT64 which forwards the
translated IPv6 packet back to the host based on the network assigned
IPv6 prefix, socket translation module translates IPv6 packet to IPv4
packet.
(15) The IPv4 packet has been forwarded back to IPv4 application.
Huang & Deng Expires January 14, 2010 [Page 11]
Internet-Draft PNAT July 2009
5. Operation of PNAT64 Gateway
When PNAT64 received 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 bit is the 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 bit is the 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 received 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.
Anyhow, PNAT64 is compatible with NAT64, make a further extention of
NAT64 to support PNAT client
Huang & Deng Expires January 14, 2010 [Page 12]
Internet-Draft PNAT July 2009
6. Socket API Translation
The IPv4 socket API could be divided into different classification
such as address conversion function, name to address translation,
address data structure, socket operation, call of socket and response
of socket. The table below has been made to identify how IPv4 socket
API should be translated into an IPv6 socket API.
+----------------------+-----------------------+
| IPv4 Socket API | IPv6 Socket API |
+----------------------+-----------------------+
| socket(AF_INET, , ) | socket(AF_INET6, , ) |
+----------------------+-----------------------+
|bind,connect | bind,connect |
|sendmsg,sendto | sendmsg,sendto |
+----------------------+-----------------------+
|accept,recvfrom | accept,recvfrom |
|recvmsg,getpeername | recvmsg,getpeername |
|getsockname | getsockname |
+----------------------+-----------------------+
|getsocketopt |getsocketopt |
|setsocketopt |setsocketopt |
+----------------------+-----------------------+
|AF_INET,socketaddr_in |AF_INET6,socketaddr_in6|
|INADDR_ANY |in6addr_any |
+----------------------+-----------------------+
| gethostbyname | getaddrinfo |
+----------------------+-----------------------+
|inet_ntoa,inet_addr |inet_pton,Inet_ntop |
+----------------------+-----------------------+
Figure 4: IPv4 IPv6 Socket API Translation
Huang & Deng Expires January 14, 2010 [Page 13]
Internet-Draft PNAT July 2009
7. Consideration about PNAT Well Known Prefix
0 127
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFIX64 | IPv4 addr | SUFFIX64 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 5: IPv4 IPv6 Socket API Translation
PREFIX64 would better be shorter as much as possible, such as
16/24/32 bits.
SUFFIX64 could be designated to all zero tentatively.
All IP device between PNAT client and PNAT64 should support it or at
least know how to route it to PNAT64. this prefix could also be set
to /96 prefix like NAT64.
Huang & Deng Expires January 14, 2010 [Page 14]
Internet-Draft PNAT July 2009
8. Alternative: PNAT Header Translation
With regard to PNAT Socket translation module, there is another
translation scheme to satisfy backward compatibility of IPv4
application . It can reach same purpose as above mentioned.
8.1. PNAT Header Translation Host modules
The detailed module implementation is described in Figure 5, which
demonstrates a PNAT module based on packet-header translation.
+----------------------------------------------+
| +------------------------------------------+ |
| | IPv4 | |
| | applications | |
| +-------------------+ +--------------------+ |
| +-------------------+ +--------------------+ |
| | DNS4 | | Socket API (IPv4) | |
| +-------------------+ +--------------------+ |
| +------------------------- ----------------+ |
| | TCP(UDP)/IPv4 | |
| +------------------------- ----------------+ |
| +------------------------------------------+ |
| |[Packet-Header translator] PNAT | |
| |[WKP support] | |
| |[DNS resolver if needed] | |
| |[ALG if needed] | |
| +------------------------------------------+ |
| +------------------------------------------+ |
| | Network card drivers | |
| +------------------------------------------+ |
+----------------------------------------------+
Figure 6: PNAT Host IPv6 translation based on packet-header
translation
A packet-header translator is deployed in a PNAT host which is
compatible with IPv4 application. The translation approach is
similar with BIS. Main difference with BIS is to use well known
prefix, other than maintaining a stateful mapping information of a
pair of IPv4 address and IPv6 address internally.
IPv4 application can make socket call and DNS query depending on IPv4
stack. And, socket handling in PNAT host is the same as that in IPv4
host. Before IPv4 datagrams are sent over an IPv6 transit network,
the PNAT module should block the data flow and make packet-header
translation, in which WKP is added to form IPv6 packet. The
translation method is identical with above PNAT scheme. It should be
Huang & Deng Expires January 14, 2010 [Page 15]
Internet-Draft PNAT July 2009
noted that ALG handing and DNS resolvering will be performed in
specific scenarios, in which communications between different address
families exist.
8.2. Signaling procedure of PNAT Header translation
The PNAT44COM procedure can be implemented depending on packet-header
translation.The data flow is shown in Figure 7. Accordingly,the
modules of host can be classified into three parts: v4 application,
Packet-header Translation and Well Known Prefix.
+--------------------------------------------+
|Host side |
| v4 [Packet-header Well Known ]| DNSv4 v4 peer
| application [Translation Prefix(P) ]| PNAT64 Server App.
+--------------------------------------------+
| DNS4 | | | | |
(0) |---------->| | | | |
| DNS4 | | | |
(1) | |----------->| | | |
| | P+Source IP | | |
(2) | |<-----------| | | |
|IPv4 Header=>IPv6 Header| | | |
(3) | |------------------------>|-------->| |
| | A | | |
(4) | |<------------------------|<--------| |
| DNS4 | | | | |
(5) |<----------| | | | |
| IPv4 | | | | |
| datagram | | | | |
(6) |---------->| | | | |
|IPv4 Header=>IPv6 Header| | | |
(7) | |----------->| | | |
| | P+Dest.IP | | |
(8) | |<-----------| | | |
(9) | |------------------------>| | |
| | | | PNAT64 |
(10)| | | |------------------->|
(11)| | | |<-------------------|
(12)| |<------------------------| | |
|IPv4 Header=>IPv6 Header| | | |
| | | | | |
| IPv4 | | | | |
| datagram | | | | |
(13)|<----------| | | | |
Figure 7: PNAT Header Translation Signaling procedure
Huang & Deng Expires January 14, 2010 [Page 16]
Internet-Draft PNAT July 2009
the host will get network assigned IPv4 address and IPv6 prefix, and
DNSv4 and DNSv6 server address which is the same as Figure 3.
(0) IPv4 application would like to start the communication with the
peer application, it sends name resolver by invoking gethostbyname()
call. The IPv4 packet header of DNS query should translated into
IPv6 packet header before the packets are sent to IPv6 transit
network.In the whole process,the DNS call payload is not be modified.
(1) When packet-header translation handles this process, it will send
this address to well known prefix module. After receiving the
destination IPv4 address, well know prefix module appends the well
known prefix and get destination IPv6 address.
(2) Well known prefix process module send destination IPv6 address
back to packet-header translation module.
(3) The host sends DNS4 query, which is encapsulated in IPv6
datagram. PNAT64 will get rid of IPv6 prefix and send it to DNSv4
server.
(4) The host gets replied DNS A record.
(5) Packet-header translation changes the DNS IPv6 header to IPv4
header in order to send DNS response to corresponding application.
(6) IPv4 application initiates communication with the peer host. The
system call will invoke IPv4 socket to form IPv4 packet, which will
be sniffered in packet-header translation module.The IPv4 header will
be tranlated into IPv6 header.
(7) Packet-header translation module will forward this address to
well known prefix module, by adding IPv6 prefix. The destination
address will be changed to IPv6 address.
(8) Well known prefix forward the IPv6 address back.
(9) Based on the destination, the host forwards the IPv6 packet to
PNAT64, PNAT64 device will translate the IPv6 packet to IPv4 packet,
if there are application layer addresses, then ALG is still needed.
(10) PNAT64 forwards the IPv4 packet to the peer IPv4 node.
(11) The peer IPv4 sends response IPv4 packet to PNAT64.
(12) PNAT64 forwards the translated IPv6 packet back to the host,
packet-header translation module translates IPv6 packet to IPv4
packet.
Huang & Deng Expires January 14, 2010 [Page 17]
Internet-Draft PNAT July 2009
(13) The IPv4 packet has been forwarded back to IPv4 application.
Huang & Deng Expires January 14, 2010 [Page 18]
Internet-Draft PNAT July 2009
9. Other scenarios: PNAT64COM, PNAT46COM, PNAT66COM
PNAT64COM has been partly described in the section of PNAT44COM, the
only difference is PNAT64 will judge whether it is v4v4 communication
over v6 or v6 communicate with v4. The 65-96 bit of IPv6 source
address of the packet received in PNAT64 don't have all zero or all
one will be the scenario of PNAT64COM. PNAT64 will process this
packet as a normal NAT64 operation.
PNAT46COM will the same as the BIA and BIS operation, but it may need
ALG for some applications like P2P and RTP service
PNAT66COM will operate as the regular v6 to v6 communiation, it will
not be interupted by PNAT module.
Huang & Deng Expires January 14, 2010 [Page 19]
Internet-Draft PNAT July 2009
10. Security Considerations
It need to be further identified.
Huang & Deng Expires January 14, 2010 [Page 20]
Internet-Draft PNAT July 2009
11. IANA Consideration
This document makes no requests to IANA.
Huang & Deng Expires January 14, 2010 [Page 21]
Internet-Draft PNAT July 2009
12. Acknowledgments
The author thanks the discussion from Gang Chen, Bo Zhou, Dapeng Liu,
Hong Liu, Tao Sun et al. in the development of this document.
The efforts of Mohamed Boucadair, Yiu L. Lee, James Woodyatt, Lorenzo
Colitti, Qibo Niu and Pierrick Seite in reviewing this document are
gratefully acknowledged.
Huang & Deng Expires January 14, 2010 [Page 22]
Internet-Draft PNAT July 2009
13. Normative References
[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.
[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 January 14, 2010 [Page 23]
Internet-Draft PNAT July 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 January 14, 2010 [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-24 01:27:07 |