RFC relevance of translation

As per Relevance of the word translation, we have this rfc below:

Network Working Group G.
Request for Comments: 2766
Category: Standards Track P.
Campio
February 2000

Network Address Translation - Protocol Translation (NAT-PT

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (2000). All Rights Reserved

This document specifies an IPv4-to-IPv6 transition mechanism,
addition to those already specified in [TRANS]. This
attempts to provide transparent routing, as defined in [NAT-TERM],
end-nodes in V6 realm trying to communicate with end-nodes in V
realm and vice versa. This is achieved using a combination of
Address Translation and Protocol Translation. The scheme
does not mandate dual-stacks (i.e., IPv4 as well as V6
support) or special purpose routing requirements (such as
tunneling support) on end nodes. This scheme is based on
combination of address translation theme as described in [NAT-TERM
and V6/V4 protocol translation theme as described in [SIIT].

Special thanks to Pedro Marques for reviewing an earlier version
this memo. Also, many thanks to Alan O'Neill and Martin Tatham,
the mechanism described in this document was initially
through discussions with them

Tsirtsis & Srisuresh Standards Track [Page 1]

RFC 2766 NAT-PT February 2000

Table of

1. Introduction.................................................. 2
2. Terminology................................................... 3
2.1 Network Address Translation (NAT)......................... 4
2.2 NAT-PT flavors............................................ 4
2.2.1 Traditional-NAT-PT................................... 4
2.2.2 Bi-directional-NAT-PT................................ 5
2.3 Protocol Translation (PT)................................. 5
2.4 Application Level Gateway (ALG)........................... 5
2.5 Requirements.............................................. 5
3. Traditional-NAT-PT operation (V6 to V4)....................... 6
3.1 NAT-PT Outgoing Sessions.................................. 6
3.2 NAPT-PT Outgoing Sessions................................. 7
4. Use of DNS-ALG for Address assignment......................... 8
4.1 V4 Address Assignment for Incoming Connections (V4 to V6). 9
4.2 V4 Address Assignment for Outgoing Connections (V6 to V4). 11
5. Protocol Translation Details.................................. 12
5.1 Translating IPv4 Headers to IPv6 Headers.................. 13
5.2 Translating IPv6 Headers to IPv4 Headers.................. 13
5.3 TCP/UDP/ICMP Checksum Update.............................. 13
6. FTP Application Level Gateway (FTP-ALG) Support............... 14
6.1 Payload modifications for V4 originated FTP sessions...... 15
6.2 Payload modifications for V6 originated FTP sessions...... 16
6.3 Header updates for FTP control packets.................... 16
7. NAT-PT Limitations and Future Work............................ 17
7.1 Topology Limitations...................................... 17
7.2 Protocol Translation Limitations.......................... 17
7.3 Impact of Address Translation............................. 18
7.4 Lack of End-to-End Security............................... 18
7.5 DNS Translation and DNSSEC................................ 18
8. Applicability Statement....................................... 18
9. Security Considerations....................................... 19
10. References................................................... 19
Authors' Addresses............................................... 20
Full Copyright Statement......................................... 21

1.

IPv6 is a new version of the IP protocol designed to modernize IPv
which was designed in the 1970s. IPv6 has a number of advantages
IPv4 that will allow for future Internet growth and will simplify
configuration and administration. IPv6 has a larger address
than IPv4, an addressing model that promotes aggressive
aggregation and a powerful autoconfiguration mechanism. In time,
is expected that Internet growth and a need for a plug-and-
solution will result in widespread adoption of IPv6.

Tsirtsis & Srisuresh Standards Track [Page 2]

RFC 2766 NAT-PT February 2000

There is expected to be a long transition period during which it
be necessary for IPv4 and IPv6 nodes to coexist and communicate.
strong, flexible set of IPv4-to-IPv6 transition and
mechanisms will be required during this transition period

The SIIT proposal [SIIT] describes a protocol translation
that allows communication between IPv6-only and IPv4-only nodes
protocol independent translation of IPv4 and IPv6 datagrams
requiring no state information for the session. The SIIT
assumes that V6 nodes are assigned a V4 address for
with V4 nodes, and does not specify a mechanism for the assignment
these addresses

NAT-PT uses a pool of V4 addresses for assignment to V6 nodes on
dynamic basis as sessions are initiated across V4-V6 boundaries.
V4 addresses are assumed to be globally unique. NAT-PT with
V4 addresses is outside the scope of this document and for
study. NAT-PT binds addresses in V6 network with addresses in V
network and vice versa to provide transparent routing [NAT-TERM]
the datagrams traversing between address realms. This requires
changes to end nodes and IP packet routing is completely
[NAT-TERM] to end nodes. It does, however, require NAT-PT to
the sessions it supports and mandates that inbound and
datagrams pertaining to a session traverse the same NAT-PT router
You will note that the topology restrictions on NAT-PT are the
with those described for V4 NATs in [NAT-TERM]. Protocol
details specified in [SIIT] would be used to extend
translation with protocol syntax/semantics translation. A
applicability statement for NAT-PT may be found at the end of
document in section 7.

By combining SIIT protocol translation with the dynamic
translation capabilities of NAT and appropriate ALGs, NAT-PT
a complete solution that would allow a large number of commonly
applications to interoperate between IPv6-only nodes and IPv4-

A fundamental assumption for NAT-PT is only to be use when no
native IPv6 or IPv6 over IPv4 tunneled means of communication
possible. In other words the aim is to only use translation
IPv6 only nodes and IPv4 only nodes, while translation between IPv
only nodes and the IPv4 part of a dual stack node should be
over other alternatives

2.

The majority of terms used in this document are borrowed almost as
from [NAT-TERM]. The following lists terms specific to this document

Tsirtsis & Srisuresh Standards Track [Page 3]

RFC 2766 NAT-PT February 2000

2.1 Network Address Translation (NAT

The term NAT in this document is very similar to the IPv4
described in [NAT-TERM], but is not identical. IPv4 NAT
one IPv4 address into another IPv4 address. In this document,
refers to translation of an IPv4 address into an IPv6 address
vice versa

While the V4 NAT [NAT-TERM] provides routing between private V4
external V4 address realms, NAT in this document provides
between a V6 address realm and an external V4 address realm

2.2 NAT-PT

Just as there are various flavors identified with V4 NAT in [NAT
TERM], the following NAT-PT variations may be identified in
document

2.2.1 Traditional NAT-

Traditional-NAT-PT would allow hosts within a V6 network to
hosts in the V4 network. In a traditional-NAT-PT, sessions are uni
directional, outbound from the V6 network. This is in contrast
Bi-directional-NAT-PT, which permits sessions in both inbound
outbound directions

Just as with V4 traditional-NAT, there are two variations
traditional-NAT-PT, namely Basic-NAT-PT and NAPT-PT

With Basic-NAT-PT, a block of V4 addresses are set aside
translating addresses of V6 hosts as they originate sessions to
V4 hosts in external domain. For packets outbound from the V6 domain
the source IP address and related fields such as IP, TCP, UDP
ICMP header checksums are translated. For inbound packets,
destination IP address and the checksums as listed above
translated

NAPT-PT extends the notion of translation one step further by
translating transport identifier (e.g., TCP and UDP port numbers
ICMP query identifiers). This allows the transport identifiers of
number of V6 hosts to be multiplexed into the transport
of a single assigned V4 address. NAPT-PT allows a set of V6 hosts
share a single V4 address. Note that NAPT-PT can be combined
Basic-NAT-PT so that a pool of external addresses are used
conjunction with port translation

Tsirtsis & Srisuresh Standards Track [Page 4]

RFC 2766 NAT-PT February 2000

For packets outbound from the V6 network, NAPT-PT would translate
source IP address, source transport identifier and related
such as IP, TCP, UDP and ICMP header checksums. Transport
can be one of TCP/UDP port or ICMP query ID. For inbound packets,
destination IP address, destination transport identifier and the
and transport header checksums are translated

2.2.2 Bi-Directional-NAT-

With Bi-directional-NAT-PT, sessions can be initiated from hosts
V4 network as well as the V6 network. V6 network addresses are
to V4 addresses, statically or dynamically as connections
established in either direction. The name space (i.e., their
Qualified Domain Names) between hosts in V4 and V6 networks
assumed to be end-to-end unique. Hosts in V4 realm access V6-
hosts by using DNS for address resolution. A DNS-ALG [DNS-ALG]
be employed in conjunction with Bi-Directional-NAT-PT to
name to address mapping. Specifically, the DNS-ALG must be
of translating V6 addresses in DNS Queries and responses into
V4-address bindings, and vice versa, as DNS packets traverse
V6 and V4 realms

2.3 Protocol Translation (PT

PT in this document refers to the translation of an IPv4 packet
a semantically equivalent IPv6 packet and vice versa.
translation details are described in [SIIT].

2.4 Application Level Gateway (ALG

Application Level Gateway (ALG) [NAT-TERM] is an application
agent that allows a V6 node to communicate with a V4 node and
versa. Some applications carry network addresses in payloads. NAT-
is application unaware and does not snoop the payload. ALG could
in conjunction with NAT-PT to provide support for many
applications

2.5

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
document, are to be interpreted as described in [KEYWORDS].

Tsirtsis & Srisuresh Standards Track [Page 5]

RFC 2766 NAT-PT February 2000

3. Traditional-NAT-PT Operation (V6 to V4)

NAT-PT offers a straight forward solution based on
routing [NAT-TERM] and address/protocol translation, allowing a
number of applications in V6 and V4 realms to inter-operate
requiring any changes to these applications

In the following paragraphs we describe the operation
traditional-NAT-PT and the way that connections can be initiated
a host in IPv6 domain to a host in IPv4 domain through
traditional-NAT-

3.1 Basic-NAT-PT

[IPv6-B]-+
| +==============+
[IPv6-A]-+-[NAT-PT]---------| IPv4 network |--[IPv4-C
| +==============+
(pool of v4 addresses

Figure 1: IPv6 to IPv4
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
120.130.26/24

The V4 addresses in the address pool could be allocated one-to-one
the V6 addresses of the V6 end nodes in which case one needs as
V4 addresses as V6 end points. In this document we assume that the V
network has less V4 addresses than V6 end nodes and thus
address allocation is required for at least some of them

Say the IPv6 Node A wants to communicate with the IPv4 Node C.
A creates a packet with

Source Address, SA=FEDC:BA98::7654:3210 and
Address, DA = PREFIX::132.146.243.30

NOTE: The prefix PREFIX::/96 is advertised in the stub domain by
NAT-PT, and packets addressed to this PREFIX will be routed to
NAT-PT. The pre-configured PREFIX only needs to be routable
the IPv6 stub domain and as such it can be any routable prefix
the network administrator chooses

The packet is routed via the NAT-PT gateway, where it is
to IPv4.

Tsirtsis & Srisuresh Standards Track [Page 6]

RFC 2766 NAT-PT February 2000

If the outgoing packet is not a session initialisation packet,
NAT-PT SHOULD already have stored some state about the
session, including assigned IPv4 address and other parameters for
translation. If this state does not exist, the packet SHOULD
silently discarded

If the packet is a session initialisation packet, the NAT-PT
allocates an address (e.g: 120.130.26.10) from its pool
addresses and the packet is translated to IPv4. The
parameters are cached for the duration of the session and the IPv6
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
session by NAT-PT. NAT-PT will use the state information to
the packet, and the resulting addresses will
SA=PREFIX::132.146.243.30, DA=FEDC:BA98::7654:3210. Note that
packet can now be routed inside the IPv6-only stub network as normal

3.2 NAPT-PT

NAPT-PT, which stands for "Network Address Port Translation +
Protocol Translation", would allow V6 nodes to communicate with
V4 nodes transparently using a single V4 address. The TCP/UDP
of the V6 nodes are translated into TCP/UDP ports of the
V4 address

While NAT-PT support is limited to TCP, UDP and other
multiplexing type of applications, NAPT-PT solves a problem that
inherent with NAT-PT. That is, NAT-PT would fall flat when the
of V4 addresses assigned for translation purposes is exhausted.
the address pool is exhausted, newer V6 nodes cannot
sessions with the outside world anymore. NAPT-PT, on the other hand
will allow for a maximum of 63K TCP and 63K UDP sessions per IPv
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
border router (instead of NAT-PT) and all V6 addresses could
mapped to a single v4 address 120.130.26.10.

IPv6 Node A would establish a TCP session with the IPv4 Node C
follows

Node A creates a packet with

Source Address, SA=FEDC:BA98::7654:3210 , source TCP port = 3017
Destination Address, DA = PREFIX::132.146.243.30, destination
port = 23.

Tsirtsis & Srisuresh Standards Track [Page 7]

RFC 2766 NAT-PT February 2000

When the packet reaches the NAPT-PT box, NAPT-PT would assign one
the TCP ports from the assigned V4 address to translate the tuple
(Source Address, Source TCP port) as follows

SA=120.130.26.10, source TCP port = 1025
DA=132.146.243.30, destination TCP port = 23.

The returning traffic from 132.146.243.30, TCP port 23 will
recognised as belonging to the same session and will be
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 service
assigned via static TCP/UDP port mapping. For example, the
[IPv6-A] in figure 1 may be the only HTTP server (port 80) in the V
domain. Node [IPv4-C] sends a packet

SA=132.146.243.30, source TCP port = 1025
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
a destination port of 80 will be redirected to the same node [IPv6-
A].

4. Use of DNS-ALG for Address

An IPv4 address is assigned by NAT-PT to a V6 node when NAT-
identifies the start of session, inbound or outbound.
of the start of a new inbound session is performed differently
for outbound sessions. However, the same V4 address pool is used
assignment to V6 nodes, irrespective of whether a session
initiated outbound from a V6 node or initiated inbound from a V
node

Policies determining what type of sessions are allowed and in
direction and from/to which nodes is out of the scope of
document

Tsirtsis & Srisuresh Standards Track [Page 8]

RFC 2766 NAT-PT February 2000

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
"AAAA" records. "A6" records have also been defined but at the
of writing they are neither fully standardized nor deployed

In any case, the DNS-ALG's principle of operation described in
section is the same with either "AAAA" or "A6" records. The
difference is that a name resolution using "A6" records may
more than one query - reply pairs. The DNS-ALG SHOULD, in that case
track all the replies in the transaction before translating an "A6"
record to an "A" record

One of the aims of NAT-PT design is to only use translation
there is no other means of communication, such as native IPv6 or
form of tunneling. For the following discussion NAT-PT, in
to the IPv4 connectivity that it has it may also have a native IPv
and/or a tunneled IPv6 connection

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
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
120.130.26/24

In figure 2 above, when Node C's name resolver sends a name look
request for Node A, the lookup query is directed to the DNS server
the V6 network. Considering that NAT-PT is residing on the
router between V4 and V6 networks, this request datagram
traverse through the NAT-PT router. The DNS-ALG on the NAT-PT
would modify DNS Queries for A records going into the V6 domain
follows: (Note that a TCP/UDP DNS packet is recognised by the
that its source or destination port number is 53)

a) For Node Name to Node Address Query requests: Change the
type from "A" to "AAAA" or "A6".

Tsirtsis & Srisuresh Standards Track [Page 9]

RFC 2766 NAT-PT February 2000

b) For Node address to Node name query requests: Replace
string "IN-ADDR.ARPA" with the string "IP6.INT". Replace
V4 address octets (in reverse order) preceding the string "IN
ADDR.ARPA" with the corresponding V6 address (if there exists
map) octets in reverse order

In the opposite direction, when a DNS response traverses from the
server on the V6 network to the V4 node, the DNS-ALG once
intercepts the DNS packet and would

a) Translate DNS responses for "AAAA" or "A6" records into "A
records, (only translate "A6" records when the name
completely been resolved
b) Replace the V6 address resolved by the V6 DNS with the V
address internally assigned by the NAT-PT router

If a V4 address is not previously assigned to this V6 node, NAT-
would assign one at this time. As an example say IPv4-C attempts
initialise a session with node IPv6-A by making a name lookup ("A
record) for Node-A . The name query goes to the local DNS and
there it is propagated to the DNS server of the IPv6 network.
DNS-ALG intercepts and translates the "A" query to "AAAA" or "A6"
query and then forwards it to the DNS server in the IPv6
which replies as follows: (The example uses AAAA records
convenience

Node-A AAAA FEDC:BA98::7654:3210,

this is returned by the DNS server and gets intercepted
translated by the DNS-ALG to

Node-A A 120.130.26.1

The DNS-ALG also holds the mapping between FEDC:BA98::7654:3210
120.130.26.1 in NAT-PT. The "A" record is then returned to Node-C
Node-C can now initiate a session as follows

SA=132.146.243.30, source TCP port = 1025
DA=120.130.26.1, destination TCP port = 80

the packet will be routed to NAT-PT, which since it already holds
mapping between FEDC:BA98::7654:3210 and 120.130.26.1 can
the packet to

SA=PREFIX::132.146.243.30, source TCP port = 1025
DA=FEDC:BA98::7654:3210, destination TCP port = 80

the communication can now proceed as normal

Tsirtsis & Srisuresh Standards Track [Page 10]

RFC 2766 NAT-PT February 2000

The TTL values on all DNS resource records (RRs) passing
NAT-PT SHOULD be set to 0 so that DNS servers/clients do not
temporarily assigned RRs. Note, however, that due to some buggy
client implementations a value of 1 might in some cases work better
The TTL values should be left unchanged for statically
addresses

Address mappings for incoming sessions, as described above,
subject to denial of service attacks since one can make
queries for nodes residing in the V6 network causing the DNS-ALG
map all V4 addresses in NAT-PT and thus block legitimate
sessions. Thus, address mappings for incoming sessions should
out to minimise the effect of denial of service attacks
Additionally, one IPv4 address (using NAPT-PT, see 3.2) could
reserved for outgoing sessions only to minimise the effect of
attacks to outgoing sessions

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 V
domain or from the DNS server internal to the V6 network.
recommend that DNS servers internal to V6 domains maintain a
of names to IPv6 addresses for internal nodes and possibly
mappings for some external nodes. In the case where the DNS server
the v6 domain contains the mapping for external V4 nodes, the
queries will not cross the V6 domain and that would obviate the
for DNS-ALG intervention. Otherwise, the queries will cross the V
domain and are subject to DNS-ALG intervention. We
external DNS servers in the V4 domain cache name mapping for
nodes (i.e., V4 nodes) only. Zone transfers across IPv4 - IPv
boundaries are strongly discouraged

In the case of NAPT-PT, a TCP/UDP source port is assigned from
registered V4 address upon detection of each new outbound session

We saw that a V6 node that needs to communicate with a V4 node
to use a specific prefix (PREFIX::/96) in front of the IPv4
of the V4 node. The above technique allows the use of this
without any configuration in the nodes

To create another example from Figure 2 say Node-A wants to set up
session with Node-C. For this Node-A starts by making a name look-
("AAAA" or "A6" record) for Node-C

Since Node-C may have IPv6 and/or IPv4 addresses, the DNS-ALG on
NAT-PT device forwards the original AAAA/A6 query to the external
system unchanged, as well as an A query for the same node. If
AAAA/A6 record exists for the destination, this will be returned

Tsirtsis & Srisuresh Standards Track [Page 11]

RFC 2766 NAT-PT February 2000

NAT-PT which will forward it, also unchanged, to the
host

If there is an A record for Node-C the reply also returns to
NAT-PT. The DNS-ALG then, translates the reply adding the
PREFIX and forwards it to the originating device with any IPv
addresses that might have learned. So, if the reply

NodeC A 132.146.243.30, it is translated
NodeC AAAA PREFIX::132.146.243.30 or
NodeC A6 PREFIX::132.146.243.30

Now Node A can use this address like any other IPv6 address and
V6 DNS server can even cache it as long as the PREFIX does
change

An issue here is how the V6 DNS server in the V6 stub domain talks
the V4 domain outside the V6 stub domain. Remember that there are
dual stack nodes here. The external V4 DNS server needs to point to
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 V
address of the internal V6 DNS server. In the other direction, the V
DNS server points to a V6 address formed by the IPv4 address of
external V4 DNS servers and the prefix (PREFIX::/96) that
non IPv6 nodes. This mechanism can easily be extended to
secondary DNS servers

Note that the scheme described in this section impacts DNSSEC.
section 7.5 of this document for details

5. Protocol Translation

The IPv4 and ICMPv4 headers are similar to their V6 counterparts
a number of field are either missing, have different meaning
different length. NAT-PT SHOULD translate all IP/ICMP headers from v
to v6 and vice versa in order to make end-to-end IPv6 to IPv
communication possible. Due to the address translation function
possible port multiplexing, NAT-PT SHOULD also make
adjustments to the upper layer protocol (TCP/UDP) headers. A
section on FTP-ALG describes the changes FTP-ALG would make to
payload as an FTP packet traverses from V4 to V6 realm or vice versa

Protocol Translation details are described in [SIIT], but there
some modifications required to SIIT because of the fact that NAT-
also performs Network Address Translation

Tsirtsis & Srisuresh Standards Track [Page 12]

RFC 2766 NAT-PT February 2000

5.1 Translating IPv4 headers to IPv6

This is done exactly the same as in SIIT apart from the
fields

Source Address
The low-order 32 bits is the IPv4 source address. The high
order 96 bits is the designated PREFIX for all v
communications. Addresses using this PREFIX will be
to the NAT-PT gateway (PREFIX::/96)

Destination Address
NAT-PT retains a mapping between the IPv4
address and the IPv6 address of the destination node.
IPv4 destination address is replaced by the IPv6
retained in that mapping

5.2 Translating IPv6 headers to IPv4

This is done exactly the same as in SIIT apart from the
Address which should be determined as follows

Source Address
The NAT-PT retains a mapping between the IPv6 source
and an IPv4 address from the pool of IPv4
available. The IPv6 source address is replaced by the IPv
address retained in that mapping

Destination Address
IPv6 packets that are translated have a destination
of the form PREFIX::IPv4/96. Thus the low-order 32 bits
the IPv6 destination address is copied to the IPv
destination address

5.3 TCP/UDP/ICMP Checksum

NAT-PT retains mapping between IPv6 address and an IPv4 address
the pool of IPv4 addresses available. This mapping is used in
translation of packets that go through NAT-PT

The following sub-sections describe TCP/UDP/ICMP checksum
procedure in NAT-PT, as packets are translated from V4 to V6 and
versa

Tsirtsis & Srisuresh Standards Track [Page 13]

RFC 2766 NAT-PT February 2000

5.3.1 TCP/UDP/ICMP Checksum Update from IPv4 to IPv

UDP checksums, when set to a non-zero value, and TCP checksum
be recalculated to reflect the address change from v4 to v6.
incremental checksum adjustment algorithm may be borrowed from [NAT].
In the case of NAPT-PT, TCP/UDP checksum should be adjusted
account for the address and TCP/UDP port changes, going from V4 to V
address

When the checksum of a V4 UDP packet is set to zero, NAT-PT
evaluate the checksum in its entirety for the V6-translated
packet. If a V4 UDP packet with a checksum of zero arrives
fragments, NAT-PT MUST await all the fragments until they can
assembled into a single non-fragmented packet and evaluate
checksum prior to forwarding the translated V6 UDP packet

ICMPv6, unlike ICMPv4, uses a pseudo-header, just like UDP and
during checksum computation. As a result, when the ICMPv6
checksum is computed [SIIT], the checksum needs to be adjusted
account for the additional pseudo-header. Note, there may also
adjustments required to the checksum due to changes in the source
destination addresses (and changes in TCP/UDP/ICMP identifiers in
case of NAPT-PT) of the payload carried within ICMP

5.3.2 TCP/UDP/ICMP Checksum Update from IPv6 to IPv

TCP and UDP checksums SHOULD be recalculated to reflect the
change from v6 to v4. The incremental checksum adjustment
may be borrowed from [NAT]. In the case of NAPT-PT, TCP/UDP
should be adjusted to account for the address and TCP/UDP
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
from the V6 ICMP header by running the checksum adjustment
[NAT] to remove the V6 pseudo header from the computation. Note,
adjustment must additionally take into account changes to
checksum as a result of updates to the source and
addresses (and transport ports in the case of NAPT-PT) made to
payload carried within ICMP

6. FTP Application Level Gateway (FTP-ALG)

Because an FTP control session carries, in its payload, the
address and TCP port information for the data session, an FTP-ALG
required to provide application level transparency for this
Internet application

Tsirtsis & Srisuresh Standards Track [Page 14]

RFC 2766 NAT-PT February 2000

In the FTP application running on a legacy V4 node, arguments to
FTP PORT command and arguments in PASV response(successful)
an IP V4 address and a TCP port, both represented in ASCII
h1,h2,h3,h4,p1,p2. However, [FTP-IPV6] suggests EPRT and EPSV
extensions to FTP, with an intent to eventually retire the use
PORT and PASV commands. These extensions may be used on a V4 or V
node. FTP-ALG, facilitating transparent FTP between V4 and V6 nodes
works as follows

6.1 Payload modifications for V4 originated FTP

A V4 host may or may not have the EPRT and EPSV command
implemented in its FTP application. If a V4 host originates the
session and uses PORT or PASV command, the FTP-ALG will
these commands into EPRT and EPSV commands respectively prior
forwarding to the V6 node. Likewise, EPSV response from V6 nodes
be translated into PASV response prior to forwarding to V4 nodes
The format of EPRT and EPSV commands and EPSV response may
specified as follows[FTP-IPV6].

EPRT EPSV (or
EPSV

Format of EPSV response(Positive): 229 extended passive mode> ()

PORT command from a V4 node is translated into EPRT command,
setting the protocol field to AF #2 (IPV6) and
the V4 host Address (represented as h1,h2,h3,h4) into its NAT-
assigned V6 address in string notation, as defined in [V6ADDR] in
field. TCP port represented by p1,p2 in PORT command
be specified as a decimal in the EPRT command. Further
translation may also be required in the case of NAPT-PT
PASV command from a V4 node is be translated into a EPSV command
the argument set to AF #2. EPSV response from a V6 node
translated into PASV response prior to forwarding to the target V
host

If a V4 host originated the FTP session and was using EPRT and
commands, the FTP-ALG will simply translate the parameters to
commands, without altering the commands themselves. The
Number field will be translated from AF #1 to AF #2.
will be translated from the V4 address in ASCII to
NAT-PT assigned V6 address in string notation as defined in [V6ADDR].
argument in EPSV response requires translation only in
case of NAPT-PT

Tsirtsis & Srisuresh Standards Track [Page 15]

RFC 2766 NAT-PT February 2000

6.2 Payload modifications for V6 originated FTP

If a V6 host originates the FTP session, however, the FTP-ALG has
approaches to pursue. In the first approach, the FTP-ALG will
the command strings "EPRT" and "EPSV" unaltered and simply
the , and arguments from V6 to
NAT-PT (or NAPT-PT) assigned V4 information. is
only in the case of NAPT-PT. Same goes for EPSV response from V
node. This is the approach we recommend to ensure forward support
RFC 2428. However, with this approach, the V4 hosts are mandated
have their FTP application upgraded to support EPRT and
extensions to allow access to V4 and V6 hosts, alike

In the second approach, the FTP-ALG will translate the
strings "EPRT" and "EPSV" and their parameters from the V6 node
their equivalent NAT-PT assigned V4 node info and attach to "PORT
and "PASV" commands prior to forwarding to V4 node. Likewise,
response from V4 nodes is translated into EPSV response prior
forwarding to the target V6 nodes. However, the FTP-ALG would
unable to translate the command "EPSVALL" issued by V6 nodes
In such a case, the V4 host, which receives the command, may
an error code indicating unsupported function. This error
may cause many RFC 2428 compliant FTP applications to simply fail
because EPSV support is mandated by RFC 2428. The benefit of
approach, however, is that is does not impose any FTP
requirements on V4 hosts

6.3 Header updates for FTP control

All the payload translations considered in the previous sections
based on ASCII encoded data. As a result, these translations
result in a change in the size of packet

If the new size is the same as the previous, only the TCP
needs adjustment as a result of the payload translation. If the
size is different from the previous, TCP sequence numbers should
be changed to reflect the change in the length of the FTP
session payload. The IP packet length field in the V4 header or
IP payload length field in the V6 header should also be changed
reflect the new payload size. A table is used by the FTP-ALG
correct the TCP sequence and acknowledgement numbers in the
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
of the session, sequence number delta for outbound control
and sequence number delta for inbound control packets

Tsirtsis & Srisuresh Standards Track [Page 16]

RFC 2766 NAT-PT February 2000

The sequence number for an outbound control packet is increased
the outbound sequence number delta, and the acknowledgement
for the same outbound packet is decreased by the inbound
number delta. Likewise, the sequence number for an inbound packet
increased by the inbound sequence number delta and
acknowledgement number for the same inbound packet is decreased
the outbound sequence number delta

7. NAT-PT Limitations and Future

All limitations associated to NAT [NAT-TERM] are also associated
NAT-PT. Here are the most important of them in detail, as well
some unique to NAT-PT

7.1 Topology

There are limitations to using the NAT-PT translation method. It
mandatory that all requests and responses pertaining to a session
routed via the same NAT-PT router. One way to guarantee this would
to have NAT-PT based on a border router that is unique to a
domain, where all IP packets are either originated from the domain
destined to the domain. This is a generic problem with NAT and it
fully described in [NAT-TERM].

Note, this limitation does not apply to packets originating from
directed to dual-stack nodes that do not require packet translation
This is because in a dual-stack set-up, IPv4 addresses implied in
V6 address can be identified from the address format PREFIX::x.y.z.
and a dual-stack router can accordingly route a packet between v4
dual-stack nodes without tracking state information

This should also not affect IPv6 to IPv6 communication and in
only actually use translation when no other means of communication
possible. For example NAT-PT may also have a native IPv6
and/or some kind of tunneled IPv6 connection. Both of the
connections should be preferred over translation when possible.
above makes sure that NAT-PT is a tool only to be used to
transition to native IPv6 to IPv6 communication

7.2 Protocol Translation

A number of IPv4 fields have changed meaning in IPv6 and
is not straightforward. For example, the option headers semantics
syntax have changed significantly in IPv6. Details of IPv4 to IPv
Protocol Translation can be found in [SIIT].

Tsirtsis & Srisuresh Standards Track [Page 17]

RFC 2766 NAT-PT February 2000

7.3 Impact of Address

Since NAT-PT performs address translation, applications that
the IP address in the higher layers will not work. In this
Application Layer Gateways (ALG) need to be incorporated to
support for those applications. This is a generic problem with
and it is fully described in [NAT-TERM].

7.4 Lack of end-to-end

One of the most important limitations of the NAT-PT proposal is
fact that end-to-end network layer security is not possible.
transport and application layer security may not be possible
applications that carry IP addresses to the application layer.
is an inherent limitation of the Network Address
function

Independent of NAT-PT, end-to-end IPSec security is not
across different address realms. The two end-nodes that seek
network level security must both support one of IPv4 or IPv6.

7.5 DNS Translation and

The scheme described in section 4.2 involves translation of
messages. It is clear that this scheme can not be deployed
combination with secure DNS. I.e., an authoritative DNS name
in the V6 domain cannot sign replies to queries that originate
the V4 world. As a result, an V4 end-node that demands DNS
to be signed will reject replies that have been tampered with
NAT-PT

The good news, however, is that only servers in V6 domain that
to be accessible from the V4 world pay the price for the
limitation, as V4 end-nodes may not access V6 servers due to
replies not being signed

Also note that zone transfers between DNS-SEC servers within the
V6 network are not impacted

Clearly, with DNS SEC deployment in DNS servers and end-
resolvers, the scheme suggested in this document would not work

8. Applicability

NAT-PT can be a valuable transition tool at the border of a
network that has been deployed as an IPv6 only network when it
connected to an Internet that is either V4-only or a combination
V4 and V6.

Tsirtsis & Srisuresh Standards Track [Page 18]

RFC 2766 NAT-PT February 2000

NAT-PT, in its simplest form, without the support of DNS-ALG
provides one way connectivity between an IPv6 stub domain and
IPv4 world meaning that only sessions initialised by IPv6
internal to the IPv6 stub domain can be translated, while
initiated by IPv4 nodes are dropped. This makes NAT-PT a
tool to IPv6 only stub networks that need to be able to
connectivity with the IPv4 world without the need to deploy
visible to the IPv4 world

NAT-PT combined with a DNS-ALG provides bi-directional
between the IPv6 stub domain and the IPv4 world allowing sessions
be initialised by IPv4 nodes outside the IPv6 stub domain.
makes NAT-PT useful for IPv6 only stub networks that need to
servers visible to the IPv4 world

Some applications count on a certain degree of address stability
their operation. Dynamic address reuse by NAT-PT might not
agreeable for these applications. For hosts running such
critical applications, NAT-PT may be configured to provide
address mapping between the host's V6 address and a specific V
address. This will ensure that address related changes by NAT-PT
not become a significant source of operational failure

9. Security

Section 7.4 of this document states that end-to-end network
transport layer security are not possible when a session
intercepted by a NAT-PT. Also application layer security may not
possible for applications that carry IP addresses in the
layer

Section 7.5 of this document states that the DNS-ALG can not
deployed in combination with secure DNS

Finally, all of the security considerations described in [NAT-TERM
are applicable to this document as well

10.

[DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A
Heffernan, "DNS extensions to Network Address
(DNS_ALG)", RFC 2694, September 1999.

[DNSSEC] Eastlake, D., "Domain Name System Security Extensions",
RFC 2065, March 1999.

[FTP-IPV6] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions
IPv6 and NATs", RFC 2428, September 1998.

Tsirtsis & Srisuresh Standards Track [Page 19]

RFC 2766 NAT-PT February 2000

[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.

[NAT] Egevang, K. and P. Francis, "The IP Network
Translator (NAT)", RFC 1631, May 1994.

[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network
Translator (NAT) Terminology and Considerations",
2663, August 1999.

[SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)",
2765, February 2000.

[TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms
IPv6 Hosts and Routers", RFC 1933, April 1996.

[V6ADDR] Hinden, R. and S. Deering, "IP Version 6
Architecture", RFC 2373, July 1998.

Authors'

George
Internet
B29 Room 129
BT Adastral
IPSWICH IP5 3

Phone: +44 181 8260073
Fax: +44 181 8260073
EMail: george.tsirtsis@bt.
EMail (alternative): gtsirt@hotmail.

Pyda
630 Alder
Milpitas, CA 95035
U.S.A

Phone: (408) 519-3849
EMail: srisuresh@yahoo.

Tsirtsis & Srisuresh Standards Track [Page 20]

RFC 2766 NAT-PT February 2000

Full Copyright

Copyright (C) The Internet Society (2000). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Tsirtsis & Srisuresh Standards Track [Page 21]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX