<pre>Network Working Group                                            C. Aoun
Request for Comments: 4966                                Energize Urnet
Obsoletes: <a href="./rfc2766">2766</a>                                                E. Davies
Category: Informational                                 Folly Consulting
                                                               July 2007


  <span class="h1">Reasons to Move the Network Address Translator - Protocol Translator</span>
                      <span class="h1">(NAT-PT) to Historic Status</span>

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document discusses issues with the specific form of IPv6-IPv4
   protocol translation mechanism implemented by the Network Address
   Translator - Protocol Translator (NAT-PT) defined in <a href="./rfc2766">RFC 2766</a>.  These
   issues are sufficiently serious that recommending <a href="./rfc2766">RFC 2766</a> as a
   general purpose transition mechanism is no longer desirable, and this
   document recommends that the IETF should reclassify <a href="./rfc2766">RFC 2766</a> from
   Proposed Standard to Historic status.






















<span class="grey">Aoun &amp; Davies                Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-3">3</a>
   <a href="#section-2">2</a>.  Issues Unrelated to an DNS-ALG . . . . . . . . . . . . . . . .  <a href="#page-7">7</a>
     <a href="#section-2.1">2.1</a>.  Issues with Protocols Embedding IP Addresses . . . . . . .  <a href="#page-7">7</a>
     <a href="#section-2.2">2.2</a>.  NAPT-PT Redirection Issues . . . . . . . . . . . . . . . .  <a href="#page-8">8</a>
     <a href="#section-2.3">2.3</a>.  NAT-PT Binding State Decay . . . . . . . . . . . . . . . .  <a href="#page-8">8</a>
     <a href="#section-2.4">2.4</a>.  Loss of Information through Incompatible Semantics . . . .  <a href="#page-9">9</a>
     <a href="#section-2.5">2.5</a>.  NAT-PT and Fragmentation . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
     <a href="#section-2.6">2.6</a>.  NAT-PT Interaction with SCTP and Multihoming . . . . . . . <a href="#page-11">11</a>
     <a href="#section-2.7">2.7</a>.  NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . <a href="#page-12">12</a>
     <a href="#section-2.8">2.8</a>.  NAT-PT and Multicast . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
   <a href="#section-3">3</a>.  Issues Exacerbated by the Use of DNS-ALG . . . . . . . . . . . <a href="#page-13">13</a>
     <a href="#section-3.1">3.1</a>.  Network Topology Constraints Implied by NAT-PT . . . . . . <a href="#page-13">13</a>
     <a href="#section-3.2">3.2</a>.  Scalability and Single Point of Failure Concerns . . . . . <a href="#page-14">14</a>
     <a href="#section-3.3">3.3</a>.  Issues with Lack of Address Persistence  . . . . . . . . . <a href="#page-15">15</a>
     <a href="#section-3.4">3.4</a>.  DoS Attacks on Memory and Address/Port Pools . . . . . . . <a href="#page-16">16</a>
   <a href="#section-4">4</a>.  Issues Directly Related to Use of DNS-ALG  . . . . . . . . . . <a href="#page-16">16</a>
     4.1.  Address Selection Issues when Communicating with
           Dual-Stack End-Hosts . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
     <a href="#section-4.2">4.2</a>.  Non-Global Validity of Translated RR Records . . . . . . . <a href="#page-18">18</a>
     <a href="#section-4.3">4.3</a>.  Inappropriate Translation of Responses to A Queries  . . . <a href="#page-19">19</a>
     <a href="#section-4.4">4.4</a>.  DNS-ALG and Multi-Addressed Nodes  . . . . . . . . . . . . <a href="#page-19">19</a>
     <a href="#section-4.5">4.5</a>.  Limitations on Deployment of DNS Security Capabilities . . <a href="#page-19">19</a>
   <a href="#section-5">5</a>.  Impact on IPv6 Application Development . . . . . . . . . . . . <a href="#page-20">20</a>
   <a href="#section-6">6</a>.  Security Considerations  . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
   <a href="#section-7">7</a>.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
   <a href="#section-8">8</a>.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
   <a href="#section-9">9</a>.  References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
     <a href="#section-9.1">9.1</a>.  Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
     <a href="#section-9.2">9.2</a>.  Informative References . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>




















<span class="grey">Aoun &amp; Davies                Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The Network Address Translator - Protocol Translator (NAT-PT)
   document [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>] defines a set of network-layer translation
   mechanisms designed to allow nodes that only support IPv4 to
   communicate with nodes that only support IPv6, during the transition
   to the use of IPv6 in the Internet.

   [<a id="ref-RFC2766">RFC2766</a>] specifies the basic NAT-PT, in which only addresses are
   translated, and the Network Address Port Translator - Protocol
   Translator (NAPT-PT), which also translates transport identifiers,
   allowing for greater economy of scarce IPv4 addresses.  Protocol
   translation is performed using the Stateless IP/ICMP Translation
   Algorithm (SIIT) defined in [<a href="./rfc2765" title="&quot;Stateless IP/ICMP Translation Algorithm (SIIT)&quot;">RFC2765</a>].  In the following discussion,
   where the term "NAT-PT" is used unqualified, the discussion applies
   to both basic NAT-PT and NAPT-PT.  "Basic NAT-PT" will be used if
   points apply to the basic address-only translator.

   A number of previous documents have raised issues with NAT-PT.  This
   document will summarize these issues, note several other issues
   carried over from traditional IPv4 NATs, and identify some additional
   issues that have not been discussed elsewhere.  Proposed solutions to
   the issues are mentioned and any resulting need for changes to the
   specification is identified.

   Whereas NAT is seen as an ongoing capability that is needed to work
   around the limited availability of globally unique IPv4 addresses,
   NAT-PT has a different status as a transition mechanism for IPv6.  As
   such, NAT-PT should not be allowed to constrain the development of
   IPv6 applications or impose limitations on future developments of
   IPv6.

   This document draws the conclusion that the technical and operational
   difficulties resulting from these issues, especially the possible
   future constraints on the development of IPv6 networks (see
   <a href="#section-5">Section 5</a>), make it undesirable to recommend NAT-PT as described in
   [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>] as a general purpose transition mechanism for
   intercommunication between IPv6 networks and IPv4 networks.

   Although the [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>] form of packet translation is not generally
   applicable, it is likely that in some circumstances a node that can
   only support IPv4 will need to communicate with a node that can only
   support IPv6; this needs a translation mechanism of some kind.
   Although this may be better carried out by an application-level proxy
   or transport-layer translator, there may still be scenarios in which
   a revised, possibly restricted version of NAT-PT can be a suitable
   solution; accordingly, this document recommends that the IETF should
   reclassify <a href="./rfc2766">RFC 2766</a> from Proposed Standard to Historic status to



