Internet DRAFT - draft-daniel-natpt-bis
draft-daniel-natpt-bis
Network Working Group S. Daniel Park
Internet-Draft SAMSUNG Electronics
Expires: April 22, 2006 S. Sivakumar
Obsoletes: RFC2766 Cisco Systems, Inc.
P. Srisuresh
Caymas Systems
T. Hain
Cisco Systems, Inc.
October 22, 2005
Network Address Translation - Protocol Translation (NAT-PT)
draft-daniel-natpt-bis-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document specifies an IPv4-to-IPv6 transition mechanism. This
solution attempts to provide transparent routing to end-nodes in V6
realm trying to communicate with end-nodes in V4 realm and vice
versa. This is achieved using a combination of Network Address
Park, et al. Expires April 22, 2006 [Page 1]
Internet-Draft NATPT-bis October 2005
Translation and Protocol Translation. The scheme described does not
mandate dual stacks (i.e., IPv4 as well as V6 protocol support) or
special purpose routing requirements (such as requiring tunneling
support) on end nodes. This scheme is based on a combination of
address translation scheme and V6/V4 protocol translation scheme.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 NAT-PT scope and applicability statement . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 V4 address realm and V6 address realm . . . . . . . . . . 5
2.2 Network Address Translation (NAT) . . . . . . . . . . . . 5
2.3 NAT-PT flavors . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Traditional NAT-PT . . . . . . . . . . . . . . . . . . 6
2.3.2 Bi-directional NAT-PT . . . . . . . . . . . . . . . . 6
2.3.3 Protocol Translation (PT) . . . . . . . . . . . . . . 7
2.3.4 Pool of V4 addresses . . . . . . . . . . . . . . . . . 7
3. Traditional NAT-PT operation overview . . . . . . . . . . . . 7
3.1 Basic NAT-PT Session processing (V6 to v4) . . . . . . . . 7
3.2 NAPT-PT Outgoing Session processing (V6 to V4) . . . . . . 8
4. Bi-directional NAT-PT operation overview . . . . . . . . . . . 10
4.1 Static address mapping within NAT-PT . . . . . . . . . . . 10
5. Translation phases within NAT-PT . . . . . . . . . . . . . . . 11
5.1 Address (and port) binding . . . . . . . . . . . . . . . . 11
5.2 NAT-PT session flows . . . . . . . . . . . . . . . . . . . 12
5.3 IP and TCP/UDP/ICMP header translations . . . . . . . . . 12
5.3.1 IPv4 Headers to IPv6 Headers . . . . . . . . . . . . . 12
5.3.2 Translating IPv6 Headers to IPv4 Headers . . . . . . . 13
5.4 TCP/UDP/ICMP Checksum update . . . . . . . . . . . . . . . 13
5.4.1 TCP/UDP/ICMP Checksum update from IPv4 to IPv6 . . . . 13
5.4.2 TCP/UDP/ICMP Checksum update from IPv6 to IPv4 . . . . 14
5.5 Address (and Port) unbinding . . . . . . . . . . . . . . . 14
6. Use case scenarios . . . . . . . . . . . . . . . . . . . . . . 14
6.1 Scenario 1 - Small devices that runs single stack . . . . 15
6.2 Scenario 2 - IPv4 Server running a legacy application . . 15
6.3 Scenario 3 - IPv6 only networks . . . . . . . . . . . . . 15
6.4 Scenario 4 - IPv6 3GPP networks . . . . . . . . . . . . . 16
7. Support for application level transparency . . . . . . . . . . 16
8. Known limitations . . . . . . . . . . . . . . . . . . . . . . 16
8.1 Topology limitations . . . . . . . . . . . . . . . . . . . 16
8.2 Protocol translation limitations . . . . . . . . . . . . . 17
8.3 Impact of address translation . . . . . . . . . . . . . . 17
8.4 Lack of end-to-end security . . . . . . . . . . . . . . . 17
8.5 DNS translation and DNSSEC . . . . . . . . . . . . . . . . 18
9. Security considerations . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
11. Change history . . . . . . . . . . . . . . . . . . . . . . . 18
Park, et al. Expires April 22, 2006 [Page 2]
Internet-Draft NATPT-bis October 2005
11.1 Since RFC 2766 . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
12.2 Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 21
Park, et al. Expires April 22, 2006 [Page 3]
Internet-Draft NATPT-bis October 2005
1. Introduction
IPv6 is a new version of the IP protocol designed to modernize IPv4
which was designed in the 1970s. IPv6 has a number of advantages
over IPv4 that will allow for future Internet growth and will
simplify IP configuration and administration. IPv6 has a larger
address space than IPv4, an addressing model that promotes aggressive
route aggregation and a powerful autoconfiguration mechanism. In
time, it is expected that Internet growth and a need for a
plug-and-play solution will result in widespread adoption of IPv6.
There is expected to be a long transition period during which it will
be necessary for IPv4 and IPv6 nodes to coexist and communicate. A
strong, flexible set of IPv4-to-IPv6 transition and coexistence
mechanisms will be required during this transition period.
The SIIT proposal [RFC2765] describes a protocol translation
mechanism that allows communication between IPv6-only and IPv4-only
nodes via protocol independent translation of IPv4 and IPv6
datagrams, requiring no state information for the session. The SIIT
proposal assumes that V6 nodes are assigned a V4 address for
communicating with V4 nodes, and does not specify a mechanism for the
assignment of these addresses.
NAT-PT uses a pool of V4 addresses for translation purposes, as
sessions are initiated across V6-V4 address realms. NAT-PT binds
addresses in V6 network with addresses in V4 network and vice versa
to provide transparent routing [RFC2663] for the datagrams traversing
between address realms. This requires no changes to end nodes and IP
packet routing is completely transparent [RFC2663] to end nodes. It
does, however, require NAT-PT to track the sessions it supports and
mandates that inbound and outbound datagrams pertaining to a session
traverse the same NAT-PT router. You will note that the topology
restrictions on NAT-PT are the same with those described for V4 NATs
in [RFC2663]. Protocol translation details specified in [RFC2765]
would be used to extend address translation with protocol syntax/
semantics translation.
Given the limitations of address translation between V4 and V6 realm,
it is recommended to use NAT-PT only in the cases where the two
end-nodes do not have a common IP stack (i.e., IPv4 or IPv6).
[RFC4213] specifies other translation mechanisms available when both
end-nodes have a common IP stack.
1.1 NAT-PT scope and applicability statement
NAT-PT can be a valuable transition tool at the border of a stub
network that has been deployed as an IPv6 only network when it is
Park, et al. Expires April 22, 2006 [Page 4]
Internet-Draft NATPT-bis October 2005
connected to an Internet that is either V4-only or a combination of
V4 and V6. if a node has both V4 and V6 stack as dual stack
architecture, NAT-PT may not be required for this case.
Traditional NAT-PT is the simplest form to provide one way
connectivity from an IPv6 stub domain to the IPv4 world meaning that
only sessions initialised by IPv6 nodes internal to the IPv6 stub
domain can be translated, while sessions initiated by IPv4 nodes are
dropped. This makes NAT-PT a useful tool to IPv6 only stub networks
that need to be able to maintain connectivity with the IPv4 world
without the need to deploy servers visible to the IPv4 world.
Bi-directional NAT-PT allows sessions to be initiated from either
domain - V6 domain or V4 domain. Only static address mapping in the
context of bi-directional NAT-PT is discussed. Dynamic address
mappings are outside of the scope of this document as that would
require a DNS-ALG to be present, either as an extension to NAT-PT on
the same device (or) as an external entity interfacing with the
NAT-PT device.
2. Terminology
The majority of terms used in this document are borrowed almost as is
from [RFC2663]. The following lists terms specific to this document.
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 [RFC2119].
2.1 V4 address realm and V6 address realm
As described in [RFC2663], an address realm is a network domain in
which the network addresses are uniquely assigned to entities such
that datagrams can be routed to them. In this document, V4(V6)
address realm means IPv4(IPv6) addresses are uniquely assigned to
entities within the network domain along with NAT-PT.
2.2 Network Address Translation (NAT)
The term NAT in this document is very similar to the IPv4 NAT
described in [RFC2663], but is not identical. IPv4 NAT translates
one IPv4 address into another IPv4 address. In this document, NAT
refers to translation of an IPv4 address into an IPv6 address and
vice versa.
While the V4 NAT [RFC2663] provides transparent routing between
private V4 and external V4 address realms, NAT in this document
provides routing between a V6 address realm and an external V4
Park, et al. Expires April 22, 2006 [Page 5]
Internet-Draft NATPT-bis October 2005
address realm. As with V4 NAT, Application Level Gateways (ALGs) are
external to NAT-PT and are not an inherent part of NAT-PT. NAT-PT
does not require any ALGs for its operation.
2.3 NAT-PT flavors
Just as there are various flavors identified with V4 NAT in
[RFC2663], the following NAT-PT variations are identified in this
document.
2.3.1 Traditional NAT-PT
Traditional NAT-PT allows hosts within a V6 network to access hosts
in the V4 network. In traditional NAT-PT, sessions are
uni-directional, outbound from the V6 network. This is in contrast
with Bi-directional NAT-PT, which permits sessions initiated in
either direction.
Just as with V4 traditional-NAT, there are two variations to
traditional NAT-PT, namely Basic NAT-PT and NAPT-PT.
With Basic NAT-PT, a block of V4 addresses are set aside for
translating addresses of V6 hosts as they originate sessions to the
V4 hosts in external domain. For packets outbound from the V6
domain, the source IP address and related fields such as IP, TCP, UDP
and ICMP header checksums are translated. Likewise, for inbound
packets, the destination IP address and and related fields such as
IP, TCP, UDP and ICMP header checksums are translated.
NAPT-PT extends the notion of translation one step further by also
translating transport identifier (e.g., TCP and UDP port numbers,
ICMP query identifiers). This allows the transport identifiers of a
number of V6 hosts to be multiplexed into the transport identifiers
of a single assigned V4 address. NAPT-PT allows a set of V6 hosts to
share a single V4 address. Note that NAPT-PT can be combined with
Basic NAT-PT so that a pool of external addresses are used in
conjunction with port translation.
For packets outbound from the V6 network, NAPT-PT would translate the
source IP address, source transport identifier and related fields
such as IP, TCP, UDP and ICMP header checksums. Transport identifier
can be one of TCP/UDP port or ICMP query ID. For inbound packets,
the destination IP address, destination transport identifier and the
IP and transport header checksums are translated.
2.3.2 Bi-directional NAT-PT
With Bi-directional NAT-PT, sessions can be initiated from hosts in
Park, et al. Expires April 22, 2006 [Page 6]
Internet-Draft NATPT-bis October 2005
V4 network as well as the V6 network. V6 network addresses are bound
to V4 addresses, statically or dynamically as connections are
established in either direction.
2.3.3 Protocol Translation (PT)
PT in this document refers to the translation of an IPv4 packet into
a semantically equivalent IPv6 packet and vice versa. Protocol
translation details are described in [RFC2765].
2.3.4 Pool of V4 addresses
A list of IPv4 addresses that are used to alias IPv6 addresses when
sessions are initiated across V4 and V6 address realms. All the IPv4
addresses must be unique and globally routable to the IPv4 address
realm on which NAT-PT resides.
3. Traditional NAT-PT operation overview
NAT-PT offers a straight forward solution based on transparent
routing [RFC2663] and address/protocol translation, allowing a large
number of applications in V6 and V4 realms to inter-operate without
requiring any changes to these applications.
In this section, we describe the operation of NAT-PT and the way that
connections can be initiated from a host in IPv6 domain to a host in
IPv4 domain through a NAT-PT.
3.1 Basic NAT-PT Session processing (V6 to v4)
[IPv6-B]-+
| +==============+
[IPv6-A]-+-[NAT-PT]---------| IPv4 network |--[IPv4-C]
| +==============+
|
(pool of v4 addresses)
<Figure 1: IPv6 to IPv4 communication>
Node [IPv6-A] has an IPv6 address -> FEDC:BA98::7654:3210
Node [IPv6-B] has an IPv6 address -> FEDC:BA98::7654:3211
Node [IPv4-C] has an IPv4 address -> 132.146.243.30
NAT-PT is configured with a pool of V4 addresses (say, 120.130.26/24)
Park, et al. Expires April 22, 2006 [Page 7]
Internet-Draft NATPT-bis October 2005
to map V6 nodes in the domain and a PREFIX to represent the V4
external nodes as V6 entities within the V6 domain.
Say the Node [IPv6-A] wants to communicate with the Node [IPv4-C].
[IPv6-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 packets addressed to this PREFIX will be routed to the
NAT-PT. The pre-configured PREFIX only needs to be routable within
the IPv6 stub domain and as such it can be any routable prefix that
the network administrator chooses.
The packet is routed via the NAT-PT gateway, where it is 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 other parameters for the
translation. if this state does not exist, the packet SHOULD be
silently discarded.
If the packet is a session initialisation packet, the NAT-PT locally
allocates an address (e.g: 120.130.26.10) from its pool of
addresses and the packet is translated to IPv4. The translation
parameters are cached for the duration of the session and the IPv6 to
IPv4 mapping is retained by NAT-PT.
The resulting IPv4 packet has SA=120.130.26.10 and DA=132.146.243.30.
Any returning traffic will be recognised as belonging to the same
session by NAT-PT. NAT-PT will use the state information to
translate the packet, and the resulting addresses will be
SA=PREFIX::132.146.243.30, DA=FEDC:BA98::7654:3210. Note that this
packet can now be routed inside the IPv6-only stub network as normal.
3.2 NAPT-PT Outgoing Session processing (V6 to V4)
NAPT-PT, which stands for "Network Address Port Translation +
Protocol Translation", would allow V6 nodes to communicate with the
V4 nodes transparently using a single V4 address. The TCP/UDP ports
of the V6 nodes are translated into TCP/UDP ports of the registered
V4 address.
While NAT-PT support is limited to TCP, UDP and other port
multiplexing type of applications, NAPT-PT solves a problem that is
inherent with NAT-PT. That is, NAT-PT would fail when the pool of V4
Park, et al. Expires April 22, 2006 [Page 8]
Internet-Draft NATPT-bis October 2005
addresses assigned for translation purposes is exhausted. Once the
address pool is exhausted, newer V6 nodes cannot establish 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 IPv4 address
before having no TCP and UDP ports left to assign.
To modify the example sited in figure 1, we could have NAPT-PT on the
border router (instead of NAT-PT) and all V6 addresses could be
mapped to a single v4 address 120.130.26.10.
Node [IPv6-A] would establish a TCP session with the Node [IPv4-C] as
follows:
[IPv6-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 tuple of
(Source Address, Source TCP port) as follows:
SA = 120.130.26.10, source TCP port = 1025 and
DA = 132.146.243.30, destination TCP port = 23.
The returning traffic from 132.146.243.30, TCP port 23 will be
recognised as belonging to the same session and will be translated
back to V6 as follows:
SA = PREFIX::132.146.243.30, source TCP port = 23;
DA = FEDC:BA98::7654:3210 , destination TCP port = 3017
Inbound NAPT-PT sessions are restricted to one server per service,
assigned via static TCP/UDP port mapping. For example, the Node
[IPv6-A] in figure 1 may be the only HTTP server (port 80) in the V6
domain. Node [IPv4-C] sends a packet:
SA = 132.146.243.30, source TCP port = 1025 and
DA = 120.130.26.10, destination TCP port = 80
NAPT-PT will translate this packet to:
SA = PREFIX::132.146.243.30, source TCP port = 1025
DA = FEDC:BA98::7654:3210, destination TCP port = 80
In the above example, note that all sessions which reach NAPT-PT with
Park, et al. Expires April 22, 2006 [Page 9]
Internet-Draft NATPT-bis October 2005
a destination port of 80 will be redirected to the same Node
[IPv6-A].
4. Bi-directional NAT-PT operation overview
With Bi-directional NAT-PT, sessions can be initiated from hosts in
V4 network as well as V6 network. V6 network addresses are bound to
V4 addresses, statically or dynamically as connections are
established in either direction.
In this section, we describe the operation of NAT-PT and the way that
connections can be initiated from a host in IPv4 domain to a host in
IPv6 domain through a NAT-PT.
4.1 Static address mapping within NAT-PT
An IPv6 node in the NAT-PT domain can be traversed to a IPv4 node
along with traditional NAT-PT operation as described in Section 3.
However, an IPv4 node initiating its session to a V6 stub domain
through NAT-PT can not communicate with a IPv6 node in the NAT-PT
domain using traditional NAT-PT.
For the address translation of incoming sessions (V4 to V6), NAT-PT
must have had the mapping of the target IPv6 address to a IPv4
address statically preconfigured. Dynamic address mapping is outside
the scops of this document.
Say the Node [IPv4-C] wants to communicate with the Node [IPv6-A].
[IPv4-C] creates a packet with:
Source Address, SA = 132.146.243.30 and
Destination Address, DA = 120.130.26.100
In figure 2 below, if Node [IPv4-C]'s name resolver sends a name look
up request for Node [IPv6-A], the DNS server on the V4 network
directly replies the IPv4 address of [IPv6-A] (120.130.26.100)
instead of the IPv6 address of [IPv6-A] (FEDC:BA98::7654:3210).
[DNS]--+
| [DNS]------[DNS]-------[DNS]
[IPv6-B]-+ | |
| +==============+ |
[IPv6-A]-+----[NAT-PT]------| IPv4 network |--[IPv4-C]
| +==============+
(pool of v4 addresses)
Park, et al. Expires April 22, 2006 [Page 10]
Internet-Draft NATPT-bis October 2005
<Figure 2: IPv4 to IPv6 communication using static mapping>
NAT-PT has a mapping information:
FEDC:BA98::7654:3210 : 120.130.26.100
(a) NAT-PT will check to see if the destination IPv4 address of
incoming packet has a matching address binding. With the static
address mapping configured as above, it would find the matching
address binding for the target IP address of 120.130.26.100. When a
matching address binding is not found and dynamic address binding on
the inbound sessions is not supported, NAT-PT will simply drop such a
packet.
(b) Replacing the destination IPv4 address (120.130.26.100) with the
IPv6 address (FEDC:BA98::7654:3210) as well as the source IPv4
address (132.146.243.30) with the IPv6 address
(PREFIX::132.146.243.30).
(c) Forwarding the IPv6 packet to the final destination in the NAT-PT
domain.
5. Translation phases within NAT-PT
The following translation phases of NAT-PT are described below.
5.1 Address (and port) binding
A IPv6 packet that matches the NAT-PT prefix will be processed by
NAT-PT.A IPv4 address will be allocated to the IPv6 source address
from the configured IPv4 pool. An association between the IPv6
source address and the IPv4 address that NAT-PT allocated will be
maintained by the NAT-PT. All subsequent packets from the same IPv6
host will use the same IPv6 - IPv4 address binding to communicate
with the IPv4 realm. If the same IPv6 host communicates with other
IPv4 hosts through the same NAT-PT, the address binding should be
re-used.
In case of NAPT-PT, the transport identifier in the IPv6 packet is
retrieved by NAPT-PT and a single IPv4 address is used but a port is
allocated to this session. NAPT-PT will maintain a port binding
between the IPv6 address, port and the IPv4 address, Port. All
subsequent packets from the same IPv6 address, port will use this
binding.
Typically the first packet in the flow will create the address and/or
port binding.
Park, et al. Expires April 22, 2006 [Page 11]
Internet-Draft NATPT-bis October 2005
5.2 NAT-PT session flows
When the first packet of a TCP/UDP session reaches NAT-PT interface,
the packet is subject to NAT-PT session lookup. If the packet fails
to match any of the known NAT-PT sessions, the packet's source/
destination endpoint is compared for a match against the address/port
bindings and address map entries in that order. If a matching
address/port binding is found, that is an indication that a binding
already exists and that the binding can be reused. Otherwise, if a
matching address map entry is found, a new address/port binding is
created from the address map. A new NAT-PT session is created to
describe the session in each of the realms and the transaltion
associated between the two. Specifically, a NAT-PT session will
refer the address/port binding it uses. NAT-PT session for a TCP
based flow may have additional information than a UDP based flow.
Note, some variations of NAPT-PT (called, symmetric NAT-PT) do not
use port binding. Instead, they use NAT-PT sessions directly without
the port binding.
All subsequent packets (other than the first packet of a session)
traversing the NAT device are subject to NAT-PT-session lookup for
translation purposes. Packets matching a NAT-PT-session undergo
translation in either direction. Individual packet translation
issues are covered in detail in the following sub-sections.
5.3 IP and TCP/UDP/ICMP header translations
The IPv4 and ICMPv4 headers are similar to their V6 counterparts but
a number of fields are either missing, have different meaning or
different length. NAT-PT SHOULD translate all IP/ICMP headers from
v4 to v6 and vice versa in order to make end-to-end IPv6 to IPv4
communication possible. Due to the address translation function and
possible port multiplexing, NAT-PT SHOULD also make appropriate
adjustments to the upper layer protocol (TCP/UDP) headers.
Protocol Translation details are described in [RFC2765], but there
are some modifications required to SIIT because of the fact that
NAT-PT also performs Network Address Translation.
5.3.1 IPv4 Headers to IPv6 Headers
This is done exactly the same as in SIIT apart from the following
fields:
Source Address:
The low-order 32 bits is the IPv4 source address. The high-order
96 bits is the designated PREFIX for all v4 communications.
Addresses using this PREFIX will be routed to the NAT-PT gateway
Park, et al. Expires April 22, 2006 [Page 12]
Internet-Draft NATPT-bis October 2005
(PREFIX::/96)
Destination Address:
NAT-PT retains a mapping between the IPv4 destination address and
the IPv6 address of the destination node. The IPv4 destination
address is replaced by the IPv6 address retained in that mapping.
5.3.2 Translating IPv6 Headers to IPv4 Headers
This is done exactly the same as in SIIT apart from the Source
Address which should be determined as follows:
Source Address:
The NAT-PT retains a mapping between the IPv6 source address and
an IPv4 address from the pool of IPv4 addresses available. The
IPv6 source address is replaced by the IPv4 address retained in
that mapping.
Destination Address:
IPv6 packets that are translated have a destination address of the
form PREFIX::IPv4/96. Thus the low-order 32 bits of the IPv6
destination address is copied to the IPv4 destination address.
5.4 TCP/UDP/ICMP Checksum update
NAT-PT retains mapping between IPv6 address and an IPv4 address from
the pool of IPv4 addresses available. This mapping is used in the
translation of packets that go through NAT-PT.
The following sub-sections describe TCP/UDP/ICMP checksum update
procedure in NAT-PT, as packets are translated from V4 to V6 and vice
versa.
5.4.1 TCP/UDP/ICMP Checksum update from IPv4 to IPv6
UDP checksums, when set to a non-zero value, and TCP checksum SHOULD
be recalculated to reflect the address change from v4 to v6. The
incremental checksum adjustment algorithm may be borrowed from
[RFC3022]. In the case of NAPT-PT, TCP/UDP checksum should be
adjusted to account for the address and TCP/UDP port changes, going
from V4 to V6 address.
When the checksum of a V4 UDP packet is set to zero, NAT-PT MUST
evaluate the checksum in its entirety for the V6-translated UDP
packet. If a V4 UDP packet with a checksum of zero arrives in
fragments, NAT-PT MUST await all the fragments until they can be
assembled into a single non-fragmented packet and evaluate the
checksum prior to forwarding the translated V6 UDP packet.
Park, et al. Expires April 22, 2006 [Page 13]
Internet-Draft NATPT-bis October 2005
ICMPv6, unlike ICMPv4, uses a pseudo-header, just like UDP and TCP
during checksum computation. As a result, when the ICMPv6 header
checksum is computed [RFC2765], the checksum needs to be adjusted to
account for the additional pseudo-header. Note, there may also be
adjustments required to the checksum due to changes in the source and
destination addresses (and changes in TCP/UDP/ICMP identifiers in the
case of NAPT-PT) of the payload carried within ICMP.
5.4.2 TCP/UDP/ICMP Checksum update from IPv6 to IPv4
TCP and UDP checksums SHOULD be recalculated to reflect the address
change from v6 to v4. The incremental checksum adjustment algorithm
may be borrowed from [RFC3022]. In the case of NAPT-PT, TCP/UDP
checksums should be adjusted to account for the address and TCP/UDP
port changes, going from V6 to V4 addresses. For UDP packets,
optionally, the checksum may simply be changed to zero.
The checksum calculation for a V4 ICMP header needs to be derived
from the V6 ICMP header by running the checksum adjustment algorithm
[RFC3022] to remove the V6 pseudo header from the computation. Note,
the adjustment must additionally take into account changes to the
checksum as a result of updates to the source and destination
addresses (and transport ports in the case of NAPT-PT) made to the
payload carried within ICMP.
5.5 Address (and Port) unbinding
When the last session based on an address or port binding is
terminated, the binding itself may be terminated, if the binding is
not static and a binding timer is not set. NAT-PT sessions are
terminated by NAT-PT using various heuristics. In case of a
connection oriented protocol like TCP, it will be a FIN/FIN-ACK or
RST that indicates connection termination. However, in case of other
protocols it will be an inactive timer that will remove the binding.
Alternately, if the binding has an idle-time binding timer set, the
binding is left unchanged for the period set by the timer, even as
there is not a single NAT-PT session that uses the binding.
When the binding timer is expired, the elements of the binding are
freed into the resourse pool which will be used by NA(P)T-PT for
subsequent address and port allocations.
6. Use case scenarios
NAT-PT is expected to be used in a limited set of scenarios where the
other forms of native IPv4 and IPv6 communication is not possible.
This restriction could arise when a node, a network or an application
is capable of supporting only one protocol, either IPv4 or IPv6.
Park, et al. Expires April 22, 2006 [Page 14]
Internet-Draft NATPT-bis October 2005
6.1 Scenario 1 - Small devices that runs single stack
In cases of smaller devices that can run only a single stack of IPv4
or IPv6, either because of memory constraints or cost constraints, a
NAT-PT will be used.
IPv6 only---(IPv6/IPv4)---NAT-PT---( IPv4 )---IPv4 Device
Device ( Network ) (Network)
6.2 Scenario 2 - IPv4 Server running a legacy application
A IPv4 server running a legacy application in an IPv4 network that
cannot be upgraded to IPv6 is a most common scenario. In this case,
a NAT-PT is used in the stub network closest to the IPv4 network that
has the server.
IPv6 Host---(IPv6 only)---NAT-PT---( IPv4 )---IPv4 only Server
Dual Stack ( Network ) (Network)
6.3 Scenario 3 - IPv6 only networks
Some networks might be built totally as IPv6 networks only, because
of operational issues like the overhead of maintaining and
troubleshooting two different networks. This option could be chosen
when a high percentage of the traffic stays within the IPv6 network
and only a smaller percentage of the traffic needs the IPv4
connectivity.
IPv6 Host---(IPv6 only)---NAT-PT---( IPv4 )---IPv4 only Server
(Dual Stack) ( Network ) (Network)
Park, et al. Expires April 22, 2006 [Page 15]
Internet-Draft NATPT-bis October 2005
6.4 Scenario 4 - IPv6 3GPP networks
As described in [RFC4215] 3GPP networks makes use of NAT-PT as
generic translators. Due to the significant lack of IPv4 addresses
in some domains, port multiplexing (NAPT-PT) is likely to be a
necessary feature for translators. Several considerations is
described in [RFC4215].
IPv6 UE---(GGSN)---NAT-PT---( IPv4 )---Peer---IPv4 Device
(Network)
7. Support for application level transparency
Some protocols carrying the IP address and port information in its
payload for the data session require Application Level Gateway (ALG)
or proxy to provide application level transparency for these popular
Internet application, i.e., DNS, FTP, SIP and etc. Each ALG should
be built on NAT-PT in order to use the application between V4 and V6
networks. Specific ALGs are out of scope and will be described in
seperate documents.
Implementation note: ALG/Proxy requirement described above are not
restricted to the DNS, FTP and SIP, so implementor should consider of
which ALG/Proxy functions are required when developing its NAT-PT
system.
8. Known limitations
All limitations associated to NAT [RFC2663] are also associated to
NAT-PT. Here are the most important of them in detail, as well as
some unique to NAT-PT.
8.1 Topology limitations
There are limitations to using the NAT-PT translation method. It is
mandatory that all requests and responses pertaining to a session be
routed via the same NAT-PT router. One way to guarantee this would
be to have NAT-PT based on a border router that is unique to a stub
domain, where all IP packets are either originated from the domain or
destined to the domain. This is a generic problem with NAT and it is
fully described in [RFC2663].
Park, et al. Expires April 22, 2006 [Page 16]
Internet-Draft NATPT-bis October 2005
Note, this limitation does not apply to packets originating from or
directed to dual-stack nodes that do not require packet translation.
This is because in a dual-stack set-up, IPv4 addresses implied in a
V6 address can be identified from the address format PREFIX::x.y.z.w
and a dual-stack router can accordingly route a packet between v4 and
dual-stack nodes without tracking state information.
This should also not affect IPv6 to IPv6 communication and in fact
only actually use translation when no other means of communication is
possible. for example NAT-PT may also have a native IPv6 connection
and/or some kind of tunneled IPv6 connection. Both of the above
connections should be preferred over translation when possible. The
above makes sure that NAT-PT is a tool only to be used to assist
transition to native IPv6 to IPv6 communication.
8.2 Protocol translation limitations
A number of IPv4 fields have changed meaning in IPv6 and translation
is not straightforward. For example, the option headers semantics
and syntax have changed significantly in IPv6. In several cases,
there are no equivalents for IPv6 in IPv4, like the flow labels in
IPv6 header. Hence a pure IPv6 to IPv4 translation may not be
possible in all cases. Details of IPv4 to IPv6 Protocol Translation
can be found in [RFC2765].
8.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 incorporated to provide
support for those applications. This is a generic problem with NAT
and it is fully described in [RFC2663].
8.4 Lack of end-to-end security
One of the most important limitations of the NAT-PT proposal is the
fact that end-to-end network layer security is not possible. Also
transport and application layer security may not be possible for
applications that carry IP addresses to the application layer. This
is an inherent limitation of the Network Address Translation
function.
Independent of NAT-PT, end-to-end IPSec security is not possible
across different address realms. The two end-nodes that seek IPSec
network level security must both support one of IPv4 or IPv6.
Park, et al. Expires April 22, 2006 [Page 17]
Internet-Draft NATPT-bis October 2005
8.5 DNS translation and DNSSEC
When involving translation of DNS messages for address translation,
this scheme can not be deployed in combination with secure DNS.
I.e., an authoritative DNS name server in the V6 domain cannot sign
replies to queries that originate from the V4 world. As a result, an
V4 end-node that demands DNS replies to be signed will reject replies
that have been tampered with by NAT-PT.
The good news, however, is that only servers in V6 domain that need
to be accessible from the V4 world pay the price for the above
limitation, as V4 end-nodes may not access V6 servers due to DNS
replies not being signed.
Also note that zone transfers between DNS-SEC servers within the same
V6 network are not impacted.
Clearly, with DNS SEC deployment in DNS servers and end-host
resolvers, the scheme suggested in this document would not work.
9. Security considerations
Following the conceptual design of middlebox communication,
end-to-end network and transport layer security are 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
in the application layer.
Regarding the DNS aspect, secure DNS is not may adoptable for NAT-PT
because of unchained authoritative DNS query/reply between V4 and V6
domain.
Finally, all of the security considerations described in [RFC2663]
are applicable to this document as well
10. Acknowledgements
Thanks to the authors of the original NAT-PT (RFC 2766).
11. Change history
11.1 Since RFC 2766
o Removed all ALG stuff (DNS-ALG, FTP-ALG) and added a new section as
"Support for application level transparency" to be considered a
protocol carrying the IP address and port in its payload for the data
session require ALG.
Park, et al. Expires April 22, 2006 [Page 18]
Internet-Draft NATPT-bis October 2005
o Added "Static address mapping within NAT-PT" section to support bi-
directional NAT-PT operation.
o Added a section on use case scenarios to help readers understood
the rationale behind NAT-PT deployments.
o Specified and reorganized translation phase within NAT-PT.
12. References
12.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
12.2 Informative References
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third
Generation Partnership Project (3GPP) Networks", RFC 4215,
October 2005.
Authors' Addresses
Soohong Daniel Park, Editor
SAMSUNG Electronics
416 Maetan-3dong, Yeongtong-gu
Suwon, Gyeonggi-do 443-742
KOREA
Phone: +82 31 200 4508
EMail: soohong.park@samsung.com
Park, et al. Expires April 22, 2006 [Page 19]
Internet-Draft NATPT-bis October 2005
Senthil Sivakumar, Editor
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
USA
Phone:
EMail: ssenthil@cisco.com
Pyda Srisuresh
Caymas Systems, Inc.
1179-A North McDowell Blvd.
Petaluma, CA 94954
USA
Phone: +1 707 283 5063
EMail: srisuresh@yahoo.com
Tony Hain
Cisco Systems, Inc.
500 108th Ave. NE
Bellevue, Wa
USA
Phone:
EMail: alh-ietf@tndh.net
Park, et al. Expires April 22, 2006 [Page 20]
Internet-Draft NATPT-bis October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Park, et al. Expires April 22, 2006 [Page 21]
