Network Working Group S. Satapati
Internet-Draft S. Sivakumar
Expires: April 16, 2004 Cisco Systems, Inc.
P. Barany
No Affiliation
S. Okazaki
NTT Multimedia Communications Labs
H. Wang
Nokia
October 17, 2003
NAT-PT Applicability
draft-satapati-v6ops-natpt-applicability-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 16, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document discusses the applicability RFC 2766, Network Address
Translation - Protocol Translation (NAT-PT) employing the Stateless
IP/ICMP Translation (SIIT) algorithm, as an IPv4-to-IPv6 transition
and co-existence mechanism. It highlights the NAT-PT/SIIT operational
principles and the network context for which NAT-PT was designed.
Known limitations of NAT-PT/SIIT are presented. Applicable scenarios
Satapati, et al. Expires April 16, 2004 [Page 1]
Internet-Draft NAT-PT Applicability October 2003
along with guidelines for deployment are being offered.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SIIT Limitations . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Overloading the Use of IPv4-mapped addresses . . . . . . . . 4
2.2 Translation Semantics Difficult to Use . . . . . . . . . . . 4
2.3 Multicast Mapping Impossible . . . . . . . . . . . . . . . . 5
2.4 SCTP and Multihoming . . . . . . . . . . . . . . . . . . . . 5
2.5 IP Security (IPsec) . . . . . . . . . . . . . . . . . . . . 5
2.5.1 IPsec Encapsulating Security Protocol (ESP) . . . . . . . . 5
2.5.2 IPsec Authentication Header (AH) . . . . . . . . . . . . . . 6
2.5.3 Key Management . . . . . . . . . . . . . . . . . . . . . . . 6
3. NAT-PT Limitations . . . . . . . . . . . . . . . . . . . . . 7
3.1 Application deployment . . . . . . . . . . . . . . . . . . . 7
3.2 Scalability/Single-point-of-failure . . . . . . . . . . . . 7
3.3 IP Security . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1 IPsec ESP/AH . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.2 Key Management . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 DNS-ALG . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5 Denial of Service . . . . . . . . . . . . . . . . . . . . . 8
3.5.1 Address Pool Depletion Attacks . . . . . . . . . . . . . . . 9
3.5.2 Reflection Attacks . . . . . . . . . . . . . . . . . . . . . 9
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 SIIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 NAT-PT . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1 Legacy IPv4-only nodes in an IPv6 network . . . . . . . . . 10
4.2.2 Special Nodes/Networks . . . . . . . . . . . . . . . . . . . 10
4.2.3 IPv6-only Networks . . . . . . . . . . . . . . . . . . . . . 11
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
Normative References . . . . . . . . . . . . . . . . . . . . 12
Informative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
A. IPv6-only Networks . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . 16
Satapati, et al. Expires April 16, 2004 [Page 2]
Internet-Draft NAT-PT Applicability October 2003
1. Introduction
NAT-PT [1], or Network Address translation Protocol translation, is
the standard mechanism that allows communication between IPv6-only
and IPv4-only nodes. RFC 2766 also defines NAPT-PT, a variant of
NAT-PT that translates transport identifiers (TCP/UDP port numbers
and ICMP identifiers) in addition to IP header, allows multiple V6
nodes to communicate with V4 nodes using a single public IPv4
address.
SIIT [2] specifies an algorithm for translation between IPv4 and IPv6
packet headers (including ICMP headers) in separate translator boxes
in the network without requiring any per-connection state in those
boxes. An IPv6-only node acquires a temporary IPv4 address (known as
an IPv4-translated address) when communicating with an IPv4-only
node. IPv6 nodes, that use SIIT, would need additional logic in the
network layer so that an application inserts IPv4 type literals in
the payload if the destination is an IPv4-mapped IPv6 address. SIIT
does not specify a mechanism for the IPv6-only node to acquire a
temporary IPv4 address, nor does it specify a mechanism for providing
routing (perhaps using tunneling) to and from the temporary IPv4
address assigned to the IPv6-only node.
NAT-PT uses SIIT algorithm for protocol independent translation of
IPv4 and IPv6 datagrams. NAT-PT describes the dynamic address
assignment of IPv4 address to IPv6 nodes and vice-versa, as sessions
are initiated across IPv4/IPv6 boundaries. The IPv4 addresses are
assigned from an IPv4 address pool and are used to transparently
replace the original IPv6 addresses used by the IPv6-only nodes.
Consequently, the IPv6-only nodes need not be changed in any way.
However, NAT-PT must track sessions (i.e., state must be maintained)
and the inbound and outband packets pertaining to a session must
traverse the same NAT-PT device.
RFC 2766 specifies DNS-ALG for address discovery to support
bidirectional session initiation. RFC 2766 also specifies FTP-ALG to
provide application level transparency between IPv4 and IPv6. For
applications (like FTP) that carry IP addresses and/or transport
layer port numbers in their application-level data, additional
Application Layer Gateways (ALGs) would need to be deployed along
with NAT-PT.
This document discusses the applicability of Network Address
Translation - Protocol Translation as an IPv4-to-IPv6 transition and
co-existence mechanism. It highlights the NAT-PT/SIIT operational
principles and the network context for which NAT-PT was designed.
Known limitations of NAT-PT/SIIT are presented. Applicable scenarios
along with guidelines for deployment are being offered.
Satapati, et al. Expires April 16, 2004 [Page 3]
Internet-Draft NAT-PT Applicability October 2003
Sections 2 and 3 talk about limitations of SIIT and NAT-PT (including
DNS-ALG) in its current form. Section 4 presents the applicable
scenarios. Section 5 summarizes the applicability and proposes some
recommendations when deploying NAT-PT.
2. SIIT Limitations
In this section, we present the limitatons that are specific to SIIT.
It is important to analyze SIIT because it is an integral part of
NAT-PT.
2.1 Overloading the Use of IPv4-mapped addresses
IPv4-mapped IPv6 addresses are of the form ::ffff:a.b.c.d, and are
used to refer to IPv4-only nodes. An IPv6 packet, going through SIIT
from an IPv6-only node, will have IPv4-mapped address as destination
in the IPv6 header. Problems associated with usage of IPv4-mapped
address have been discussed in an expired draft [3].
Most notably, as described in RFC 3493 [8], the IPv4-mapped address
representation is used in the basic API to denote IPv4 addresses
using the AF_INET6 socket. However, at the same time, the IPv4-mapped
address is also used by SIIT to denote IPv6 communication using
AF_INET6 sockets. Consequently, a security threat exists due to the
ambiguous dual use of IPv4-mapped addresses.
2.2 Translation Semantics Difficult to Use
Some of the translation semantics defined by SIIT are difficult to
implement/interpret. The ICMPv4 "Parameter Problem" (type 12 code 0)
and the ICMPv6 "Parameter Problem" (Type 4 Code 0, 1, 2) error
messages are classic examples. Some ICMP error messages do not have
IPv6 counterpart and hence there were no semantics defined. A
particular problem being reported in the IPv4-side may go
unrecognized from the IPv6 perspective.
In order to translate from ICMPv6 to ICMPv4, if the ICMPv6 code field
is set to 1 (unrecognizable Next Header Type encountered), then the
ICMPv6 message is translated into an ICMPv4 Destination Unreachable
Message (Type 3 code 2) Error Message. There is no loss of
information in this case. However, if the ICMPv6 code field is set to
0 (erronenous header field encountered) or 2 (unrecognized IPv6
option encountered), then the ICMPv6 message is translated into an
ICMPv4 Parameter Problem (Type 12 Code 0) Error Message and the
pointer needs to be updated to point to the corresponding field in
the translated and included IP header. There is a loss of information
in this case.
Satapati, et al. Expires April 16, 2004 [Page 4]
Internet-Draft NAT-PT Applicability October 2003
2.3 Multicast Mapping Impossible
IPv4 multicast addresses cannot be mapped to IPv6 multicast addresses
(e.g., ::ffff:224.1.2.3 is an IPv4-mapped address with a Class D IPv4
address, but it is not an IPv6 multicast address). This limitation
makes it impossible for SIIT to support multicast between IPv6 and
IPv4 networks.
2.4 SCTP and Multihoming
SCTP [9] supports multihoming. If an IPv6-only node sets up SCTP
connections to an IPv4-only node with one or more SIITs between them,
there could be a problem. If more than one IPv4-translated address is
used, these addresses are transported to the IPv4-only node during
association setup in the payloads of the INIT and INIT-ACK chunks.
SIIT, as specified in [1], cannot translate IP addresses included in
INIT and INIT-ACK chunks. Even if it could, there would be a problem
with SCTP/IP packets being carried through the translator using ESP
in Transport-mode.
Also, there is ongoing work which allows the modification of the IP
address once an SCTP association has been established (for
non-multihoming purposes). The modification messages have IP
addresses in the SCTP packet [14].
2.5 IP Security (IPsec)
2.5.1 IPsec Encapsulating Security Protocol (ESP)
ESP provides both confidentiality and integrity for the packet that
it is protecting [10]. ESP in Transport-mode encrypts the transport
layer header, the data, and the ESP trailer (optional Padding, Pad
Length, and Next Header). ESP in Transport-mode authenticates the ESP
header (SPI, Sequence Number, and IV) in addition to the transport
layer header, the data, and the ESP trailer.
SIIT does not modify any headers above the logical IP layer (IP
headers, IPv6 fragment headers). Therefore, TCP/UDP packets encrypted
using ESP in Transport-mode can pass through, assuming that key
management (manual or IKE) can operate somehow between an IPv6-only
node and IPv4-only node. The reason being the notation of
IPv4-translatable addresses, which is ::ffff:0:a.b.c.d, was chosen to
avoid any changes to the transport layer protocol's pseudo-header
checksum. Also, SCTP calculates a CRC-32c checksum only on the SCTP
packet (SCTP common header and one or more control or DATA chunks).
Therefore, as long as SCTP control chunks like INIT and INIT-ACK do
not contain IP addresses, SCTP packets encrypted using ESP in
Transport-mode can pass through SIIT.
Satapati, et al. Expires April 16, 2004 [Page 5]
Internet-Draft NAT-PT Applicability October 2003
ICMP messages, on the other hand, cannot be carried through SIIT for
a number of reasons:
o the ICMP checksum field must be updated as part of the translation
since ICMPv6, unlike ICMPv4, has a pseudo-header checksum like TCP
or UDP
o ICMP packets need to have the Type value translated
o for ICMP error messages, the included IP header also needs
translation
ESP in Tunnel-mode encrypts the IP header of the encapsulated IP
packet in addition to the transport layer header, the data, and the
ESP trailer of the encapsulated IP packet. ESP in Tunnel-mode
authenticates the ESP header in addition to the encapsulated IP
packet and the transport layer header, the data, and the ESP trailer
of the encapsulated IP packet. Consequently, TCP/IP packets, UDP/IP
packets, SCTP/IP packets, and ICMP packets cannot be carried through
the SIIT translator using ESP in Tunnel-mode.
2.5.2 IPsec Authentication Header (AH)
AH provides integrity for the packet that it is protecting [11]. AH
is explicitly designed to detect alterations to IP packet headers. AH
in Transport-mode authenticates the immutable fields of the IP header
(setting the mutable fields to zero prior to calculating the
Integrity Check Value (ICV)), the AH header (Next Header, Payload
Length, Reserved, SPI, and Sequence Number), and the data.
Consequently, TCP/IP packets, UDP/IP packets, SCTP/IP packets, and
ICMP packets, or any such packets cannot be carried through the SIIT
translator using AH in Transport-mode.
AH in Tunnel-mode authenticates the immutable fields of the outer IP
header (setting the mutable fields to zero prior to calculating the
ICV), the AH header, the encapsulated IP header, the transport layer
header, and the data. Consequently, TCP/IP packets, UDP/IP packets,
SCTP/IP packets, and ICMP packets, or any such packets cannot be
carried through the SIIT translator using AH in Tunnel-mode.
2.5.3 Key Management
Note that this entire discussion begs the question that key
management can operate between the IPv6-only node and the IPv4-only
node. While this may not be an issue for IPsec implementations that
are integrated with the host's Operating System (OS), there could be
substantial challenges that need to be overcome with either a
Bump-In-the-Stack (BIS) or Bump-In-The-Wire (BITW) IPsec
Satapati, et al. Expires April 16, 2004 [Page 6]
Internet-Draft NAT-PT Applicability October 2003
implementation [12].
For example, the ISAKMP Identification payload [13] that is used in
IKE Phase 1 Main Mode/Aggressive Mode (pre-shared secret, digital
signatures with certificates, public key encryption, and revised
public key encryption) may contain the IP address of the host as an
identifier (e.g., ID_IPV6_ADDR, ID_IPV4_ADDR). The same holds true
for IKE Phase 2 Quick Mode and the optional usage of the Client
Identification payload. While the use of other identifiers such as
ID_FQDN and ID_USER_FQDN are possible, there are usage scenarios that
cannot be accommodated in this manner (e.g., SPD entries describing
subnets).
3. NAT-PT Limitations
The adverse effects of NAT [4] have been studied to a great extent in
the past [7]. While NAT-PT has exactly the same implications as NAT,
the DNS-ALG as specified in RFC 2766 introduces additional failure
modes. Most applications may fail for exactly the same reasons as
those cited for IPv4 NAT. All SIIT limitations mentioned above hold
true for NAT-PT, except those due to usage of IPv4-mapped IPv6
addresses. NAT-PT proposes to use a /96 prefix, which need not be a
IPv4-mapped IPv6 address type. The limitations of DNS-ALG, as an
inherent address discovery mechanism, are also discussed in this
section.
3.1 Application deployment
Applications that embed literals, such as IP addresses and/or TCP/UDP
port numbers, will break across NAT-PT in the absence of a supporting
ALG. ALGs are required to setup bindings during signalling, which
would subsequently be used for data (or media) traffic. Each
application requires its own specific ALG to be deployed that should
work in tandem with header-translation functionality. It is hard to
cope up with this situation, as new applications become popular or
existing applications define new extensions or message types.
3.2 Scalability/Single-point-of-failure
A single device implementing NAT-PT (and ALGs) can easily become a
bottleneck, when traffic from a large IPv6 network is forced to go
through a single device. The device builds and maintains binding
state as traffic flows traverse. Therefore all subsequent traffic of
the flow must pass through it, turning the device into a single point
of failure.
3.3 IP Security
Satapati, et al. Expires April 16, 2004 [Page 7]
Internet-Draft NAT-PT Applicability October 2003
3.3.1 IPsec ESP/AH
All of the IPsec ESP and AH limitations that apply to SIIT also apply
to NAT-PT because NAT-PT(and NAPT-PT) make use of SIIT translation
algorithm to translate IP headers and transport identifiers. However,
unlike SIIT, NAT-PT need not use IPv4-translated addresses and IPv4-
mapped addresses. Therefore, TCP/IP, UDP/IP, and ICMP packets cannot
be carried through NAT-PT in ESP Transport-mode because TCP, UDP, and
ICMPv6 checksums have a dependency on the IP source and destination
addresses via the pseudo-header. However, SCTP calculates a CRC-32c
checksum only on the SCTP packet (SCTP common header and one or more
control or DATA chunks). Therefore, as long as SCTP control chunks
like INIT and INIT-ACK do not contain IP addresses, SCTP packets
encrypted using ESP in Transport-mode can pass through NAT-PT.
3.3.2 Key Management
All of the key management limitations that apply to SIIT also apply
to NAT-PT because NAT-PT (and NAPT-PT) make use of SIIT translation
algorithm to translate IP headers and transport identifiers. Also,
since NAT-PT maintains state (unlike SIIT), even if IP addresses are
not used in the ISAKMP Identification payload during IKE Phase 1 Main
Mode/Aggressive Mode and IKE Phase 2 Quick Mode, there is still
difficulty with retaining the IPv4-to-IPv6 address mapping on NAT-PT
from the time that IKE completes negotiation to the time that IPsec
uses the key on an application.
3.4 DNS-ALG
Address discovery is the mechanism by which an IPv4-only or an
IPv6-only node discovers the "translated address" to which the
packets should be sent. The NAT-PT specification proposes to solve
address discovery, for applications that use DNS, by using a DNS-ALG,
as specified in section 4 of RFC-2766.
Address discovery through DNS-ALG is broken when dual-stack nodes
attempt to talk to either IPv6-only or IPv4-only nodes. The result
here is the possibility of traffic flow taking a translated path as
opposed to native. Additionally an IPv4 node that sends an A query,
through DNS-ALG, may receive a AAAA reply.
Since DNS-ALG modifies queries (from A to AAAA) and replies (IPv6
address to IPv4 address literals), DNSSEC cannot be deployed in the
presence of DNS-ALG.
3.5 Denial of Service
The DoS attacks being discussed here are mostly due to address
Satapati, et al. Expires April 16, 2004 [Page 8]
Internet-Draft NAT-PT Applicability October 2003
spoofing.
3.5.1 Address Pool Depletion Attacks
Suppose that the attacker resides in the same IPv6 stub domain as
NAT-PT, and is sending packets to an IPv4-only destination. If the
IPv6 attacker sends multiple packets with different source address
(that are topologically inside the stub domain), then the pool of
IPv4 addresses managed by NAT-PT will quickly exhaust resulting in a
Denial of Service to legitimate IPv6-only nodes.
3.5.2 Reflection Attacks
There is another address spoofing attack, wherein the attacker forges
the IPv6 source address to be a broadcast or multicast or the source
address of an existing node. The reply IPv4 packets that get
translated by NAT-PT will result in an attack.
4. Applicability
4.1 SIIT
SIIT assumes v4 address assignment to IPv6 nodes, and routing to that
assigned v4 address. These aspects are actually requirements for SIIT
deployment. Additionally, IPv6 nodes need some modification as
mentioned in Section 1. Any host modifications to support a certain
transition mechanism are strongly discouraged. Applications cannot
interoperate between pure IPv6-only and IPv4-only nodes using SIIT,
unless there exists an ALG accompanying SIIT.
If SIIT were to de deployed for IPv6-only nodes (i.e. without the
modifications proposed by SIIT), it is mandatory to have supporting
ALGs for applications that need interoperability. The device
implementing SIIT must maintain binding state somehow. This
combination is not very different from deployment model of NAT-PT.
Hence applicable scenarios would be the same as the ones explained
below.
The SIIT algorithm may be useful in header translation if some
specific-purpose translators are specified which can live with the
shortcomings of SIIT.
4.2 NAT-PT
It is theoretically possible to deploy NAT-PT at the border of an
IPv6-only stub network, either translating specific IPv6-only
services to IPv4 nodes or by translating IPv4-only services to IPv6
nodes. The latter comes in two flavors: translation by the party
Satapati, et al. Expires April 16, 2004 [Page 9]
Internet-Draft NAT-PT Applicability October 2003
providing such an IPv4-only service, or someone servicing them, or by
the party which is planning to deploy IPv6-only infrastructure. There
are some very specific cases, where one may be able to consider its
use.
4.2.1 Legacy IPv4-only nodes in an IPv6 network
This is the scenario where the entire network infrastructure is IPv6
and the majority of nodes attached to the network are IPv6-only. But
there are some existing (legacy) IPv4-only hosts that cannot be
upgraded (or abandoned) and that need connectivity to the neighboring
IPv6 nodes.
It is unrealistic to continue deploying/supporting dual-stack nodes
network-wide to support a small set of legacy IPv4-only hosts.
Ideally, legacy nodes must be retired as quickly as possible. Proxy/
relay mechanism, such as TRT[5], could be used to enable basic
applications that use TCP/UDP. Since host upgrade is ruled out,
NAT-PT can be used when traffic to/from these legacy hosts is
minimal. NAT-PT must be considered only when proxies cannot be
deployed or deemed unfit for the specific application being enabled.
While this scenario may be acceptable within an organization/domain,
the same may not be true between independent domains. The
consequences of NAT-PT, as discussed above, must be kept in mind
during deployment.
4.2.2 Special Nodes/Networks
This scenario applies to situations where constraints arise that are
either imposed by the network or by the end nodes. These constraints
do not apply to a general purpose IP network or generic TCP/IP hosts
connected to a general purpose IP network. Few special cases are
listed below:
o devices are IPv6-only due to memory and code size constraints
o devices are built to run a specific well-defined set of
applications
o devices could be dual-stack; but resource consumption in the
network should be kept at a minimum
3GPP networks is an example of the latter, where IMS is IPv6-only by
design and PDP context is supposedly a scarce resource.
4.2.2.1 Restricted use in 3GPP Networks
Satapati, et al. Expires April 16, 2004 [Page 10]
Internet-Draft NAT-PT Applicability October 2003
An important requirement for 3GPP networks is that 3GPP hosts,
running SIP-based IMS applications over IPv6, must be able to
communicate with IPv4 SIP hosts on the Internet [6]. To minimize the
number of active PDP Contexts in the mobile network, it should be
possible for a 3GPP host to access both IMS applications and other
non-IMS applications (non-SIP-based) over a single IPv6 connection
(IPv6 PDP Context in 3GPP).
NA(P)T-PT may be used for translating traffic pertaining to specific
(non-IMS) applications, for which dual-stack application proxies are
not suitable. NA(P)T-PT may be used for header translation of IMS
media traffic, provided the binding is acquired through different
means. In other words, the device implementing header translation
must not implement ALGs. The mechanism of acquiring the binding from
an external entity is beyond the scope of this document.
IMS media translation may prove to be a burden and inefficient if a
single device is implementing header translation. Distributed
approaches/techniques may be considered to offload the translation
responsibility to multiple devices, which requires exchange of
binding state between devices. The exact operation of such an
approach is beyond the scope of this document.
4.2.2.2 3GPP2 Networks
For further study.
4.2.3 IPv6-only Networks
The deployment of IPv6-only networks in general is not recommended,
and therefore this scenario is only tentatively described in Appendix
A.
5. Summary
This document discourages NAT-PT (RFC 2766) as a general purpose
transition mechanism, except for the scenarios mentioned above. The
limitations cited in this document must be observed during
deployment. Only if the shortcomings of NAT-PT are acceptable in a
particular deployment, may the use of NAT-PT be considered as a
short-term solution. In no case should NAT-PT be viewed as a generic
solution for IPv6/IPv4 transition in an IPv6-only network.
It is to be noted that DNS-ALG has severe failure modes when
processing AAAA queries. However, DNS-ALG could still be used for
IPv4-initiated connections.
For special networks, targeted translation using NAT-PT is acceptable
Satapati, et al. Expires April 16, 2004 [Page 11]
Internet-Draft NAT-PT Applicability October 2003
for short term. Migrating entirely to IPv6 is considered beneficial
in the long run.
RFC 2766 specifies NAT-PT using the SIIT algorithm for header
conversion, DNS-ALG for address discovery, and FTP-ALG as one
application level gateway mechanism. The terminology in RFC 2766 can
easily be misinterpreted, in that NAT-PT mandates ALGs. RFC 2766 does
not mandate DNS-ALG to be implemented along with header translation
mechanism.
6. Security Considerations
This memo discusses the limitations and the applicability of NAT-PT.
One important consideration in this analysis is the security related
to packet translation. As shown, IPsec AH and ESP generally do not
work through the NAT-PT translators. Similarly, the NAT-PT DNS-ALG
and similar algorithms cause bottlenecks and a concern for
availability if deployed. The generic translation mechanisms seem to
be causing a number of problems. Therefore, mass deployment of
translators is not recommended; some use may be possible in very
specific cases identified in this memo.
7. Acknowledgements
The authors gratefully acknowledge the contributions of Pekka Savola
and Rob Austein.
Normative References
[1] Tsirtsis and Srisuresh, "Network Address Translation - Protocol
Translation (NAT-PT)", RFC 2766, February 2000.
[2] Nordmark, "Stateless IP/ICMP Translator (SIIT)", RFC 2765,
February 2000.
[3] Metz and Hagino, "IPv4-Mapped Addresses on the Wire Considered
Harmful", draft-itojun-v6ops-v4mapped-harmful-01 Expired,
October 2002.
[4] Srisuresh and Egevang, "The IP Network Address Translator", RFC
3022, January 2001.
[5] Hagino and Yamamoto, "An IPv6-to-IPv4 Transport Relay
Translator", RFC 3142, June 2001.
[6] Soininen et al., "Transition Scenarios for 3GPP Networks", RFC
3574, August 2003.
Satapati, et al. Expires April 16, 2004 [Page 12]
Internet-Draft NAT-PT Applicability October 2003
Informative References
[7] Hain, "Architectural Implications of NAT", RFC 2993, November
2000.
[8] Gilligan, R. et al., "Basic Socket Interface Extensions for
IPv6", RFC 3493, February 2003.
[9] Stewart, R. et al., "Stream Control Transmission Protocol", RFC
2960, October 2000.
[10] Kent and Atkinson, "IP Encapsulating Security Payload", RFC
2406, November 1998.
[11] Kent and Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[12] Kent and Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[13] Maughan, D. et al., "Internet Security Association and Key
Management Protocol", RFC 2408, November 1998.
[14] Stewart, R. et al., "Stream Control Transmission Protocol
(SCTP) Dynamic Address Reconfiguration",
draft-ietf-tsvwg-addip-sctp-08 Work in progress, September
2003.
Authors' Addresses
Suresh Satapati
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
USA
EMail: satapati@cisco.com
Senthil Sivakumar
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
USA
EMail: ssenthil@cisco.com
Satapati, et al. Expires April 16, 2004 [Page 13]
Internet-Draft NAT-PT Applicability October 2003
Peter Barany
No Affiliation
EMail: Baranyp9@aol.com
Satomi Okazaki
NTT Multimedia Communications Labs
250 Cambridge Avenue
Palo Alto, CA 94306
USA
EMail: satomi@nttmcl.com
Hao H. Wang
Nokia
5th Floor, House 1, No.11, Hepingli Dongjie
Beijing
China
EMail: hao.h.wang@nokia.com
Appendix A. IPv6-only Networks
To roll out a new network, the options are IP4-only, IPv6-only or
dual-stack. The most important requirement would be connectivity to
surrounding internal networks or an external network such as the
Internet. This connectivity has to be IPv4, due to existing deployed
base. Therefore the options are:
o If the new network is deployed as IPv4-only, there needs to be a
NAT at the edge of the network due to private addressing.
o If the network is dual-stack, there is still a need for NAT again
due to private addressing.
o If the network is deployed as IPv6-only, then there is a need for
mechanism such as NAT-PT.
Some are of the opinion that dual-stack network is most preferred
manner of introducing IPv6, until such time when there are no
IPv4-only nodes. Several questions arise like: what are the costs
involved in running a dual-stack network; will IPv4-only
implementations cease to appear in the marketplace; will the true
potential of IPv6 be realized on a dual-stack network; how do
protocols interact in a dual-stack network; are there known problems/
limitations/failure modes; do we have enough experience running a
Satapati, et al. Expires April 16, 2004 [Page 14]
Internet-Draft NAT-PT Applicability October 2003
dual-stack network etc.
Satapati, et al. Expires April 16, 2004 [Page 15]
Internet-Draft NAT-PT Applicability October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Satapati, et al. Expires April 16, 2004 [Page 16]
Internet-Draft NAT-PT Applicability October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Satapati, et al. Expires April 16, 2004 [Page 17]