[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Behave and Softwires WGs                                         D. Wing
Internet-Draft                                                   D. Ward
Intended status:  Informational                                    Cisco
Expires:  April 2, 2009                                        A. Durand
                                                                 Comcast
                                                      September 29, 2008


              A Comparison of Proposals to Replace NAT-PT
              draft-wing-nat-pt-replacement-comparison-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 2, 2009.

Abstract

   As we approach IPv4 address depletion, the IETF must provide for IPv4
   and IPv6 coexistence:  a way for ISPs and enterprises to reduce
   public IPv4 address consumption and a way for hosts to migrate to
   IPv6 connectivity -- while providing reasonable access for those IPv6
   hosts to access the IPv4 Internet.

   This draft compares eight proposals for IPv6 and IPv4 coexistence.






Wing, et al.              Expires April 2, 2009                 [Page 1]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview of Proposals  . . . . . . . . . . . . . . . . . . . .  5
     3.1.  IPv4 hosts in Customer Premise . . . . . . . . . . . . . .  6
       3.1.1.  Address Plus Port (A+P)  . . . . . . . . . . . . . . .  6
       3.1.2.  Stateless Address Mapping (SAM) (previously
               APB-Revised) . . . . . . . . . . . . . . . . . . . . .  7
       3.1.3.  Dual-Stack Lite (DS-Lite)  . . . . . . . . . . . . . .  9
       3.1.4.  NAT444 . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.2.  IPv6 hosts in Customer Premise . . . . . . . . . . . . . . 11
       3.2.1.  IVI  . . . . . . . . . . . . . . . . . . . . . . . . . 11
       3.2.2.  NAT6 . . . . . . . . . . . . . . . . . . . . . . . . . 12
       3.2.3.  NAT64  . . . . . . . . . . . . . . . . . . . . . . . . 13
       3.2.4.  NAT-PT . . . . . . . . . . . . . . . . . . . . . . . . 13
       3.2.5.  sNAT-PT  . . . . . . . . . . . . . . . . . . . . . . . 14
   4.  Changes Required in Network Elements . . . . . . . . . . . . . 15
     4.1.  IPv4 and IPv6 Hosts Accessing the IPv4 Internet  . . . . . 15
     4.2.  IPv4 Hosts Accessing the IPv4 Internet . . . . . . . . . . 18
     4.3.  IPv4 Internet Accessing IPv6 hosts . . . . . . . . . . . . 19
   5.  Port Forwarding  . . . . . . . . . . . . . . . . . . . . . . . 19
     5.1.  Static Incoming Ports  . . . . . . . . . . . . . . . . . . 20
     5.2.  Dynamic Incoming Ports . . . . . . . . . . . . . . . . . . 21
   6.  Transport Protocol Support . . . . . . . . . . . . . . . . . . 21
   7.  Analysis with V6OPS's NAT64 Problem Statement  . . . . . . . . 22
   8.  Comparison of Proposals with NAT-PT Problems . . . . . . . . . 22
     8.1.  Issues Unrelated to an DNS-ALG . . . . . . . . . . . . . . 22
       8.1.1.  Issues with Protocols Embedding IP Addresses . . . . . 22
       8.1.2.  NAPT-PT Redirection Issues . . . . . . . . . . . . . . 22
       8.1.3.  NAT-PT Binding State Decay . . . . . . . . . . . . . . 22
       8.1.4.  Loss of Information through Incompatible Semantics . . 22
       8.1.5.  NAT-PT and Fragmentation . . . . . . . . . . . . . . . 22
       8.1.6.  NAT-PT Interaction with SCTP and Multihoming . . . . . 22
       8.1.7.  NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . 23
       8.1.8.  NAT-PT and Multicast . . . . . . . . . . . . . . . . . 23
     8.2.  Issues Exacerbated by the Use of DNS-ALG . . . . . . . . . 23
       8.2.1.  Network Topology Constraints Implied by NAT-PT . . . . 23
       8.2.2.  Scalability and Single Point of Failure Concerns . . . 23
       8.2.3.  Issues with Lack of Address Persistence  . . . . . . . 23
       8.2.4.  DoS Attacks on Memory and Address/Port Pool  . . . . . 24
     8.3.  Issues Directly Related to Use of DNS-ALG  . . . . . . . . 24
       8.3.1.  Address Selection Issues when Communicating with
               Dual-Stack End-Hosts . . . . . . . . . . . . . . . . . 24
       8.3.2.  Non-Global Validity of Translated RR Records . . . . . 24
       8.3.3.  Inappropriate Translation of Responses to A Queries  . 24
       8.3.4.  DNS-ALG and Multi-Addressed Nodes  . . . . . . . . . . 24
       8.3.5.  Limitations on Deployment of DNS Security



Wing, et al.              Expires April 2, 2009                 [Page 2]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


               Capabilities . . . . . . . . . . . . . . . . . . . . . 24
     8.4.  Impact on IPv6 Application Development . . . . . . . . . . 25
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
     9.1.  Address Sharing  . . . . . . . . . . . . . . . . . . . . . 25
     9.2.  IPsec Compatibility  . . . . . . . . . . . . . . . . . . . 26
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
     12.2. Informative References . . . . . . . . . . . . . . . . . . 28
   Appendix A.  Changes . . . . . . . . . . . . . . . . . . . . . . . 30
     A.1.  Changes from 01 to 02  . . . . . . . . . . . . . . . . . . 30
     A.2.  Changes from 00 to 01  . . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
   Intellectual Property and Copyright Statements . . . . . . . . . . 32




































Wing, et al.              Expires April 2, 2009                 [Page 3]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


1.  Terminology

   The following terms are used throughout this document.

   Address Family Translation (AFT):  The function of translating from
        one IP address family (IPv4 or IPv6) to another (IPv6 or IPv4).

   Carrier Grade NAT (CGN):  A NAT device used by many subscribers
        (homes or end sites), where 'many' would be on the order of
        dozens to hundreds of thousands of subscribers.  This might NAT
        between any combination of IPv4 and IPv6.  Typically, the end
        user does not have the ability to adjust the behavior of the CGN
        (i.e., no ability to create static port mapping).

   CPE router:  Customer Premise Equipment router.  A device that
        performs routing functions, located at the customer's premise.
        This device does not perform NAT functions.  (Some referenced
        specifications use the term 'Home GateWay' (HGW) to mean the
        same thing.  We use CPE router because the subscriber might not
        be a business and not a 'home'.)

   DNS rewriting:  The generalized function of synthesizing a DNS AAAA
        response from a DNS A response.  The term "DNS rewriting"
        instead of "DNS-ALG" because in NAT-PT [RFC2766] DNS-ALG meant a
        DNS rewriting function with an interface to the NAT function.

   NAT: Network Address Translation.  This translates IP addresses, one-
        for-one, between two networks, without changing transport
        protocol ports.  The two networks might be IPv4 (NAT44), IPv6
        and IPv4 (NAT64), or IPv4 and IPv6 (NAT46).  This document
        follows (the unfortunate) common usage that "NAT" can also mean
        "NAPT" (Network Address and Port Translator).

   Softwire  A tunnel for carrying IPv4 and IPv6 traffic over IPv6 and
        IPv4 networks [RFC4925].


2.  Introduction

   As the Internet approaches IPv4 address depletion, it will be
   necessary for Internet Service Providers to continue to
   simultaneously provide their users with access to the IPv4 Internet,
   reduce the number of IPv4 public addresses consumed by each
   subscriber, and provide a way for subscribers to migrate to IPv6.

   The proposals have several high-level attributes in common:





Wing, et al.              Expires April 2, 2009                 [Page 4]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


      Provide access to the IPv4 Internet:  There are two approaches to
      provide access to the v4 Internet.  One approach is to have a
      dual-stack host with some modifications from the classic design
      [RFC4213].  The other approach is to have an IPv6-only host and
      operate an address family translation (AFT) device between the
      IPv6-only host and the IPv4 Internet.

      Reduce consumption of global IPv4 addresses:  Network address and
      port translator (NAPT) technology, and NAPT itself, allows more
      than one host to simultaneously use a single IPv4 address.  NAPT
      technology is used in all proposals to conserve IPv4 public
      address space.

      IPv6 migration:  it is important that a migration path for users
      and content providers to move to IPv6 is enabled and encouraged.
      This is necessary because operating a NAT device in order to
      reduce per-subscriber IPv4 address consumption is not a viable
      long-term solution:  we will still exhaust the IPv4 public address
      space, and operating NATs is expensive and reduces the reliability
      of the Internet.

      Port limitations:  All proposals use a NAPT to provide access to
      the IPv4 Internet, which reduces the number of ports each
      subscriber can use.  This has negative impacts on some
      applications (e.g., Apple iTunes, Google Maps).  This problem is
      resolved by the content provider and the subscriber both using
      IPv6.

   This draft is discussed on the [v4v6interm-interest] mailing list.
   Individual proposals are discussed on the mailing list indicated in
   this document.


3.  Overview of Proposals

   This document classifies the proposals into two categories.  The
   first category provides IPv4 and IPv6 access to the subscriber, and
   the second category provides only IPv6 access to the subscriber.  In
   both categories, IPv4 addresses are conserved by using a NAT device.
   This NAT device is placed in the carrier's network ("Carrier Grade
   NAT") or (in the case of A+P and SAM) in the CPE router.  In all
   proposals (except NAT444) a host can obtain native IPv6 connectivity
   with native IPv6 hosts without regard to the co-existence proposal.

   The descriptions below provide a very brief overview of each
   proposal, in alphabetical order.





Wing, et al.              Expires April 2, 2009                 [Page 5]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


3.1.  IPv4 hosts in Customer Premise

   For Internet access, the following proposals allow for IPv4 hosts in
   the customer premise.

3.1.1.  Address Plus Port (A+P)

   Address Plus Port [A+P] uses a NAT in (or close to) the customer
   premise for access to the IPv4 Internet.  The Service Provider
   conveys both an IPv4 address (as done today) and a range of TCP/UDP
   ports to the NAT.  Outgoing IPv4 traffic is NATted to that range of
   TCP/UDP ports, and the Service Provider routes packets to the
   appropriate customer using both the destination IPv4 address (as done
   today) and destination TCP/UDP port.

   One of A+P's architectures is depicted in Figure 1, where the ISP's
   network supports both IPv4 and IPv6.  In this architecture, the NAT's
   job is straight forward:  it NATs to a limited port range and sends
   the packet upstream to the ISP.  Because multiple customers share a
   single IPv4 address, the aggregation router needs to route return
   packets to the appropriate customer's NAT using destination IPv4 and
   destination port.  This architecture is denoted as "A+P-v4".

                      +---+                             +-------------+
        IPv6 host-----+   |            +----------------+IPv6 Internet|
                      |   +--IPv6------+                +-------------+
     Dual-stack host--+   |
                      |NAT|        +------+             +-------------+
         IPv4 host----+   +--------+router+-------------+IPv4 Internet|
                      +---+        +------+             +-------------+

        |<private IPv4>NAT<-----------------------------public v4----->

           Figure 1: Address Plus Port, v4-capable ISP (A+P-v4)

   Another of A+P's architectures is depicted in Figure 2, where the
   ISP's network runs only IPv6.  In this architecture, the NAT
   encapsulates the IPv4 packet into an IPv6 packet, where the IPv6
   packet has a source address that corresponds to that NAT, and a
   destination address that corresponds to a well-known prefix which
   routes to a IPv6 tunnel concentrator.  When the packet arrives at the
   IPv6 tunnel concentrator the IPv6 source address is used to construct
   the IPv4 source address and TCP/UDP port, and the IPv6 destination
   address is used to construct the IPv4 destination address; the IPv6
   destination TCP/UDP port is taken from the IPv6 packet's destination
   TCP/UDP header.  This architecture is denoted as "A+P-v6".





Wing, et al.              Expires April 2, 2009                 [Page 6]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


                      +---+                             +-------------+
        IPv6 host-----+   |            +----------------+IPv6 Internet|
                      |   +--IPv6------+                +-------------+
     Dual-stack host--+   |
                      |NAT|                 +--------+  +-------------+
         IPv4 host----+   +===IPv6 tunnel===+ tunnel +--+IPv4 Internet|
                      +---+                 |concent.|  +-------------+
                                            +--------+

        |<private IPv4>NAT<----------------------------public v4----->

             Figure 2: Address Plus Port, v6-only ISP (A+P-v6)

3.1.2.  Stateless Address Mapping (SAM) (previously APB-Revised)

   Stateless Address Mapping (SAM) [I-D.despres-sam] shares each IPv4
   address amongst several subscribers through a tunnel aggregation
   device.  The static mapping avoids the need for the service provider
   equipment to NAT.

   SAM can be implemented with subscriber site tunnel endpoints either
   in a router (CPE router or other router) or in a SAM host.  In both
   implementations, each subscriber site is assigned a shared IPv4
   address (shared with other subscribers) and a port range.  Figure 3
   shows the SAM architecture in the case where the tunnel is
   established between the CPE router (upgraded to support SAM) and the
   SAM-capable tunnel concentrator.  Any IPv4 traffic from hosts behind
   the CPE router is NAT'd (using classic NAT44) and forwarded through
   the tunnel to the SAM tunnel concentrator.  The customer premise NATs
   using the external port range it is 'borrowing' from the SAM
   concentrator.  This is abbreviated SAM-CPE in this document.

   This proposal is discussed in [Softwires].

                      +---+                             +-------------+
        IPv6 host-----+   |            +----------------+IPv6 Internet|
                      |   +--IPv6------+                +-------------+
     Dual-stack host--+   |                 +--------+
                      |NAT|                 |  SAM   |  +-------------+
         IPv4 host----+   +===IPv6 tunnel===+ tunnel +--+IPv4 Internet|
                      +---+                 |concent.|  +-------------+
                                            +--------+

        |<private IPv4>NAT<----------------------------public v4------>

       Figure 3: SAM-CPE, tunnel between CPE and tunnel concentrator

   In the figure above, the IPv6 tunnel is an IPv4-over-IPv6 tunnel.



Wing, et al.              Expires April 2, 2009                 [Page 7]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


   Figure 4 shows another SAM architecture where the tunnel is
   established directly between the host (upgraded to support SAM) and
   the SAM tunnel endpoint.  Any IPv4 traffic from the SAM host is
   routed through the tunnel to the SAM-capable tunnel concentrator.
   Tunnelling is sufficient; no NAT device is needed between the host
   and the public IPv4 network.  This is abbreviated SAM-host in this
   document.  In Figure 4, the customer premise NAT does not NAT traffic
   to/from the SAM host; however, it does NAT traffic to/from the IPv4-
   only host to support a non-SAM-capable IPv4 host.

                    +---+                             +-------------+
      IPv6 host-----+   |            +----------------+IPv6 Internet|
                    |   +--IPv6------+                +-------------+
          SAM host--+   |                 +--------+
                    |CPE|                 |  SAM   |  +-------------+
       IPv4 host----+   +===IPv6 tunnel===+ tunnel +--+IPv4 Internet|
                    +---+                 |concent.|  +-------------+
                                          +--------+

      |<private IPv4>NAT<----------------------------public v4------>

     Figure 4: SAM-host - tunnel between host and tunnel concentrator

   Figure 5 shows the SAM architecture with two tunnels.  One tunnel is
   established between the CPE router and the SAM endpoint, and a second
   tunnel between the subscriber host and the CPE router.  In this
   architecture, the CPE router is upgraded to establish a tunnel to the
   SAM-capable tunnel concentrator (external side) and to accept a
   tunnel from the host (internal side); the SAM-capable host IP stack
   is upgraded to establish a tunnel to the CPE router.  Any traffic
   from the SAM-capable host is routed by the host's SAM stack and
   forwarded through the tunnel to the CPE router.  Tunnelling is
   sufficient; no NAT device is needed between the host and the core
   IPv4 network.  This is abbreviated SAM-HC (Host and CPE router) in
   this document.
















Wing, et al.              Expires April 2, 2009                 [Page 8]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


                     +---+                             +-------------+
       IPv6 host-----+   |            +----------------+IPv6 Internet|
                     |   +--IPv6------+                +-------------+
     SAM host=v4/v4==+   |                 +--------+
                     |NAT|                 |  SAM   |  +-------------+
        IPv4 host----+   +===IPv6 tunnel===+ tunnel +--+IPv4 Internet|
                     +---+                 |concent.|  +-------------+
                                           +--------+

       |<------- public v4 (partially in 2 consecutive tunnels ------>
       |<-private v4-->|<--service provider IPv6--->|<----public v4-->

                  Figure 5: SAM-HC - host and CPE tunnels

3.1.3.  Dual-Stack Lite (DS-Lite)

   Dual-Stack Lite (DS-Lite) [I-D.durand-softwire-dual-stack-lite]
   provides a global IPv4 address that is shared amongst several
   subscribers through a CGN.  Each subscriber network is connected to
   the CGN through a tunnel, using IPv6 as the tunnel transport.  All
   IPv4 traffic is sent inside of that tunnel.  The tunnel endpoint
   implements Dual-Stack [RFC4213].  This draft is discussed in
   [Softwires].

   DS-Lite can be implemented with the tunnel endpoints either in a
   router (CPE router or aggregation router) or in a host.  In both
   cases, a single subscriber IPv4 address or IPv4 prefix may overlap,
   or even be identical for all subscribers.  Addresses from overlapping
   address spaces are disambiguated by the tunnels between the
   subscriber networks and the CGN.

   Figure 6 shows the DS-Lite architecture in the case where the tunnel
   is terminated in a router, which could be the CPE router or an
   aggregation router.  In the diagram, the router terminating the
   tunnel is a CPE router, but another router could be used as well
   (e.g., service provider's aggregation router).  In this architecture,
   the router is upgraded to establish a tunnel to the CGN, and does not
   perform any NAT processing on subscriber traffic.  The router
   provides DHCP service (addresses and other configuration information)
   to the subscriber hosts.  This is abbreviated "DS-Lite router" in
   this document.










Wing, et al.              Expires April 2, 2009                 [Page 9]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


                   +------+                              +-------------+
     IPv6 host-----+      |            +-----------------+IPv6 Internet|
                   |      +--IPv6------+                 +-------------+
   Dual-stack host-+      |
                   |router|                       +---+  +-------------+
     IPv4 host-----+      +===IPv6 tunnel=========+CGN+--+IPv4 Internet|
                   +------+                       +---+  +-------------+

            |<--private v4 (partially in tunnel)-->NAT<---public v4---->
                       |<--service provider IPv6-->|<----public v4----->

      Figure 6: Dual-Stack Lite, tunnel terminated on router (DS-Lite
                                  router)

   The choice of encapsulation for the IPv6 tunnel is outside the scope
   of this document.

   Figure 7 shows the DS-Lite architecture when the tunnel is terminated
   in the subscriber host.  In this architecture, the DS-Lite host IP
   stack is upgraded to establish a tunnel to the CGN, through an
   unmodified CPE router and across either IPv6 transport.  IPv4 traffic
   from the DS-Lite host is routed through the tunnel to the CGN.  This
   is abbreviated "DS-Lite host" in this document.

                  +------+                               +-------------+
     IPv6 host----+      +-------------------------------+IPv6 Internet|
                  |      |                               +-------------+
                  |router|
     DS-Lite      |      |                        +---+  +-------------+
     host==================IPv4-over-IPv6 tunnel==+CGN+--+IPv4 Internet|
                  +------+                        +---+  +-------------+

           |<--private v4 (in tunnel)------------->NAT<---public v4---->
      |<-subscr. IPv6-->|<--service provider IPv6-->|<----public v4---->

    Figure 7: Dual-Stack Lite, tunnel terminated on host (DS-Lite host)

   The choice of encapsulation for the IPv6 tunnel is outside the scope
   of this document.

3.1.4.  NAT444

   NAT444 (no written proposal) would NAT twice:  first using a NAT
   device in the customer premise (as typically deployed today) and
   another NAT device in the ISP's network (a CGN).  This proposal is
   discussed in [Behave].

   The subscriber could access the IPv6 Internet using Teredo [RFC4380].



Wing, et al.              Expires April 2, 2009                [Page 10]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


   The Teredo service could be provided by the ISP (shown as "Teredo
   relay-1") or on the Internet (shown as "Teredo relay-2").

                                                    +-------------+
                                         +----------|IPv6 Internet|
                                         |          +-+-----------|
                                  Teredo relay-1      |
                                         |          Teredo relay-2
                                         |            |
                     +---+               |   +---+  +-+-----------+
        IPv4 host----+NAT+------IPv4-----+---+CGN+--+IPv4 Internet|
                     +---+                   +---+  +-------------+

        |<private v4->NAT<-----private v4---->NAT<----public v4--->

                             Figure 8: NAT444

3.2.  IPv6 hosts in Customer Premise

   For access to the IPv4 Internet, the following proposals require IPv6
   hosts in the customer premise, and do not support IPv4 hosts.  These
   proposals provide access to the IPv4 Internet without requiring dual-
   stack on client equipment.

3.2.1.  IVI

   IVI ([I-D.xli-behave-ivi], [I-D.baker-behave-ivi]) uses an address
   and service architecture designed to facilitate transition from an
   IPv4 Internet to an IPv6 Internet.  This service contains three
   parts:  A DNS Application Layer Gateway, a stateful Network Address
   Translator that enables IPv6 clients to initiate connections to IPv4
   servers and peers, and a stateless Network Address Translator that
   enables IPv4 and IPv6 systems to interoperate freely.

   For an IPv6 host needing access to IPv4 hosts, IVI is similar to both
   SIIT [RFC2765] and NAT-PT [RFC2766] but with a different address
   format.  IVI's DNS rewriting function (A to AAAA) returns an IPv6
   address that routes to a specific translation gateway that advertises
   that IPv6 prefix in the service provider's network.  The DNS server
   may be in the IVI gateway or in a separate system related to it.

   IVI also allows IPv4 hosts to access a IPv6 host, using a stateless
   NAT.  This is accomplished by providing the IPv6 host an IVI address,
   which is simply an IPv6 address from a pool of IPv6 addresses.  This
   pool of IPv6 addresses has a fixed IPv4-to-IPv6 mapping algorithm
   applied to translate between the two address families and the
   translation is implemented by an IVI gateway.  The IPv6 address would
   be advertised in DNS with an A record, pointing to the IVI gateway.



Wing, et al.              Expires April 2, 2009                [Page 11]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


   This allows IPv6-only hosts to have a presence on the IPv4 Internet.
   In this scheme, subsets of the IPv4 addresses are embedded in prefix-
   specific IPv6 addresses and these IPv6 addresses can therefore
   communicate with the global IPv6 networks directly and can
   communicate with the global IPv4 networks via stateless (or almost
   stateless) gateways.  DNS rewriting is not used, or necessary, for
   this fixed mapping of IPv4 addresses to IPv6 address.

   This proposal is discussed in [Behave].

                                                        +-------------+
                           +----------------------------+IPv6 Internet|
                           |                            +-------------+
                           |          +-----+
                +------+   |     +----+ IVI |------+
    IPv6 host---+      |   |    /     +-----+       \   +-------------+
                | CPE  +--IPv6-<                     >--+IPv4 Internet|
                |router|        \   +-----------+   /   +-------------+
    IPv6 host---+      |         +--+DNS-rewrite|--+
                +------+            +-----------+

                               Figure 9: IVI

3.2.2.  NAT6

   NAT6 [I-D.jennings-behave-nat6] encourages IPv6 host itself to
   provide necessary DNS rewriting functions (appending a configured
   IPv6 prefix to an IPv4 address to create an IPv6 address) and have
   the NAT function (from IPv6 to IPv4) performed in the network.  By
   having the host provide the DNS rewriting function, a DNS rewriting
   function in the network is avoided.  This proposal is discussed in
   [Behave].

                                                  +-------------+
                                   +--------------+IPv6 Internet|
                                   |              +-------------+
                      +------+     |
          IPv6 host---+      |     |   +----+     +-------------+
                      | CPE  +---IPv6--+NAT6+-----+IPv4 Internet|
          IPv6 host---+router|         +----+     +-------------+
                      +------+

                              Figure 10: NAT6








Wing, et al.              Expires April 2, 2009                [Page 12]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


3.2.3.  NAT64

   For an IPv6 host needing access to IPv4 hosts, NAT64
   [I-D.bagnulo-behave-nat64] uses the logic of SIIT [RFC2765] and
   NAT-PT [RFC2766] but with a different address format.  This removes
   the relationship between the NAT function and DNS function.  Rather
   than using the DNS-ALG described in [RFC2766], the DNS service simply
   advertises DNS A and AAAA records specifying the IPv6 address of the
   NAT64 device (which is a CGN device).  The DNS server may be in the
   CGN or in a separate system related to it.  This proposal is
   discussed in [Behave].

                                                      +-------------+
                            +-------------------------+IPv6 Internet|
                            |                         +-------------+
                            |          +-----+
                 +------+   |     +----+NAT64+----+
       IPv6 host-+      |   |    /     +-----+     \  +-------------+
                 | CPE  +--IPv6-<                   >-+IPv4 Internet|
       IPv6 host-+router|        \ +-------------+ /  +-------------+
                 +------+         ++DNS rewriting|+
                                   +-------------+

                             Figure 11: NAT64

   It is also possible to utilize NAT64 to access private IPv4 address
   (Figure 12).  To perform this function, NAT64 allows using a locally-
   assigned IPv6 prefix out of the address block of the site running the
   NAT64 device, and allows using a well-known prefix assigned to this
   purpose.

                                                  IPv4 host
                                  +-----+        /
                  IPv6------------+NAT64+-------<-IPv4 host
                Internet          +-----+        \
                                                  IPv4 host

                                    NAT<--private IPv4---->

                Figure 12: NAT64 to Private IPv4 Addresses

   Note that in this scenario, DNS rewriting is not necessary as all of
   the IPv4 addresses could be given AAAA records.

3.2.4.  NAT-PT

   This section is provided for reference only, because NAT-PT has been
   deprecated by [RFC4966].



Wing, et al.              Expires April 2, 2009                [Page 13]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


   NAT-PT [RFC2766] provides a combined DNS-ALG and NAT function, which
   share state.  This is typically implemented in a single device.

                                                     +-------------+
                               +---------------------+IPv6 Internet|
                               |                     +-------------+
                               |     +-----------+
                               |     |  +- - -+  |
                    +------+   |     +--+ NAT +--+
        IPv6 host---+      |   |    /|  +- + -+  |\  +-------------+
                    | CPE  +--IPv6-< |     |     | >-+IPv4 Internet|
        IPv6 host---+router|        \| +- -+- -+ |/  +-------------+
                    +------+         +-+DNS-ALG|-+
                                     | +- - - -+ |
                                     +-----------+

                             Figure 13: NAT-PT

   NAT-PT [RFC2766] and [RFC4966] can be discussed in [Behave].

3.2.5.  sNAT-PT

   For an IPv6 host needing access to IPv4 hosts, sNAT-PT
   [I-D.miyata-v6ops-snatpt] provides DNS rewriting and NAT
   functionality.  The DNS rewriting component is described in
   [I-D.endo-v6ops-dnsproxy].

   This proposal is discussed in [Behave].

                                                       +-------------+
                         +-----------------------------+IPv6 Internet|
                         |                             +-------------+
                         |           +-------+
               +------+  |     +-----+sNAT-PT|----+
     IPv6 host-+      |  |    /      +-------+     \   +-------------+
               | CPE  +-IPv6-<                      >--+IPv4 Internet|
     IPv6 host-+router|       \   +-------------+  /   +-------------+
               +------+        +--+DNS rewriting|-+
                                  +-------------+

                            Figure 14: sNAT-PT

   sNAT-PT also provides access from the IPv4 Internet to IPv6 hosts.
   This can be done with a 1-for-1 mapping or with a 1-for-N mapping
   using IPv4 ports.  These do not require a DNS rewriting function.






Wing, et al.              Expires April 2, 2009                [Page 14]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


                                                   IPv4 host
                                 +-------+        /
                 IPv6------------+sNAT-PT+-------<-IPv4 host
               Internet          +-------+        \
                                                   IPv4 host

                                   NAT<------------IPv4---->

                            Figure 15: sNAT-PT


4.  Changes Required in Network Elements

   This section describes changes to network elements for various
   scenarios.  In all cases, the content provider's DNS and content
   provider's network does not need to change (except due to the problem
   of port limitations as described in Section 2).

4.1.  IPv4 and IPv6 Hosts Accessing the IPv4 Internet

   For the case of an IPv4 host, IPv6 host, or dual-stack host that need
   to connect to IPv4 hosts on the Internet, the following table
   summarizes the changes required to subscriber's hosts (when CPE
   routers are present and when CPE routers are not present) and to some
   network elements:


























Wing, et al.              Expires April 2, 2009                [Page 15]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


   +----------+-------------+--------------+------------+--------------+
   | Proposal |  Subscriber |  Subscriber  | CPE router |  ISP Access  |
   |          | Hosts w/CPE |   Hosts w/o  |            | Edge Network |
   |          |    router   |  CPE router  |            |              |
   +----------+-------------+--------------+------------+--------------+
   |  A+P-v4  |  no change  |   no change  |     A+P    |  route using |
   |          |             |   (A+P NAT   |   support  |  destination |
   |          |             |   would be   |            |     port     |
   |          |             | performed by |            |              |
   |          |             |      SP)     |            |              |
   +----------+-------------+--------------+------------+--------------+
   |  A+P-v6  |  no change  |   no change  |     A+P    |    tunnel    |
   |          |             |   (A+P NAT   |   support  | concentrator |
   |          |             |   would be   |            |              |
   |          |             | performed by |            |              |
   |          |             |      SP)     |            |              |
   +----------+-------------+--------------+------------+--------------+
   |  SAM-CPE |  no change  |     (not     |   SAM CPE  |    tunnel    |
   |          |             |  applicable) |            | concentrator |
   +----------+-------------+--------------+------------+--------------+
   | SAM-host |   SAM-host  |   SAM-host   |  no change |    tunnel    |
   |          |             |              |            | concentrator |
   +----------+-------------+--------------+------------+--------------+
   |  SAM-HC  | SAM support |     (not     |   SAM CPE  |    tunnel    |
   |          |             |  applicable) | internal & | concentrator |
   |          |             |              |  external  |              |
   +----------+-------------+--------------+------------+--------------+
   |  NAT444  |  no change  |   no change  |  no change |   NAT v4v4   |
   +----------+-------------+--------------+------------+--------------+
   |  DS-Lite |  no change  |     (not     |   DS-Lite  |   NAT v4v4   |
   |  router  |             |  supported;  |     CPE    |   w/tunnel   |
   |          |             |  use DS-Lite |            |              |
   |          |             |     host)    |            |              |
   +----------+-------------+--------------+------------+--------------+
   |  DS-Lite |     (not    |  DS-Lite v6  |  no change |   NAT v4v4   |
   |   host   |  supported; |              |            |   w/tunnel   |
   |          | use DS-Lite |              |            |              |
   |          |   router)   |              |            |              |
   +----------+-------------+--------------+------------+--------------+
   |    IVI   |  move to v6 |  move to v6  | move to v6 |   IVI + DNS  |
   |          |             |              |            |   rewriting  |
   +----------+-------------+--------------+------------+--------------+
   |   NAT6   |  move to v6 |  move to v6  | move to v6 |     NAT6     |
   +----------+-------------+--------------+------------+--------------+
   |   NAT64  |  move to v6 |  move to v6  | move to v6 |  NAT64 + DNS |
   |          |             |              |            |   rewriting  |
   +----------+-------------+--------------+------------+--------------+




Wing, et al.              Expires April 2, 2009                [Page 16]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


   +----------+-------------+--------------+------------+--------------+
   |  NAT-PT  |  move to v6 |  move to v6  | move to v6 |   NAT-PT +   |
   |          |             |              |            |    DNS-ALG   |
   +----------+-------------+--------------+------------+--------------+
   |  sNAT-PT |  move to v6 |  move to v6  | move to v6 |   sNAT-PT +  |
   |          |             |              |            |      DNS     |
   |          |             |              |            |   rewriting  |
   +----------+-------------+--------------+------------+--------------+

               Table 1: Changes Required to Network Elements

   For IPv6 hosts that access the IPv4 Internet, the following table
   describes the high-level technologies used by each proposal.

   +----------+------------------+------------+------------------------+
   | Proposal |  ISP's Internal  | DNS Impact |    Carrier Grade NAT   |
   |          |      Network     |            |                        |
   +----------+------------------+------------+------------------------+
   |  A+P-v4  | IPv4 destination |  no change |       (no CGN, if      |
   |          |   port routing   |            |    subscriber's NAT    |
   |          |                  |            |    support A+P NAT)    |
   +----------+------------------+------------+------------------------+
   |  A+P-v6  | IPv4/IPv6 tunnel |  no change |       (no CGN, if      |
   |          |                  |            |    subscriber's NAT    |
   |          |                  |            |    support A+P NAT)    |
   +----------+------------------+------------+------------------------+
   |    SAM   | IPv4/IPv6 tunnel |  no change |        (no CGN)        |
   +----------+------------------+------------+------------------------+
   |  DS-Lite | IPv4/IPv6 tunnel |  no change |        IPv4/IPv4       |
   |  router  |                  |            |                        |
   +----------+------------------+------------+------------------------+
   |  DS-Lite | IPv4/IPv6 tunnel |  no change |        IPv4/IPv4       |
   |   host   |                  |            |                        |
   +----------+------------------+------------+------------------------+
   |  NAT444  |      (v6 not     |   (v6 not  |   (v6 not supported)   |
   |          |    supported)    | supported) |                        |
   +----------+------------------+------------+------------------------+
   |    IVI   |    v4 NATted,    |     DNS    |        IPv6/IPv4       |
   |          |     native v6    |  rewriting |                        |
   |          |      address     |            |                        |
   +----------+------------------+------------+------------------------+
   |   NAT64  |    v4 NATted,    |     DNS    |        IPv6/IPv4       |
   |          |     native v6    |  rewriting |                        |
   |          |      address     |            |                        |
   +----------+------------------+------------+------------------------+
   |  NAT-PT  |    v4 NATted,    |   DNS-ALG  |        IPv6/IPv4       |
   |          |     native v6    |            |                        |
   |          |      address     |            |                        |



Wing, et al.              Expires April 2, 2009                [Page 17]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


   |  sNAT-PT |    v4 NATted,    |     DNS    |        IPv6/IPv4       |
   |          |     native v6    |  rewriting |                        |
   |          |      address     |            |                        |
   +----------+------------------+------------+------------------------+

               Table 2: IPv6 to IPv4 - technologies involved

4.2.  IPv4 Hosts Accessing the IPv4 Internet

   The following table compares the five mechanisms that support end
   hosts running IPv4 to access the IPv4 Internet:  SAM, Dual-Stack
   Lite, NAT444.

   +----------+-------------------+-----------------+------------------+
   | Proposal |     CPE router    |  ISP's Internal | Service Provider |
   |          |                   |     Network     |     Equipment    |
   +----------+-------------------+-----------------+------------------+
   |  A+P-v4  |   IPv6 support +  |  IPv4 and IPv6  | destination port |
   |          |     A+P NAT44     |                 |      routing     |
   +----------+-------------------+-----------------+------------------+
   |  A+P-v6  |   IPv6 support +  |       IPv6      |    IPv6 tunnel   |
   |          |  IPv4/IPv6 tunnel |                 |    termination   |
   |          |    + A+P NAT44    |                 |                  |
   +----------+-------------------+-----------------+------------------+
   |  SAM-CPE |   IPv6 support +  |       IPv6      |    IPv6 tunnel   |
   |          |  IPv4/IPv6 tunnel |                 |    termination   |
   |          |      + NAT44      |                 |                  |
   +----------+-------------------+-----------------+------------------+
   |  DS-Lite |   IPv6 support +  |       IPv6      |    IPv6 tunnel   |
   |  router  |  IPv4/IPv6 tunnel |                 |   termination,   |
   |          |                   |                 |    NAT44 (CGN)   |
   +----------+-------------------+-----------------+------------------+
   |  DS-Lite |  IPv6 support (if |  IPv6 (if using |    IPv6 tunnel   |
   |   host   |   using DS-Lite   |   DS-Lite IPv6  |   termination,   |
   |          |  IPv6 tunneling)  |    tunneling)   |       NAT44      |
   +----------+-------------------+-----------------+------------------+
   |  NAT444  |     no change     |   multi-realm   |    NAT44 (CGN)   |
   |          |                   |       IPv4      |                  |
   +----------+-------------------+-----------------+------------------+

              Table 3: IPv4 Hosts Accessing the IPv4 Internet

   The proposals IVI, NAT6, NAT64, NAT-PT, and sNAT-PT are not shown in
   table Table 3 because those proposals provide no support for IPv4-
   only hosts to access the IPv4 Internet.






Wing, et al.              Expires April 2, 2009                [Page 18]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


4.3.  IPv4 Internet Accessing IPv6 hosts

   IVI, NAT-PT, and sNAT-PT all provide mechanisms for IPv4 hosts on the
   Internet to access IPv6-only servers.  Such mappings consume IPv4
   address space.

   IVI:  IVI allows 1:1 mapping from an IPv4 client to an IPv6 server.
   IVI also allows 1:n mappings, by utilizing the TCP/UDP port number of
   the incoming IPv4 packet in the algorithm to determine the
   destination IPv6 host; this conserves IPv4 address space consumption
   for those hosts that need a few TCP/UDP ports available from the IPv4
   Internet.

   NAT-PT:  NAT-PT allows 1:n mapping from an IPv4 client to an IPv6
   server, which is accomplished by dynamically mapping an IPv4 address
   to an IPv6 address after a DNS "A" record query.

   sNAT-PT:  NAT-PT allows 1:1 mapping from an IPv4 client to an IPv6
   server.


5.  Port Forwarding

   Some applications require accepting incoming UDP or TCP traffic.
   When the remote host is on IPv4, the incoming traffic will be
   directed towards an IPv4 address.  The applications are separated
   into two broad categories:  those requiring static incoming ports and
   those requiring dynamic incoming ports.

   Due to IPv4 NATs and IPv4 firewalls, some applications use [UPnP-IGD]
   (e.g., XBox) or ICE [I-D.ietf-mmusic-ice] (e.g., SIP, Yahoo!/Google/
   Microsoft chat networks), other applications have all but completely
   abandoned incoming connections (e.g., most FTP transfers use passive
   mode).  But some applications rely on ALGs, UPnP IGD, or manual port
   configuration.  Further discussion in the IETF community is necessary
   to decide how to proceed on this issue.

      Note:  Placing application awareness (i.e., ALG) in the CGN will
      cause bug fixes and new features to be delayed by development,
      testing, and deployment.  To prevent such delays, application
      awareness should be placed elsewhere (e.g., in the CPE router or
      in the end host).

      Note:  Extending NAT-PMP [I-D.cheshire-nat-pmp] to support IPv6
      could provide provide static port forwarding and dynamic port
      forwarding for IPv4 and IPv6 hosts needing access from IPv4 hosts.





Wing, et al.              Expires April 2, 2009                [Page 19]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


5.1.  Static Incoming Ports

   Static incoming ports are used by applications for multiple sessions.

      Note:  Some applications (e.g., BitTorrent) can use UPnP IGD to
      control IPv4 NATs and open a static incoming port.  However,
      technical limitations of UPnP IGD appear to prevent UPnP IGD from
      being directly implemented in a CGN.  The most significant
      technical limitation is that UPnP IGD expects the control point
      (the host) to be able to specify the public port; with hundreds of
      subscribers utilizing the same public IP address, this is
      untenable.  Other UPnP IGD technical limitations may be
      surmountable (e.g., UPnP IGD's ability to create and destroy
      mappings for other IP addresses).

   Examples of applications that require static incoming ports include:

   o  HTTP

   o  SMTP (must be on TCP/25)

   o  ssh

   o  BitTorrent

   o  games (of particular note is that XBox uses UPnP IGD)

   The solutions proposed for static ports are:

      A+P:  The subscriber's customer premise NAT can forward ports
      within the allocated port range.  This port could be advertised by
      the subscriber using DNS SRV resource records or other means.

      SAM-host and SAM-HC:  assign a port in the available port range;
      advertise it with the IPv4 address using a DNS SRV resource
      record.

      Dual-Stack Lite:  none

      NAT444:  none

      IVI:  assign IPv6 IVI address to IPv6 hosts that require incoming
      IPv4 connections

      NAT6:  none

      NAT64:  none




Wing, et al.              Expires April 2, 2009                [Page 20]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


      sNAT-PT:  assign IPv4 address to IPv6 hosts that require incoming
      IPv4 sessions.

5.2.  Dynamic Incoming Ports

   Dynamic incoming ports are, generally, used by applications for a
   single session.  Examples of applications that require dynamic
   incoming ports include:

   o  applications that use real-time transport protocol (RTP)

      *  SIP, RTSP, H.323, MGCP, H.248/Megaco

   o  non-passive FTP client

   o  games (of particular note is that XBox uses UPnP IGD)

   The solutions proposed for dynamic ports are:

      A+P:  An ALG can be incorporated into the subscriber's A+P-aware
      NAT, as done today with subscriber's NAT44 devices.

      SAM-host and SAM-HC:  assign a port in the available port range.

      Dual-Stack Lite:  none

      NAT444:  none (although it is reasonable to expect that ALGs, as
      they exist in today's IPv4 NATs, might be utilized)

      IVI:  assign IPv6 IVI address to IPv6 hosts that require incoming
      IPv4 connections

      NAT6:  none

      NAT64:  applications could be modified to support STUN (for TCP
      and UDP) to learn their public IPv4 address and TCP/UDP port.

      sNAT-PT:  assign IPv4 address to IPv6 hosts that require incoming
      IPv4 connections.


6.  Transport Protocol Support

   [[Placeholder:  discuss how DCCP and SCTP (and other transport
   protocols) are supported by each proposal.  Although existing IPv4
   NATs do not support DCCP or SCTP, it is reasonable to expect that new
   NATs could support those transport protocols if we want those
   protocols to work between address families.



Wing, et al.              Expires April 2, 2009                [Page 21]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


7.  Analysis with V6OPS's NAT64 Problem Statement

   This section analyzes how each proposal maps to the requirements in
   [I-D.ietf-v6ops-nat64-pb-statement-req].

   [[Placeholder until [I-D.ietf-v6ops-nat64-pb-statement-req] becomes
   more stable.]]


8.  Comparison of Proposals with NAT-PT Problems

   The following sections analyze how proposals fare against the
   problems caused by NAT-PT [RFC2766] as documented in [RFC4966]:

8.1.  Issues Unrelated to an DNS-ALG

8.1.1.  Issues with Protocols Embedding IP Addresses

   NAT6 requires applications to handle NAT6 traversal themselves.

   The other proposals are silent on this issue, but in general using an
   application layer gateway (ALG), in some device in the network,
   appears to be the only solution to this problem.  See also Section 5.

8.1.2.  NAPT-PT Redirection Issues

   All proposals are silent on this issue.

8.1.3.  NAT-PT Binding State Decay

   NAT6 and NAT64 discuss binding lifetimes.

   The other proposals are silent on this issue.

8.1.4.  Loss of Information through Incompatible Semantics

   All proposals are silent on this issue.

8.1.5.  NAT-PT and Fragmentation

   [[NAT64, NAT6, DS-Lite, and IVI all mention fragmentation.  Need to
   analyze how they differ.]]

8.1.6.  NAT-PT Interaction with SCTP and Multihoming

   IVI supports multi-homing if there is a 1:1 mapping between IPv4 and
   IPv6 addresses.  However, 1:1 mapping is not sustainable as we
   approach IPv4 exhaustion.



Wing, et al.              Expires April 2, 2009                [Page 22]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


   SAM (both SAM-host and SAM-HC) support SCTP.

   sNAT-PT explicitly indicates SCTP is out-of-scope.

   The other proposals are silent on this issue.  All proposals seem to
   be considering only TCP, UDP, and ICMP.

8.1.7.  NAT-PT as a Proxy Correspondent Node for MIPv6

   All proposals are silent on this issue.

8.1.8.  NAT-PT and Multicast

   IVI can support Source-Specific Multicast [RFC4607] (see Section 7 of
   [I-D.xli-behave-ivi]).

   Dual-Stack Lite does not support multicast.

   NAT6 does not specify how it can work with multicast.

   In sNAT-PT, multicasting in either direction requires manual mapping.

   The other proposals are silent on this issue.

      Note:  it may be possible for IGMP messages to be propagated and
      proxied [RFC4605] across their respective NAT device [RFC5135].
      More study on this is needed.

8.2.  Issues Exacerbated by the Use of DNS-ALG

8.2.1.  Network Topology Constraints Implied by NAT-PT

   The separation of NAT and DNS-rewriting reduces the impact of this
   issue.  IVI, NAT64, and sNAT-PT separate the NAT and DNS-rewrite
   functions, and avoid this constraint.

8.2.2.  Scalability and Single Point of Failure Concerns

   The separation of NAT and DNS-rewriting reduces the impact of this
   issue.  IVI, NAT64, and sNAT-PT all separate the NAT and DNS-rewrite
   functions.

8.2.3.  Issues with Lack of Address Persistence

   TBD.






Wing, et al.              Expires April 2, 2009                [Page 23]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


8.2.4.  DoS Attacks on Memory and Address/Port Pool

   A CGN would only allow a certain subscriber to open a certain number
   of ports, thereby preventing a single subscriber from DoSing other
   subscribers ([I-D.nishitani-cgn], "a CGN SHOULD limit the number of
   the CGN external ports").

8.3.  Issues Directly Related to Use of DNS-ALG

8.3.1.  Address Selection Issues when Communicating with Dual-Stack End-
        Hosts

   Unlike NAT-PT, all proposals that involve DNS-rewriting (IVI, NAT64,
   sNAT-PT) do not return synthetic AAAA records if a real AAAA record
   exists.  This prevents the problem.  A DNS timeout (of the AAAA
   query) will prevent the optimum DNS response from being returned
   (that is, the real AAAA record rather than the synthesized AAAA
   record pointing to the CGN device), but it is still possible to
   connect even when such a timeout occurs.  In practice, such DNS
   timeouts are not a common occurance.

   In [I-D.bagnulo-behave-nat64], EDNS0 [RFC2671] is proposed as the
   mechanism for a host to determine if the AAAA record is synthetic
   (that is, generated by the DNS rewriting function) or if the AAAA
   record is genuine (that is, was not synthesized).

8.3.2.  Non-Global Validity of Translated RR Records

   TBD.

8.3.3.  Inappropriate Translation of Responses to A Queries

   sNAT-PT avoids this problem with its stateful DNS proxy.

8.3.4.  DNS-ALG and Multi-Addressed Nodes

   The additional NAT binding state is not created if the DNS rewriting
   and NAT functions are separate.  Thus, this problem is avoided by
   [I-D.xli-behave-ivi], [I-D.bagnulo-behave-nat64], and
   [I-D.miyata-v6ops-snatpt].

8.3.5.  Limitations on Deployment of DNS Security Capabilities

   DNSSEC is incompatible with synthesized DNS responses (DNS
   rewriting).

   NAT64 recommends that DNSSEC-capable IPv6-only hosts use the EDNS SAS
   option to ignore synthetic DNS responses.  This would allow the IPv6



Wing, et al.              Expires April 2, 2009                [Page 24]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


   host to ignore synthetic DNS responses and allows DNSSEC to work for
   non- synthesized AAAA responses.  This means, however, that DNSSEC
   only works for native IPv6 AAAA responses, and DNSSEC cannot be used
   for IPv4 A responses.

   No other proposal discusses how it would work with DNSSEC.

   Note:  A proposal that does DNS rewriting only in a validating
   resolver (after validation), or construct records in the
   authoritative server, will work fine with DNSsec.

8.4.  Impact on IPv6 Application Development

   TBD.


9.  Security Considerations

9.1.  Address Sharing

   When resources are shared it is important they are shared fairly.  On
   today's Internet, the shared resource is bandwidth -- both the
   service provider's core bandwidth (sharing between subscribers) and
   subscriber access bandwidth (sharing between a subscriber's own
   hosts).  Subscribers are given an IP address(es) for their exclusive
   use.  With all of the NAT44 and NAT64 mechanisms proposed, an IPv4
   address is shared amongst several subscribers.

   This address sharing raises some security considerations, including
   DoS potential (a subscriber might accidentally or purposefully use
   all available ports, denying ports to other subscribers
   [I-D.nishitani-cgn] and spoofing (a subscriber might send a packet
   with the correct IP address, but the port belongs to a different
   subscriber).  Address sharing causes false negatives and false
   positives for existing IP sddress spoofing mechanisms (DHCP snooping,
   ARP security, ingress filtering [RFC2827]).

   For lack of a better identifier, many applications and systems use an
   IPv4 address as an end-host identifier and take action based on that
   identity.  In the past, IP addresses sometimes provided additional
   privileges (e.g., the ability to login without a password using
   Berkeley "r services").  This persists today with some systems (e.g.,
   DHCP snooping, ARP security, and email Sender Policy Framework
   (SPF)).  Conversely, undesired behavior of a certain IP address can
   cause servers to refuse to provide service.  For example, excessive
   connection attempts or excessive downloading can cause an HTTP server
   to delay (or refuse) providing service to that IP address.  As
   another example, IP address blacklisting (e.g., DNSBL) might cause



Wing, et al.              Expires April 2, 2009                [Page 25]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


   e-mail from that IP address to be considered more likely to be spam.
   Even with consumer NAT44, these systems work reasonably well because
   excessive connection attempts or spam originating from any host
   belonging to a subscriber is punished, without harming other
   subscribers of that ISP.  (Of course, some such systems apply their
   rate limiting to entire subnets in order to purposefully punish other
   subscribers of that ISP.)  However, when an ISP aggregates many
   subscribers behind the same public IPv4 address (such as used by all
   systems described in this paper), all of those subscribers will be
   appear as one identity to the rest of the Internet.  This will cause
   problems with existing systems that equate an IPv4 address with an
   identity, and take action based on such identities.

9.2.  IPsec Compatibility

   It is well known that IPSec AH [RFC4302] does not work with NAT
   [RFC3715].  However, IPsec ESP [RFC4303] can work with NATs because
   it does not include source or destination addresses in its keyed
   message integrity check.  It is possible to carry IPsec ESP over UDP
   [RFC3948], which survives well over NATs at the expense of a UDP
   header (8 bytes).

   To avoid the UDP overhead and to allow for IPsec ESP endpoints that
   do not support IPsec over UDP, many deployed IPv4 NAT devices provide
   an "IPsec Passthru" feature, which uses the destination IP address
   and the IPsec ESP Security Parameters Index (SPI) field to perform
   its NAT function.  However, "IPsec passthru" has some drawbacks (not
   described here).


10.  Acknowledgements

   Thanks to the authors of the contributions compared in this document,
   Cullen Jennings (NAT6); Marcelo Bagnulo, Philip Matthews, Iljitsch
   van Beijnum (NAT64); Xing Li, Maoke Chen, Congxiao Bao, Hong Zhang,
   Jianping Wu, Fred Baker (IVI); Alain Durand, Ralph Droms, Brian
   Haberman (DS-Lite); Tomohiro Nishitani, Shin Miyakawa (CGN); Remi
   Despres (SAM); Hiroshi Miyata, Masahito Endo (sNAT-PT); Olaf Maennel,
   Randy Bush, Luca Cittadini, Steven M. Bellovin (A+P).

   Thanks to Fred Baker, Randy Bush, Wojciech Dec, Thomas Narten, Dave
   Thaler and Eric Vyncke for their review and suggested improvements to
   the document.


11.  IANA Considerations

   This document has no IANA actions.



Wing, et al.              Expires April 2, 2009                [Page 26]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


12.  References

12.1.  Normative References

   [A+P]      Maennel, O., Bush, R., Cittadini, L., and S. Bellovin, "A
              Better Approach than Carrier-Grade-NAT", <http://
              mice.cs.columbia.edu/getTechreport.php?techreportID=560>.

   [I-D.bagnulo-behave-nat64]
              Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64/DNS64:
              Network Address and Protocol Translation from IPv6 Clients
              to  IPv4 Servers", draft-bagnulo-behave-nat64-01 (work in
              progress), September 2008.

   [I-D.baker-behave-ivi]
              Li, X., Bao, C., Baker, F., and K. Yin, "IVI Update to
              SIIT and NAT-PT", draft-baker-behave-ivi-01 (work in
              progress), September 2008.

   [I-D.durand-softwire-dual-stack-lite]
              Durand, A., Droms, R., Haberman, B., and J. Woodyatt,
              "Dual-stack lite broadband deployments post IPv4
              exhaustion", draft-durand-softwire-dual-stack-lite-00
              (work in progress), September 2008.

   [I-D.endo-v6ops-dnsproxy]
              Endo, M. and H. Miyata, "Translator Friendly DNS Proxy",
              draft-endo-v6ops-dnsproxy-00 (work in progress),
              August 2008.

   [I-D.ietf-v6ops-nat64-pb-statement-req]
              Bagnulo, M., Baker, F., and I. Beijnum, "IPv4/IPv6
              Coexistence and Transition: Requirements for solutions",
              draft-ietf-v6ops-nat64-pb-statement-req-00 (work in
              progress), May 2008.

   [I-D.jennings-behave-nat6]
              Jennings, C., "NAT for IPv6-Only Hosts",
              draft-jennings-behave-nat6-00 (work in progress),
              July 2008.

   [I-D.miyata-v6ops-snatpt]
              Miyata, H. and M. Endo, "sNAT-PT: Simplified Network
              Address Translation - Protocol Translation",
              draft-miyata-v6ops-snatpt-02 (work in progress),
              September 2008.

   [I-D.nishitani-cgn]



Wing, et al.              Expires April 2, 2009                [Page 27]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


              Nishitani, T. and S. Miyakawa, "Carrier Grade Network
              Address Translator (NAT) Behavioral Requirements for
              Unicast UDP, TCP and ICMP", draft-nishitani-cgn-00 (work
              in progress), July 2008.

   [I-D.xli-behave-ivi]
              Li, X., Chen, M., Bao, C., Zhang, H., and J. Wu, "Prefix-
              specific and Stateless Address Mapping (IVI) for IPv4/IPv6
              Coexistence and Transition", draft-xli-behave-ivi-00 (work
              in progress), July 2008.

   [RFC4966]  Aoun, C. and E. Davies, "Reasons to Move the Network
              Address Translator - Protocol Translator (NAT-PT) to
              Historic Status", RFC 4966, July 2007.

12.2.  Informative References

   [Behave]   IETF, "BEHAVE working group mailing list",
              <https://www.ietf.org/mailman/listinfo/behave>.

   [I-D.cheshire-nat-pmp]
              Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
              draft-cheshire-nat-pmp-03 (work in progress), April 2008.

   [I-D.despres-sam]
              Despres, R., "Stateless Address Mapping with A+P Extended
              IPv4 addressing (SAM)", draft-despres-sam-00 (work in
              progress), September 2008.

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address  Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in progress), October 2007.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, August 1999.

   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
              (SIIT)", RFC 2765, February 2000.

   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
              Translation - Protocol Translation (NAT-PT)", RFC 2766,
              February 2000.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.



Wing, et al.              Expires April 2, 2009                [Page 28]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


   [RFC3715]  Aboba, B. and W. Dixon, "IPsec-Network Address Translation
              (NAT) Compatibility Requirements", RFC 3715, March 2004.

   [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
              Stenberg, "UDP Encapsulation of IPsec ESP Packets",
              RFC 3948, January 2005.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              February 2006.

   [RFC4605]  Fenner, B., He, H., Haberman, B., and H. Sandick,
              "Internet Group Management Protocol (IGMP) / Multicast
              Listener Discovery (MLD)-Based Multicast Forwarding
              ("IGMP/MLD Proxying")", RFC 4605, August 2006.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC4925]  Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
              Problem Statement", RFC 4925, July 2007.

   [RFC5135]  Wing, D. and T. Eckert, "IP Multicast Requirements for a
              Network Address Translator (NAT) and a Network Address
              Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.

   [Softwires]
              IETF, "Softwires working group mailing list",
              <https://www.ietf.org/mailman/listinfo/softwires>.

   [UPnP-IGD]
              UPnP Forum, "Universal Plug and Play Internet Gateway
              Device", 2000,
              <http://www.upnp.org/standardizeddcps/igd.asp>.

   [v4v6interm-interest]
              IETF, "v4v6interm-interest mailing list", <https://
              www.ietf.org/mailman/listinfo/v4v6interm-interest>.




Wing, et al.              Expires April 2, 2009                [Page 29]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


Appendix A.  Changes

A.1.  Changes from 01 to 02

   o  Updated DS-Lite reference; no changes to text

   o  Updated from APB-Revised to SAM; changed text

   o  Updated sNAT-PT reference; added description of IPv4-to-IPv6 1:N
      port mapping

   o  Mentioned policing difficulties for shared addresses (DHCP
      snooping, ARP security, ingress filtering)

   o  Discuss IPsec compatibility

   o  Added explanation of how NAT444 can support IPv6 using Teredo

A.2.  Changes from 00 to 01

   o  Added A+P

   o  Refined security considerations for sharing addresses

   o  "CPE" -> "CPE router"

   o  removed NAPT defintion (we use NAT to mean NAPT, as is done
      colloquially)

   o  fixed some text and figures for APB-Revised

   o  removed the DNS rewriting function from NAT64's figure showing
      IPv6 hosts accessing IPv4 servers.


Authors' Addresses

   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email:  dwing@cisco.com







Wing, et al.              Expires April 2, 2009                [Page 30]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


   David Ward
   Cisco Systems, Inc.


   Email:  wardd@cisco.com


   Alain Durand
   Comcast
   1500 Market st
   Philadelphia, PA  19102
   USA

   Email:  alain_durand@cable.comcast.com





































Wing, et al.              Expires April 2, 2009                [Page 31]

Internet-Draft        NAT-PT Replacement Comparison       September 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   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 BCP 78 and BCP 79.

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

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


Acknowledgment

   This document was produced using xml2rfc v1.33 (of
   http://xml.resource.org/) from a source in RFC-2629 XML format.





Wing, et al.              Expires April 2, 2009                [Page 32]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/