INTERNET-DRAFT George Tsirtsis
NGTRANS WG BT
Expires December, 1999 Pyda Srishuresh
Lucent Technologies
June 1999
Network Address Translation - Protocol Translation (NAT-PT)
<draft-ietf-ngtrans-natpt-06.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that oth-
er 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 mate-
rial 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.
Abstract
This document specifies an IPv4-to-IPv6 transition mechanism, in ad-
dition to those already specified in [TRANS]. This solution al-
lows IPv6-only nodes to transparently communicate with IPv4-only
nodes and vice versa using a combination of Network Address Trans-
lation and Protocol Translation. The scheme described does not man-
date dual-stacks (i.e., IPv4 as well as V6 protocol support) or spe-
cial purpose routing requirments (such as requiring tunneling sup-
port) on end hosts. This scheme is based on a combination of address
translation theme as described in [NAT-TERM] and V6/V4 protocol
translation theme as described in [SIIT]
Acknowledgements
Special thanks to Pedro Marques for reviewing an earlier version of
the draft. Also, many thanks to Alan O'Neill and Martin Tatham, as
the mechanism described in this document was initially developed
through discussions with them.
Tsirtsis & Srisuresh [Page 1]
Internet Draft Network Address + Protocol Translator June 1999
Index
1. Introduction
2. Terminology
3. Network Address Translation operation (V6 to V4)
3.1 NAT-PT Outgoing Sessions (V6 to V4)
3.2 NAPT-PT Outgoing Sessions (V6 to V4) with a single V4 address
4. Use of DNS-ALG for Address assignment
4.1 V4 Address Assignment for Incoming Connections (V4 to V6)
4.2 V4 Address Assignment for Outgoing Connections (V6 to V4)
5. Protocol Translation Details
5.1 Translating IPv4 Headers to IPv6 Headers
5.2 Translating IPv6 Headers to IPv4 Headers
5.3 TCP/UDP/ICMP Checksum Update
6. FTP Application Level Gateway (FTP-ALG) Support
7. NAT-PT Limitations and Future Work
7.1 Topology Limitations
7.2 Protocol Translation Limitations
7.3 Impact of Address Translation
7.4 Lack of End-to-End Security
7.5 DNS Translation and DNSSEC
8. Applicability Statement
9. Security Considerations
10. References
Tsirtsis & Srisuresh [Page 2]
Internet Draft Network Address + Protocol Translator June 1999
1. Introduction
IPv6 is a new version of the IP protocol designed to modernize IPv4
which was designed in the 1970s. IPv6 has a number of advantages over
IPv4 that will allow for future Internet growth and will simplify IP
configuration and administration. IPv6 has a larger address space
than IPv4, an addressing model that promotes aggressive route aggre-
gation and a powerful autoconfiguration mechanism. In time, it is
expected that Internet growth and a need for a plug-and-play solution
will result in widespread adoption of IPv6.
There is expected to be a long transition period during which it will
be necessary for IPv4 and IPv6 nodes to coexist and communicate. A
strong, flexible set of IPv4-to-IPv6 transition and coexistence mech-
anisms will be required during this transition period.
The SIIT proposal [SIIT] describes a protocol translation mechanism
that allows communication between IPv6-only and IPv4-only nodes via
protocol independent translation of IPv4 and IPv6 datagrams, requir-
ing no state information for the session. This proposal assumes that
V6 nodes are assigned a V4 address for communicating with V4 nodes,
and does not specify a mechanism for the assignment of these address-
es.
NAT-PT uses a pool of V4 addresses for assignment to V6 nodes on a
dynamic basis as sessions are initiated across V4-V6 boundaries.
These assigned addresses in turn are used to transparently replace
the original addresses used by V6 end nodes and vice versa. This
requires no changes to end nodes and IP packet routing is completely
transparent to end nodes. It does, however, require NAT-PT to track
the sessions it supports and mandates that inbound and outbound data-
grams pertaining to a session traverse the same NAT-PT router. You
will note that the topology restrictions on NAT-PT are very similar
to those described for V4 NATs in [NAT-TERM]. Protocol translation
details specified in [SIIT] would be used to extend address transla-
tion with protocol syntax/semantics translation. A detailed applica-
bility statement for NAT-PT may be found at the end of this docu-
ment in section 7.
By combining SIIT protocol translation with the dynamic address
translation capabilities of NAT, NAT-PT provides a complete mechanism
for IPv6-only nodes to communicate with IPv4-only nodes.
Tsirtsis & Srisuresh [Page 3]
Internet Draft Network Address + Protocol Translator June 1999
2. Terminology
Session initiation packet
This is the first packet of an IP session. The first
packet of a TCP session can be identified in a deterministic
way, by the presence of a SYN bit and the absence of an ACK
bit in the TCP header. There is no deterministic way to
recognise the start of a UDP session or of any non-TCP ses-
sion. A heuristic approach would be to assume the first
packet with hitherto non-existent session parameters (namely
src IP address, destination IP address, protocol, src port
no, destination port number) as constituting the start of
new session. [NAT-TERM].
Network Address Translation (NAT)
The term NAT in this document is very similar to the IPv4
NAT described in [NAT-TERM], but is not identical. IPv4 NAT
translates one IPv4 address into another IPv4 address. In
this document, NAT refers to translation of an IPv4 address
into an IPv6 address and vice versa.
Network Address Port Translation (NAPT)
NAPT [NAT-TERM] is a method by which nodes in a private net-
work domain are allowed simultaneous access to nodes in the
external network transparently using a single external ad-
dress. This is made possible by multiplexing transport lay-
er identifiers of private nodes into the transport identi-
fiers of the single assigned external address. For this
reason, only the applications based on TCP and UDP proto-
cols are supported by NAPT. ICMP query based applications
are also supported as the ICMP header carries a query iden-
tifier that is used to correlate responses with requests.
Protocol Translation (PT)
PT in this document refers to the translation of an IPv4
packet into a semantically equivalent IPv6 packet and vice
versa. Protocol translation details are described in [SI-
IT].
Application Level Gateway (ALG)
Application Level Gateway (ALG) [NAT-TERM] is an appli-
cation specific agent that allows a V6 node to communicate
with a V4 node and vice versa. Some applications carry
network addresses in payloads. NAT-PT is application unaware
and does not snoop the payload. ALG could work in conjunc-
tion with NAT-PT to provide application level transparency.
Tsirtsis & Srisuresh [Page 4]
Internet Draft Network Address + Protocol Translator June 1999
3. Network Address Translation operation (V6 to V4)
NAT-PT offers a straight forward end-to-end solution with trans-
parent routing and address/protocol translation. Operation of NAT-PT
is described in the following sub-sections. There are limitations to
using the translation method. Is it mandatory that all requests and
responses pertaining to a session be routed via the same NAT router.
One way to ascertain this would be to have NAT based on a border
router that is unique to a stub domain, where all IP packets are ei-
ther originated from the domain or destined to the domain. There are
other ways to ensure this with multiple NAT devices.. For example, a
private domain could have two distinct exit points to different
providers and the session flow from the nodes in a private network
could traverse through whichever NAT device has the best metric for
an external node.
NAT-PT is application independent. Applications such as "FTP" that
include IP addresses in the payload will need to be supported by ap-
plication specific ALGs in conjunction with NAT-PT. This document
describes the functioning of FTP and DNS ALGs in conjunction with
NAT-PT. Specifications of ALGs for other applications is outside
the scope of this document.
NAT-PT is also limited by the fact that it can translate only the
shared semantics between the V4 and V6 protocols. Features specific
only to V6 or features not supported in V6 will not be supported by
NAT-PT.
In the following paragraphs we describe the operation of NAT-PT and
the way that connections can be initiated from either side when an
IPv6 domain is connected to an IPv4 domain through a NAT-PT.
3.1 NAT-PT Outgoing Sessions (V6 to V4)
[IPv6-B]-+
| +==============+
[IPv6-A]-+-[NAT-PT]---------| IPv4 network |--[IPv4-C]
| +==============+
(pool of v4 addresses)
Figure 1: IPv6 to IPv4 communication
Node IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210
Node IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
Node IPv4-C has an IPv4 address -> 132.146.243.30
NAT-PT has a pool of addresses including the IPv4 subnet
120.130.26/24
Tsirtsis & Srisuresh [Page 5]
Internet Draft Network Address + Protocol Translator June 1999
Say the IPv6 Node A wants to communicate with the IPv4 Node C.
Node A creates a packet with:
Source Address, SA=FEDC:BA98::7654:3210 and Destination Ad-
dress, DA = PREFIX::132.146.243.30
NOTE: The prefix PREFIX::/96 is advertised in the stub domain by
the NAT-PT, and packets addressed to this PREFIX will be routed to
the NAT-PT. The pre-configured PREFIX only needs to be routable
within the IPv6 stub domain and as such it can be any routable
prefix that the network administrator choses. It can NOT for ex-
ample be a mapped prefix (::FFFF/96) since this is illegal on the
wire nor an IPv4 compatible prefix (::/96) since this is only le-
gal as a tunnel end-point.
The packet is routed via the NAT-PT gateway, where it is translat-
ed to IPv4.
If the outgoing packet is not a session initialisation packet, the
NAT-PT SHOULD already have stored some state about the related
session, including assigned IPv4 address and cached parameters for
the translation. If this state does not exist, the packet
SHOULD be silently discarded.
If the packet is a session initialisation packet, the NAT-
PT locally allocates an address (e.g: 120.130.26.10) from
its pool of addresses and the packet is translated to IPv4.
The translation parameters are cached for the duration of the
session and the IPv6 to IPv4 mapping is retained by NAT-PT.
The resulting IPv4 packet has SA=120.130.26.10 and
DA=132.146.243.30. Any returning traffic will be recognised as
belonging to the same session by NAT-PT. NAT-PT will use the
cached information to translate the packet, and the resulting
addresses will be SA=PREFIX::132.146.243.30,
DA=FEDC:BA98::7654:3210. Note that this packet can now be routed
inside the IPv6-only stub network as normal.
3.2 NAPT-PT Outgoing Sessions (V6 to V4) with a single V4 address
NAPT-PT, which stands for "Network Address Port Translation + Pro-
tocol Translation", would allow V6 nodes to communicate with the
V4 nodes transparently using a single V4 address. The TCP/UDP
ports of the V6 nodes are translated into TCP/UDP ports of the
registered V4 address.
While NAT-PT support is limited to TCP,UDP and other port multi-
plexing type of applications, NAPT-PT solves a problem that is in-
Tsirtsis & Srisuresh [Page 6]
Internet Draft Network Address + Protocol Translator June 1999
herent with NAT-PT. That is, NAT-PT would fall flat when the pool
of V4 addresses assigned for translation purposes is exhaust-
ed. Once the address pool is exhausted, newer V6 nodes cannot es-
tablish sessions with the outside world anymore. NAPT-PT, on the
other hand, will allow for a maximum of 63K TCP and 63K UDP ses-
sions per IPv4 address before having no TCP and UDP ports left to
assign.
To modify the example sited in figure 1, we could have NAPT-PT on
the border router (instead of NAT-PT) and all V6 addresses could
be mapped to a single v4 address 120.130.26.10.
IPv6 Node A would establish a TCP session with the IPv4 Node C as
follows:
Node A creates a packet with:
Source Address, SA=FEDC:BA98::7654:3210 , source TCP port = 3017
and Destination Address, DA = PREFIX::132.146.243.30, destination
TCP port = 23.
When the packet reaches the NAPT-PT box, NAPT-PT would assign one
of the TCP ports from the assigned V4 address to translate the tu-
ple of (Source Address, Source TCP port) as follows:
SA=120.130.26.10, source TCP port = 1025 and
DA=132.146.243.30, destination TCP port = 23.
The returning traffic from 132.146.243.30, TCP port 23 will be
recognised as belonging to the same session and will be translated
back to V6 as follows:
SA = PREFIX::132.146.243.30, source TCP port = 23;
DA = FEDC:BA98::7654:3210 , destination TCP port = 3017
Inbound NAPT-PT sessions are restricted to one server per ser-
vice, assigned via static TCP/UDP port mapping. For example, the
Node [IPv6-A] in figure 1 may be the only HTTP server (port 80) in
the V6 domain. Node [IPv4-C] sends a packet:
SA=132.146.243.30, source TCP port = 1025 and
DA=120.130.26.10, destination TCP port = 80
NAPT-PT will translate this packet to:
SA=PREFIX::132.146.243.30, source TCP port = 1025
DA=FEDC:BA98::7654:3210, destination TCP port = 80
In the above example, note that all sessions which reach NAPT-PT
Tsirtsis & Srisuresh [Page 7]
Internet Draft Network Address + Protocol Translator June 1999
with a destination port of 80 will be redirected to the same node
[IPv6-A].
4. Use of DNS-ALG for Address Assignment
An IPv4 address is assigned by NAT-PT to a V6 node when NAT-PT iden-
tifies the start of session, inbound or outbound. Identification of
the start of a new inbound session is performed differently than for
outbound sessions. However, the same V4 address pool is used for as-
signment to V6 nodes, irrespective of whether a session is initiated
outbound from a V6 node or initiated inbound from a V4 node.
Policies determining what type of sessions are allowed and in which
direction and from/to which nodes is out of the scope of this docu-
ment.
IPv4 name to address mappings are held in the DNS with "A" records.
IPv6 name to address mappings are at the moment held in the DNS with
"AAAA" records. "A6" records have also been defined but at the time
of writing they are neither fully standardized nor deployed.
In any case, the DNS-ALG's principle of operation described in this
section is the same with either "AAAA" or "A6" records. The only dif-
ference is that a name resolution using "A6" records may require more
than one query - reply pairs. NAT-PT SHOULD, in that case, track all
the replies in the transaction before translating an "A6" record to
an "A" record.
4.1 V4 Address assignment for incoming connections (V4 to V6)
[DNS]--+
| [DNS]------[DNS]-------[DNS]
[IPv6-B]-+ | |
| +==============+ |
[IPv6-A]-+----[NAT-PT]------| IPv4 network |--[IPv4-C]
| +==============+
(pool of v4 addresses)
Figure 2: IPv4 to IPv6 communication
Node IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210
Node IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
Node IPv4-C has an IPv4 address -> 132.146.243.30
NAT-PT has a pool of addresses including the IPv4 subnet
120.130.26/24
In figure 2 above, when Node C's name resolver sends a name look
up request for Node A, the lookup query is directed to the DNS
Tsirtsis & Srisuresh [Page 8]
Internet Draft Network Address + Protocol Translator June 1999
server on the V6 network. Considering that NAT-PT is residing on
the border router between V4 and V6 networks, this request data-
gram would traverse through the NAT-PT router. The DNS ALG on
NAT-PT would modify the DNS Queries going into the V6 domain as
follows: (Note that a DNS UDP packet is recognized by the fact
that its source or destination port number is 53)
a) For Node Name to Node Address Query requests:
Change the Query type from "A" to "AAAA" or "A6".
b) For Node address to Node name query requests:
Replace the string "IN-ADDR.ARPA" with the string "IP6.INT".
Replace the V4 address octets (in reverse order) preceding
the string "IN-ADDR.ARPA" with the corresponding V6 address
(if there exists a map) octets in reverse order.
In the opposite direction, when a DNS response traverses from the
DNS server on the V6 network to the V4 node, the DNS-ALG once
again traps the DNS packet and would:
a) Translate DNS responses for "AAAA" or "A6" records into
"A" records, (only translate "A6" records when the name has
completely been resolved)
b) Replace the V6 address resolved by the V6 DNS with the V4
address internally assigned by the NAT-PT router.
If a V4 address is not previously assigned to this V6 node,
NAT-PT would assign one at this time. The TTL values on all DNS
resource records (RRs) passing through NAT-PT SHOULD be set to 0
so that DNS servers/clients do not cache temporarily assigned RRs.
Note, however, that due to some buggy DNS client implementations a
value of 1 might in some cases work better. The TTL values should
be left unchanged for statically mapped addresses.
This technique, as described below, is also useful for outgo-
ing communication.
4.2 V4 Address assignment for outgoing connections (V6 to V4)
V6 nodes learn the address of V4 nodes from the DNS server in the
V4 domain or from the DNS server internal to the V6 network. We
recommend that DNS servers internal to V6 domains maintain a map-
ping of names to IPv6 addresses for internal nodes and possibly
for some external nodes. In the case where the DNS server in the
v6 domain contains the mapping for external V4 nodes, the DNS
queries will not cross the V6 domain and that would obviate the
need for DNS-ALG intervention. Otherwise, the queries will cross
the V6 domain and are subject to DNS-ALG intervention. We recom-
mend external DNS servers in the V4 domain maintain name mapping
Tsirtsis & Srisuresh [Page 9]
Internet Draft Network Address + Protocol Translator June 1999
for external nodes (i.e., V4 nodes) only. Thus, zone transfers
across IPv4 - IPv6 boundaries are strongly discouraged.
In the case of NAPT-PT, a TCP/UDP source port is assigned from the
registered V4 address upon detection of each new outbound session.
We saw that a V6 node that needs to communicate with a V4 node
needs to use a specific prefix (PREFIX::/96) in front of the IPv4
address of the V4 node. The above technique allows the use of
this PREFIX without any configuration in the nodes. E.g.: In Fig-
ure 2, Node-A makes a name look-up ("AAAA" or "A6" record) for
Node-C. The DNS query goes to the V6 DNS server and from
there to the V4 DNS server outside the V6 stub domain, after it
has been translated by the DNS-ALG. The reply follows the
same route but now the DNS-ALG translates the reply adding the ap-
propriate PREFIX. So, if the reply is
NodeC A 132.146.243.30, it is translated to
NodeC AAAA PREFIX::132.146.243.30 or to
NodeC A6 PREFIX::132.146.243.30
Now Node A can use this address like any other IPv6 address and
the V6 DNS server can even cache it as long as the PREFIX does
not change.
An issue here is how the V6 DNS server in the V6 stub domain
talks to the V4 domain outside the V6 stub domain. Remember that
there are no dual stack nodes here. The external V4 DNS server
needs to point to a V4 address, part of the V4 pool of addresses,
available to NAT-PT. NAT-PT keeps a one-to-one mapping between
this V4 address and the V6 address of the internal V6 DNS server.
In the other direction, the V6 DNS server points to a V6 address
formed by the IPv4 address of the external V4 DNS servers and the
prefix (PREFIX::/96) that indicates non IPv6 nodes. This mecha-
nism can easily be extended to accommodate secondary DNS servers.
Note that the scheme described in this section impacts DNSSEC.
See section 7.5 of this document for details.
5. Protocol Translation Details
The IPv4 and ICMPv4 headers are similar to their V6 counterparts but
a number of field are either missing, have different meaning or dif-
ferent length. NAT-PT SHOULD translate all IP/ICMP headers from v4 to
v6 and vice versa in order to make end-to-end IPv6 to IPv4 communica-
tion possible. Due to the address translation function and possible
port multiplexing, NAT-PT SHOULD also make appropriate adjustments
to the upper layer protocol (TCP/UDP) headers. A separate section on
Tsirtsis & Srisuresh [Page 10]
Internet Draft Network Address + Protocol Translator June 1999
FTP-ALG describes the changes FTP-ALG would make to FTP payload as an
FTP packet traverses from v4 to v6 realm or vice versa.
Protocol Translation details are described in [SIIT], but there are
some modifications required to SIIT because of the fact that NAT-PT
also performs Network Address Translation.
5.1 Translating IPv4 headers to IPv6 headers
This is done exactly the same as in SIIT apart from the following
fields:
Source Address:
The low-order 32 bits is the IPv4 source address. The
high-order 96 bits is the designated PREFIX for all v4 com-
munications. Addresses using this PREFIX will be routed to
the NAT-PT gateway (PREFIX::/96)
Destination Address:
NAT-PT retains a mapping between the IPv4 destination ad-
dress and the IPv6 address of the destination node. The IPv4
destination address is replaced by the IPv6 address retained
in that mapping.
5.2 Translating IPv6 headers to IPv4 headers
This is done exactly the same as in SIIT apart from the Source Ad-
dress which should be determined as follows:
Source Address:
The NAT-PT retains a mapping between the IPv6 source address
and an IPv4 address from the pool of IPv4 addresses avail-
able. The IPv6 source address is replaced by the IPv4 ad-
dress retained in that mapping.
5.3 TCP/UDP/ICMP Checksum Update
NAT-PT retains mapping between IPv6 address and an IPv4 address
from the pool of IPv4 addresses available. This mapping is used in
the translation of packets that go through NAT-PT.
The following sub-sections describe TCP/UDP/ICMP checksum update
procedure in NAT-PT, as packets are translated from V4 to V6 and
vice versa.
5.3.1. TCP/UDP/ICMP Checksum Update from IPv4 to IPv6
UDP checksums, when set to a non-zero value, and TCP check-
Tsirtsis & Srisuresh [Page 11]
Internet Draft Network Address + Protocol Translator June 1999
sum SHOULD be recalculated to reflect the address change
from v4 to v6. The incremental checksum adjustment algo-
rithm may be borrowed from [NAT]. In the case of NAPT-PT,
TCP/UDP checksum should be adjusted to account for the ad-
dress and TCP/UDP port changes, going from V4 to V6 ad-
dress.
When the checksum of a V4 UDP packet is set to zero, NAT-PT
must evaluate the checksum in its entirety for the
V6-translated UDP packet. If a V4 UDP packet with a check-
sum of zero arrives in fragments, NAT-PT must queue the
fragments until they can be assembled into a single
non-fragmented packet and evaluate the checksum prior to
forwarding the translated V6 UDP packet.
ICMPv6, unlike ICMPv4, uses a pseudo-header, just like UDP
and TCP during checksum computation. As a result, when the
ICMPv6 header checksum is computed [SIIT], the checksum
needs to be adjusted to to account for the additional pseu-
do-header. Note, there may also be adjustments required to
the checksum due to changes in the source and destination
addresses (and changes in TCP/UDP/ICMP identifiers in the
case of NAPT-PT) of the payload carried within ICMP.
5.3.2. TCP/UDP/ICMP Checksum Update from IPv6 to IPv4
TCP and UDP checksums SHOULD be recalculated to reflect the
address change from v6 to v4. The incremental checksum
adjustment algorithm may be borrowed from [NAT]. In the
case of NAPT-PT, TCP/UDP checksums should be adjusted to
account for the address and TCP/UDP port changes, going
from V6 to V4 addresses. For UDP packets, optionally, the
checksum may simply be changed to zero.
The checksum calculation for a V4 ICMP header needs to be
derived from the V6 ICMP header by running the check-
sum adjustment algorithm [NAT] to remove the V6 pseudo
header from the computation. Note, the adjustment must
additionally take into account changes to the checksum as
a result of updates to the source and destination addresses
(and transport ports in the case of NAPT-PT) made to the
payload carried within ICMP.
6. FTP Application Level Gateway (FTP-ALG) Support
Because an FTP control session carries, in its payload, the IP ad-
dress and TCP port information for the data session, an FTP-ALG is
required to provide application level transparency for this popular
Tsirtsis & Srisuresh [Page 12]
Internet Draft Network Address + Protocol Translator June 1999
Internet application.
In the FTP application runnning on a legacy V4 node, arguments to the
FTP PORT command and arguments in PASV response(successful) include
an IP V4 address and a TCP port, both represented in ASCII as
h1,h2,h3,h4,p1,p2. However, [FTP-IPV6] suggests EPRT and EPSV command
extensions to FTP, with an intent to eventually retire the use of
PORT and PASV commands. These extensions may be used on a V4 or V6
node. FTP-ALG, facilitating transparent FTP between V4 and V6 nodes,
works as follows.
A V4 host may or may not have the EPRT and EPSV command extensions
implemented in its FTP application. If a V4 host originates the FTP
session and uses PORT or PASV command, the FTP-ALG will translate
these commands into EPRT and EPSV commands respectively prior to
forarding to the V6 node. Likewise, EPSV response from V6 nodes will
be translated into PASV response prior to forwarding to V4 nodes.
The format of EPRT and EPSV commands and EPSV response may be speci-
fied as follows[FTP-IPV6].
EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>
EPSV<space><net-prt>
(or)
EPSV<space>ALL
Format of EPSV response(Positive): 229 <text indicating extended
passive mode> (<d><d><d><tcp-port><d>)
PORT command from a V4 node is translated into EPRT command, by set-
ting the protocol <net-prt> field to AF #2 (IPV6) and translating the
V4 host Address (represented as h1,h2,h3,h4) into its NAT-PT assigned
V6 address in ::: notation in the <net-addr> field. TCP port repre-
sented by p1,p2 in PORT command must be specified as a decimal <tcp-
port> in the EPRT command. Further, <tcp-port> translation may also
be required in the case of NAPT-PT. PASV command from a V4 node is be
translated into a EPSV command with the <net-prt> argument set to AF
#2. EPSV response from a V6 node is translated into PASV response
prior to forwarding to the target V4 host.
If a V4 host originated the FTP session and was using EPRT and EPSV
commands, the FTP-ALG will simply translate the parameters to these
commands, without altering the commands themselves. The protocol Num-
ber <net-prt> field will be translated from AF #1 to AF #2. <net-ad-
dr> will be translated from the V4 address in ASCII to its NAT-PT as-
signed V6 address in ::: notation. <tcp-port> argument in EPSV re-
sponse requires translation only in the case of NAPT-PT.
However, if a V6 host originates the FTP session, the FTP-ALG has two
Tsirtsis & Srisuresh [Page 13]
Internet Draft Network Address + Protocol Translator June 1999
approaches to pursue. In the first approach, the FTP-ALG will leave
the command strings "EPRT" and "EPSV" unaltered and simply translate
the <net-prt>, <net-addr> and <tcp-port> arguments from V6 to its
NAT-PT (or NAPT-PT) assigned V4 information. <tcp-port> is translated
only in the case of NAPT-PT. Same goes for EPSV response from V4
node. This is the approach we recommend to ensure forward support for
RFC 2428. However, with this approach, the V4 hosts are mandated to
have their FTP application upgraded to support EPRT and EPSV exten-
sions to allow access to V4 and V6 hosts, alike.
In the second approach, the FTP-ALG will translate the command
strings "EPRT" and "EPSV" and their parameters from the V6 node into
their equivalent NAT-PT assigned V4 node info and attach to "PORT"
and "PASV" commands prior to forwarding to V4 node. Likewise, PASV
response from V4 nodes is translated into EPSV response prior to for-
warding to the target V6 nodes. However, the FTP-ALG would be unable
translate the command "EPSV<space>ALL" issued by V6 nodes. In such a
case, the V4 host, which receives the command, may return an error
code indicating unsupported function. This -ve response may cause
many RFC 2428 compliant FTP applications to simply fail, because EPSV
support is mandated by RFC 2428. The benefit of this approach, how-
ever, is that is does not impose any FTP upgrade requirements on V4
hosts.
Note, all translations are ASCII encoded translations. As a result,
these translations may result in a change in the size of packet.
If the new size is the same as the previous, only the TCP checksum
needs adjustment as a result of the payload translation. If the new
size is different from the previous, TCP sequence numbers should
also be changed to reflect the change in the length of the FTP con-
trol session payload. The IP packet length field in the V4 header or
the IP payload length field in the V6 header should also be changed
to reflect the new payload size. A table is used by the FTP- ALG to
correct the TCP sequence and acknowledgement numbers in the TCP
header for control packets in both directions.
The table entries should have the source address, source data port,
destination address and destination data port for V4 and V6 portions
of the session, sequence number delta for outbound control packets
and sequence number delta for inbound control packets.
The sequence number for an outbound control packet is increased by
the outbound sequence number delta, and the acknowledgement number
for the same outbound packet is decreased by the inbound sequence
number delta. Likewise, the sequence number for an inbound packet
is increased by the inbound sequence number delta and the acknowl-
edgement number for the same inbound packet is decreased by the out-
Tsirtsis & Srisuresh [Page 14]
Internet Draft Network Address + Protocol Translator June 1999
bound sequence number delta.
7. NAT-PT Limitations and Future Work
7.1 Topology limitations
There are limitations to using the NAT-PT translation method. It
is mandatory that all requests and responses pertaining to a ses-
sion be routed via the same NAT-PT router. One way to guarantee
this would be to have NAT-PT based on a border router that is
unique to a stub domain, where all IP packets are either origi-
nated from the domain or destined to the domain.
Note, this limitation does not apply to packets originating
from or directed to dual-stack nodes that do not require packet
translation. This is because in a dual-stack set-up, IPv4 ad-
dresses implied in a V6 address can be identified from the address
format PREFIX::x.y.z.w and a dual-stack router can accordingly
route a packet between v4 and dual-stack nodes without tracking
state information.
7.2 Protocol Translation Limitations
A number of IPv4 fields have changed meaning in IPv6 and transla-
tion is not straightforward. For example, the option headers
semantics and syntax have changed significantly in IPv6. More
meaningful translations may be possible in the future using NAT-
PT.
7.3 Impact of Address Translation
Since NAT-PT performs address translation, applications that
carry the IP address in the higher layers will not work. In
this case Application Layer Gateways (ALG) need to be incorpo-
rated to provide support for those applications.
7.4 Lack of end-to-end security
One of the most important limitations of the NAT-PT proposal is
the fact that end-to-end network layer security is not possible.
Also transport and application layer security may not be possible
for applications that carry IP addresses to the application
layer. This is an inherent limitation of the Network Address
Translation function.
Independent of NAT-PT, end-to-end IPSec security is not possible
across different address realms. The two end-nodes that seek IPSec
Tsirtsis & Srisuresh [Page 15]
Internet Draft Network Address + Protocol Translator June 1999
network level security must both support one of IPv4 or IPv6.
7.5 DNS Translation and DNSSEC
The scheme described in section 4.2 involves translation of DNS
messages. It is clear that this scheme can not be deployed in
combination with secure DNS. I.e., an authoritative DNS name
server in the V6 domain cannot sign replies to queries that
originate from the V4 world. As a result, an V4 end-node that
demands DNS replies to be signed will reject replies that have
been tampered with by NAT-PT.
The good news, however, is that only servers in V6 domain that
need to be accessible from the V4 world pay the price for the
above limitation, as V4 end-nodes may not access V6 servers due to
DNS replies not being signed.
Also note that zone transfers between DNS-SEC servers within the
same V6 network are not impacted.
Clearly, with DNS SEC deployment in DNS servers and end-host re-
solvers, the scheme suggested in this document would not work.
8. Applicability Statement
NAT-PT can be a valuable transition tool at the border of a stub net-
work that has been deployed as an IPv6 only network when it is
connected to an Internet that is either V4-only or a combination of
V4 and V6.
NAT-PT, in its simplest form, without the support of DNS-ALG, pro-
vides one way connectivity between an IPv6 stub domain and the IPv4
world meaning that only sessions initialised by IPv6 nodes internal
to the IPv6 stub domain can be translated, while sessions initiated
by IPv4 nodes are dropped. This makes NAT-PT a useful tool to IPv6
only stub networks that need to be able to maintain connectivity with
the IPv4 world without the need to deploy servers visible to the
IPv4 world.
NAT-PT combined with a DNS-ALG provides bi-directional connectivity
between the IPv6 stub domain and the IPv4 world allowing sessions to
be initialised by IPv4 nodes outside the IPv6 stub domain. This
makes NAT-PT useful for IPv6 only stub networks that need to deploy
servers visible to the IPv4 world.
9. Security Considerations
Tsirtsis & Srisuresh [Page 16]
Internet Draft Network Address + Protocol Translator June 1999
Section 7.4 of this document describes the fact that end-to-end
network and transport layer security are not possible when a ses-
sion is intercepted by a NAT-PT. Also application layer security
may not be possible for applications that carry IP addresses in
the application layer.
Section 7.5 of this document describes the fact that the DNS-ALG can
not be deployed in combination with secure DNS.
Finally, all of the security considerations described in [NAT-TERM]
are applicable to this document as well.
10. REFERENCES
[FTP-IPV6] M. Allman, S. Ostermann, C. Metz, "FTP Extensions for IPv6
and NATs", RFC 2428, September 1998.
[DNSSEC] D. Eastlake, "Domain Name System Security Extensions", RFC
2065, March 1999.
[NAT] K. Egevang, P. Francis, The IP Network Address Translator (NAT),
RFC 1631, May 1994
[NAT-TERM] P. Srisuresh, M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations" <draft-ietf-nat-terminolo-
gy-03.txt>, Work in Progress, June 1999.
[SIIT] E. Nordmark, "Stateless IP/ICMP Translator (SIIT)",
<draft-ietf-ngtrans-siit-05.txt>, Work in progress, January 1999.
[TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts
and Routers, RFC 1933, April 1996
AUTHORS
George Tsirtsis
Internet Transport Group
B29 Room 129
BT Laboratories
IPSWICH IP5 3RE
England
Phone: +44 1473 640756
Fax: +44 1473 640709
e-mail: george.tsirtsis@bt.com
e-mail (alternative): gtsirt@hotmail.com
Tsirtsis & Srisuresh [Page 17]
Internet Draft Network Address + Protocol Translator June 1999
Pyda Srisuresh
Lucent Technologies
4464 Willow Road
Pleasanton, CA 94588-8519
U.S.A.
Voice: (925) 737-2153
Fax: (925) 737-2110
EMail: suresh@ra.lucent.com
Tsirtsis & Srisuresh [Page 18]