<span class="grey">Aoun &amp; Davies                Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


   avoid it from being used in inappropriate scenarios while any
   replacement is developed.

   The following documents relating directly to NAT-PT have been
   reviewed while drafting this document:

   o  Network Address Translation - Protocol Translation (NAT-PT)
      [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>]

   o  Stateless IP/ICMP Translation Algorithm (SIIT) [<a href="./rfc2765" title="&quot;Stateless IP/ICMP Translation Algorithm (SIIT)&quot;">RFC2765</a>]

   o  NAT-PT Applicability Statement [<a href="#ref-NATP-APP" title="&quot;NAT-PT Applicability&quot;">NATP-APP</a>]

   o  Issues with NAT-PT DNS ALG (Application Layer Gateway) in <a href="./rfc2766">RFC 2766</a>
      [<a href="#ref-DNS-ALG-ISSUES" title="&quot;Issues with NAT-PT DNS ALG in RFC2766&quot;">DNS-ALG-ISSUES</a>]

   o  NAT-PT DNS ALG Solutions [<a href="#ref-DNS-ALG-SOL" title="&quot;NAT-PT DNS ALG solutions&quot;">DNS-ALG-SOL</a>]

   o  NAT-PT Security Considerations [<a href="#ref-NATPT-SEC" title="&quot;NAT-PT Security Considerations&quot;">NATPT-SEC</a>]

   o  Issues when Translating between IPv4 and IPv6 [<a href="#ref-TRANS-ISSUES" title="&quot;Issues when translating between IPv4 and IPv6&quot;">TRANS-ISSUES</a>]

   o  IPv6-IPv4 Translation Mechanism for SIP-Based Services in Third
      Generation Partnership Project (3GPP) Networks [<a href="#ref-3GPP-TRANS" title="&quot;IPv6-IPv4 Translation mechanism for SIP-based services in Third Generation Partnership Project (3GPP) Networks&quot;">3GPP-TRANS</a>]

   o  Analysis on IPv6 Transition in 3GPP Networks [<a href="./rfc4215" title="&quot;Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks&quot;">RFC4215</a>]

   o  Considerations for Mobile IP Support in NAT-PT [<a href="#ref-NATPT-MOB" title="&quot;Considerations for Mobility Support in NAT-PT&quot;">NATPT-MOB</a>]

   o  An IPv6-IPv4 Multicast Translator based on Internet Group
      Management Protocol / Multicast Listener Discovery (IGMP/MLD)
      Proxying (mtp) [<a href="#ref-MTP" title="&quot;An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)&quot;">MTP</a>]

   o  An IPv4-IPv6 Multicast Gateway [<a href="#ref-MCASTGW" title="&quot;An IPv4 - IPv6 multicast gateway&quot;">MCASTGW</a>]

   o  Scalable mNAT-PT Solution [<a href="#ref-MUL-NATPT" title="&quot;Scalable mNAT-PT Solution&quot;">MUL-NATPT</a>]

   Because the majority of the documents containing discussions of the
   issues are documents that are unlikely to become RFCs, the issues are
   summarized here to avoid the need for normative references.

   Some additional issues can be inferred from corresponding issues
   known to exist in 'traditional' IPv4 NATs.  The following documents
   are relevant:







<span class="grey">Aoun &amp; Davies                Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


   o  Protocol Complications with the IP Network Address Translator
      [<a href="./rfc3027" title="&quot;Protocol Complications with the IP Network Address Translator&quot;">RFC3027</a>]

   o  IP Network Address Translator (NAT) Terminology and Considerations
      [<a href="./rfc2663" title="&quot;IP Network Address Translator (NAT) Terminology and Considerations&quot;">RFC2663</a>]

   There is some ambiguity in [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>] about whether the Application
   Layer Gateway (ALG) for DNS (referred to as DNS-ALG in this document)
   is an integral and mandatory part of the specification.  The
   ambiguity arises mainly from the first section of the applicability
   section (<a href="#section-8">Section 8</a>), which appears to imply that 'simple' use of
   NAT-PT could avoid the use of the DNS-ALG.

   This is important because a number of the major issues arise from the
   interactions between DNS and NAT-PT.  However, detailed inspection of
   [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>] shows that the 'simple' case has not been worked out and it
   is unclear how information about the address translation could be
   passed to the hosts in the absence of the DNS-ALG.  Therefore, this
   document assumes that the DNS-ALG is an integral part of NAT-PT;
   accordingly, issues with the DNS-ALG must be considered as issues for
   the whole specification.

   Note that issues not specifically related to the use of the DNS-ALG
   will apply to any network-layer translation scheme, including any
   based on the SIIT algorithm [<a href="./rfc2765" title="&quot;Stateless IP/ICMP Translation Algorithm (SIIT)&quot;">RFC2765</a>].  In the event that new forms
   of a translator are developed as alternatives to NAT-PT, the generic
   issues relevant to all IPv6-IPv4 translators should be borne in mind.

   Issues raised with IPv6-IPv4 translators in general and NAT-PT in
   particular can be categorized as follows:

   o  Issues that are independent of the use of a DNS-ALG and are,
      therefore, applicable to any form of an IPv6-IPv4 translator:

      *  Disruption of all protocols that embed IP addresses (and/or
         ports) in packet payloads or apply integrity mechanisms using
         IP addresses (and ports).

      *  Inability to redirect traffic for protocols that lack
         demultiplexing capabilities or are not built on top of specific
         transport-layer protocols in situations where one NAPT-PT is
         translating for multiple IPv6 hosts.

      *  Requirement for applications to use keepalive mechanisms to
         workaround connectivity issues caused by premature NAT-PT state
         timeout.





<span class="grey">Aoun &amp; Davies                Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


      *  Loss of information due to incompatible semantics between IPv4
         and IPv6 versions of headers and protocols.

      *  Need for additional state and/or packet reconstruction in
         NAPT-PT translators dealing with packet fragmentation.

      *  Interaction with SCTP and multihoming.

      *  Need for NAT-PT to act as proxy for correspondent node when
         IPv6 node is mobile, with consequent restrictions on mobility.

      *  NAT-PT not being able to handle multicast traffic.

   o  Issues that are exacerbated by the use of a DNS-ALG and are,
      therefore, also applicable to any form of an IPv6-IPv4 translator:

      *  Constraints on network topology.

      *  Scalability concerns together with introduction of a single
         point of failure and a security attack nexus.

      *  Lack of address mapping persistence: Some applications require
         address retention between sessions.  The user traffic will be
         disrupted if a different mapping is used.  The use of the DNS-
         ALG to create address mappings with limited lifetimes means
         that applications must start using the address shortly after
         the mapping is created, as well as keep it alive once they
         start using it.

      *  Creation of a DoS (Denial of Service) threat relating to
         exhaustion of memory and address/port pool resources on the
         translator.

   o  Issues that result from the use of a DNS-ALG and are, therefore,
      specific to NAT-PT as defined in [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>]:

      *  Address selection issues when either the internal or external
         hosts implement both IPv4 and IPv6.

      *  Restricted validity of translated DNS records: a translated
         record may be forwarded to an application that cannot use it.

      *  Inappropriate translation of responses to A queries from IPv6
         nodes.







