INTERNET-DRAFT George Tsirtsis
NGTRANS WG BT Laboratories
Expires June, 1999 Pyda Srishuresh
Category: EXPERIMENTAL Lucent Technologies
January 1999
Network Address Translation - Protocol Translation (NAT-PT)
<draft-ietf-ngtrans-natpt-04.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Eu-
rope), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
This document specifies a transition mechanism in addition to those
already specified in [TRANS]. The new mechanism provides an
end-to-end solution to allow IPv6-only hosts to communicate with
IPv4-only hosts and vice versa using Network Address Translation
and Protocol Translation. The scheme described does not require du-
al-stack hosts; nor does it mandate any routing related changes on
the hosts. The scheme is based on a combination of address transla-
tion theme as described in [NAT-TERM] and V6/V4 protocol transla-
tion theme as described in [SIIT].
Acknowledgements
Special thanks to Pedro Marques for reviewing an earlier version of
the draft. Finally, many thanks to Alan O'Neill and Martin Tatham
since the initial idea described in this document was developed af-
ter discussions with them.
Tsirtsis & Srisuresh [Page 1]
Internet Draft Network Address + Protocol Translator January 1999
Index
1. Introduction
2. Terminology
3. Network Address Translation operation
3.1 NAT-PT Outgoing Sessions (IPv6 to IPv4)
3.2 NAPT-PT Outgoing Sessions (IPv6 to IPv4)
4. IP v4 Address Assignment
4.1 V4 Address assignment for outgoing connections
4.2 V4 Address assignment for incoming connections
4.2.1 DNS Application Layer Gateway (ALG) support
5. Protocol Translation Details
5.1 Translating IPv4 headers to IPv6 headers
5.2 Translating IPv6 headers to IPv4 headers
5.3 TCP/UDP/ICMP Checksum Update
5.4 FTP Application level Gateway (FTP-ALG) support
6. NAT-PT Limitations and Future Work
6.1 Topology limitations
6.2 Protocol Translation Limitations
6.3 Impact of Address Translation
6.4 Lack of end-to-end security
6.5 DNS Translation and DNSSEC
7. Applicability Statement
8. Security Considerations
9. References
1. Introduction
IPv6 is the upcoming IP protocol that was designed in order to
modernise IPv4, which was designed in the 1970s. IPv6 has a number of
advantages over IPv4 including the fact that it provides a much
larger address space than IPv4, which for many, is the number one
reason to move to IPv6. A basic requirement, however, for a large
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.
Tsirtsis & Srisuresh [Page 2]
Internet Draft Network Address + Protocol Translator January 1999
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. With these assumptions, SIIT
purports to do protocol independent translation of V4/V6 datagrams,
requiring no state details on the sessions.
NAT-PT uses a pool of V4 addresses for assignment to V6 hosts on a
dynamic basis as sessions are initiated across V4-V6 boundaries.
These assigned addresses in turn are used to transparently replace
the original addresses used by V6 end nodes and vice versa. This
requires no changes to end nodes and IP packet routing is completely
transparent to end nodes. It does, however, require NAT-PT to track
the sessions it supports and mandates that inbound and outbound data-
grams pertaining to a session traverse the same NAT-PT router. You
will note that the topology restriction on NAT-PT are very similar to
those described for V4 NATs in [NAT-TERM]. Protocol translation de-
tails specified in [SIIT] would be used to extend address translation
with protocol syntax/semantics translation.
2. Terminology
Session initiation packet
This is the first packet of an IP session. Only the
first packet of a TCP session can be identified in a de-
terministic way, with the presence of SYN bit and absence of
ACK bit in TCP header. There is no deterministic way to
recognise the start of a UDP or any non-TCP session. [NAT-
TERM].
Network Address Translation (NAT)
NAT in this document is very similar, but not the same,
with IPv4 NAT as described in [NAT-TERM]. IPv4 NAT
translates one IPv4 address into another IPv4 address . In
this document, NAT refers to translation of an IPv4 ad-
dress into an IPv6 address and vice versa.
Network Address Port Translation (NAPT)
NAPT [NAT-TERM] is a method by which hosts in a private net-
work domain are allowed simultaneous access to hosts in the
external network transparently using a single external ad-
dress. This is made possible by multiplexing transport lay-
er identifiers of private hosts into the transport identi-
fiers of the single assigned external address. For this rea-
son, only the applications based on TCP and UDP protocols
are supported by NAPT. ICMP query based applications are al-
Tsirtsis & Srisuresh [Page 3]
Internet Draft Network Address + Protocol Translator January 1999
so supported as the ICMP header carries a query identifier
that is used to corelate responses with requests.
Protocol Translation (PT)
PT in this document refers to translation of an IPv4
packet into a semantically equivalent IPv6 packet and
vice versa. Protocol translation details are described in
[SIIT].
Application Level Gateway (ALG)
Application Level Gateway (ALG) [NAT-TERM] is an appli-
cation specific agent that allows a V6 host to communicate
with a V4 host and vice versa. Some applications carry
network addresses in payload. NAT-PT is application inde-
pendent and does not snoop the payload to fix IP addresses
in payload. ALG works in conjucntion with NAT-PT to provide
application level transparency.
3. Network Address Translation operation
NAT-PT offers a straight forward end-to-end solution with trans-
parent routing and address/protocol translation. Operation of NAT-PT
is described in the following sub-sections. There are limitations to
using the translation method. Is it mandatory that all requests and
responses pertaining to a session be routed via the same NAT router.
One way to ascertain this would be to have NAT based on a border
router that is unique to a stub domain, where all IP packets are ei-
ther originated from the domain or destined to the domain. There are
other ways to ensure this with multiple NAT devices. For example, a
private domain could have two distinct exit points to different
providers and the session flow from the hosts in a private network
could traverse through whichever NAT device has the best metric for
an external host.
NAT-PT is application independent. Applications such as "FTP" that
include IP addresses in payload will need to be supported by appli-
cation specific ALGs in conjunction with NAT-PT. This document de-
scribes the functioning of FTP and DNS ALGs in conjunction with NAT-
PT. Specifications of ALGs for other applications is outside the
scope of this document.
NAT-PT is also limited by the fact that it can translate only the
shared semantics between the V4 and V6 protocols. Features specific
only to V6 or features not supported in V6 will not be supported by
NAT-PT.
In the following paragraphs we describe the operation of NAT-PT and
Tsirtsis & Srisuresh [Page 4]
Internet Draft Network Address + Protocol Translator January 1999
the way that connections can be initiated from both sides, when an
IPv6 domain is connected to an IPv4 domain through a NAT-PT.
3.1 NAT-PT Outgoing Sessions (IPv6 to IPv4)
^
|
[IPv6-B]-+
| +==============+
[IPv6-A]-+-[NAT-PT]---------| IPv4 network |--[IPv4-C]
| +==============+
(pool of v4 addresses)
Figure 1: IPv6 to IPv4 communication
Host IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210
Host IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
Host IPv4-C has an IPv4 address -> 132.146.243.30
NAT-PT has a pool of addresses including the IPv4 subnet
120.130.26/24
Say the IPv6 Host A wants to communicate with the IPv4 Host C.
Host A creates a packet with:
Source Address, SA=FEDC:BA98::7654:3210 and
Destination Address, DA = prefix::132.146.243.30
NOTE: The prefix PREFIX::/96 is advertised in the stub domain by
the NAT-PT and it points to it. The pre-configured prefix has to
be routable only inside the stub domain representing the IPv4
world.
The packet is routed via the NAT-PT gateway, where it is translat-
ed to IPv4.
If the outgoing packet is not a session initialisation packet, the
NAT-PT SHOULD already have stored some state about the related
session, including assigned IPv4 address and cached parameters for
the translation. If this state does not exist the packet SHOULD
be silently discarded.
If the packet is a session initialisation packet the NAT-PT
locally allocates an address (e.g: 120.130.26.10) from its
pool of addresses and the packet is translated to IPv4, 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 January 1999
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.
NAPT-PT also solves a problem that is inherent with NAT-PT. That
is, NAT-PT would fall flat when the pool of V4 addresses assigned
for translation purposes is exhausted. Once the address pool is
exhausted, newer V6 hosts cannot establish sessions with the out-
side world anymore. NAPT-PT, on the other hand, will allow for a
maximum of 63K TCP and 63K UDP sessions before falling flat with
no TCP and UDP ports left to assign.
In the example sited in figure 1, say, we have NAPT-PT on the bor-
der router (instead of NAT-PT) and all V6 addresses are mapped in-
to a single v4 address 120.130.26.10.
Say the IPv6 Host A wanted to set up a TCP session with the IPv4
Host C.
Host A creates a packet with:
Source Address, SA=FEDC:BA98::7654:3210 , source TCP port = 3017
and Destination Address, DA = PREFIX::132.146.243.30, destination
TCP port = 23.
When the packet reaches the NAPT-PT box, NAPT-PT would assign one
of the TCP ports from the assigned V4 address to translate the tu-
ple of (source Address, Source TCP port) as follows.
SA=120.130.26.10, source TCP port = 1025 and
DA=132.146.243.30, destination TCP port = 23.
The returning traffic from 132.146.243.30, TCP port 23 will be
recognised as belonging to the same session and will be translated
Tsirtsis & Srisuresh [Page 6]
Internet Draft Network Address + Protocol Translator January 1999
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 January 1999
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.
^
[DNS]--+
| [DNS]------[DNS]-------[DNS]
[IPv6-B]-+ | |
| +==============+ |
[IPv6-A]-+----[NAT-PT]------| IPv4 network |--[IPv4-C]
| +==============+
(pool of v4 addresses)
Figure 2: IPv4 to IPv6 communication
Host IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210
Host IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
Host IPv4-C has an IPv4 address -> 132.146.243.30
NAT-PT has a pool of addresses including the IPv4 subnet
120.130.26/24
4.2.1 DNS Application Layer Gateway (ALG) support
In figure 2 above, when Host C name resolver makes a name look
up request for Host A, the lookup query is redirected to the
DNS server on the V6 network. Considering that NAT-PT is resid-
ing on the border router between V4 and V6 networks, this re-
quest datagram would traverse through the NAT-PT router. The
DNS ALG on NAT-PT would modify the DNS Queries going into V6
domain as follows:
a) For Host Name to Host Address Query requests:
Change the Query type from "A" to "AAAA".
b) For Host address to Host name query requests:
Replace the V4 address octets (in reverse order) pre-
ceding the string "IN-ADDR.ARPA" with the corresponding
V6 address (if there exists a map) octets in reverse or-
der.
Tsirtsis & Srisuresh [Page 8]
Internet Draft Network Address + Protocol Translator January 1999
In the opposite direction, when DNS response traverse from the
DNS server on V6 network to V4 host, the DNS-ALG once again
traps the DNS packet and would:
a) Translate DNS responses for "AAAA" records into 'A'
records,
b) Replace the V6 address sent by the V6 DNS server with the
V4 address internally assigned by the NAT-PT router.
If a V4 address is not previously assigned to this V6 host,
NAT-PT would assign it this time. The TTL values on all DNS re-
source records (RRs) passing through NAT-PT would be set to 0.
This technique is also useful for outgoing communication as
well. We saw that a v6host that needs to communicate with a v4
hosts needs to use a specific prefix (PREFIX::) in front of the
IPv4 address of the v4host. The above technique allows the use
of this prefix without any configuration in the hosts. E.g.: In
Figure 2, Host-A makes a name look-up on the Host-C. The DNS
query goes to the v6 DNS server and from there to the v4 DNS
server outside the v6 stub domain after it has been translated
by the NAT-PT. The reply follows the same route but now the
NAT-PT translates the reply adding the appropriate prefix. So,
if the reply is:
HostC A 132.146.243.30, it is translated to
HostC AAAA PREFIX::132.146.243.30
Now Host A can use this address as any other IPv6 address and
the v6 DNS server can even cache it as long as the prefix does
not change.
An additional problem is how the v6 DNS server in the v6 stub
domain talks to the v4 domain outside the v6 stub domain. Re-
member that there are no dual stack hosts here. The v4 DNS
server needs to point to a v4 address, part of the v4 pool of
addresses, available to the NAT-PT. The NAT-PT keeps a one-to-
one mapping between this v4 address and the IPv6 address of the
v6 DNS server. In the other direction, the v6 DNS server points
to the IPv4 address of the v4 DNS servers with the prefix (PRE-
FIX::) which indicates non IPv6 address. This mechanism can
easily be extended to accommodate secondary DNS servers.
Note that the scheme described above impacts DNSSEC and look at
section 6.5 of this document for details.
Tsirtsis & Srisuresh [Page 9]
Internet Draft Network Address + Protocol Translator January 1999
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 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 the appropriate adjustments to
the upper layer protocol (TCP/UDP) header. A seperate section on FTP-
ALG describes the changes FTP-ALG would make to FTP payload as an FTP
packet traverses from v4 to v6 realm or vice versa.
Protocol Translation details are adequately in [SIIT]. Here are the
required modifications on SIIT that are imposed by the fact that NAT-
PT also performes Network Address Translation.
5.1 Translating IPv4 headers to IPv6 headers
This is done exactly the same as in SIIT apart from the following
fields:
Source Address:
The low-order 32 bits is the IPv4 source address. The
high-order 96 bits is the designated prefix for all v4
communications and points to the NAT-PT gateway (PRE-
FIX::/96)
Destination Address:
The NAT-PT retains a mapping between the IPv4 DA and
the IPv6 address of the destination host. The IPv4 DA is
replaced by the IPv6 address retained in that mapping.
5.2 Translating IPv6 headers to IPv4 headers
This is done exactly the same as in SIIT apart from the Source Ad-
dress which should be calculated as follows:
Source Address:
The NAT-PT retains a mapping between the IPv6 SA and an
IPv4 address from the pool of IPv4 addresses available.
The IPv6 SA is replaced by the above IPv4 address.
5.3 TCP/UDP/ICMP Checksum Update
Tsirtsis & Srisuresh [Page 10]
Internet Draft Network Address + Protocol Translator January 1999
The NAT-PT retains a mapping between an IPv6 address and an IPv4
address from the pool of IPv4 addresses available. The above map-
ping is used in the translation process of every packet that goes
through the NAT-PT.
TCP/UDP checksum SHOULD be recalculated according to the ad-
dress change: Source Address for v6 to v4 translation; Destina-
tion Address for v4 to v6 translation.
The incremental checksum adjustment algorithm may be borrowed from
[NAT].
In the case of NAPT-PT, TCP/UDP checksum should be recalculated
on the outbound (V6 to V4) to account for V6 source address and
V6 TCP/UDP port changes. Likewise, TCP/UDP checksum on the in-
bound packets (V4 to V6) should be recalculated to account for
destination V4 address and destination TCP/UDP port changes.
Also note that ICMPv6, unlike ICMPv4, has a pseudo-header checksum
just like UDP and TCP. When the ICMPv6 header is computed for V4
to V6 translation [SIIT], the checksum calculation needs to take
into account the address changes due to the address translation
function of NAT-PT. The necessary changes to source and destina-
tion addresses as well as IPv4 checksum is also required for the
packet headers carried inside the ICMP packets.
5.4 FTP Application level Gateway (FTP-ALG) support
FTP control session carries in its payload the IP address and TCP
port information pertaining to the data session it supports, an
FTP ALG on NAT-PT is needed to provide support for the popular In-
ternet application.
The arguments to the File Transfer Protocol (FTP) PORT command and
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 FTP-ALG should substitute this with the
NAT-PT assigned V4 address. In case of NAPT-PT, even the TCP port
following the IP address should be translated. The reverse
(translation from v4 address to V6 address) is true in the in-
bound packets.
Note, all translations are ASCII encoded translations. As a re-
sult, these translations may result in a change in the size of
packet.
If the new size is same as the previous, only the TCP checksum
Tsirtsis & Srisuresh [Page 11]
Internet Draft Network Address + Protocol Translator January 1999
needs adjustment as a result of payload translation. If the new
size is different from the previous, TCP sequence numbers should
also be changed to reflect the change in length of FTP control
session payload. The IP packet length field in V4 header or the
IP payload length in V6 field should also be changed by the same
delta change in payload size. A special table is used by the FTP-
ALG to correct the TCP sequence and acknowledge numbers in the
TCP header for control packets in both directions.
The table entries should have the source address, source data
port, destination address and destination data port for V4 and V6
portions of the session, sequence number delta for outbound pack-
ets and sequence number delta for inbound packets. The sequence
number deltas are negative (i.e., payload size decreases) on the
outbound and positive (i.e., payload increases) on the inbound.
Sequence number for an outbound packet is increased by the out-
bound sequence number delta and acknowledgement number for the
same outbound packet is decreased by the inbound sequence number
delta. Likewise, sequence number for an inbound packet is in-
creased by the inbound sequence number delta and acknowledgement
number for the same inbound packet is decreased by the outbound
sequence number delta.
6. NAT-PT Limitations and Future Work
6.1 Topology limitations
There are limitations to using the translation method. It is
mandatory that all requests and responses pertaining to a session
be routed via the same NAT router. One way to ascertain this would
be to have NAT based on a border router that is unique to a stub
domain, where all IP packets are either originated from the domain
or destined to the domain.
Note, this limitation does not apply to packets originating
from or directed to dual-stack hosts that do not require packet
translation. This is because in a dual-stack set-up, IPv4 address
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 in-
formation
6.2 Protocol Translation Limitations
A number of IPv4 fields have changed meaning in IPv6 and transla-
tion is not straightforward. For example, the option headers
semantics and syntax have changed significantly in IPv6, some
Tsirtsis & Srisuresh [Page 12]
Internet Draft Network Address + Protocol Translator January 1999
meaningful translation may also be possible in the future using
NAT-PT.
6.3 Impact of Address Translation
Since NAT-PT performs address translation, applications that
carry the IP address in the higher layers will not work. In
this case Application Layer Gateways (ALG) need to be incorpo-
rated to provide services to that kind of applications.
6.4 Lack of end-to-end security
One of the most important limitations of the NAT-PT proposal is
the fact that end-to-end network 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 from the Network Address
Translation function.
Independent of NAT-PT, end-to-end IPsec security is not possible
across different routing realms. The two end-nodes that seek IPsec
network level security must both support one of IPv4 or IPv6.
6.5 DNS Translation and DNSSEC
The scheme described in section 4.2 involves translation of DNS
messages. It is clear that this scheme can not be deployed in
combination with secure DNS. I.e., an authoritative DNS name
server in the V6 domain cannot sign replies to queries that
originate from the V4 world. As a result, an V4 end-node that
demands DNS replies to be signed will reject replies that have
been tampered with by NAT-PT.
The good news, however, is that only servers in V6 domain that
need to be accessable from the V4 world pay the price for the
above limitation, as V4 end-nodes may not access V6 servers due to
DNS replies not being signed.
Also note that zone transfers between DNS-SEC servers within the
same V6 network are not impacted.
Clearly, if DNS-SEC were to become the norm in both V4 and V6
DNS servers and end-host resolvers, the scheme suggested in this
document will not work.
7. Applicability Statement
Tsirtsis & Srisuresh [Page 13]
Internet Draft Network Address + Protocol Translator January 1999
NAT-PT can be a valuable transition tool at the border of a stub net-
work that has been deployed as an IPv6 only network and it is con-
nected to an Internet that is either V4-only or a combination of V4
and V6.
NAT-PT, in its simplest form, without the support of DNS-ALG provides
one way connectivity between an IPv6 stub domain and the IPv4 world
meaning that only sessions initialised by IPv6 nodes internal to the
IPv6 stub domain can be translated, while sessions initiated by IPv4
nodes are droped. This makes NAT-PT a useful tool to IPv6 only stub
networks that need to be able to maintain connectivity with the IPv4
world without the need to deploy servers visible to the IPv4 world.
NAT-PT combined with a DNS-ALG provides bi-directional connectivity
between the IPv6 stub domain and the IPv4 world allowing sessions to
be initialised by IPv4 nodes outside the IPv6 stub domain. This
makes NAT-PT useful for IPv6 only stub networks that need to deploy
servers visible to the IPv4 world.
8. Security Considerations
Section 6.4 of this document describes the fact that end-to-end
network and transport layer security is not possible when a session
is intercepted by a NAT-PT. Also application layer security may not
be possible for applications that carry IP addresses to the ap-
plication layer.
Section 6.5 of this document describes the fact that the DNS-ALG can
not be deployed in combination with secure DNS.
Finally, all of the security considerations described in [NAT-TERM]
are applicable to this document as well.
9. REFERENCES
[DNSSEC] D. Eastlake, C. Kaufman, "Domain Name System Security Exten-
sions", RFC 2065, January 1997.
[NAT] K. Egevang, P. Francis, The IP Network Address Translator (NAT),
RFC 1631, May 1994
[NAT-TERM] P. Srisuresh, M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations" <draft-ietf-nat-terminolo-
gy-01.txt>
Tsirtsis & Srisuresh [Page 14]
Internet Draft Network Address + Protocol Translator January 1999
[SIIT] E. Nordmark, "Stateless IP/ICMP Translator (SIIT)",
<draft-ietf-ngtrans-siit-04.txt>, Work in progress, December 1998
[TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts
and Routers, RFC 1933, April 1996
AUTHORS
George Tsirtsis
Internet Transport Group
B29 Room 129
BT Laboratoties
IPSWICH IP5 3RE
England
Phone: +44 1473 640756
Fax: +44 1473 640709
e-mail: george@gideon.bt.co.uk
Pyda Srisuresh
Lucent Technologies
4464 Willow Road
Pleasanton, CA 94588-8519
U.S.A.
Voice: (925) 737-2153
Fax: (925) 737-2110
EMail: suresh@ra.lucent.com
Tsirtsis & Srisuresh [Page 15]
Internet Draft Network Address + Protocol Translator January 1999
