One document matched: draft-wing-nat-pt-replacement-comparison-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.bagnulo-behave-nat64 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bagnulo-behave-nat64.xml">
<!ENTITY I-D.xli-behave-ivi SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.xli-behave-ivi.xml">
<!ENTITY I-D.baker-behave-ivi SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.baker-behave-ivi.xml">
<!ENTITY I-D.ietf-v6ops-nat64-pb-statement-req SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-nat64-pb-statement-req.xml">
<!ENTITY I-D.nishitani-cgn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.nishitani-cgn.xml">
<!ENTITY I-D.jennings-behave-nat6 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jennings-behave-nat6.xml">
<!ENTITY rfc4966 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4966.xml">
<!ENTITY I-D.miyata-v6ops-snatpt SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.miyata-v6ops-snatpt.xml">
<!ENTITY I-D.endo-v6ops-dnsproxy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.endo-v6ops-dnsproxy.xml">
<!ENTITY rfc2765 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2765.xml">
<!ENTITY rfc4303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY rfc4302 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4302.xml">
<!ENTITY rfc3715 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3715.xml">
<!ENTITY rfc3948 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3948.xml">
<!ENTITY rfc2766 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2766.xml">
<!ENTITY I-D.ietf-mmusic-ice SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-ice.xml">
<!ENTITY rfc4607 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4607.xml">
<!ENTITY rfc4213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4213.xml">
<!ENTITY rfc2671 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2671.xml">
<!ENTITY I-D.despres-sam SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.despres-sam.xml">
<!ENTITY I-D.cheshire-nat-pmp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cheshire-nat-pmp.xml">
<!ENTITY rfc4605 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4605.xml">
<!ENTITY rfc5135 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5135.xml">
<!ENTITY rfc2827 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml">
<!ENTITY rfc4380 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml">
<!ENTITY rfc4925 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4925.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc rfcprocack="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="info" docName="draft-wing-nat-pt-replacement-comparison-02"
ipr="full3978">
<front>
<title abbrev="NAT-PT Replacement Comparison">A Comparison of Proposals to
Replace NAT-PT</title>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="David Ward" initials="D." surname="Ward">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>wardd@cisco.com</email>
</address>
</author>
<author fullname="Alain Durand" initials="A." surname="Durand">
<organization>Comcast</organization>
<address>
<postal>
<street>1500 Market st</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19102</code>
<country>USA</country>
</postal>
<email>alain_durand@cable.comcast.com</email>
</address>
</author>
<date year="2008" />
<workgroup>Behave and Softwires WGs</workgroup>
<abstract>
<t>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.</t>
<t>This draft compares eight proposals for IPv6 and IPv4
coexistence.</t>
</abstract>
</front>
<middle>
<section title="Terminology">
<t>The following terms are used throughout this document.<list
hangIndent="5" style="hanging">
<t hangText="Address Family Translation (AFT):">The function of
translating from one IP address family (IPv4 or IPv6) to another
(IPv6 or IPv4).</t>
<t hangText="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).</t>
<t hangText="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'.)</t>
<t hangText="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 <xref
target="RFC2766">NAT-PT</xref> DNS-ALG meant a DNS rewriting
function with an interface to the NAT function.</t>
<t hangText="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).</t>
<t hangText="Softwire">A tunnel for carrying IPv4 and IPv6 traffic
over IPv6 and IPv4 networks <xref target="RFC4925"></xref>.</t>
</list></t>
</section>
<section anchor="introduction" title="Introduction">
<t>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.</t>
<t>The proposals have several high-level attributes in common:</t>
<t><list style="empty">
<t>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
<xref target="RFC4213"></xref>. 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>This draft is discussed on the <xref
target="v4v6interm-interest"></xref> mailing list. Individual proposals
are discussed on the mailing list indicated in this document.</t>
</section>
<section title="Overview of Proposals">
<t>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.</t>
<t>The descriptions below provide a very brief overview of each
proposal, in alphabetical order.</t>
<section title="IPv4 hosts in Customer Premise">
<t>For Internet access, the following proposals allow for IPv4 hosts
in the customer premise.</t>
<section title="Address Plus Port (A+P)">
<t><xref target="A+P">Address Plus Port </xref> 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.</t>
<t>One of A+P's architectures is depicted in <xref
target="fig.aplusp-v4"></xref>, 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".</t>
<figure anchor="fig.aplusp-v4"
title="Address Plus Port, v4-capable ISP (A+P-v4)">
<preamble></preamble>
<artwork align="center"><![CDATA[ +---+ +-------------+
IPv6 host-----+ | +----------------+IPv6 Internet|
| +--IPv6------+ +-------------+
Dual-stack host--+ |
|NAT| +------+ +-------------+
IPv4 host----+ +--------+router+-------------+IPv4 Internet|
+---+ +------+ +-------------+
|<private IPv4>NAT<-----------------------------public v4----->]]></artwork>
</figure>
<t>Another of A+P's architectures is depicted in <xref
target="fig.aplusp-v6"></xref>, 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".</t>
<figure anchor="fig.aplusp-v6"
title="Address Plus Port, v6-only ISP (A+P-v6)">
<preamble></preamble>
<artwork align="center"><![CDATA[ +---+ +-------------+
IPv6 host-----+ | +----------------+IPv6 Internet|
| +--IPv6------+ +-------------+
Dual-stack host--+ |
|NAT| +--------+ +-------------+
IPv4 host----+ +===IPv6 tunnel===+ tunnel +--+IPv4 Internet|
+---+ |concent.| +-------------+
+--------+
|<private IPv4>NAT<----------------------------public v4----->]]></artwork>
</figure>
</section>
<section title="Stateless Address Mapping (SAM) (previously APB-Revised)">
<t>Stateless Address Mapping (SAM) <xref
target="I-D.despres-sam"></xref> 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.</t>
<t>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. <xref
target="SAM-CPE"></xref> 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.</t>
<t>This proposal is discussed in <xref
target="Softwires"></xref>.</t>
<figure anchor="SAM-CPE"
title="SAM-CPE, tunnel between CPE and tunnel concentrator">
<preamble></preamble>
<artwork align="center"><![CDATA[ +---+ +-------------+
IPv6 host-----+ | +----------------+IPv6 Internet|
| +--IPv6------+ +-------------+
Dual-stack host--+ | +--------+
|NAT| | SAM | +-------------+
IPv4 host----+ +===IPv6 tunnel===+ tunnel +--+IPv4 Internet|
+---+ |concent.| +-------------+
+--------+
|<private IPv4>NAT<----------------------------public v4------>]]></artwork>
</figure>
<t>In the figure above, the IPv6 tunnel is an IPv4-over-IPv6
tunnel.</t>
<t><xref target="SAM-host"></xref> 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 <xref
target="SAM-host"></xref>, 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.</t>
<figure anchor="SAM-host"
title="SAM-host - tunnel between host and tunnel concentrator">
<preamble></preamble>
<artwork align="center"><![CDATA[ +---+ +-------------+
IPv6 host-----+ | +----------------+IPv6 Internet|
| +--IPv6------+ +-------------+
SAM host--+ | +--------+
|CPE| | SAM | +-------------+
IPv4 host----+ +===IPv6 tunnel===+ tunnel +--+IPv4 Internet|
+---+ |concent.| +-------------+
+--------+
|<private IPv4>NAT<----------------------------public v4------>]]></artwork>
</figure>
<t><xref target="SAM-HC"></xref> 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.</t>
<figure anchor="SAM-HC"
title="SAM-HC - host and CPE tunnels">
<preamble></preamble>
<artwork align="center"><![CDATA[ +---+ +-------------+
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-->]]></artwork>
</figure>
<t></t>
</section>
<section title="Dual-Stack Lite (DS-Lite)">
<t>Dual-Stack Lite (DS-Lite) <xref
target="I-D.durand-softwire-dual-stack-lite"></xref>
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 <xref
target="RFC4213">Dual-Stack</xref>. This draft is discussed
in <xref target="Softwires"></xref>.</t>
<t>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.</t>
<t><xref target="DS-Lite-router"></xref> 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.</t>
<figure anchor="DS-Lite-router"
title="Dual-Stack Lite, tunnel terminated on router (DS-Lite router)">
<preamble></preamble>
<artwork align="center"><![CDATA[ +------+ +-------------+
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----->]]></artwork>
</figure>
<t>The choice of encapsulation for the IPv6 tunnel is outside the
scope of this document.</t>
<t><xref target="DS-Lite-host"></xref> 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.</t>
<figure anchor="DS-Lite-host"
title="Dual-Stack Lite, tunnel terminated on host (DS-Lite host)">
<preamble></preamble>
<artwork align="center"><![CDATA[ +------+ +-------------+
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---->
]]></artwork>
</figure>
<t>The choice of encapsulation for the IPv6 tunnel is outside the
scope of this document.</t>
</section>
<section title="NAT444">
<t>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 <xref target="Behave"></xref>.</t>
<t>The subscriber could access the IPv6 Internet using <xref
target="RFC4380">Teredo</xref>. The Teredo service could be provided
by the ISP (shown as "Teredo relay-1") or on the Internet (shown as
"Teredo relay-2").</t>
<figure anchor="NAT444" title="NAT444">
<preamble></preamble>
<artwork align="center"><![CDATA[ +-------------+
+----------|IPv6 Internet|
| +-+-----------|
Teredo relay-1 |
| Teredo relay-2
| |
+---+ | +---+ +-+-----------+
IPv4 host----+NAT+------IPv4-----+---+CGN+--+IPv4 Internet|
+---+ +---+ +-------------+
|<private v4->NAT<-----private v4---->NAT<----public v4--->]]></artwork>
</figure>
</section>
</section>
<section title="IPv6 hosts in Customer Premise">
<t>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.</t>
<section title="IVI">
<t>IVI (<xref target="I-D.xli-behave-ivi"></xref>, <xref
target="I-D.baker-behave-ivi"></xref>) 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.</t>
<t>For an IPv6 host needing access to IPv4 hosts, IVI is similar to
both <xref target="RFC2765">SIIT</xref> and <xref
target="RFC2766">NAT-PT</xref> 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.</t>
<t>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. 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.</t>
<t>This proposal is discussed in <xref target="Behave"></xref>.</t>
<figure anchor="IVI" title="IVI">
<preamble></preamble>
<artwork align="center"><![CDATA[ +-------------+
+----------------------------+IPv6 Internet|
| +-------------+
| +-----+
+------+ | +----+ IVI |------+
IPv6 host---+ | | / +-----+ \ +-------------+
| CPE +--IPv6-< >--+IPv4 Internet|
|router| \ +-----------+ / +-------------+
IPv6 host---+ | +--+DNS-rewrite|--+
+------+ +-----------+]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="NAT6">
<t><xref target="I-D.jennings-behave-nat6">NAT6</xref> 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 <xref
target="Behave"></xref>.</t>
<figure anchor="NAT6" title="NAT6">
<preamble></preamble>
<artwork align="center"><![CDATA[ +-------------+
+--------------+IPv6 Internet|
| +-------------+
+------+ |
IPv6 host---+ | | +----+ +-------------+
| CPE +---IPv6--+NAT6+-----+IPv4 Internet|
IPv6 host---+router| +----+ +-------------+
+------+]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="NAT64">
<t>For an IPv6 host needing access to IPv4 hosts, <xref
target="I-D.bagnulo-behave-nat64">NAT64</xref> uses the logic of
<xref target="RFC2765">SIIT</xref> and <xref
target="RFC2766">NAT-PT</xref> 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 <xref
target="RFC2766"></xref>, 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 <xref
target="Behave"></xref>.</t>
<figure anchor="NAT64" title="NAT64">
<preamble></preamble>
<artwork align="center"><![CDATA[ +-------------+
+-------------------------+IPv6 Internet|
| +-------------+
| +-----+
+------+ | +----+NAT64+----+
IPv6 host-+ | | / +-----+ \ +-------------+
| CPE +--IPv6-< >-+IPv4 Internet|
IPv6 host-+router| \ +-------------+ / +-------------+
+------+ ++DNS rewriting|+
+-------------+]]></artwork>
<postamble></postamble>
</figure>
<t>It is also possible to utilize NAT64 to access private IPv4
address (<xref target="NAT64-Private-IPv4"></xref>). 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.</t>
<figure anchor="NAT64-Private-IPv4"
title="NAT64 to Private IPv4 Addresses">
<preamble></preamble>
<artwork align="center"><![CDATA[ IPv4 host
+-----+ /
IPv6------------+NAT64+-------<-IPv4 host
Internet +-----+ \
IPv4 host
NAT<--private IPv4---->]]></artwork>
</figure>
<t>Note that in this scenario, DNS rewriting is not necessary as all
of the IPv4 addresses could be given AAAA records.</t>
</section>
<section title="NAT-PT">
<t>This section is provided for reference only, because NAT-PT has
been deprecated by <xref target="RFC4966"></xref>.</t>
<t><xref target="RFC2766">NAT-PT</xref> provides a combined DNS-ALG
and NAT function, which share state. This is typically implemented
in a single device.</t>
<figure anchor="NAT-PT" title="NAT-PT">
<preamble></preamble>
<artwork align="center"><![CDATA[ +-------------+
+---------------------+IPv6 Internet|
| +-------------+
| +-----------+
| | +- - -+ |
+------+ | +--+ NAT +--+
IPv6 host---+ | | /| +- + -+ |\ +-------------+
| CPE +--IPv6-< | | | >-+IPv4 Internet|
IPv6 host---+router| \| +- -+- -+ |/ +-------------+
+------+ +-+DNS-ALG|-+
| +- - - -+ |
+-----------+]]></artwork>
<postamble></postamble>
</figure>
<t><xref target="RFC2766">NAT-PT</xref> and <xref
target="RFC4966"></xref> can be discussed in <xref
target="Behave"></xref>.</t>
</section>
<section title="sNAT-PT">
<t>For an IPv6 host needing access to IPv4 hosts, <xref
target="I-D.miyata-v6ops-snatpt">sNAT-PT</xref> provides DNS
rewriting and NAT functionality. The DNS rewriting component is
described in <xref target="I-D.endo-v6ops-dnsproxy"></xref>.</t>
<t>This proposal is discussed in <xref target="Behave"></xref>.</t>
<figure anchor="sNAT-PT" title="sNAT-PT">
<preamble></preamble>
<artwork align="center"><![CDATA[ +-------------+
+-----------------------------+IPv6 Internet|
| +-------------+
| +-------+
+------+ | +-----+sNAT-PT|----+
IPv6 host-+ | | / +-------+ \ +-------------+
| CPE +-IPv6-< >--+IPv4 Internet|
IPv6 host-+router| \ +-------------+ / +-------------+
+------+ +--+DNS rewriting|-+
+-------------+]]></artwork>
<postamble></postamble>
</figure>
<t>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.</t>
<figure anchor="sNAT-PT-46"
title="sNAT-PT ">
<preamble></preamble>
<artwork align="center"><![CDATA[ IPv4 host
+-------+ /
IPv6------------+sNAT-PT+-------<-IPv4 host
Internet +-------+ \
IPv4 host
NAT<------------IPv4---->]]></artwork>
</figure>
</section>
</section>
</section>
<section title="Changes Required in Network Elements">
<t>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 <xref
target="introduction"></xref>).</t>
<section title="IPv4 and IPv6 Hosts Accessing the IPv4 Internet">
<t>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:</t>
<texttable anchor="table-changes" style="all"
title="Changes Required to Network Elements">
<preamble></preamble>
<ttcol align="center">Proposal</ttcol>
<ttcol align="center">Subscriber Hosts w/CPE router</ttcol>
<ttcol align="center">Subscriber Hosts w/o CPE router</ttcol>
<ttcol align="center">CPE router</ttcol>
<ttcol align="center">ISP Access Edge Network</ttcol>
<c>A+P-v4</c>
<c>no change</c>
<c>no change (A+P NAT would be performed by SP)</c>
<c>A+P support</c>
<c>route using destination port</c>
<c>A+P-v6</c>
<c>no change</c>
<c>no change (A+P NAT would be performed by SP)</c>
<c>A+P support</c>
<c>tunnel concentrator</c>
<c>SAM-CPE</c>
<c>no change</c>
<c>(not applicable)</c>
<c>SAM CPE</c>
<c>tunnel concentrator</c>
<c>SAM-host</c>
<c>SAM-host</c>
<c>SAM-host</c>
<c>no change</c>
<c>tunnel concentrator</c>
<c>SAM-HC</c>
<c>SAM support</c>
<c>(not applicable)</c>
<c>SAM CPE internal & external</c>
<c>tunnel concentrator</c>
<c>NAT444</c>
<c>no change</c>
<c>no change</c>
<c>no change</c>
<c>NAT v4v4</c>
<c>DS-Lite router</c>
<c>no change</c>
<c>(not supported; use DS-Lite host)</c>
<c>DS-Lite CPE</c>
<c>NAT v4v4 w/tunnel</c>
<c>DS-Lite host</c>
<c>(not supported; use DS-Lite router)</c>
<c>DS-Lite v6</c>
<c>no change</c>
<c>NAT v4v4 w/tunnel</c>
<c>IVI</c>
<c>move to v6</c>
<c>move to v6</c>
<c>move to v6</c>
<c>IVI + DNS rewriting</c>
<c>NAT6</c>
<c>move to v6</c>
<c>move to v6</c>
<c>move to v6</c>
<c>NAT6</c>
<c>NAT64</c>
<c>move to v6</c>
<c>move to v6</c>
<c>move to v6</c>
<c>NAT64 + DNS rewriting</c>
<c>NAT-PT</c>
<c>move to v6</c>
<c>move to v6</c>
<c>move to v6</c>
<c>NAT-PT + DNS-ALG</c>
<c>sNAT-PT</c>
<c>move to v6</c>
<c>move to v6</c>
<c>move to v6</c>
<c>sNAT-PT + DNS rewriting</c>
<postamble></postamble>
</texttable>
<t>For IPv6 hosts that access the IPv4 Internet, the following table
describes the high-level technologies used by each proposal.</t>
<texttable anchor="table-v6-users" style="all"
title="IPv6 to IPv4 - technologies involved">
<preamble></preamble>
<ttcol align="center">Proposal</ttcol>
<ttcol align="center">ISP's Internal Network</ttcol>
<ttcol align="center">DNS Impact</ttcol>
<ttcol align="center">Carrier Grade NAT</ttcol>
<c>A+P-v4</c>
<c>IPv4 destination port routing</c>
<c>no change</c>
<c>(no CGN, if subscriber's NAT support A+P NAT)</c>
<c>A+P-v6</c>
<c>IPv4/IPv6 tunnel</c>
<c>no change</c>
<c>(no CGN, if subscriber's NAT support A+P NAT)</c>
<c>SAM</c>
<c>IPv4/IPv6 tunnel</c>
<c>no change</c>
<c>(no CGN)</c>
<c>DS-Lite router</c>
<c>IPv4/IPv6 tunnel</c>
<c>no change</c>
<c>IPv4/IPv4</c>
<c>DS-Lite host</c>
<c>IPv4/IPv6 tunnel</c>
<c>no change</c>
<c>IPv4/IPv4</c>
<c>NAT444</c>
<c>(v6 not supported)</c>
<c>(v6 not supported)</c>
<c>(v6 not supported)</c>
<c>IVI</c>
<c>v4 NATted, native v6 address</c>
<c>DNS rewriting</c>
<c>IPv6/IPv4</c>
<c>NAT64</c>
<c>v4 NATted, native v6 address</c>
<c>DNS rewriting</c>
<c>IPv6/IPv4</c>
<c>NAT-PT</c>
<c>v4 NATted, native v6 address</c>
<c>DNS-ALG</c>
<c>IPv6/IPv4</c>
<c>sNAT-PT</c>
<c>v4 NATted, native v6 address</c>
<c>DNS rewriting</c>
<c>IPv6/IPv4</c>
</texttable>
</section>
<section title="IPv4 Hosts Accessing the IPv4 Internet">
<t>The following table compares the five mechanisms that support end
hosts running IPv4 to access the IPv4 Internet: SAM,
Dual-Stack Lite, NAT444.</t>
<texttable anchor="table-v4-users" style="all"
title="IPv4 Hosts Accessing the IPv4 Internet">
<preamble></preamble>
<ttcol align="center">Proposal</ttcol>
<ttcol align="center">CPE router</ttcol>
<ttcol align="center">ISP's Internal Network</ttcol>
<ttcol align="center">Service Provider Equipment</ttcol>
<c>A+P-v4</c>
<c>IPv6 support + A+P NAT44</c>
<c>IPv4 and IPv6</c>
<c>destination port routing</c>
<c>A+P-v6</c>
<c>IPv6 support + IPv4/IPv6 tunnel + A+P NAT44</c>
<c>IPv6</c>
<c>IPv6 tunnel termination</c>
<c>SAM-CPE</c>
<c>IPv6 support + IPv4/IPv6 tunnel + NAT44</c>
<c>IPv6</c>
<c>IPv6 tunnel termination</c>
<c>DS-Lite router</c>
<c>IPv6 support + IPv4/IPv6 tunnel</c>
<c>IPv6</c>
<c>IPv6 tunnel termination, NAT44 (CGN)</c>
<c>DS-Lite host</c>
<c>IPv6 support (if using DS-Lite IPv6 tunneling)</c>
<c>IPv6 (if using DS-Lite IPv6 tunneling)</c>
<c>IPv6 tunnel termination, NAT44</c>
<c>NAT444</c>
<c>no change</c>
<c>multi-realm IPv4</c>
<c>NAT44 (CGN)</c>
</texttable>
<t>The proposals IVI, NAT6, NAT64, NAT-PT, and sNAT-PT are not shown
in table <xref target="table-v4-users"></xref> because those proposals
provide no support for IPv4-only hosts to access the IPv4
Internet.</t>
</section>
<section title="IPv4 Internet Accessing IPv6 hosts">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>sNAT-PT: NAT-PT allows 1:1 mapping from an IPv4 client to an IPv6
server.</t>
</section>
</section>
<section anchor="port-forwarding" title="Port Forwarding">
<t>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.</t>
<t>Due to IPv4 NATs and IPv4 firewalls, some applications use <xref
target="UPnP-IGD"></xref> (e.g., XBox) or <xref
target="I-D.ietf-mmusic-ice">ICE</xref> (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.</t>
<t><list style="empty">
<t>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).</t>
</list></t>
<t><list style="empty">
<t>Note: Extending <xref
target="I-D.cheshire-nat-pmp">NAT-PMP</xref> to support IPv6 could
provide provide static port forwarding and dynamic port forwarding
for IPv4 and IPv6 hosts needing access from IPv4 hosts.</t>
</list></t>
<section title="Static Incoming Ports">
<t>Static incoming ports are used by applications for multiple
sessions. <list style="empty">
<t>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).</t>
</list></t>
<t>Examples of applications that require static incoming ports
include: <list hangIndent="" style="symbols">
<t>HTTP</t>
<t>SMTP (must be on TCP/25)</t>
<t>ssh</t>
<t>BitTorrent</t>
<t>games (of particular note is that XBox uses UPnP IGD)</t>
</list></t>
<t>The solutions proposed for static ports are:<list>
<t>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.</t>
<t>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.</t>
<t>Dual-Stack Lite: none</t>
<t>NAT444: none</t>
<t>IVI: assign IPv6 IVI address to IPv6 hosts that require
incoming IPv4 connections</t>
<t>NAT6: none</t>
<t>NAT64: none</t>
<t>sNAT-PT: assign IPv4 address to IPv6 hosts that require
incoming IPv4 sessions.</t>
</list></t>
</section>
<section title="Dynamic Incoming Ports">
<t>Dynamic incoming ports are, generally, used by applications for a
single session. Examples of applications that require dynamic incoming
ports include: <list style="symbols">
<t>applications that use real-time transport protocol (RTP)<list
style="symbols">
<t>SIP, RTSP, H.323, MGCP, H.248/Megaco</t>
</list></t>
<t>non-passive FTP client</t>
<t>games (of particular note is that XBox uses UPnP IGD)</t>
</list>The solutions proposed for dynamic ports are:<list>
<t>A+P: An ALG can be incorporated into the subscriber's A+P-aware
NAT, as done today with subscriber's NAT44 devices.</t>
<t>SAM-host and SAM-HC: assign a port in the available port
range.</t>
<t>Dual-Stack Lite: none</t>
<t>NAT444: none (although it is reasonable to expect that ALGs, as
they exist in today's IPv4 NATs, might be utilized)</t>
<t>IVI: assign IPv6 IVI address to IPv6 hosts that require
incoming IPv4 connections</t>
<t>NAT6: none</t>
<t>NAT64: applications could be modified to support STUN (for TCP
and UDP) to learn their public IPv4 address and TCP/UDP port.</t>
<t>sNAT-PT: assign IPv4 address to IPv6 hosts that require
incoming IPv4 connections.</t>
</list></t>
</section>
</section>
<section anchor="transport-protocol" title="Transport Protocol Support">
<t>[[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.</t>
</section>
<section title="Analysis with V6OPS's NAT64 Problem Statement">
<t>This section analyzes how each proposal maps to the requirements in
<xref target="I-D.ietf-v6ops-nat64-pb-statement-req"></xref>.</t>
<t>[[Placeholder until <xref
target="I-D.ietf-v6ops-nat64-pb-statement-req"></xref> becomes more
stable.]]</t>
</section>
<section title="Comparison of Proposals with NAT-PT Problems">
<t>The following sections analyze how proposals fare against the
problems caused by <xref target="RFC2766">NAT-PT</xref> as documented in
<xref target="RFC4966"></xref>:</t>
<section title="Issues Unrelated to an DNS-ALG">
<section title="Issues with Protocols Embedding IP Addresses">
<t>NAT6 requires applications to handle NAT6 traversal
themselves.</t>
<t>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
<xref target="port-forwarding"></xref>.</t>
</section>
<section title="NAPT-PT Redirection Issues">
<t>All proposals are silent on this issue.</t>
</section>
<section title="NAT-PT Binding State Decay">
<t>NAT6 and NAT64 discuss binding lifetimes.</t>
<t>The other proposals are silent on this issue.</t>
</section>
<section title="Loss of Information through Incompatible Semantics">
<t>All proposals are silent on this issue.</t>
</section>
<section title="NAT-PT and Fragmentation">
<t>[[NAT64, NAT6, DS-Lite, and IVI all mention fragmentation. Need
to analyze how they differ.]]</t>
</section>
<section title="NAT-PT Interaction with SCTP and Multihoming">
<t>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.</t>
<t>SAM (both SAM-host and SAM-HC) support SCTP.</t>
<t>sNAT-PT explicitly indicates SCTP is out-of-scope.</t>
<t>The other proposals are silent on this issue. All proposals seem
to be considering only TCP, UDP, and ICMP.</t>
</section>
<section title="NAT-PT as a Proxy Correspondent Node for MIPv6">
<t>All proposals are silent on this issue.</t>
</section>
<section title="NAT-PT and Multicast">
<t>IVI can support <xref target="RFC4607">Source-Specific
Multicast</xref> (see Section 7 of <xref
target="I-D.xli-behave-ivi"></xref>).</t>
<t>Dual-Stack Lite does not support multicast.</t>
<t>NAT6 does not specify how it can work with multicast.</t>
<t>In sNAT-PT, multicasting in either direction requires manual mapping.</t>
<t>The other proposals are silent on this issue.</t>
<t><list>
<t>Note: it may be possible for IGMP messages to be propagated
and <xref target="RFC4605">proxied</xref> across their
respective <xref target="RFC5135">NAT device</xref>. More study
on this is needed.</t>
</list></t>
</section>
</section>
<section title="Issues Exacerbated by the Use of DNS-ALG">
<t></t>
<section title="Network Topology Constraints Implied by NAT-PT">
<t>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.</t>
</section>
<section title="Scalability and Single Point of Failure Concerns">
<t>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.</t>
</section>
<section title="Issues with Lack of Address Persistence">
<t>TBD.</t>
</section>
<section title="DoS Attacks on Memory and Address/Port Pool">
<t>A CGN would only allow a certain subscriber to open a certain
number of ports, thereby preventing a single subscriber from DoSing
other subscribers (<xref target="I-D.nishitani-cgn"></xref>, "a CGN
SHOULD limit the number of the CGN external ports").</t>
</section>
</section>
<section title="Issues Directly Related to Use of DNS-ALG">
<t></t>
<section title="Address Selection Issues when Communicating with Dual-Stack End-Hosts">
<t>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.</t>
<t>In <xref target="I-D.bagnulo-behave-nat64"></xref>, <xref
target="RFC2671">EDNS0</xref> 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).</t>
</section>
<section title="Non-Global Validity of Translated RR Records">
<t>TBD.</t>
</section>
<section title="Inappropriate Translation of Responses to A Queries">
<t>sNAT-PT avoids this problem with its stateful DNS proxy.</t>
</section>
<section title="DNS-ALG and Multi-Addressed Nodes">
<t>The additional NAT binding state is not created if the DNS
rewriting and NAT functions are separate. Thus, this problem is
avoided by <xref target="I-D.xli-behave-ivi"></xref>, <xref
target="I-D.bagnulo-behave-nat64"></xref>, and <xref
target="I-D.miyata-v6ops-snatpt"></xref>.</t>
</section>
<section title="Limitations on Deployment of DNS Security Capabilities">
<t>DNSSEC is incompatible with synthesized DNS responses (DNS
rewriting).</t>
<t>NAT64 recommends that DNSSEC-capable IPv6-only hosts use the EDNS
SAS option to ignore synthetic DNS responses. This would allow the
IPv6 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.</t>
<t>No other proposal discusses how it would work with DNSSEC.</t>
<t>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.</t>
</section>
</section>
<section title="Impact on IPv6 Application Development">
<t>TBD.</t>
</section>
</section>
<section anchor="security_considerations" title="Security Considerations">
<section anchor="address-sharing" title="Address Sharing">
<t>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.</t>
<t>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 <xref
target="I-D.nishitani-cgn"></xref> 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, <xref target="RFC2827">ingress
filtering</xref>).</t>
<t>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 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.</t>
</section>
<section title="IPsec Compatibility">
<t>It is well known that <xref target="RFC4302">IPSec AH</xref> does
not work with NAT <xref target="RFC3715"></xref>. However, <xref
target="RFC4303">IPsec ESP</xref> 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
<xref target="RFC3948"></xref>, which
survives well over NATs at the expense of a UDP header (8 bytes).</t>
<t>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).</t>
</section>
</section>
<section title="Acknowledgements">
<t>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).</t>
<t>Thanks to Fred Baker, Randy Bush, Wojciech Dec, Thomas Narten, Dave
Thaler and Eric Vyncke for their review and suggested improvements to
the document.</t>
</section>
<section title="IANA Considerations">
<t>This document has no IANA actions.</t>
</section>
</middle>
<back>
<references title="Normative References">
&I-D.bagnulo-behave-nat64;
&I-D.xli-behave-ivi;
&I-D.baker-behave-ivi;
<reference anchor='I-D.durand-softwire-dual-stack-lite'>
<front>
<title>Dual-stack lite broadband deployments post IPv4 exhaustion</title>
<author initials='A' surname='Durand' fullname='Alain Durand'>
<organization />
</author>
<author initials='R' surname='Droms' fullname='Ralph Droms'>
<organization />
</author>
<author initials='B' surname='Haberman' fullname='Brian Haberman'>
<organization />
</author>
<author initials='J' surname='Woodyatt' fullname='James Woodyatt'>
<organization />
</author>
<date month='September' day='29' year='2008' />
</front>
<seriesInfo name='Internet-Draft'
value='draft-durand-softwire-dual-stack-lite-00' /> <format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-durand-softwire-dual-stack-lite-00.txt' /> </reference>
&I-D.ietf-v6ops-nat64-pb-statement-req;
&I-D.nishitani-cgn;
&I-D.jennings-behave-nat6;
&rfc4966;
&I-D.miyata-v6ops-snatpt;
&I-D.endo-v6ops-dnsproxy;
<reference anchor="A+P"
target="http://mice.cs.columbia.edu/getTechreport.php?techreportID=560">
<front>
<title>A Better Approach than Carrier-Grade-NAT</title>
<author fullname="Olaf Maennel" initials="O." surname="Maennel">
<organization></organization>
</author>
<author fullname="Randy Bush" initials="R." surname="Bush">
<organization></organization>
</author>
<author fullname="Luca Cittadini" initials="L." surname="Cittadini">
<organization></organization>
</author>
<author fullname="Steven M." initials="S." surname="Bellovin">
<organization></organization>
</author>
<date></date>
</front>
</reference>
</references>
<references title="Informative References">
&rfc2765;
&rfc2766;
&I-D.ietf-mmusic-ice;
&rfc4607;
&rfc4213;
&rfc2671;
&I-D.despres-sam;
&I-D.cheshire-nat-pmp;
&rfc4605;
&rfc5135;
&rfc2827;
&rfc4380;
&rfc4925;
&rfc4303;
&rfc4302;
&rfc3715;
&rfc3948;
<reference anchor="Behave"
target="https://www.ietf.org/mailman/listinfo/behave">
<front>
<title>BEHAVE working group mailing list</title>
<author fullname="IETF" surname="IETF">
<organization></organization>
</author>
<date></date>
</front>
</reference>
<reference anchor="Softwires"
target="https://www.ietf.org/mailman/listinfo/softwires">
<front>
<title>Softwires working group mailing list</title>
<author fullname="IETF" surname="IETF">
<organization></organization>
</author>
<date></date>
</front>
</reference>
<reference anchor="UPnP-IGD"
target="http://www.upnp.org/standardizeddcps/igd.asp">
<front>
<title>Universal Plug and Play Internet Gateway Device</title>
<author fullname="UPnP Forum" surname="UPnP Forum">
<organization></organization>
</author>
<date year="2000" />
</front>
</reference>
<reference anchor="v4v6interm-interest"
target="https://www.ietf.org/mailman/listinfo/v4v6interm-interest">
<front>
<title>v4v6interm-interest mailing list</title>
<author fullname="IETF" surname="IETF">
<organization></organization>
</author>
<date></date>
</front>
</reference>
</references>
<section title="Changes">
<section title="Changes from 01 to 02">
<t><list style="symbols">
<t>Updated DS-Lite reference; no changes to text</t>
<t>Updated from APB-Revised to SAM; changed text</t>
<t>Updated sNAT-PT reference; added description of IPv4-to-IPv6 1:N
port mapping</t>
<t>Mentioned policing difficulties for shared
addresses (DHCP snooping, ARP security, ingress filtering)</t>
<t>Discuss IPsec compatibility</t>
<t>Added explanation of how NAT444 can support IPv6 using Teredo</t>
</list></t>
</section>
<section title="Changes from 00 to 01">
<t><list style="symbols">
<t>Added A+P</t>
<t>Refined security considerations for sharing addresses</t>
<t>"CPE" -> "CPE router"</t>
<t>removed NAPT defintion (we use NAT to mean NAPT, as is done
colloquially)</t>
<t>fixed some text and figures for APB-Revised</t>
<t>removed the DNS rewriting function from NAT64's figure showing
IPv6 hosts accessing IPv4 servers.</t>
</list></t>
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 20:48:23 |