INTERNET-DRAFT George Tsirtsis
BT Laboratories
Pyda Srisuresh
Lucent Technologies
March 1998
Network Address Translation - Protocol Translation (NAT-PT)
<draft-ietf-ngtrans-natpt-01.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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other In-
ternet Draft.
Abstract
This document specifies a transition mechanism in addition to those
already specified in RFC 1933. 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/SUN whose Protocol
Translation details in [SIIT] formed the bases of the corresponding
section 5 in this document. Section 4.2.1. has been based on an idea
originally described in [NNAT] by Jim Bound/DEC.
Special thanks to Pedro Marques/Cisco for reviewing the draft. Final-
ly, many thank to Alan O'Neill and Martin Tatham/BTLABS since the
initial idea described in this document was developed after discus-
Tsirtsis & Srisuresh [Page 1]
Internet Draft Network Address + Protocol Translator March 1998
sions with them.
Index
1. Introduction
2. Terminology
2.1 NAT-PT Terminology
2.2 Specification Language
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 updates with dynamic V4 address assignments
4.2.2 DNS Request and Response Translation
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
7. Security Considerations
8. 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 March 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
2.1 NAT-PT 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 deterministic
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 translates one
IPv4 address into another IPv4 address . In this document, NAT
refers to translation of an IPv4 address into an IPv6 ad-
dress and vice versa.
Tsirtsis & Srisuresh [Page 3]
Internet Draft Network Address + Protocol Translator March 1998
Protocol Translation (PT)
PT in this document refers to translation of an IPv4 packet
into a semantically equivalent IPv6 packet and vice versa.
Application Layer Gateway (ALG)
Application Level Gateway (ALG) is an application specific
agent that allows a V6 host to communicate with a V4 host and
vice versa. Some applications carry network addresses in pay-
load. NAT-PT is application independent (with the notable ex-
ception of FTP) and does not snoop the payload to fix IP ad-
dresses in payload. ALG is an alternative to NAT-PT for such
applications.
2.2 Specification Language
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
this document, are to be interpreted as described in [KEYWORDS].
3. Network Address Translation operation
While NAT-PT offers a straight forward end-to-end solution with
transparent routing and address/protocol translation for V6 hosts to
communicate with V4 hosts and vice versa; the scheme has certain lim-
itations. Firstly, it is mandatory that all requests and responses
pertaining to a session between a client and server be routed via the
same NAT-PT router. For this reason, we recommend NAT-PTs be operat-
ed on a border router that is unique to a V6 stub domain where all IP
packets are either originated from the domain or destined to the do-
main.
NAT-PT is predominantly application independent, with the notable ex-
ception of FTP and a few other applications. As a general rule, ap-
plications that include IP addresses in payload (encrypted or non-
encrypted) will not be supported by NAT-PT. It is recommended that
NAT-PT be complemented with ALGs as necessary to expand the list of
supported applications. Specifications of ALGs, however, 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
Tsirtsis & Srisuresh [Page 4]
Internet Draft Network Address + Protocol Translator March 1998
IPv6 domain is connected to an IPv4 domain through a NAT-PT
3.1 NAT-PT Outgoing Sessions (IPv6 to IPv4)
^
|
[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.0
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.
Tsirtsis & Srisuresh [Page 5]
Internet Draft Network Address + Protocol Translator March 1998
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
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
Tsirtsis & Srisuresh [Page 6]
Internet Draft Network Address + Protocol Translator March 1998
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
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-
Tsirtsis & Srisuresh [Page 7]
Internet Draft Network Address + Protocol Translator March 1998
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.
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.
Two approaches are presented here by which NAT-PT could assign V4
address to a target V6 host.
4.2.1 DNS updates with dynamic V4 address assignments
^
| [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 sub-
net 120.130.26.0
Say Host C wants to communicate with Host A, Host C can not
send a packet to V6 address of Host A because Host C can not
use an IPv6 address and Host A does not have an IPv4 address.
Host A, however, has a DNS name, which has the same format in
IPv4 and IPv6. Host C makes a name lookup through its local
DNS server. The DNS server does not have a record of IPv4 ad-
dress attached to this name so it forwards the request
to a parent server. The request at some point reaches the Pri-
mary DNS server of the IPv6 stub domain, which redirects the
request to the NAT-PT. The NAT-PT returns a valid IPv4 ad-
dress (e.g: from its pool of addresses) to the DNS server
and eventually the reply returns to Host C, while NAT-PT re-
Tsirtsis & Srisuresh [Page 8]
Internet Draft Network Address + Protocol Translator March 1998
tains the address mapping for a fixed amount of time (until
an actual session is initiated). The TTL values on all DNS re-
source records (RRs) returned by NAT-PT would be set to 0.
Host C can now initiate a connection to Host A with an IPv4
packet which includes the following addresses from figure
2: say SA=132.146.243.30 and DA=120.130.26.10.
On receiving the packet, the NAT-PT, recognises the session
and translates the packets and its addresses as normal to
SA=PREFIX::132.146.243.30 and DA= FEDC:BA98::7654:3210.
Note that in the above configuration we assume that the DNS
server of the V6 domain is co-located with the NAT-PT, thus,
the details of the DNS/NAT-PT interaction are an implementation
issue.
Alternatively, a mechanism could be developed to allow communi-
cation between DNS and NAT-PT to dynamically update DNS Re-
source records, even as the two exist on different platforms.
Although the definition of such mechanism is outside the scope
of this document, the use of the DNS Route Through (RT) record
[RFC1183] has been proposed in [NNAT], however, there are con-
cerns that this record is now obsolete.
4.2.2 DNS Request and Response Translation
Here is an alternate approach to making a V4 address assignment
on inbound sessions; One that does not involve dynamic updates
to the DNS server in V6 network. However, this approach does
involve adding DNS extensions to NAT-PT as follows.
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. NAT-
PT would modify the DNS Queries going into V6 domain as fol-
lows:
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) 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 DNS response traverse from the
DNS server on V6 network to V4 host, NAT-PT once again traps
Tsirtsis & Srisuresh [Page 9]
Internet Draft Network Address + Protocol Translator March 1998
the DNS packet and would:
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 wi th 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
be 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 p ool 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.
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 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 multi-
plexing, NAT-PT MUST also make the appropriate adjustments to the up-
Tsirtsis & Srisuresh [Page 10]
Internet Draft Network Address + Protocol Translator March 1998
per layer protocol (TCP/UDP) as well as to the FTP control session
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 must 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 de-
scribed 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
communications and points to the NAT-PT gateway (PRE-
FIX::/96)
Destination Address:
The NAT-PT retains a mapping between the IPv4 DA and
Tsirtsis & Srisuresh [Page 11]
Internet Draft Network Address + Protocol Translator March 1998
the IPv6 address of the destination host. The IPv4 DA
is replaced by the IPv6 address retained in that map-
ping.
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-
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
Tsirtsis & Srisuresh [Page 12]
Internet Draft Network Address + Protocol Translator March 1998
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 ad-
just 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).
Code 2: Translate to an ICMPv6 Parameter Problem (Type
4, Code 1) and make the Pointer point to the IPv6 Pay-
load Type field.
Tsirtsis & Srisuresh [Page 13]
Internet Draft Network Address + Protocol Translator March 1998
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 must use the plateau
values specified in [PMTUv4] to determine a likely
path MTU and include that path MTU in the ICMPv6 pack-
et. (Use the greatest plateau value that is less than
the returned 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 destina-
tion 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 in-
clude 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
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
Tsirtsis & Srisuresh [Page 14]
Internet Draft Network Address + Protocol Translator March 1998
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 IPv4 address from the pool of IPv4 addresses avail-
able. The IPv6 SA is replaced by the above IPv4 ad-
dress.
Destination Address:
Tsirtsis & Srisuresh [Page 15]
Internet Draft Network Address + Protocol Translator March 1998
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 Identifica-
tion 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 header.
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
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
Tsirtsis & Srisuresh [Page 16]
Internet Draft Network Address + Protocol Translator March 1998
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 tak-
ing into account whether or not the packet in error
includes 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
updated to point to the corresponding field in the
translated include IP header.
Unknown error messages
Tsirtsis & Srisuresh [Page 17]
Internet Draft Network Address + Protocol Translator March 1998
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 MUST be recalculated according to the address
change: Source Address for v6 to v4 translation; Destination Ad-
dress 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 must 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 must
be recalculated to account for destination v4 address and destina-
tion 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, NAT-
PT is extended to support FTP application, as FTP happens to be
one of the most popular internet applications.
The arguments to the File Transfer Protocol (FTP) PORT command and
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 must substitute this with the NAT-PT
assigned V4 address. In case of NAPT-PT, even the TCP port follow-
ing the IP address must be translated. The reverse (translation
from v4 address to V6 address) is true in the inbound packets.
Tsirtsis & Srisuresh [Page 18]
Internet Draft Network Address + Protocol Translator March 1998
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 must al-
so be changed to reflect the change in length of FTP control ses-
sion payload. The IP packet length field in V4 header or the IP
payload length in V6 field must 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
It is recommended that NAT-PT is only gateway between the IPv6
stub domain and the IPv4 Internet, since a flow MUST undergo ad-
dress translation using the same IPv6 to IPv4 address (and port
number if used) mapping. Note that NAT-PT does NOT need to be the
only gateway of the IPv6 stub domain to other IPv6 domains. In
this case, a route is required to forward all the outgoing packets
with destination address of the form PREFIX::x.y.z.w (PREFIX::/96)
to the NAT-PT.
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 'class' field in IPv6. When the IPv6 class field be standard-
ised meaningful mapping may be possible. As another example, the
Tsirtsis & Srisuresh [Page 19]
Internet Draft Network Address + Protocol Translator March 1998
option headers semantics and syntax have changed significantly in
IPv6, some meaningful translation may also be possible in the fu-
ture using NAT-PT.
Future revisions of this draft may add functionality to NAT-PT in
order to make IPv4 to IPv6 communication more flexible and com-
plete.
6.3 Impact of Address Translation
Since NAT-PT performs address translation, applications that
carry the IP address in the higher layers (except FTP) will not
work. In this case Application Layer Gateways (ALG) MAY be in-
corporated 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 is not possible for
applications that carry IP addresses to the application layer.
This is an inherent limitation from the Network Address Transla-
tion function.
7. Security Considerations
All security considerations associated with NAT routers, described
in [NAT] as well as those described in [SIIT] are applicable
to NAT-PT.
8. REFERENCES
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Require-
ment Levels", RFC 2119, March 1997.
[NAT] P. Srisuresh, et.al., The IP Network Address Translator (NAT),
ftp://ietf.org/internet-drafts/draft-rfced-info-srisuresh-03.txt,
September 1997
[NNAT] Jim Bound, No Network Address Translation (NNAT) for IPv6
,ftp://ietf.org/internet-drafts/draft-ietf-ngtrans-nnat-00.txt, November
1997
[SIIT] Erik Nordmark, Stateless IP/ICMP Translator (SIIT),
ftp://ietf.org/internet-drafts/draft-ietf-ngtrans-header-trans-01.txt
November 20, 1997
Tsirtsis & Srisuresh [Page 20]
Internet Draft Network Address + Protocol Translator March 1998
AUTHORS
George Tsirtsis
Internet Transport Group
B29 Room 129
BT Laboratoties
Martlesham Heath
IPSWICH
Suffolk IP5 3RE
England
Phone: +44 1473 640756
Fax: +44 1473 640709
e-mail: george@gideon.bt.co.uk
Pyda Srisuresh
Lucent Technologies
Pleasanton, CA 94588-8519
U.S.A.
Voice: (510) 737-2153
Fax: (510) 737-2110
EMail: suresh@livingston.com
DISCLAIMER
Notice: This contribution has been prepared to assist the IETF as a ba-
sis for discussion. It is not a binding proposal on British telecommuni-
cations plc; specifically, British Telecommunications plc reserves the
right to modify, delete and amend any statements contain herein.
Tsirtsis & Srisuresh [Page 21]
Internet Draft Network Address + Protocol Translator March 1998
Tsirtsis & Srisuresh [Page 22]
