[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/