INTERNET-DRAFT George Tsirtsis
NGTRANS WG BT Laboratories
Expires April, 1999 Pyda Srishuresh
Category: EXPERIMENTAL Lucent Technologies
November 1998
Network Address Translation - Protocol Translation (NAT-PT)
<draft-ietf-ngtrans-natpt-03.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing 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."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Eu-
rope), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
This document specifies a transition mechanism in addition to those
already specified in [TRANS]. The new mechanism provides an
end-to-end solution to allow IPv6-only hosts to communicate with
IPv4-only hosts and vice versa using Network Address Translation
and Protocol Translation. The scheme described does not require du-
al-stack hosts; nor does it mandate any routing related changes on
the hosts. The scheme is based on a combination of address transla-
tion theme as described in [NAT] and V6/V4 protocol translation
theme as described in [SIIT].
Acknowledgements
The authors would like to thank Erik Nordmark whose Protocol
Translation details in [SIIT] formed the bases of the corresponding
section 5 in this document
Special thanks to Pedro Marques for reviewing the draft. Finally,
many thanks to Alan O'Neill and Martin Tatham since the initial
Tsirtsis & Srisuresh [Page 1]
Internet Draft Network Address + Protocol Translator November 1998
idea described in this document was developed after discussions with
them.
Index
1. Introduction
2. Terminology
3. Network Address Translation operation
3.1 NAT-PT Outgoing Sessions (IPv6 to IPv4)
3.2 NAPT-PT Outgoing Sessions (IPv6 to IPv4)
4. IP v4 Address Assignment
4.1 V4 Address assignment for outgoing connections
4.2 V4 Address assignment for incoming connections
4.2.1 DNS Application Layer Gateway (ALG) support
5. Protocol Translation Details
5.1 Translating IPv4 headers to IPv6 headers
5.2 Translating ICMPv4 headers to ICMPv6 headers
5.3 Translating IPv6 headers to IPv4 headers
5.4 Translating ICMPv6 headers to ICMPv4 headers
5.5 TCP/UDP Checksum Update
5.6 FTP Control session payload
6. NAT-PT Limitations and Future Work
6.1 Topology limitations
6.2 Protocol Translation Limitations
6.3 Impact of Address Translation
6.4 Lack of end-to-end security
6.5 DNS Translation and DNSSEC
7. Applicability Statement
8. Security Considerations
9. References
1. Introduction
IPv6 is the upcoming IP protocol that was designed in order to
modernise IPv4, which was designed in the 1970s. IPv6 has a number of
advantages over IPv4 including the fact that it provides a much
larger address space than IPv4, which for many, is the number one
reason to move to IPv6. A basic requirement, however, for a large
Tsirtsis & Srisuresh [Page 2]
Internet Draft Network Address + Protocol Translator November 1998
number of people is to be able to communicate with IPv4 hosts during
the transition period. Keeping in mind that the chances are that
IPv4 and IPv6 will have to coexist for a very long time,
interoperability becomes a very important issue.
The SIIT proposal [SIIT] describes a protocol translation mechanism
that allows communication between IPv6-only and IPv4-only machines.
This proposal assumes that V6 hosts are somehow assigned a V4 address
for communicating with V4 hosts. Further, it assumes that the V6
hosts would use a V6 address based on their V4 address (V4 mapped or
V4 compatible) as their source V6 address and V4-mapped address of
the target V4 machine as the destination V6 address. With these as-
sumptions, SIIT purports to do protocol independent translation of
V4/V6 datagrams, requiring no state details on the sessions.
Unlike SIIT, NAT-PT provides a transparent end-to-end solution re-
quiring no changes to end nodes. NAT-PT uses a pool of V4 addresses
for assignment to V6 hosts on a dynamic basis as sessions are initi-
ated 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 NAT-PT to track the sessions it
supports and mandates that inbound and outbound datagrams pertaining
to a session traverse through the same NAT-PT router. You will note
that the topology restriction on NAT-PT are very similar to those de-
scribed for V4 NATs in [NAT]. Protocol translation details specified
in [SIIT] would be used to extend address translation with protocol
syntax/semantics translation.
2. Terminology
Session initiation packet
This is the first packet of an IP session. Only the
first packet of a TCP session can be identified in a de-
terministic way, with the presence of SYN bit and absence of
ACK bit in TCP header. There is no deterministic way to
recognise the start of a UDP or any non-TCP session. [NAT].
Network Address Translation (NAT)
NAT in this document is very similar, but not the same,
with IPv4 NAT as described in [NAT]. IPv4 NAT trans-
lates 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.
Protocol Translation (PT)
PT in this document refers to translation of an IPv4
Tsirtsis & Srisuresh [Page 3]
Internet Draft Network Address + Protocol Translator November 1998
packet into a semantically equivalent IPv6 packet and
vice versa.
Application Layer Gateway (ALG)
Application Level Gateway (ALG) is an application spe-
cific agent that allows a V6 host to communicate with a V4
host and vice versa. Some applications carry network ad-
dresses in payload. NAT-PT is application independent (with
the notable exception of FTP) and does not snoop the
payload to fix IP addresses in payload. ALG is an alterna-
tive to NAT-PT for such applications.
3. Network Address Translation operation
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 hosts in a private network
could traverse through whichever NAT device has the best metric for
an external host.
NAT-PT is application independent. Applications such as "FTP" that
include IP addresses in payload will need to be supported by appli-
cation specific ALGs in conjunction with NAT-PT. This document de-
scribes 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 both sides, when an
IPv6 domain is connected to an IPv4 domain through a NAT-PT.
3.1 NAT-PT Outgoing Sessions (IPv6 to IPv4)
Tsirtsis & Srisuresh [Page 4]
Internet Draft Network Address + Protocol Translator November 1998
^
|
[IPv6-B]-+
| +==============+
[IPv6-A]-+-[NAT-PT]---------| IPv4 network |--[IPv4-C]
| +==============+
(pool of v4 addresses)
Figure 1: IPv6 to IPv4 communication
Host IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210
Host IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
Host 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
Say the IPv6 Host A wants to communicate with the IPv4 Host C.
Host A creates a packet with:
Source Address, SA=FEDC:BA98::7654:3210 and
Destination Address, DA = prefix::132.146.243.30
NOTE: The prefix PREFIX::/96 is advertised in the stub domain by
the NAT-PT and it points to it. The pre-configured prefix has to
be routable only inside the stub domain representing the IPv4
world.
The packet is routed to the NAT-PT gateway, where it has to be
translated 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, while
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. The returning traffic will be recognised as
belonging to the same session and the packet will use the cached
information in order to be translated, while the addresses after
the translation will be as follows.
SA=PREFIX::132.146.243.30, DA=FEDC:BA98::7654:3210. Note that
Tsirtsis & Srisuresh [Page 5]
Internet Draft Network Address + Protocol Translator November 1998
this packet can now be routed inside the IPv6-only network as nor-
mal.
3.2 NAPT-PT Outgoing Sessions (IPv6 to IPv4) with a single V4 address
NAPT-PT, which stands for "Network Address Port Translation + Pro-
tocol Translation", would allow V6 hosts to communicate with the
V4 world transparently using a single V4 address. The TCP/UDP
ports of the V6 hosts are translated into TCP/UDP ports of the
registered V4 address. The port translation and ICMP query iden-
tifier translation works very similar to the way NAPT is described
in [NAT].
NAPT-PT also solves a problem that is inherent with NAT-PT. That
is, NAT-PT would fall flat when the pool of V4 addresses assigned
for translation purposes is exhausted. Once the address pool is
exhausted, newer V6 hosts cannot establish sessions with the out-
side world anymore. NAPT-PT, on the other hand, will allow for a
maximum of 63K TCP and 63K UDP sessions before falling flat with
no TCP and UDP ports left to assign.
In the example sited in figure 1, say, we have NAPT-PT on the bor-
der router (instead of NAT-PT) and all V6 addresses are mapped in-
to a single v4 address 120.130.26.10.
Say the IPv6 Host A wanted to set up a TCP session with the IPv4
Host C.
Host 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
Tsirtsis & Srisuresh [Page 6]
Internet Draft Network Address + Protocol Translator November 1998
As for inbound sessions, they are restricted to one server per
service made possible by static TCP/UDP port mapping. For example,
say the Host [IPv6-A] in figure 1 is the only HTTP server in the
V6 domain. Host [IPv4-C] sends a packet:
SA=132.146.243.30, source TCP port = 1025 and
DA=120.130.26.10, destination TCP port = 80 (http port)
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 (http
port)
In the above example, note that all sessions to NAPT registered
address with service port of 80 will be redirected to the same
host [IPv6-A].
4. IPv4 Address Assignment
IPv4 addresses are assigned by NAT-PT to a V6 host, when NAT-PT iden-
tifies the start of session, inbound or outbound. Identification of
session start on the inbound is done differently from that on the
outbound. However, the same V4 address pool is used for assigning to
V6 hosts, irrespective of whether a session is initiated outbound
from a V6 host or initiated inbound from a V4 host.
Policies determining what type of sessions are allowed and in which
direction and from/to which hosts is out of the scope of this docu-
ment.
4.1 V4 Address assignment for outgoing connections
Outbound session start is based on identifying the first packet of
a session. For ex: SYN, !ACK for TCP sessions.
V6 hosts learn the address of V4 hosts from the DNS server in the
V4 domain or the DNS server internal to the V6 network. We recom-
mend that DNS servers internal to V6 maintain mapping of names to
IP V6 addresses for internal hosts and possibly some external
hosts. External DNS servers in the V4 domain maintain name map-
ping for external hosts (i.e., V4 hosts) alone.
In case of NAPT-PT, a TCP/UDP source port is assigned from the
registered V4 address upon detection of each new outbound session.
Tsirtsis & Srisuresh [Page 7]
Internet Draft Network Address + Protocol Translator November 1998
4.2 V4 Address assignment for incoming connections
In order to initiate incoming sessions, a V4 host obtains the V4
address of the V6 host it is trying to connect to by making a DNS
request. This request constitutes the start of a potential new
session.
^
[DNS]--+
| [DNS]------[DNS]-------[DNS]
[IPv6-B]-+ | |
| +==============+ |
[IPv6-A]-+----[NAT-PT]------| IPv4 network |--[IPv4-C]
| +==============+
(pool of v4 addresses)
Figure 2: IPv4 to IPv6 communication
Host IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210
Host IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
Host 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
4.2.1 DNS Application Layer Gateway (ALG) support
In figure 2 above, when Host C name resolver makes a name look
up request for Host A, the lookup query is redirected to the
DNS server on the V6 network. Considering that NAT-PT is resid-
ing on the border router between V4 and V6 networks, this re-
quest datagram would traverse through the NAT-PT router. The
DNS ALG on NAT-PT would modify the DNS Queries going into V6
domain as follows:
a) For Host Name to Host Address Query requests:
Change the Query type from "A" to "AAAA".
b) For Host address to Host name query requests:
Replace the V4 address octets (in reverse order) pre-
ceding the string "IN-ADDR.ARPA" with the corresponding
V6 address (if there exists a map) octets in reverse or-
der.
In the opposite direction, when DNS response traverse from the
DNS server on V6 network to V4 host, the DNS-ALG once again
traps the DNS packet and would:
Tsirtsis & Srisuresh [Page 8]
Internet Draft Network Address + Protocol Translator November 1998
a) Translate DNS responses for "AAAA" records into 'A'
records,
b) Replace the V6 address sent by the V6 DNS server with the
V4 address internally assigned by the NAT-PT router.
If a V4 address is not previously assigned to this V6 host,
NAT-PT would assign it this time. The TTL values on all DNS re-
source records (RRs) passing through NAT-PT would be set to 0.
This technique is also useful for outgoing communication as
well. We saw that a v6host that needs to communicate with a v4
hosts needs to use a specific prefix (PREFIX::) in front of the
IPv4 address of the v4host. The above technique allows the use
of this prefix without any configuration in the hosts. E.g.: In
Figure 2, Host-A makes a name look-up on the Host-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 NAT-PT. The reply follows the same route but now the
NAT-PT translates the reply adding the appropriate prefix. So,
if the reply is:
HostC A 132.146.243.30, it is translated to
HostC AAAA PREFIX::132.146.243.30
Now Host A can use this address as any other IPv6 address and
the v6 DNS server can even cache it as long as the prefix does
not change.
An additional problem is how the v6 DNS server in the v6 stub
domain talks to the v4 domain outside the v6 stub domain. Re-
member that there are no dual stack hosts here. The v4 DNS
server needs to point to a v4 address, part of the v4 pool of
addresses, available to the NAT-PT. The NAT-PT keeps a one-to-
one mapping between this v4 address and the IPv6 address of the
v6 DNS server. In the other direction, the v6 DNS server points
to the IPv4 address of the v4 DNS servers with the prefix (PRE-
FIX::) which indicates non IPv6 address. This mechanism can
easily be extended to accommodate secondary DNS servers.
Note that the scheme described above impacts DNSSEC and look at
section 6.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-
Tsirtsis & Srisuresh [Page 9]
Internet Draft Network Address + Protocol Translator November 1998
ferent length. NAT-PT SHOULD translate all IP/ICMP headers from and
to IPv6 in order to make end-to-end IPv6 to IPv4 communication possi-
ble. Due to the address translation function and possible port mul-
tiplexing, NAT-PT SHOULD also make the appropriate adjustments to the
upper layer protocol (TCP/UDP) as well as to the FTP control ses-
sion payload.
In the following paragraphs we are borrowing the translation mecha-
nism from the SIIT specification and we make the changes imposed by
the address translation.
5.1 Translating IPv4 headers to IPv6 headers
If the DF flag is not set and the IPv4 packet will result in an
IPv6 packet larger than 1280 bytes the IPv4 packet SHOULD be frag-
mented prior to translating it. Since IPv4 packets with DF not
set will always result in a fragment header being added to the
packet, the IPv4 packets should be fragmented so that their
length, excluding the IPv4 header, is at most 1232 bytes (1280
minus 40 for the IPv6 header and 8 for the Fragment header). The
resulting fragments are then translated independently using the
logic described below.
If the DF bit is set and the packet is not a fragment (i.e., the
MF flag is not set and the Fragment Offset is zero) then there is
no need to add a fragment header to the packet. The IPv6 header
fields are set as follows:
Version:
6
Flow ID:
0 (all zero bits)
Payload Length:
Total length value from IPv4 header, minus the size of
the IPv4 header and IPv4 options, if present.
Payload Type:
Protocol field copied from IPv4 header
Hop Limit:
TTL value copied from IPv4 header, decremented by one.
Source Address:
The low-order 32 bits is the IPv4 source address. The
high-order 96 bits is the designated prefix for all v4
Tsirtsis & Srisuresh [Page 10]
Internet Draft Network Address + Protocol Translator November 1998
communications and points to the NAT-PT gateway (PRE-
FIX::/96)
Destination Address:
The NAT-PT retains a mapping between the IPv4 DA and
the IPv6 address of the destination host. The IPv4 DA is
replaced by the IPv6 address retained in that mapping.
If IPv4 options are present in the IPv4 packet, they
are ignored i.e., there is no attempt to translate
them.
If there is need to add a fragment header (the DF bit is
not set or the packet is a fragment) the header fields
are set as above with the following exceptions:
IPv6 fields:
Payload Length:
Total length value from IPv4 header, plus 8 for the
fragment header, minus the size of the IPv4 header and
IPv4 options, if present.
Payload Type:
Fragment Header (44).
Fragment header fields:
Next Header:
Protocol field copied from IPv4 header.
Fragment Offset:
Fragment Offset copied from the IPv4 header.
M flag:
More Fragments bit copied from the IPv4 header.
Identification:
The low-order 16 bits copied from the Identification
field in the IPv4 header. The high-order 16 bits set to
zero
5.2 Translating ICMPv4 headers to ICMPv6 headers
All ICMP messages that are to be translated require that the ICMP
checksum field be updated as part of the translation since ICMPv6,
unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP.
The NAT-PT retains a mapping between the IPv4 DA and the IPv6 ad-
dress of the destination host. The checksum update needs to in-
Tsirtsis & Srisuresh [Page 11]
Internet Draft Network Address + Protocol Translator November 1998
clude this IPv6 address in the calculation.
In addition all ICMP packets needs to have the Type value trans-
lated and for ICMP error messages the included IP header also
needs translation.
The actions needed to translate various ICMPv4 messages are:
ICMPv4 query messages:
Echo and Echo Reply (Type 8 and Type 0)
Adjust the type to 128 and 129, respectively, and adjust
the ICMP checksum both take the type change into account
and to include the ICMPv6 pseudo-header.
Information Request/Reply (Type 15 and Type 16)
Obsoleted in ICMPv4. Silently drop.
Timestamp and Timestamp Reply (Type 13 and Type 14)
Obsoleted in ICMPv6. Silently drop.
Address Mask Request/Reply (Type 17 and Type 18)
Obsoleted in ICMPv6. Silently drop.
ICMP Router Advertisement (Type 9)
Single hop message. Silently drop.
ICMP Router Solicitation (Type 10)
Single hop message. Silently drop.
Unknown ICMPv4 types
Silently drop.
IGMP messages:
While there are ICMPv6 counterparts for the IGMP messages all
the "normal" IGMP messages are single-hop messages and should
be silently dropped by the translator. Other IGMP messages
might be used by multicast routing protocols and, since it
would be a configuration error to try to have router adjacen-
cies across IPv4/IPv6 translators those packets should also be
silently dropped.
ICMPv4 error messages:
Destination Unreachable (Type 3)
For all that are not explicitly listed below set the Type to
1.
Translate the code field as follows:
Code 0, 1: Set Code to 0 (no route to destination).
Tsirtsis & Srisuresh [Page 12]
Internet Draft Network Address + Protocol Translator November 1998
Code 2: Translate to an ICMPv6 Parameter Problem (Type 4,
Code 1) and make the Pointer point to the IPv6 Payload
Type field.
Code 3: Set Code to 4 (port unreachable).
Code 4: Translate to an ICMPv6 Packet Too Big message
(Type 2) with code 0. The MTU field needs to be ad-
justed for the difference between the IPv4 and IPv6
header sizes. Note that if the IPv4 router did not
set the MTU field i.e. the router does not implement
[PMTUv4], then the translator should use the plateau
values specified in [PMTUv4] to determine a likely
path MTU and include that path MTU in the ICMPv6 packet.
(Use the greatest plateau value that is less than the re-
turned Total Length field.)
Code 5: Set Code to 2 (not a neighbor).
Code 6,7: Set Code to 0 (no route to destination).
Code 8: Set Code to 0 (no route to destination).
Code 9, 10: Set Code to 1 (communication with destination
administratively prohibited)
Code 11, 12: Set Code to 0 (no route to destination).
Redirect (Type 5)
Single hop message. Silently drop.
Source Quench (Type 4)
Obsoleted in ICMPv6. Silently drop.
Time Exceeded (Type 11)
Set the Type field to 3. The Code field is unchanged.
Parameter Problem (Type 12)
Set the Type field to 4. The Pointer needs to be updated to
point to the corresponding field in the translated include
IP header.
There are some differences between the IPv4 and the IPv6 ICMP er-
ror message formats as detailed above. In addition, the ICMP er-
ror messages contain the IP header for the packet in error which
needs to be translated just like a normal IP header. The transla-
tion will change the length of the datagram thus the Payload
Tsirtsis & Srisuresh [Page 13]
Internet Draft Network Address + Protocol Translator November 1998
Length field in the outer IPv6 header will need to be updated.
TCP/UDP/ICMP query headers within the ICMP error messages will
need to be translated to account for checksum changes. In the case
of NAPT-PT, even the TCP/UDP port numbers and ICMP Query ID will
need to be translated.
5.3 Translating IPv6 headers to IPv4 headers
If there is no IPv6 Fragment header the IPv4 header fields are set
as follows:
Version:
4
Internet Header Length:
5 (no IPv4 options)
Type of Service:
All zero.
Total Length:
Payload length value from IPv6 header, plus the size of
the IPv4 header.
Identification:
All zero.
Flags:
The More Fragments flag is set to zero. The Don't
Fragments flag is set to one.
Fragment Offset:
All zero.
Time to Live:
Hop Limit value copied from IPv6 header, decremented by
one.
Protocol:
Payload Type field copied from IPv6 header.
Header Checksum:
Computed once the IPv4 header has been created.
Source Address:
The NAT-PT retains a mapping between the IPv6 SA and an
Tsirtsis & Srisuresh [Page 14]
Internet Draft Network Address + Protocol Translator November 1998
IPv4 address from the pool of IPv4 addresses available.
The IPv6 SA is replaced by the above IPv4 address.
Destination Address:
IPv6 packets that are translated have a destination
address that includes an IPv4 address in the lower 32
bits of the address. Thus, the low-order 32 bits of
the IPv6 destination address is copied to the IPv4
source address.
If any of an IPv6 hop-by-hop options header, destination options
header, or routing header are present in the IPv6 packet, they are
ignored i.e., there is no attempt to translate them. However, the
Total Length field and the Protocol field would have to be adjust-
ed to "skip" these extension headers.
If the IPv6 packet contains a Fragment header the header fields
are set as above with the following exceptions:
Total Length:
Payload length value from IPv6 header, minus 8 for the
Fragment header, plus the size of the IPv4 header.
Identification:
Copied from the low-order 16-bits in the Identification
field in the Fragment header.
Flags:
The More Fragments flag is copied from the M flag in
the Fragment header. The Don't Fragments flag is set to
zero allowing this packet to be fragmented by IPv4
routers.
Fragment Offset:
Copied from the Fragment Offset field in the Fragment
Header.
Protocol:
Next Header value copied from Fragment heade
5.4 Translating ICMPv6 headers to ICMPv4 headers
All ICMP messages that are to be translated require that the ICMP
checksum field be updated as part of the translation since ICMPv6,
unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP.
The NAT-PT retains a mapping between the IPv6 SA and an IPv4 ad-
dress from the pool of IPv4 addresses. The checksum update needs
Tsirtsis & Srisuresh [Page 15]
Internet Draft Network Address + Protocol Translator November 1998
to include this IPv4 address in the calculation.
In addition all ICMP packets needs to have the Type value trans-
lated and for ICMP error messages the included IP header also
needs translation.
The actions needed to translate various ICMPv6 messages are:
ICMPv6 informational messages:
Echo Request and Echo Reply (Type 128 and 129)
Adjust the type to 0 and 8, respectively, and adjust
the ICMP checksum both take the type change into ac-
count and to exclude the ICMPv6 pseudo-header.
Group Membership Query/Report/Reduction (Type 130, 131, 132)
Single hop message. Silently drop.
Neighbor Discover messages (Type 133 through 137)
Single hop message. Silently drop.
Unknown informational messages
Silently drop.
ICMPv6 error messages:
Destination Unreachable (Type 1)
Set the Type field to 3. Translate the code field as fol-
lows:
Code 0: Set Code to 1 (host unreachable).
Code 1: Set Code to 10 (communication with destination
host administratively prohibited).
Code 2: Set Code to 5 (source route failed).
Code 3: Set Code to 1 (host unreachable).
Code 4: Set Code to 3 (port unreachable).
Packet Too Big (Type 2)
Translate to an ICMPv4 Destination Unreachable with
code 4. The MTU field needs to be adjusted for the
difference between the IPv4 and IPv6 header sizes taking
into account whether or not the packet in error in-
cludes a Fragment header.
Time Exceeded (Type 3)
Set the Type to 11. The Code field is unchanged.
Parameter Problem (Type 4)
If the Code is 1 translate this to an ICMPv4 protocol
unreachable (Type 3, Code 2). Otherwise set the Type to
12 and the Code to zero. The Pointer needs to be up-
Tsirtsis & Srisuresh [Page 16]
Internet Draft Network Address + Protocol Translator November 1998
dated to point to the corresponding field in the
translated include IP header.
Unknown error messages
Silently drop.
There are some differences between the IPv4 and the IPv6 ICMP er-
ror message formats as detailed above. In addition, the ICMP er-
ror messages contain the IP header for the packet in error which
needs to be translated just like a normal IP header. The transla-
tion will change the length of the datagram thus the Payload
Length field in the outer IPv6 header might need to be updated.
TCP/UDP/ICMP query headers within the ICMP error messages will
need to be translated to account for checksum changes. In the case
of NAPT-PT, even the TCP/UDP port numbers and ICMP Query ID will
need to be translated.
5.5 TCP/UDP Checksum Update
The NAT-PT retains a mapping between an IPv6 address and an IPv4
address from the pool of IPv4 addresses available. The above map-
ping is used in the translation process of every packet that goes
through the NAT-PT.
TCP/UDP checksum SHOULD be recalculated according to the ad-
dress change: Source Address for v6 to v4 translation; Destina-
tion Address for v4 to v6 translation
The incremental checksum adjustment algorithm may be borrowed from
[NAT] draft.
In the case of NAPT-PT, TCP/UDP checksum should be recalculated
on the outbound to account for V6 source address and V6 TCP/UDP
port changes. Likewise, TCP/UDP checksum on the inbound packets
should be recalculated to account for destination v4 address and
destination TCP/UDP port changes.
5.6 FTP Control session payload
FTP control session carries in its payload the IP address and TCP
port information pertaining to the data session it supports, an
FTP ALG on NAT-PT is needed to provide support for the popular In-
ternet application.
The arguments to the File Transfer Protocol (FTP) PORT command and
Tsirtsis & Srisuresh [Page 17]
Internet Draft Network Address + Protocol Translator November 1998
PASV response include an IP address (V4 or V6 address) and a TCP
port in ASCII. If the IP address in PORT command or PASV response
is a V6 address, then NAT-PT should substitute this with the NAT-
PT assigned V4 address. In case of NAPT-PT, even the TCP port fol-
lowing the IP address should be translated. The reverse (trans-
lation from v4 address to V6 address) is true in the inbound
packets.
Note, all translations are ASCII encoded translations. As a re-
sult, these translations may result in a change in the size of
packet.
If the new size is same as the previous, only the TCP checksum
needs adjustment as a result of payload translation. If the new
size is different from the previous, TCP sequence numbers should
also be changed to reflect the change in length of FTP control
session payload. The IP packet length field in V4 header or the
IP payload length in V6 field should also be changed by the same
delta change in payload size. A special table is used to correct
the TCP sequence and acknowledge 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 pack-
ets and sequence number delta for inbound packets. The sequence
number deltas are negative (i.e., payload size decreases) on the
outbound and positive (i.e., payload increases) on the inbound.
Sequence number for an outbound packet is increased by the out-
bound sequence number delta and acknowledgement number for the
same outbound packet is decreased by the inbound sequence number
delta. Likewise, sequence number for an inbound packet is in-
creased by the inbound sequence number delta and acknowledgement
number for the same inbound packet is decreased by the outbound
sequence number delta.
6. NAT-PT Limitations and Future Work
6.1 Topology limitations
There are limitations to using the translation method. It is
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 either originated from the domain
or destined to the domain.
Tsirtsis & Srisuresh [Page 18]
Internet Draft Network Address + Protocol Translator November 1998
Note that the same limitation does not apply to IPv6 routing,
since IPv4 routing cn be recognised from its form PREFIX::x.y.z.w
(PREFIX::/96) and be treated differently.
6.2 Protocol Translation Limitations
A number of IPv4 fields have changed meaning in IPv6 and transla-
tion is not straightforward. For example the TOS field in IPv4 be-
came meaningful mapping may be possible. As another example, the
option headers semantics and syntax have changed significantly in
IPv6, some meaningful translation may also be possible in the fu-
ture using NAT-PT.
6.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 services to that kind of applications.
6.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 and transport layer security is
not possible. Also application layer security may not be possible
for applications that carry IP addresses to the application
layer. This is an inherent limitation from the Network Address
Translation function.
6.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 accessable 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, if DNS-SEC were to become the norm in both V4 and V6
Tsirtsis & Srisuresh [Page 19]
Internet Draft Network Address + Protocol Translator November 1998
DNS servers and end-host resolvers, the scheme suggested in this
document will not work.
7. 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 and it is con-
nected to an Internet that is either V4-only or a combination of V4
and V6.
NAT-PT by default provides 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 droped. This makes NAT-PT a use-
ful 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 as described in 4.2.1 provides two way
connectivity between the IPv6 stub domain and the IPv4 world allowing
sessions to be initialised by IPv4 nodes outside the IPv6 stub do-
main. This makes NAT-PT useful for IPv6 only stub networks that
need to deploy servers visible to the IPv4 world.
8. Security Considerations
Section 6.4 of this document describes the fact that end-to-end
network and transport layer security is not possible when a session
is intercepted by a NAT-PT. Also application layer security may not
be possible for applications that carry IP addresses to the ap-
plication layer.
Section 6.5 of this document describes the fact that the DNS-ALG can
not be deployed in combination with secure DNS.
9. REFERENCES
[DNSSEC] D. Eastlake, C. Kaufman, "Domain Name System Security Exten-
sions", RFC 2065, January 1997.
[NAT] K. Egevang, P. Francis, The IP Network Address Translator (NAT),
RFC 1631, May 1994
[PMTUv4] J. Mogul, S. Deering, "Path MTU Discovery", RFC 1191, November
1990
Tsirtsis & Srisuresh [Page 20]
Internet Draft Network Address + Protocol Translator November 1998
[SIIT] E. Nordmark, "Stateless IP/ICMP Translator (SIIT)",
<draft-ietf-ngtrans-siit-02.txt>, Work in progress, November 1998
[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 Laboratoties
IPSWICH IP5 3RE
England
Phone: +44 1473 640756
Fax: +44 1473 640709
e-mail: george@gideon.bt.co.uk
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 21]
Internet Draft Network Address + Protocol Translator November 1998
Tsirtsis & Srisuresh [Page 22]