<span class="grey">Aoun &amp; Davies                Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


      *  Address selection issues and resource consumption in a DNS-ALG
         with multi-addressed nodes.

      *  Limitations on DNS security capabilities when using a DNS-ALG.

   <a href="#section-2">Section 2</a>, <a href="#section-3">Section 3</a> and <a href="#section-4">Section 4</a> discuss these groups of issues.
   <a href="#section-5">Section 5</a> examines the consequences of deploying NAT-PT for
   application developers and the long term effects of NAT-PT (or any
   form of generally deployed IPv6-IPv4 translator) on the further
   development of IPv6.

   The terminology used in this document is defined in [<a href="./rfc2663" title="&quot;IP Network Address Translator (NAT) Terminology and Considerations&quot;">RFC2663</a>],
   [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>], and [<a href="./rfc3314" title="&quot;Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards&quot;">RFC3314</a>].

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Issues Unrelated to an DNS-ALG</span>

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Issues with Protocols Embedding IP Addresses</span>

   It is well known from work on IPv4 NATs (see <a href="./rfc2663#section-8">Section&nbsp;8 of [RFC2663]</a>
   and [<a href="./rfc3027" title="&quot;Protocol Complications with the IP Network Address Translator&quot;">RFC3027</a>]) that the large class of protocols that embed numeric
   IP addresses in their payloads either cannot work through NATs or
   require specific ALGs as helpers to translate the payloads in line
   with the address and port translations.  The same set of protocols
   cannot pass through NAT-PT.  The problem is exacerbated because the
   IPv6 and IPv4 addresses are of different lengths, so that packet
   lengths as well as packet contents are altered.  [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>] describes
   the consequences as part of the description of the FTP ALG.  Similar
   workarounds are needed for all protocols with embedded IP addresses
   that run over TCP transports.

   The issues raised in Sections <a href="#section-2">2</a> and <a href="#section-3">3</a> of [<a href="./rfc2663" title="&quot;IP Network Address Translator (NAT) Terminology and Considerations&quot;">RFC2663</a>], relating to the
   authentication and encryption with NAT, are also applicable to
   NAT-PT.

   Implementing a suite of ALGs requires that NAT-PT equipment includes
   the logic for each of the relevant protocols.  Most of these
   protocols are continuously evolving, requiring continual and
   coordinated updates of the ALGs to keep them in step.

   Assuming that the NAT-PT contains a colocated ALG for one of the
   relevant protocols, the ALG could replace the embedded IP addresses
   and ports.  However, this replacement can only happen if no
   cryptographic integrity mechanism is used and the protocol messages
   are sent in the clear (i.e., not encrypted).

   A possible workaround relies on the NAT-PT being party to the
   security association used to provide authentication and/or
   encryption.  NAT-PT would then be aware of the cryptographic



<span class="grey">Aoun &amp; Davies                Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


   algorithms and keys used to secure the traffic.  It could then modify
   and re-secure the packets; this would certainly complicate network
   operations and provide additional points of security vulnerability.

   Unless UDP encapsulation is used for IPsec [<a href="./rfc3498" title="&quot;Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures&quot;">RFC3498</a>], traffic using
   IPsec AH (Authentication Header), in transport and tunnel mode, and
   IPsec ESP (Encapsulating Security Payload), in transport mode, is
   unable to be carried through NAT-PT without terminating the security
   associations on the NAT-PT, due to their usage of cryptographic
   integrity protection.

   A related issue with DNS security is discussed in <a href="#section-4.5">Section 4.5</a>.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  NAPT-PT Redirection Issues</span>

   <a href="./rfc3027#section-4.2">Section&nbsp;4.2 of [RFC3027]</a> discusses problems specific to RSVP and
   NATs, one of which is actually a more generic problem for all port
   translators.  When several end-hosts are using a single NAPT-PT box,
   protocols that do not have a demultiplexing capability similar to
   transport-layer port numbers may be unable to work through NAPT-PT
   (and any other port translator) because there is nothing for NAPT-PT
   to use to identify the correct binding.

   This type of issue affects IPsec encrypted packets where the
   transport port is not visible (although it might be possible to use
   the Security Parameter Index (SPI) as an alternative demultiplexer),
   and protocols, such as RSVP, which are carried directly in IP
   datagrams rather than using a standard transport-layer protocol such
   as TCP or UDP.  In the case of RSVP, packets going from the IPv4
   domain to the IPv6 domain do not necessarily carry a suitable
   demultiplexing field, because the port fields in the flow identifier
   and traffic specifications are optional.

   Several ad hoc workarounds could be used to solve the demultiplexing
   issues, however in most cases these solutions are not documented
   anywhere, which could lead to non-deterministic and undesirable
   behavior (for example, such workarounds often assume particular
   network topologies, etc., in order to function correctly; if the
   assumptions are not met in a deployment, the workaround may not work
   as expected).

   This issue is closely related to the fragmentation issue described in
   <a href="#section-2.5">Section 2.5</a>.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  NAT-PT Binding State Decay</span>

   NAT-PT will generally use dynamically created bindings to reduce the
   need for IPv4 addresses both for basic NAT-PT and NAPT-PT.  Both



<span class="grey">Aoun &amp; Davies                Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


   basic NAT-PT and NAPT-PT use soft state mechanisms to manage the
   address and, in the case of NAPT-PT, port pools are used for
   dynamically created address bindings.  This allows all types of
   NAT-PT boxes to operate autonomously without requiring clients to
   signal, either implicitly or explicitly, that a binding is no longer
   required.  In any case, without soft state timeouts, network and
   application unreliability would inevitably lead to leaks, eventually
   causing address or port pool exhaustion.

   For a dynamic binding to persist for longer than the soft state
   timeout, packets must be sent periodically from one side of the
   NAT-PT to the other (the direction is not specified by the NAT-PT
   specification).  If no packets are sent in the proper direction, the
   NAT-PT binding will not be refreshed and the application connection
   will be broken.  Hence, all applications need to maintain their
   NAT-PT bindings during long idle periods by incorporating a keepalive
   mechanism, which may not be possible for legacy systems.

   Also, [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>] does not specify how to choose timeouts for bindings.
   As discussed in [<a href="./rfc2663" title="&quot;IP Network Address Translator (NAT) Terminology and Considerations&quot;">RFC2663</a>] for traditional NATs, selecting suitable
   values is a matter of heuristics, and coordinating with application
   expectations may be impossible.

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>.  Loss of Information through Incompatible Semantics</span>

   NAT-PT reuses the SIIT header and protocol translations defined in
   [<a href="./rfc2765" title="&quot;Stateless IP/ICMP Translation Algorithm (SIIT)&quot;">RFC2765</a>].  Mismatches in semantics between IPv4 and IPv6 versions
   can lead to loss of information when packets are translated.  Three
   issues arising from this are:

   o  There is no equivalent in IPv4 for the flow label field of the
      IPv6 header.  Hence, any special treatment of packets based on
      flow label patterns cannot be propagated into the IPv4 domain.

   o  IPv6 extension headers provide flexibility for future improvements
      in the IP protocol suite and new headers that do not have
      equivalents in IPv4 may be defined.  In practice, some existing
      extensions such as routing headers and mobility extensions are not
      translatable.

   o  As described in Section 2.2 of [<a href="#ref-NATP-APP" title="&quot;NAT-PT Applicability&quot;">NATP-APP</a>], there are no
      equivalents in IPv6 for some ICMP(v4) messages, while for others
      (notably the 'Parameter Problem' messages) the semantics are not
      equivalent.  Translation of such messages may lead to the loss of
      information.  However, this issue may not be very severe because
      the error messages relate to packets that have been translated by
      NAT-PT rather than by arbitrary packets.  If the NAT-PT is




<span class="grey">Aoun &amp; Davies                Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


      functioning correctly, there is, for example, no reason why IPv6
      packets with unusual extension headers or options should be
      generated.

   Loss of information in any of these cases could be a constraint to
   certain applications.

   A related matter concerns the propagation of the Differentiated
   Services Code Point (DSCP).  NAT-PT and SIIT simply copy the DSCP
   field when translating packets.  Accordingly, the IPv4 and IPv6
   domains must have equivalent Per-Hop Behaviors for the same code
   point, or alternative means must be in place to translate the DSCP
   between domains.

