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]