<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>.  NAT-PT and Fragmentation</span>

   As mentioned in [<a href="./rfc3027" title="&quot;Protocol Complications with the IP Network Address Translator&quot;">RFC3027</a>], simple port translators are unable to
   translate packet fragments, other than the first, from a fragmented
   packet, because subsequent fragments do not contain the port number
   information.

   This means that, in general, fragmentation cannot be allowed for any
   traffic that traverses a NAPT-PT.  One attempted workaround requires
   the NAPT-PT to maintain state information derived from the first
   fragment until all fragments of the packet have transited the
   NAPT-PT.  This is not a complete solution because fragment
   misordering could lead to the first fragment appearing at the NAPT-PT
   after later fragments.  Consequently, the NAPT-PT would not have the
   information needed to translate the fragments received before the
   first.

   Although it would not be expected in normal operation, NAPT-PT needs
   to be proofed against receiving short first fragments that don't
   contain the transport port numbers.  Note that such packets are a
   problem for many forms of stateful packet inspection applied to IPv6
   packets.  The current specifications of IPv6 do not mandate (1) any
   minimum packet size beyond the need to carry the unfragmentable part
   (which doesn't include the transport port numbers) or (2) reassembly
   rules to minimize the effects of overlapping fragments.  Thus, IPv6
   is open to the sort of attacks described in [<a href="./rfc1858" title="&quot;Security Considerations for IP Fragment Filtering&quot;">RFC1858</a>] and [<a href="./rfc3128" title="&quot;Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)&quot;">RFC3128</a>].

   An additional concern arises when a fragmented IPv4 UDP packet, which
   does not have a transport-layer checksum, traverses any type of
   NAT-PT box.  As described in [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>], the NAT-PT has to reconstruct
   the whole packet so that it can calculate the checksum needed for the
   translated IPv6 packet.  This can result in a significant delay to
   the packet, especially if it has to be re-fragmented before
   transmission on the IPv6 side.



<span class="grey">Aoun &amp; Davies                Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


   If NAT-PT boxes reassembled all incoming fragmented packets (both
   from the IPv4 and IPv6 directions) in the same way they have to for
   unchecksummed IPv4 UDP packets, this would be a solution to the first
   problem.  The resource cost would be considerable apart from the
   potential delay problem if the outgoing packet has to be re-
   fragmented.  In any case, fragmentation would mean that the NAT-PT
   would consume extra memory and CPU resources, making the NAT-PT even
   less scalable (see <a href="#section-3.2">Section 3.2</a>).

   Packet reassembly in a NAT-PT box also opens up the possibility of
   various fragment-related security attacks.  Some of these are
   analogous to attacks identified for IPv4.  Of particular concern is a
   DoS attack based on sending large numbers of small fragments without
   a terminating last fragment, which would potentially overload the
   reconstruction buffers and consume large amounts of CPU resources.

<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>.  NAT-PT Interaction with SCTP and Multihoming</span>

   The Stream Control Transmission Protocol (SCTP) [<a href="./rfc2960" title="&quot;Stream Control Transmission Protocol&quot;">RFC2960</a>] is a
   transport protocol, which has been standardized since SIIT was
   specified.  SIIT does not explicitly cover the translation of SCTP,
   but SCTP uses transport port numbers in the same way that UDP and TCP
   do, so similar techniques can be used when translating SCTP packets.

   However, SCTP also supports multihoming.  During connection setup,
   SCTP control packets carry embedded addresses that would have to be
   translated.  This would also require that the types of the options
   fields in the SCTP control packets be changed with consequent changes
   to packet length; the transport checksum would also have to be
   recalculated.  The ramifications of multihoming as it might interact
   with NAT-PT have not been fully explored.  Because of the 'chunked'
   nature of data transfer, it does not appear that that state would
   have to be maintained to relate packets transmitted using the
   different IP addresses associated with the connection.

   Even if these technical issues can be overcome, using SCTP in a
   NAT-PT environment may effectively nullify the multihoming advantages
   of SCTP if all the connections run through the same NAT-PT.  The
   consequences of running a multihomed network with separate NAT-PT
   boxes associated with each of the 'homes' have not been fully
   explored, but one issue that will arise is described in <a href="#section-4.4">Section 4.4</a>.
   SCTP will need an associated "ALG" -- actually a Transport Layer
   Gateway -- to handle the packet payload modifications.  If it turns
   out that that state is required, the state would have to be
   distributed and synchronized across several NAT-PT boxes in a
   multihomed environment.





<span class="grey">Aoun &amp; Davies                Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


   SCTP running through NAT-PT in a multihomed environment is also
   incompatible with IPsec as described in <a href="#section-2.1">Section 2.1</a>.

<span class="h3"><a class="selflink" id="section-2.7" href="#section-2.7">2.7</a>.  NAT-PT as a Proxy Correspondent Node for MIPv6</span>

   As discussed in [<a href="#ref-NATPT-MOB" title="&quot;Considerations for Mobility Support in NAT-PT&quot;">NATPT-MOB</a>], it is not possible to propagate Mobile
   IPv6 (MIPv6) control messages into the IPv4 domain.  According to the
   IPv6 Node Requirements [<a href="./rfc4294" title="&quot;IPv6 Node Requirements&quot;">RFC4294</a>], IPv6 nodes should normally be
   prepared to support the route optimization mechanisms needed in a
   correspondent node.  If communications from an IPv6 mobile node are
   traversing a NAT-PT, the destination IPv4 node will certainly not be
   able to support the correspondent node features needed for route
   optimization.

   This can be resolved in two ways:

   o  The NAT-PT can discard messages and headers relating to changes of
      care-of addresses, including reverse routing checks.
      Communications with the mobile node will continue through the home
      agent without route optimization.  This is clearly sub-optimal,
      but communication should remain possible.

   o  Additional functionality could be implemented in the NAT-PT to
      allow it to function as a proxy correspondent node for all IPv4
      nodes for which it has bindings.  This scheme adds considerably to
      the complexity of NAT-PT.  Depending on the routability of the
      IPv6 PREFIX used for translated IPv4 addresses, it may also limit
      the extent of mobility of the mobile node: all communications to
      the IPv4 destination have to go through the same NAT-PT, even if
      the mobile node moves to a network that does not have direct IPv6
      connectivity with the NAT-PT.

   In both cases, the existing NAT-PT specification would need to be
   extended to deal with IPv6 mobile nodes, and neither is a fully
   satisfactory solution.

<span class="h3"><a class="selflink" id="section-2.8" href="#section-2.8">2.8</a>.  NAT-PT and Multicast</span>

   SIIT [<a href="./rfc2765" title="&quot;Stateless IP/ICMP Translation Algorithm (SIIT)&quot;">RFC2765</a>] cannot handle the translation of multicast packets and
   NAT-PT does not discuss a way to map multicast addresses between IPv4
   and IPv6.  Some separate work has been done to provide an alternative
   mechanism to handle multicast.  This work uses a separate gateway
   that understands some or all of the relevant multicast control and
   routing protocols in each domain.  It has not yet been carried
   through into standards.






<span class="grey">Aoun &amp; Davies                Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


   A basic mechanism, which involves only IGMP on the IPv4 side and MLD
   on the IPv6 side, is described in 'An IPv6-IPv4 Multicast Translator
   based on IGMP/MLD Proxying (mtp)' [<a href="#ref-MTP" title="&quot;An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)&quot;">MTP</a>].  A more comprehensive
   approach, which includes proxying of the multicast routing protocols,
   is described in 'An IPv4 - IPv6 multicast gateway' [<a href="#ref-MCASTGW" title="&quot;An IPv4 - IPv6 multicast gateway&quot;">MCASTGW</a>].  Both
   approaches have several of the issues described in this section,
   notably issues with embedded addresses.

   [<a id="ref-NATPT-SEC">NATPT-SEC</a>] identifies the possibility of a multiplicative reflection
   attack if the NAT-PT can be spoofed into creating a binding for a
   multicast address.  This attack would be very hard to mount because
   routers should not forward packets with multicast addresses in the
   source address field.  However, it highlights the possibility that a
   naively implemented DNS-ALG could create such bindings from spoofed
   DNS responses since [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>] does not mention the need for checks on
   the types of addresses in these responses.

   The issues for NAT-PT and multicast reflect the fact that NAT-PT is
   at best a partial solution.  Completing the translation solution to
   cater for multicast traffic is likely to carry a similar set of
   issues to the current unicast NAT-PT and may open up significant
   additional security risks.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Issues Exacerbated by the Use of DNS-ALG</span>

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Network Topology Constraints Implied by NAT-PT</span>

   Traffic flow initiators in a NAT-PT environment are dependent on the
   DNS-ALG in the NAT-PT to provide the mapped address needed to
   communicate with the flow destination on the other side of the
   NAT-PT.  Whether used for flows initiated in the IPv4 domain or the
   IPv6 domain, the NAT-PT has to be on the path taken by the DNS query
   sent by the flow initiator to the relevant DNS server; otherwise, the
   DNS query will not be modified and the response type will not be
   appropriate.

   The implication is that the NAT-PT box also has to be the default
   IPv6 router for the site so that the DNS-ALG is able to examine all
   DNS requests made over IPv6.  On sites with both IPv6 and dual-stack
   nodes, this will result in all traffic flowing through the NAT-PT
   with consequent scalability concerns.

   These constraints are described in more detail in [<a href="#ref-DNS-ALG-ISSUES" title="&quot;Issues with NAT-PT DNS ALG in RFC2766&quot;">DNS-ALG-ISSUES</a>].

   [<a id="ref-DNS-ALG-SOL">DNS-ALG-SOL</a>] proposes a solution for flows initiated from the IPv6
   domain, but it appears that this solution still has issues.





<span class="grey">Aoun &amp; Davies                Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


   For IPv6-only clients, the solution requires the use of a DNS server
   in the IPv4 domain, accessed via an IPv6 address which uses the
   NAT-PT PREFIX (see [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>]).  Queries to this server would
   necessarily pass through the NAT-PT.  Dual-stack hosts would use a
   separate DNS server accessed through a normal IPv6 address.  This
   removes the need for the NAT-PT box to be the default IPv6 gateway
   for the domain.

   The primary proposal suggests that the IPv6-only clients should use
   this DNS server for all queries.  This is expensive on NAT-PT
   resources because requests relating to hosts with native IPv6
   addresses would also use the NAT-PT DNS-ALG.

   The alternate suggestion to reduce this burden appears to be flawed:
   if IPv6-only clients are provided with a list of DNS servers
   including both the server accessed via NAT-PT and server(s) accessed
   natively via IPv6, the proposal suggests that the client could avoid
   using NAT-PT for hosts that have native IPv6 addresses.

   Unfortunately, for the alternate suggestion, there is no a priori way
   in which the initiator can decide which DNS server to use for a
   particular query.  In the event that the initiator makes the wrong
   choice, the DNS query will return an empty list rather than failing
   to respond.  With standard DNS logic, the initiator will not try
   alternative DNS servers because it has received a response.  This
   means that the solution would consist of always using DNS servers
   having the NAT-PT PREFIX.  This imposes the burden of always
   requiring the DNS RR (Resource Record) [<a href="./rfc1035" title="&quot;Domain names - implementation and specification&quot;">RFC1035</a>] translation.

   For flows initiated from the IPv4 network, the proposal recommends
   that the advertised DNS servers for the IPv6 network would have the
   IPv4 address of the NAT-PT.  Again there is no deterministic way to
   choose the correct DNS server for each query resulting in the same
   issues as were raised for flows initiated from the IPv6 domain.

   Although the engineering workaround, just described, provides a
   partial solution to the topology constraints issue, it mandates that
   DNS queries and responses should still go through a NAT-PT even if
   there would normally be no reason to do so.  This mandatory passage
   through the NAT-PT for all DNS requests will exacerbate the other
   DNS-related issues discussed in <a href="#section-3.4">Section 3.4</a> and <a href="#section-4.1">Section 4.1</a>.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Scalability and Single Point of Failure Concerns</span>

   As with traditional NAT, NAT-PT is a bottleneck in the network with
   significant scalability concerns.  Furthermore, the anchoring of
   flows to a particular NAT-PT makes the NAT-PT a potential single




<span class="grey">Aoun &amp; Davies                Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


   point of failure in the network.  The addition of the DNS-ALG in
   NAT-PT further increases the scalability concerns.

   Solutions to both problems have been envisaged using collections of
   cooperating NAT-PT boxes, but such solutions require coordination and
   state synchronization, which has not yet been standardized and again
   adds to the functional and operational complexity of NAT-PT.  One
   such solution is described in [<a href="#ref-MUL-NATPT" title="&quot;Scalable mNAT-PT Solution&quot;">MUL-NATPT</a>].

   As with traditional NAT, the concentration of flows through NAT-PT
   and the legitimate modification of packets in the NAT-PT make NAT-PTs
   enticing targets for security attacks.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Issues with Lack of Address Persistence</span>

   Using the DNS-ALG to create address bindings requires that the
   translated address returned by the DNS query is used for
   communications before the NAT-PT binding state is timed out (see
   <a href="#section-2.3">Section 2.3</a>).  Applications will not normally be aware of this
   constraint, which may be different from the existing lifetime of DNS
   query responses.  This could lead to "difficult to diagnose" problems
   with applications.

   Additionally, the DNS-ALG needs to determine the initial lifetime of
   bindings that it creates.  As noted in <a href="#section-2.3">Section 2.3</a>, this may need to
   be determined heuristically.  The DNS-ALG does not know which
   protocol the mapping is to be used for, and so needs another way to
   determine the initial lifetime.  This could be tied to the DNS
   response lifetime, but that might open up additional DoS attack
   possibilities if very long binding lifetimes are allowed.  Also, the
   lifetime should be adjusted once the NAT-PT determines which protocol
   is being used with the binding.

   As with traditional NATs (see <a href="./rfc3027#section-2.5">Section&nbsp;2.5 of [RFC3027]</a>), NAT-PT will
   most likely break applications that require address mapping to be
   retained across contiguous sessions.  These applications require the
   IPv4 to IPv6 address mapping to be retained between sessions so the
   same mapped address may be reused for subsequent session
   interactions.  NAT-PT cannot know this requirement and may reassign
   the previously used mapped address to different hosts between
   sessions.

   Trying to keep NAT-PT from discarding an address mapping would
   require either a NAT-PT extension protocol that would allow the
   application to request the NAT-PT device to retain the mappings, or
   an extended ALG (which has all the issues discussed in <a href="#section-2.1">Section 2.1</a>)
   that can interact with NAT-PT to keep the address mapping from being
   discarded after a session.



<span class="grey">Aoun &amp; Davies                Informational                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  DoS Attacks on Memory and Address/Port Pools</span>

   As discussed in <a href="#section-2.3">Section 2.3</a>, a NAT-PT may create dynamic NAT
   bindings, each of which consumes memory resources as well as an
   address (or port if NAPT-PT is used) from an address (or port) pool.
   A number of documents, including [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>] and [<a href="#ref-NATPT-SEC" title="&quot;NAT-PT Security Considerations&quot;">NATPT-SEC</a>] discuss
   the possible denial of service (DoS) attacks on basic NAT-PT and
   NAPT-PT that would result in a resource depletion associated with
   address and port pools.  NAT-PT does not specify any authentication
   mechanisms; thus, an attacker may be able to create spurious bindings
   by spoofing addresses in packets sent through NAT-PT.  The attack is
   more damaging if the attacker is able to spoof protocols with long
   binding timeouts (typically used for TCP).

   The use of the DNS-ALG in NAT-PT introduces another vulnerability
   that can result in resource depletion.  The attack identified in
   [<a href="#ref-DNS-ALG-ISSUES" title="&quot;Issues with NAT-PT DNS ALG in RFC2766&quot;">DNS-ALG-ISSUES</a>] exploits the use of DNS queries traversing NAT-PT to
   create dynamic bindings.  Every time a DNS query is sent through the
   NAT-PT, the NAT-PT may create a new basic NAT-PT or NAPT-PT binding
   without any end-host authentication or authorization mechanisms.
   This behavior could lead to a serious DoS attack on both memory and
   address or port pools.  Address spoofing is not required for this
   attack to be successful.

   [<a id="ref-DNS-ALG-SOL">DNS-ALG-SOL</a>] proposes to mitigate the DoS attack by using Access
   Control Lists (ACLs) and static binds, which increases the
   operational cost and may not always be practical.

   The ideal mitigation solution would be to disallow dynamically
   created binds until authentication and authorization of the end-host
   needing the protocol translation has been carried out.  This would
   require that the proper security infrastructure be in place to
   support the authentication and authorization, which increases the
   network operational complexity.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Issues Directly Related to Use of DNS-ALG</span>

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Address Selection Issues when Communicating with Dual-Stack End-</span>
<span class="h3">      Hosts</span>

   [<a id="ref-DNS-ALG-ISSUES">DNS-ALG-ISSUES</a>] discusses NAT-PT DNS-ALG issues with regard to
   address selection.  As specified in [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>], the DNS-ALG returns
   AAAA Resource Records (RRs) from two possible sources, to the IPv6
   host that has made an AAAA DNS query.

   If the query relates to a dual-stack host, the query will return both
   the native IPv6 address(es) and the translated IPv4 address(es) in
   AAAA RRs.  Without additional information, the IPv6 host address



<span class="grey">Aoun &amp; Davies                Informational                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


   selection may pick a translated IPv4 address instead of selecting the
   more appropriate native IPv6 address.  Under some circumstances, the
   address selection algorithms [<a href="./rfc3484" title="&quot;Default Address Selection for Internet Protocol version 6 (IPv6)&quot;">RFC3484</a>] will always prefer the
   translated address over the native IPv6 address; this is obviously
   undesirable.

   [<a id="ref-DNS-ALG-SOL">DNS-ALG-SOL</a>] proposes a solution that involves modification to the
   NAT-PT specification intended to return only the most appropriate
   address(es) to an IPv6 capable host as described below:

   o  When a DNS AAAA query traverses the NAT-PT DNS-ALG, the NAT-PT
      will forward the query to the DNS server in the IPv4 domain
      unchanged, but using IPv4 transport.  The following two results
      can occur:

      *  If the authoritative DNS server has one or more AAAA records,
         it returns them.  The DNS-ALG then forwards this response to
         the IPv6 host and does not send an A query as the standard
         NAT-PT would do.

      *  Otherwise, if the DNS server does not understand the AAAA query
         or has no AAAA entry for the host, it will return an error.
         The NAT-PT DNS-ALG will intercept the error or empty return and
         send an A query for the same host.  If this query returns an
         IPv4 address, the ALG creates a binding and synthesizes a
         corresponding AAAA record, which it sends back to the IPv6
         host.

   o  The NAT-PT thus forwards the result of the first successful DNS
      response back to the end-host or an error if neither succeeds.
      Consequently, only AAAA RRs from one source will be provided
      instead of two as specified in [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>], and it will contain the
      most appropriate address for a dual-stack or IPv6-only querier.

   There is, however, still an issue with the proposed solution:

   o  The DNS client may timeout the query if it doesn't receive a
      response in time.  This is more likely than for queries not
      passing through a DNS ALG because the NAT-PT may have to make two
      separate, sequential queries of which the client is not aware.  It
      may be possible to reduce the response time by sending the two
      queries in parallel and ignoring the result of the A query if the
      AAAA returns one or more addresses.  However, it is still
      necessary to delay after receiving the first response to determine
      if a second is coming, which may still trigger the DNS client
      timeout.





<span class="grey">Aoun &amp; Davies                Informational                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


   Unfortunately, the two queries cannot be combined in a single DNS
   request (all known DNS servers only process a single DNS query per
   request message because of difficulties expressing authoritativeness
   for arbitrary combinations of requests).

   An alternative solution would be to allow the IPv6 host to use the
   NAT-PT PREFIX [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>] within its address selection policies and to
   assign it a low selection priority.  This solution requires an
   automatic configuration of the NAT-PT PREFIX as well as its
   integration within the address selection policies.  The simplest way
   to integrate this automatic configuration would be through a
   configuration file download (in case the host or Dynamic Host
   Configuration Protocol for IPv6 (DHCPv6) server did not support
   vendor options and to avoid a standardization effort on the NAT-PT
   PREFIX option).  This solution does not require any modification to
   the NAT-PT specification.

   Neither of these solutions resolves a second issue related to address
   selection that is identified in [<a href="#ref-DNS-ALG-ISSUES" title="&quot;Issues with NAT-PT DNS ALG in RFC2766&quot;">DNS-ALG-ISSUES</a>].  Applications have
   no way of knowing that the IPv6 address returned from the DNS-ALG is
   not a 'real' IPv6 address, but a translated IPv4 address.  The
   application may therefore, be led to believe that it has end-to-end
   IPv6 connectivity with the destination.  As a result, the application
   may use IPv6-specific options that are not supported by NAT-PT.  This
   issue is closely related to the issue described in <a href="#section-4.2">Section 4.2</a> and
   the discussion in <a href="#section-5">Section 5</a>.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Non-Global Validity of Translated RR Records</span>

   Some applications propagate information records retrieved from DNS to
   other applications.  The published semantics of DNS imply that the
   results will be consistent to any user for the duration of the
   attached lifetime.  RR records translated by NAT-PT violate these
   semantics because the retrieved addresses are only usable for
   communications through the translating NAT-PT.

   Applications that pass on retrieved DNS records to other applications
   will generally assume that they can rely on the passed on addresses
   to be usable by the receiving application.  This may not be the case
   if the receiving application is on another node, especially if it is
   not in the domain served by the NAT-PT that generated the
   translation.









<span class="grey">Aoun &amp; Davies                Informational                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Inappropriate Translation of Responses to A Queries</span>

   Some applications running on dual-stack nodes may wish to query the
   IPv4 address of a destination.  If the resulting A query passes
   through the NAT-PT DNS-ALG, the DNS-ALG will translate the response
   inappropriately into a AAAA record using a translated address.  This
   happens because the DNS-ALG specified in [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>] operates
   statelessly and hence has no memory of the IPv6 query that induced
   the A request on the IPv4 side.  The default action is to translate
   the response.

   The specification of NAT-PT could be modified to maintain a minimal
   state about queries passed through the DNS-ALG, and hence to respond
   correctly to A queries as well as AAAA queries.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  DNS-ALG and Multi-Addressed Nodes</span>

   Many IPv6 nodes, especially in multihomed situations but also in
   single homed deployments, can expect to have multiple global
   addresses.  The same may be true for multihomed IPv4 nodes.
   Responses to DNS queries for these nodes will normally contain all
   these addresses.  Since the DNS-ALG in the NAT-PT has no knowledge
   which of the addresses can or will be used by the application issuing
   the query, it is obliged to translate all of them.

   This could be a significant drain on resources in both basic NAT-PT
   and NAPT-PT, as bindings will have to be created for each address.

   When using SCTP in a multihomed network, the problem is exacerbated
   if multiple NAT-PTs translate multiple addresses.  Also, it is not
   clear that SCTP will actually look up all the destination IP
   addresses via DNS, so that bindings may not be in place when packets
   arrive.

<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>.  Limitations on Deployment of DNS Security Capabilities</span>

   Secure DNS (DNSSEC) [<a href="./rfc4033" title="&quot;DNS Security Introduction and Requirements&quot;">RFC4033</a>] uses public key cryptographic signing
   to authenticate DNS responses.  The DNS-ALG modifies DNS query
   responses traversing the NAT-PT in both directions, which would
   invalidate the signatures as (partially) described in <a href="./rfc2766#section-7.5">Section&nbsp;7.5 of
   [RFC2766]</a>.

   Workarounds have been proposed, such as making the DNS-ALG behave
   like a secure DNS server.  This would need to be done separately for
   both the IPv6 and IPv4 domains.  This is operationally very complex
   and there is a risk that the server could be mistaken for a
   conventional DNS server.  The NAT-PT specification would have to be
   altered to implement any such workaround.



<span class="grey">Aoun &amp; Davies                Informational                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


   Hence, DNSSEC is not deployable in domains that use NAT-PT as
   currently specified.  Widespread deployment of NAT-PT would become a
   serious obstacle to the large scale deployment of DNSSEC.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Impact on IPv6 Application Development</span>

   One of the major design goals for IPv6 is to restore the end-to-end
   transparency of the Internet.  Therefore, because IPv6 may be
   expected to remove the need for NATs and similar impediments to
   transparency, developers creating applications to work with IPv6 may
   be tempted to assume that the complex expedients that might have been
   needed to make the application work in a 'NATted' IPv4 environment
   are not required.

   Consequently, some classes of applications (e.g., peer-to-peer) that
   would need special measures to manage NAT traversal, including
   special encapsulations, attention to binding lifetime, and provision
   of keepalives, may build in assumptions on whether IPv6 is being used
   or not.  Developers would also like to exploit additional
   capabilities of IPv6 not available in IPv4.

   NAT-PT as specified in [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>] is intended to work autonomously and
   be transparent to applications.  Therefore, there is no way for
   application developers to discover that a path contains a NAT-PT.

   If NAT-PT is deployed, applications that have assumed a NAT-free IPv6
   environment may break when the traffic passes through a NAT-PT.  This
   is bad enough, but requiring developers to include special
   capabilities to work around what is supposed to be a temporary
   transition 'aid' is even worse.  Finally, deployment of NAT-PT is
   likely to inhibit the development and use of additional IPv6
   capabilities enabled by the flexible extension header system in IPv6
   packets.

   Some of these deleterious effects could possibly be alleviated if
   applications could discover the presence of NAT-PT boxes on paths in
   use, allowing the applications to take steps to workaround the
   problems.  However, requiring applications to incorporate extra code
   to workaround problems with a transition aid still seems to be a very
   bad idea: the behavior of the application in native IPv6 and NAT-PT
   environments would be likely to be significantly different.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Security Considerations</span>

   This document summarizes security issues related to the NAT-PT
   [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>] specification.  Security issues are discussed in various
   sections:




<span class="grey">Aoun &amp; Davies                Informational                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


   o  <a href="#section-2.1">Section 2.1</a> discusses how IPsec AH (transport and tunnel mode) and
      IPsec ESP transport mode are broken by NAT-PT (when IPsec UDP
      encapsulation is not used [<a href="./rfc3498" title="&quot;Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures&quot;">RFC3498</a>]) and authentication and
      encryption are generally incompatible with NAT-PT.

   o  <a href="#section-2.5">Section 2.5</a> discusses possible fragmentation related security
      attacks on NAT-PT.

   o  <a href="#section-2.8">Section 2.8</a> discusses security issues related to multicast
      addresses and NAT-PT.

   o  <a href="#section-3.3">Section 3.3</a> highlights that NAT-PT is an enticing nexus for
      security attacks.

   o  <a href="#section-3.4">Section 3.4</a> discusses possible NAT-PT DoS attacks on both memory
      and address/port pools.

   o  <a href="#section-4.5">Section 4.5</a> discusses why NAT-PT is incompatible with DNSSEC
      [<a href="./rfc4033" title="&quot;DNS Security Introduction and Requirements&quot;">RFC4033</a>] and how deployment of NAT-PT may inhibit deployment of
      DNSSEC.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Conclusion</span>

   This document has discussed a number of significant issues with
   NAT-PT as defined in [<a href="./rfc2766" title="&quot;Network Address Translation - Protocol Translation (NAT-PT)&quot;">RFC2766</a>].  From a deployment perspective, 3GPP
   networks are currently the only 'standardised' scenario where NAT-PT
   is envisaged as a potential mechanism to allow communication between
   an IPv6-only host and an IPv4-only host as discussed in the 3GPP IPv6
   transition analysis [<a href="./rfc4215" title="&quot;Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks&quot;">RFC4215</a>].  But <a href="./rfc4215">RFC 4215</a> recommends that the
   generic form of NAT-PT should not be used and that modified forms
   should only be used under strict conditions.  Moreover, it documents
   a number of caveats and security issues specific to 3GPP.  In
   addition, NAT-PT has seen some limited usage for other purposes.

   Although some of the issues identified with NAT-PT appear to have
   solutions, many of the solutions proposed require significant
   alterations to the existing specification and would likely increase
   operational complexity.  Even if these solutions were applied, we
   have shown that NAT-PT still has significant, irresolvable issues and
   appears to have limited applicability.  The potential constraints on
   the development of IPv6 applications described in <a href="#section-5">Section 5</a> are
   particularly undesirable.  It appears that alternatives to NAT-PT
   exist to cover the circumstances where NAT-PT has been suggested as a
   solution, such as the use of application proxies in 3GPP scenarios
   [<a href="./rfc4215" title="&quot;Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks&quot;">RFC4215</a>]

   However, it is clear that in some circumstances an IPv6-IPv4 protocol
   translation solution may be a useful transitional solution,



<span class="grey">Aoun &amp; Davies                Informational                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


   particularly in more constrained situations where the translator is
   not required to deal with traffic for a wide variety of protocols
   that are not determined in advance.  Therefore, it is possible that a
   more limited form of NAT-PT could be defined for use in specific
   situations.

   Accordingly, we recommend that:

   o  the IETF no longer suggest its usage as a general IPv4-IPv6
      transition mechanism in the Internet, and

   o  <a href="./rfc2766">RFC 2766</a> is moved to Historic status to limit the possibility of
      it being deployed inappropriately.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Acknowledgments</span>

   This work builds on a large body of existing work examining the
   issues and applicability of NAT-PT: the work of the authors of the
   documents referred to in <a href="#section-1">Section 1</a> has been extremely useful in
   creating this document.  Particular thanks are due to Pekka Savola
   for rapid and thorough review of the document.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  References</span>

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  Normative References</span>

   [<a id="ref-RFC2765">RFC2765</a>]         Nordmark, E., "Stateless IP/ICMP Translation
                     Algorithm (SIIT)", <a href="./rfc2765">RFC 2765</a>, February 2000.

   [<a id="ref-RFC2766">RFC2766</a>]         Tsirtsis, G. and P. Srisuresh, "Network Address
                     Translation - Protocol Translation (NAT-PT)",
                     <a href="./rfc2766">RFC 2766</a>, February 2000.

   [<a id="ref-RFC2663">RFC2663</a>]         Srisuresh, P. and M. Holdrege, "IP Network Address
                     Translator (NAT) Terminology and Considerations",
                     <a href="./rfc2663">RFC 2663</a>, August 1999.

   [<a id="ref-RFC3027">RFC3027</a>]         Holdrege, M. and P. Srisuresh, "Protocol
                     Complications with the IP Network Address
                     Translator", <a href="./rfc3027">RFC 3027</a>, January 2001.

   [<a id="ref-RFC3314">RFC3314</a>]         Wasserman, M., "Recommendations for IPv6 in Third
                     Generation Partnership Project (3GPP) Standards",
                     <a href="./rfc3314">RFC 3314</a>, September 2002.

   [<a id="ref-RFC3484">RFC3484</a>]         Draves, R., "Default Address Selection for Internet
                     Protocol version 6 (IPv6)", <a href="./rfc3484">RFC 3484</a>,
                     February 2003.



<span class="grey">Aoun &amp; Davies                Informational                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


   [<a id="ref-RFC1035">RFC1035</a>]         Mockapetris, P., "Domain names - implementation and
                     specification", STD 13, <a href="./rfc1035">RFC 1035</a>, November 1987.

   [<a id="ref-RFC4294">RFC4294</a>]         Loughney, J., "IPv6 Node Requirements", <a href="./rfc4294">RFC 4294</a>,
                     April 2006.

   [<a id="ref-RFC4215">RFC4215</a>]         Wiljakka, J., "Analysis on IPv6 Transition in Third
                     Generation Partnership Project (3GPP) Networks",
                     <a href="./rfc4215">RFC 4215</a>, October 2005.

   [<a id="ref-RFC4033">RFC4033</a>]         Arends, R., Austein, R., Larson, M., Massey, D.,
                     and S. Rose, "DNS Security Introduction and
                     Requirements", <a href="./rfc4033">RFC 4033</a>, March 2005.

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Informative References</span>

   [<a id="ref-RFC1858">RFC1858</a>]         Ziemba, G., Reed, D., and P. Traina, "Security
                     Considerations for IP Fragment Filtering",
                     <a href="./rfc1858">RFC 1858</a>, October 1995.

   [<a id="ref-RFC3128">RFC3128</a>]         Miller, I., "Protection Against a Variant of the
                     Tiny Fragment Attack (<a href="./rfc1858">RFC 1858</a>)", <a href="./rfc3128">RFC 3128</a>,
                     June 2001.

   [<a id="ref-RFC2960">RFC2960</a>]         Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
                     Schwarzbauer, H., Taylor, T., Rytina, I., Kalla,
                     M., Zhang, L., and V. Paxson, "Stream Control
                     Transmission Protocol", <a href="./rfc2960">RFC 2960</a>, October 2000.

   [<a id="ref-RFC3498">RFC3498</a>]         Kuhfeld, J., Johnson, J., and M. Thatcher,
                     "Definitions of Managed Objects for Synchronous
                     Optical Network (SONET) Linear Automatic Protection
                     Switching (APS) Architectures", <a href="./rfc3498">RFC 3498</a>,
                     March 2003.

   [<a id="ref-NATP-APP">NATP-APP</a>]        Satapati, S., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22NAT-PT+Applicability%22'>"NAT-PT Applicability"</a>, Work
                     in Progress, October 2003.

   [<a id="ref-DNS-ALG-ISSUES">DNS-ALG-ISSUES</a>]  Durand, A., "Issues with NAT-PT DNS ALG in
                     <a href="./rfc2766">RFC2766</a>", Work in Progress, February 2002.

   [<a id="ref-DNS-ALG-SOL">DNS-ALG-SOL</a>]     Hallingby, P. and S. Satapati, "NAT-PT DNS ALG
                     solutions", Work in Progress, July 2002.

   [<a id="ref-NATPT-MOB">NATPT-MOB</a>]       Shin, M. and J. Lee, "Considerations for Mobility
                     Support in NAT-PT", Work in Progress, July 2005.





<span class="grey">Aoun &amp; Davies                Informational                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


   [<a id="ref-NATPT-SEC">NATPT-SEC</a>]       Okazaki, S. and A. Desai, "NAT-PT Security
                     Considerations", Work in Progress, June 2003.

   [<a id="ref-TRANS-ISSUES">TRANS-ISSUES</a>]    Pol, R., Satapati, S., and S. Sivakumar, "Issues
                     when translating between IPv4 and IPv6", Work
                     in Progress, January 2003.

   [<a id="ref-3GPP-TRANS">3GPP-TRANS</a>]      Malki, K., "IPv6-IPv4 Translation mechanism for
                     SIP-based services in Third Generation Partnership
                     Project (3GPP) Networks", Work in Progress,
                     December 2003.

   [<a id="ref-MTP">MTP</a>]             Tsuchiya, K., Higuchi, H., Sawada, S., and S.
                     Nozaki, "An IPv6/IPv4 Multicast Translator based on
                     IGMP/MLD Proxying (mtp)", Work in Progress,
                     February 2003.

   [<a id="ref-MCASTGW">MCASTGW</a>]         Venaas, S., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22An+IPv4+-+IPv6+multicast+gateway%22'>"An IPv4 - IPv6 multicast gateway"</a>,
                     Work in Progress, February 2003.

   [<a id="ref-MUL-NATPT">MUL-NATPT</a>]       Park, S., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22Scalable+mNAT-PT+Solution%22'>"Scalable mNAT-PT Solution"</a>, Work
                     in Progress, May 2003.

Authors' Addresses

   Cedric Aoun
   Energize Urnet
   Paris
   France

   EMail: ietf@energizeurnet.com


   Elwyn B. Davies
   Folly Consulting
   Soham, Cambs
   UK

   Phone: +44 7889 488 335
   EMail: elwynd@dial.pipex.com











<span class="grey">Aoun &amp; Davies                Informational                     [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc4966">RFC 4966</a>                 NAT-PT Issues Analysis                July 2007</span>


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

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







Aoun &amp; Davies                Informational                     [Page 25]
</pre>