One document matched: draft-wing-behave-v4app-v6server-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.saito-mmusic-sdp-ike SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.saito-mmusic-sdp-ike.xml">
<!ENTITY I-D.ietf-sipping-v6-transition SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-v6-transition.xml">
<!ENTITY I-D.ietf-mmusic-media-path-middleboxes SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-media-path-middleboxes.xml">
<!ENTITY I-D.wing-v6ops-v6app-v4server SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-v6ops-v6app-v4server.xml">
<!ENTITY I-D.huang-behave-pnat SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.huang-behave-pnat.xml">
<!ENTITY I-D.ietf-mmusic-rtsp-nat-evaluation SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-rtsp-nat-evaluation.xml">
<!ENTITY I-D.ietf-mmusic-rfc2326bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-rfc2326bis.xml">
<!ENTITY I-D.ietf-mmusic-rtsp-nat SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-rtsp-nat.xml">
<!ENTITY I-D.ietf-behave-v6v4-xlate-stateful SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-v6v4-xlate-stateful.xml">
<!ENTITY I-D.huang-behave-rfc3338bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.huang-behave-rfc3338bis.xml">
<!ENTITY I-D.huang-behave-rfc2767bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.huang-behave-rfc2767bis.xml">
<!ENTITY I-D.vogt-durand-virtual-ip6-connectivity SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vogt-durand-virtual-ip6-connectivity.xml">
<!ENTITY I-D.van-beijnum-behave-ftp64 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.van-beijnum-behave-ftp64.xml">
<!ENTITY I-D.boucadair-port-range SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.boucadair-port-range.xml">
<!ENTITY I-D.ymbk-aplusp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ymbk-aplusp.xml">
<!ENTITY I-D.ietf-softwire-dual-stack-lite SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-dual-stack-lite.xml">
<!ENTITY I-D.ietf-mmusic-ice SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-ice.xml">
<!ENTITY rfc3484 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml">
<!ENTITY rfc3920 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3920.xml">
<!ENTITY I-D.ietf-sip-sips SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-sips.xml">
<!ENTITY rfc4217 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4217.xml">
<!ENTITY rfc4380 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml">
<!ENTITY rfc5389 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5389.xml">
<!ENTITY rfc2326 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2326.xml">
<!ENTITY rfc3947 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3947.xml">
<!ENTITY rfc3715 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3715.xml">
<!ENTITY I-D.ietf-geopriv-held-identity-extensions SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-held-identity-extensions.xml">
<!ENTITY rfc2428 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2428.xml">
<!ENTITY rfc4409 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4409.xml">
<!ENTITY rfc3501 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3501.xml">
<!ENTITY rfc1939 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1939.xml">
<!ENTITY xml2rfcversion SYSTEM "/xml2rfc/version.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-behave-v4app-v6server-01"
ipr="trust200902">
<front>
<title abbrev="Concerns with v4 Apps to v6 Servers">Concerns with IPv4
Applications Accessing IPv6 Servers (NAT46)</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="Cameron Byrne" initials="C." surname="Byrne">
<organization abbrev="T-Mobile USA">T-Mobile USA, Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>cameron.byrne@t-mobile.com</email>
</address>
</author>
<date year="2010" />
<workgroup>BEHAVE Working Group</workgroup>
<abstract>
<t>Bump-in-the-Stack and Bump-in-the-API allow IPv4 applications to
access IPv6 servers, using an in-host NAT46 translator. When used in
conjunction with an in-network NAT64, it is also possible for the IPv4
application to access an IPv4 server via an IPv6-only network. This
document describes how these functions work in detail, and discusses
some concerns especially around IPv4 applications accessing IPv6
servers. These concerns can be reduced by not having IPv4 applications
access IPv6 servers.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>As IPv6 is introduced to networks it is desirable that existing IPv4
applications continue to function across native IPv6-only networks.
However, due to exhaustion of IPv4 address space, it is not possible to
provide a publicly-routable IPv4 address to every host. Thus, some form
of IPv4 address multiplexing is necessary. There are several proposals
to accomplish this multiplexing in combination with IPv6 (<xref
target="I-D.ietf-softwire-dual-stack-lite"></xref>, <xref
target="I-D.ymbk-aplusp"></xref>, <xref
target="I-D.boucadair-port-range"></xref>). All of these proposals
expect the applications and host to use IPv4 to communicate with other
IPv4 hosts and to use IPv6 to communicate with other IPv6 hosts. With
these techniques, the host sends and receives IPv4 packets and IPv6
packets on the wire, which are tunneled by some of the techniques.</t>
<t>Two approaches have been proposed which perform IPv4 to IPv6
translation. Both approaches have similar needs for ALG assistance to
support protocols which contain IP addresses in their payloads (e.g.,
FTP, SIP, XMPP). One approach does translation in the host <xref
target="I-D.huang-behave-pnat"> </xref> by extending existing in-host
translation Bump-in-the-API ("BIA", <xref
target="I-D.huang-behave-rfc3338bis"></xref>) or Bump-in-the-Stack
("BIS", <xref target="I-D.huang-behave-rfc2767bis"></xref>), and uses an
in-network stateful NAT64 access IPv4 servers. The other approach, <xref
target="I-D.vogt-durand-virtual-ip6-connectivity">Virtual IPv6
Connectivity</xref>, does DNS manipulation and translation in a CPE
device, external from the IPv4 host. Virtual IPv6 Connectivity is not
studied in detail in this document.</t>
<t>PNAT provides two features for IPv4 applications, which are analyzed
in detail in the sections below: <list style="symbols">
<t>access IPv4 servers over an IPv6-only access network. This
achieves the same end result as the dual-stack approaches listed in
the previous paragraph. PNAT provides this function by doing NAT464.
NAT464 is realized by a combination of NAT46 in the host (achieved
by extensions to BIA/BIS) and an in-network stateful NAT64 <xref
target="I-D.ietf-behave-v6v4-xlate-stateful"></xref> to translate
the IPv6 packets back to IPv4 packets.</t>
<t>access IPv6 servers (or dual-stack servers) over an IPv6-only
access network. This is realized by a NAT46 function in the host
(achieved by extensions to BIA/BIS). The NAT46 function provides a
unique advantage, in that IPv4 applications are immediately able to
connect to IPv6 servers. However, it also raises some concerns
described below.</t>
</list></t>
</section>
<section title="PNAT Walk-Through">
<section title="FTP">
<t>This section details the operation of PNAT, using an IPv4-only FTP
client application. PNAT is a system that combines extensions to
BIA/BIS in the host and (when necessary to access an IPv4 server) an
in-network stateful NAT64.</t>
<t>In some of the following scenarios, the BIA/BIS function in the
host needs to create artificial IPv4 addresses in order to access IPv6
servers. These IPv4 addresses are never exposed outside of the host.
To clarify the examples, this document assumes the network
10.127.0.0/16 is used for these artificial IPv4 addresses.</t>
<t>These walk-throughs detail how outgoing and incoming connections
are handled with BIA/BIS when IP addresses are contained in
application payloads. FTP is a simple, well-understood protocol which
supports both outgoing data connections (passive mode) and incoming
data connections (active mode), both of which require communicating IP
addresses and TCP ports in the application payload. FTP is a good
example because its data connection can be outgoing (from the client)
or incoming (to the client), and FTP is sensitive to the IP address
family (PASV is needed with IPv4; EPSV with IPv6). The servers can be
in another host ("peer to peer"), inside the operator's network, or on
the Internet.</t>
<t>The following table summarizes the notes in the subsequent
sections:</t>
<texttable anchor="table_ftp_summary"
title="Summary of PNAT Walk-Through">
<preamble></preamble>
<ttcol align="center">Direction</ttcol>
<ttcol align="center">Server</ttcol>
<ttcol align="center">result</ttcol>
<ttcol align="center">in-host ALG</ttcol>
<ttcol align="center">in-network ALG</ttcol>
<c>Outgoing</c>
<c>IPv4</c>
<c>succeed</c>
<c>no</c>
<c>no</c>
<c>Outgoing</c>
<c>IPv6</c>
<c>fail</c>
<c>no</c>
<c>no</c>
<c>Outgoing</c>
<c>dual-stack</c>
<c>fail</c>
<c>no</c>
<c>no</c>
<c>Incoming</c>
<c>IPv4</c>
<c>succeed</c>
<c>required</c>
<c>required</c>
<c>Incoming</c>
<c>IPv6</c>
<c>succeed</c>
<c>required</c>
<c>no</c>
<c>Incoming</c>
<c>dual-stack</c>
<c>succeed</c>
<c>required</c>
<c>no</c>
<postamble></postamble>
</texttable>
<section title="Outgoing Connection: FTP Passive Mode">
<t>This demonstrates how an outgoing connection is performed with
BIA/BIS with an application containing an IP address in the
application payload.</t>
<t>Passive mode FTP causes the FTP data connection to be initiated
by the FTP client. Passive mode FTP is necessary to operate behind
NATs (or firewalls) that lack an FTP-aware ALG in the NAT (or
firewall). FTP passive mode is the default for many standalone FTP
clients (e.g., WS_FTP Pro) and all major web browsers (e.g.,
Internet Explorer, Firefox, Safari, Opera).</t>
<section anchor="ipv4-to-ipv4"
title="IPv4 Application to IPv4 Server (NAT464)">
<t>An IPv4-only FTP application wants to connect to an FTP server
at ftp.example.com, which has the IPv4 address 192.0.2.1 and an A
record, and no IPv6 address and no AAAA record.</t>
<figure align="center" anchor="ftp-4-4"
title="FTP, IPv4 client to IPv4 server (FTP passive mode)">
<artwork><![CDATA[
+-----------------+ +---------+
|IPv4 FTP +------| < IPv6 > +-----+- < IPv4 > |IPv4 FTP |
| client | HBT +-<network>--|NAT64| -<network>--+ server |
| using | | +-----+ +---------+
| PASV | |
+----------+------+ ]]></artwork>
</figure>
<t>The IPv4 FTP application does a gethostaddr() call for
ftp.example.com. This is intercepted by the BIA/BIS in the host,
and converted to an AAAA query and sent to the DNS server and
receives 'no such host' as the response. This causes the BIA/BIS
in the host to send an A query to the DNS server and receive
192.0.2.1 as the response. This address is returned to the
application's gethostaddr() call. The FTP application then opens a
TCP connection to 192.0.2.1, which is intercepted by BIA/BIS in
the host which adds the necessary IPv6 prefix for the in-network
NAT64 device, and sends the IPv6 packet towards that address. The
in-network NAT64 translates the packet to IPv4 and sends it to
192.0.2.1. The TCP connection is established and the FTP client
logs into the FTP server. After login, the FTP client sends the
PASV command prior to its data transfer command. The IPv4 FTP
server responds to the PASV command with its IPv4 address and the
TCP port for the incoming data connection. The FTP client connects
to that IPv4 address and port, which is intercepted by BIA/BIS in
the host which adds the necessary IPv6 prefix for the in-network
NAT64 device, and sends the IPv6 packet towards that address. The
in-network NAT64 translates the packet to IPv4 and sends it to the
FTP server.</t>
<t>Notes:<list style="symbols">
<t>This scenario is transparent to the application.</t>
<t>No Application-Layer Gateway (ALG) is needed.</t>
<t>A requirement is that both the FTP control channel and the
FTP data channel use the same NAT64, so that the IPv4 FTP
server sees both connections coming from the same IPv4
address. This is trivially accomplished, as the IPv6 prefix --
which selects the NAT64 for this host -- is implemented inside
the host's BIA/BIS function.</t>
<t>The BIA/BIS function creates no additional state in the
host for any of the IPv4/IPv6 mappings; the mappings are
entirely algorithmic. Also note that a DNS query is not
required for the BIA/BIS function to work.</t>
</list></t>
</section>
<section anchor="ipv4-to-v6-only"
title="IPv4 Application to IPv6 Server (NAT46)">
<t>An IPv4-only FTP application wants to connect to an FTP server
at ftp.example.com, which has the IPv6 address 2001:DB8::1 and an
AAAA record, and no IPv4 address and no A record.</t>
<figure align="center" anchor="ftp-4-6"
title="FTP, IPv4 client to IPv6-only server (FTP passive mode)">
<artwork><![CDATA[
+-----------------+ +---------+
|IPv4 FTP +------| < IPv6 > |IPv6 FTP |
| client | HBT +-<network>--| server |
| using |w/FTP | +---------+
| PASV | ALG |
+----------+------+ ]]></artwork>
</figure>
<t></t>
<t>The IPv4 FTP application does a gethostaddr() call for
ftp.example.com. This is intercepted by the BIA/BIS in the host,
and converted to an AAAA query and sent to the DNS server and
receives 2001:DB8::1 as the response. The BIA/BIS in the host
creates an artificial IPv4 address, 10.127.0.1, and a mapping
between that artificial address and the IPv6 address. The
artificial address 10.127.0.1 is returned to the application's
gethostaddr() call. The FTP application then opens a TCP
connection to 10.127.0.1, which is intercepted by BIA/BIS in the
host and maps this to the IPv6 address 2001:DB8::1 and sends the
IPv6 packet towards that address. The TCP connection is
established and the FTP client logs into the FTP server. After
login, the FTP client sends the PASV command prior to its data
transfer command. The IPv6 FTP server cannot send a useful
response to the PASV command, because the PASV response can only
indicate an IPv4 address.</t>
<t>Notes:<list style="symbols">
<t>Not transparent to application.</t>
<t>This scenario needs an FTP ALG in the host</t>
<t>There is no in-network translation, and there is no need
for in-network ALG.</t>
<t>The BIA/BIS function creates additional state in the host
for the IPv4/IPv6 mappings.</t>
</list></t>
</section>
<section anchor="ipv4-to-dual-stack"
title="IPv4 Application to Dual-Stack Server (NAT46)">
<t>An IPv4-only FTP application wants to connect to an FTP server
at ftp.example.com, which has the IPv4 address 192.0.2.1 and A
record, and the IPv6 address 2001:DB8::1 and AAAA record.</t>
<figure align="center" anchor="ftp-4-6-second"
title="FTP, IPv4 client to dual-stack server (FTP passive mode)">
<artwork><![CDATA[
+-----------------+ +--------------+
|IPv4 FTP +------| < IPv6 > |dual-stack FTP|
| client | HBT +-<network>--| server |
| using |w/FTP | +--------------+
| PASV | ALG |
+----------+------+ ]]></artwork>
</figure>
<t></t>
<t>The IPv4 FTP application does a gethostaddr() call for
ftp.example.com. This is intercepted by the BIA/BIS in the host,
and converted to an AAAA query and sent to the DNS server and
receives 2001:DB8::1 as the response. From this point forward, the
behavior is exactly the same as the previous section, <xref
target="ipv4-to-v6-only"></xref>, and has the same requirement for
an in-host FTP ALG.</t>
<t>Notes:<list style="symbols">
<t>The same Notes from <xref target="ipv4-to-v6-only"></xref>,
above, apply to this scenario.</t>
<t>This walk-through assumes the application and the host
stack both prefer IPv6 over IPv4, which is the default (<xref
target="RFC3484"></xref>).</t>
</list></t>
</section>
</section>
<section title="Incoming connection: FTP Active Mode">
<t>This demonstrates how an incoming connection is performed with
BIA/BIS with an application containing an IP address in the
application payload.</t>
<t>Active mode FTP is the 'normal' mechanism popular before the
widespread deployment of IPv4 NATs and firewalls. In this mode, the
data connection is initiated from the FTP server back to the FTP
client. For this to work when the client is behind a typical IPv4
NAT (NAT44) or a typical firewall, the NAT (or firewall) needs to
implement an FTP-aware ALG, so that when the FTP client sends its
PORT command (containing the FTP client's TCP port), the ALG can
perform the necessary functions. If a NAT, the necessary ALG
functions are to map the internal TCP port to an external TCP port
and rewrite the FTP command to contain the that newly-mapped port.
If a firewall ALG, the necessary ALG function is to create a
temporary permission for the incoming TCP connection.</t>
<section title="IPv4 Application to IPv4 Server (NAT464)">
<t>An IPv4-only FTP application wants to connect to an FTP server
at ftp.example.com, which has the IPv4 address 192.0.2.1 and an A
record, and no IPv6 address and no AAAA record.</t>
<figure align="center" anchor="ftp-4-4-active"
title="FTP, IPv4 client to IPv4 server (FTP active mode)">
<artwork><![CDATA[
+-----------------+ +---------+
|IPv4 FTP +------| < IPv6 > +-----+- < IPv4 > |IPv4 FTP |
| client | HBT +-<network>--|NAT64| -<network>--+ server |
| using | | +-----+ +---------+
| PASV | |
+----------+------+ ]]></artwork>
</figure>
<t>The IPv4 FTP application does a gethostaddr() call for
ftp.example.com. This is intercepted by the BIA/BIS in the host,
and converted to an AAAA query and sent to the DNS server and
receives 'no such host' as the response. This causes the BIA/BIS
in the host to send an A query to the DNS server and receive
192.0.2.1 as the response. This address is returned to the
application's gethostaddr() call. The FTP application then opens a
TCP connection to 192.0.2.1, which is intercepted by BIA/BIS in
the host which notices the TCP connection is to the FTP control
port (TCP port 21) and activates its FTP-aware ALG function. The
BIA/BIS in the host adds the necessary IPv6 prefix for the
in-network NAT64 device, and sends the IPv6 packet towards that
address. The FTP ALG in the in-network NAT64 notices the packet is
to the FTP control port (TCP port 21) and activates its FTP ALG
function. The in-network NAT64 translates the packet to IPv4 and
sends it to 192.0.2.1. The TCP connection is established with the
FTP server and the FTP client logs into the FTP server. After
login, the FTP client wants to accept an incoming connection for a
data transfer. It begins listening on a TCP port, and sends the
PORT command which indicates its own IPv4 address and the TCP port
it is listening on. The FTP-aware ALG in the host modifies the FTP
control packet to contain the host's IPv6 address, and sends it.
The FTP-aware ALG in the in-network NAT64 sees the PORT command
and creates a mapping from a public TCP port to the IPv6 address
and TCP port, and modifies the FTP control packet to contain the
public IPv4 address of the NAT64 and that newly-mapped TCP port,
and sends it to the FTP server. The FTP server initiates a TCP
connection to the listening port and the data transfer is
successful.</t>
<t>Notes:<list style="symbols">
<t>As with NAT44, this requires an Application Layer
Gateway.</t>
<t>Two Application Layer Gateways are necessary - one in the
host (to modify the FTP command from containing IPv4 to
containing IPv6) and another in the in-network NAT64 (to
create the necessary TCP mapping on the NAT64, and to modify
the FTP command to contain the NAT64's public IPv4 address and
that newly-mapped TCP port).s</t>
<t>A requirement is that both the FTP control channel and the
FTP data channel use the same NAT64, so that the IPv4 FTP
server sees both connections coming from the same IPv4
address. This is trivially accomplished, as the IPv6 prefix --
which selects the NAT64 for this host -- is implemented inside
the host's BIA/BIS function.</t>
<t>The BIA/BIS function creates no additional state in the
host for any of the IPv4/IPv6 mappings; the mappings are
entirely algorithmic. Also note that a DNS query is not
required for the BIA/BIS function to work.</t>
</list></t>
</section>
<section anchor="active_ftp_ipv4-to-v6-only"
title="IPv4 Application to IPv6-only Server (NAT46)">
<t>An IPv4-only FTP application wants to connect to an FTP server
at ftp.example.com, which has the IPv6 address 2001:DB8::1 and an
AAAA record. It has no IPv4 address and no A record.</t>
<figure align="center" anchor="ftp-4-6-second-active"
title="FTP, IPv4 client to IPv6-only server (FTP active mode)">
<artwork><![CDATA[
+-----------------+ +---------+
|IPv4 FTP +------| < IPv6 > |IPv6 FTP |
| client | HBT +-<network>--| server |
| using |w/FTP | +---------+
| PASV | ALG |
+----------+------+ ]]></artwork>
</figure>
<t>The IPv4 FTP application does a gethostaddr() call for
ftp.example.com. This is intercepted by the BIA/BIS in the host,
and converted to an AAAA query and sent to the DNS server and
receives 2001:DB8::1 as the response. The BIA/BIS in the host
creates an artificial IPv4 address, 10.127.0.1, and a mapping
between that artificial address and the IPv6 address. The
artificial address 10.127.0.1 is returned to the application's
gethostaddr() call. The FTP application then opens a TCP
connection to 10.127.0.1 which is intercepted by BIA/BIS in the
host which notices the TCP connection is to the FTP control port
(TCP port 21) and activates its FTP-aware ALG function. The
BIA/BIS in the host maps the TCP connection to 2001:DB8::1 and
sends the IPv6 packet towards this address. The TCP connection is
established and the FTP client logs into the FTP server. After
login, the FTP client wants to accept an incoming connection for a
data transfer. It begins listening on a TCP port, and sends the
PORT command which indicates its own IPv4 address and the TCP port
it is listening on. The FTP-aware ALG in the host intercepts this
information, and changes the PORT command to EPRT <xref
target="RFC2428"></xref> containing the host's IPv6 address and
the listening TCP port, and sends it to 2001:DB8::1. The FTP
server initiates a TCP connection to the listening port and the
data transfer is successful.</t>
<t>Notes:<list style="symbols">
<t>As with NAT44, this requires an Application Layer Gateway
(ALG).</t>
<t>One ALG is necessary in the host.</t>
</list></t>
</section>
<section title="IPv4 Application to Dual-Stack Server (NAT46)">
<t>An IPv4-only FTP application wants to connect to an FTP server
at ftp.example.com, which has the IPv4 address 192.0.2.1 an A
record, and the IPv6 address 2001:DB8::1 and AAAA record.</t>
<figure align="center" anchor="ftp-4-6-active"
title="FTP, IPv4 client to dual-stack server (FTP active mode)">
<artwork><![CDATA[
+-----------------+ +--------------+
|IPv4 FTP +------| < IPv6 > |dual-stack FTP|
| client | HBT +-<network>--| server |
| using |w/FTP | +--------------+
| PASV | ALG |
+----------+------+ ]]></artwork>
</figure>
<t>The IPv4 FTP application does a gethostaddr() call for
ftp.example.com. This is intercepted by the BIA/BIS in the host,
and converted to an AAAA query and sent to the DNS server and
receives 2001:DB8::1 as the response. From this point forward, the
behavior is exactly the same as the previous section, <xref
target="active_ftp_ipv4-to-v6-only"></xref>, and also
succeeds.</t>
<t>Notes:<list style="symbols">
<t>The same Notes from <xref target="ipv4-to-v6-only"></xref>
apply to this scenario.</t>
<t>This walk-through assumes the application and the host
stack both prefer IPv6 over IPv4, which is the default (<xref
target="RFC3484"></xref>).</t>
</list></t>
</section>
</section>
</section>
<section title="RTSP">
<t>Real Time Streaming Protocol (<xref target="RFC2326">RTSP</xref>)
is most commonly used to stream unicast or multicast RTP media from a
server to a client. RTSP encodes information about the media stream
into SDP such as the codec, and information about IP address and port
of the media stream into RTSP's transport headers. Many existing ALGs,
shipping in NATs today, modify these payloads.</t>
<t>However, <xref target="I-D.ietf-mmusic-rfc2326bis">RTSP 2.0</xref>
includes NAT traversal built into the RTSP client and RTSP server
itself <xref target="I-D.ietf-mmusic-rtsp-nat"></xref> which uses a
technique derived from <xref target="I-D.ietf-mmusic-ice">ICE</xref>.
An ALG that mistakenly interferes with these components of RTSP
signaling will cause failure of the RTSP setup, as discussed in
Section 4.1.5 of <xref
target="I-D.ietf-mmusic-rtsp-nat-evaluation"></xref> but the
mitigation suggested in that document (encrypting RTSP signaling) also
means both in-host and in-network RTSP ALGs cannot be used, as
discussed in <xref target="encryption"></xref>. The general concern of
ALG interference with application evolution discussed in <xref
target="evolution"></xref>.</t>
<section title="IPv4 Client to IPv4 Server (peer to peer)">
<t>An IPv4 RTSP client might want to stream data from an IPv4
server, located on the same network -- that is, peer-to-peer. With
host-based translation, both of the IPv4 clients would believe they
are communicating with IPv4-based servers, but their traffic is
translated to IPv6 over the network. This is depicted in the
following figure.</t>
<figure align="center" anchor="rtsp-4-4-peerpeer"
title="RTSP, IPv4 client to IPv4 server (peer to peer)">
<artwork><![CDATA[
+-----------------+ +-----------------+
|IPv4 RTSP +------| |------+ IPv4 RTSP|
| client | HBT +--<IPv6 network>--+HBT | server |
| |w/RTSP| |w/RTSP| |
| | ALG | |ALG | |
+----------+------+ +------+----------+]]></artwork>
</figure>
<t>To accomplish this, both hosts need an RTSP ALG between IPv4 RTSP
messages and IPv6 RTSP messages. This is because they are in
different IPv4 address domains and their IPv4 addresses may overlap.
The host operating as an RTSP client uses an IPv4-to-IPv6 ALG, which
rewrites the RTSP signaling messages from IPv4 to IPv6. The host
operating as the RTSP server uses an IPv6-to-IPv4 ALG, which
rewrites the RTSP signaling messages from IPv6 to IPv4.</t>
<t>The hosts can avoid an in-network ALG if they realize the
communication is with a peer that has an integrated RTSP ALG; this
might be accomplished, for example, by assuming all IPv6 hosts with
a certain IPv6 prefix have an integrated RTSP ALG, which would be
somehow configured into the host-based ALG.</t>
</section>
<section anchor="rtsp_internet"
title="IPv4 client to IPv4 Server (client/server)">
<t>An IPv4 RTSP client might want to stream data from an IPv4 RTSP
server on an IPv4 network, as depicted in the following figure.</t>
<figure align="center" anchor="rtsp-4-4-clientserver"
title="RTSP, IPv4 client to IPv4 server (client/server)">
<artwork><![CDATA[
+-----------------+ +-----+ +---------+
|IPv4 RTSP +------| < IPv6 > +NAT64+- < IPv4 > |IPv4 RTSP|
| client | HBT +-<network>--| with| -<network>--+ server |
| |w/RTSP| | RTSP| +---------+
| | ALG | | ALG |
+----------+------+ +-----+]]></artwork>
</figure>
<t>To accomplish this, both the IPv4 RTSP client and the network
need an RTSP ALG. This is because the IPv4-only RTSP application
only understands IPv4 addresses, the IPv6 network only routes IPv6
packets, and the IPv4-only RTSP server only understands IPv4
addresses. The host implements an IPv4-to-IPv6 ALG, which rewrites
the RTSP signaling messages from IPv4 to IPv6. The in-network RTSP
ALG, implemented in conjunction with the network's NAT64 device,
rewrites the RTSP signaling messages from IPv6 to IPv4.</t>
</section>
<section title="IPv4 Client to IPv6 Server">
<t>An IPv4 RTSP client might want to stream data from an IPv6
server, as depicted in the following figure.</t>
<figure align="center" anchor="rtsp-4-6"
title="RTSP, IPv4 client to IPv6 server">
<artwork><![CDATA[+-----------------+ +---------+
|IPv4 RTSP +------| < IPv6 > |IPv6 RTSP|
| client | HBT +-<network>--+ server |
| |w/RTSP| +---------+
| | ALG |
+----------+------+]]></artwork>
</figure>
<t>To accomplish this, the IPv4 host needs an RTSP ALG, because it
won't understand the IPv6 addresses provided by the IPv6 RTSP
server.</t>
</section>
</section>
<section title="XMPP">
<t>Extensible Messaging and Presence Protocol (<xref
target="RFC3920">XMPP</xref>) is commonly used for text-based chat. In
addition to text-based chat, XMPP also supports voice and video which
is signaled using XMPP extensions <xref target="ICE-UDP"></xref>. This
evolution of XMPP to include voice and video requires either (a)
host-based XMPP-aware ALGs and in-network XMPP-aware ALGs are
deployed, or (b) XMPP clients are updated to natively support IPv6 and
support network-based NAT64 translation (e.g., by supporting <xref
target="I-D.wing-v6ops-v6app-v4server"></xref> so that XMPP-aware ALGs
would be unnecessary). A difficulty with achieving (a), above, is that
XMPP clients routinely use TLS to encrypt traffic to their XMPP
servers because text chat messages are often considered confidential,
which renders ALGs impossible to deploy with XMPP.</t>
<t>These problems prevent an IPv4-only XMPP application from being
transparently translated from IPv4 to IPv6 and successfully use voice
or video chat. Instead, the XMPP application has to support IPv6 and
has to support NAT64 translation to communicate with IPv4 XMPP
peers.</t>
</section>
<section title="IPsec">
<t>Many residential-grade NATs implement "IPsec Passthru" for a
variety of reasons. These create a variety of problems <xref
target="RFC3715"></xref>, but some of the problems are masked if only
one IPsec association to a specific VPN concentrator -- as is common
for Internet access from a coffee shop or hotel. However, when a large
NAT serves a larger community of users it becomes more difficult or
impossible to mask the deficiencies of IPsec Passthru. Thus, a NAT64
with many IPsec associations, especially to the same VPN concentrator,
will fail sessions whereas dozens of low-end NAT devices, with the
same number of IPsec associations, will fare better. This is discussed
in detail in Section 4.1 of <xref target="RFC3715"></xref>.</t>
<t>Thus, in a large NAT environment, IPsec applications will need to
use <xref target="RFC3947">IPsec-over-UDP</xref> rather than
IPsec-over-IP (protocol 50) and relying on IPsec Passthru. This is not
unique to v4 applications contacting v6 servers, but it does mean that
IPsec cannot enjoy transparent translation from IPv4 to IPv6 to IPv4;
it has to run over UDP.</t>
<t>Traditionally, IPsec is used purely in client/server scenarios for
corporate PCs to connect to a VPN concentrator. However, deployments
of Windows 7's DirectAccess and OSX's Back-to-My-Mac service, and of
<xref target="I-D.saito-mmusic-sdp-ike">peer-to-peer IPsec</xref>
(which standardizes a similar mechanism), means use of IPsec is likely
to increase in peer-to-peer scenarios.</t>
</section>
<section title="SIP">
<t>Most SIP networks deploy SBCs to assist with IPv4 NAT traversal
("media latching", described in Section 5 of <xref
target="I-D.ietf-mmusic-media-path-middleboxes"></xref>), IPv6/IPv4
interworking, protection of the service provider's network, and
peering between service providers. When used with an SBC, a SIP
endpoint works fine with in-host translation, as shown in the figure
below.</t>
<figure align="center">
<artwork><![CDATA[+-------------+ +---------+
|IPv4 SIP +---+ < IPv6 > +---+ < IPv4 > |IPv4 SIP |
|endpoint |HBT+--<network>--+SBC+--<network>--+ endpoint|
+---------+---+ +---+ +---------+]]></artwork>
</figure>
<t>However, if an SBC is not present, the IPv4-only SIP endpoint would
need its SIP peer to support ICE <xref
target="I-D.ietf-sipping-v6-transition"></xref>, as shown in the
figure below.</t>
<figure>
<artwork><![CDATA[+-------------+ +---------+
|IPv4 SIP +---+ < IPv6 > +-----+ < IPv4 > |IPv4 SIP |
|endpoint |HBT+--<network>--+NAT64+--<network>--+ endpoint|
+---------+---+ +-----+ | w/ ICE |
+---------+]]></artwork>
</figure>
</section>
<section title="email protocols (SMTP, IMAP, POP)">
<t><xref target="RFC4409">SMTP Submission</xref>, <xref
target="RFC3501">IMAP</xref>, and <xref target="RFC1939">POP3</xref>
are client-initiated protocols and do not contain IP addresses in
their payload (except Received: header fields which are only used for
troubleshooting). These protocols work fine with in-host translation.
Similarly, supporting IPv6 natively in these application is a trivial
change, as they are typically configured with a hostname within the
host's mail application. HTML rendering by IMAP and POP clients,
especially of external objects, does require more effort in the mail
client, almost on par with HTTP. However, all major mail clients
(e.g., Outlook, Thunderbird, mail.app) already support IPv6 including
their HTML renderers.</t>
</section>
<section anchor="http" title="HTTP">
<t>HTTP is a client-initiated protocol. When an IPv4 address literals
are contained within the URI, or within a page (such as in Javascript
or used by a plug-in), the IPv4 server can still be accessed (because
the host-based translator knows how to convert an IPv4 address into a
corresponding IPv6 address).</t>
<t>An HTTP client is more difficult to update to support IPv6
natively. However, all major web browsers have supported IPv6 natively
(Internet Explorer, Firefox, Safari, Opera) for years. Thus, native
IPv6 support by HTTP clients has already been achieved and there is no
need to expect HTTP clients are IPv4-only.</t>
</section>
</section>
<section title="Concerns">
<section title="Interference with IPv6 Deployment">
<t>We assume that BIA/BIS prefer IPv6 addresses over IPv4 addresses,
as is common today <xref target="RFC3484"></xref>. With BIA/BIS, a
client application will experience new behavior as soon as its server
adds an AAAA record. The addition of an AAAA record changes the
operation from NAT464 (IPv4 application accessing an IPv4 server) to
NAT46 (IPv4 application accessing an IPv6 server). This new behavior
occurs no matter if an ALG is necessary for that application or not.
But the new behavior is even more severe if an ALG is necessary. This
means if a server on the Internet adds an AAAA record it may cause
existing IPv4 applications to break if an ALG is necessary for those
applications (see also <xref target="alg"></xref>).</t>
<t>By comparison, if a dual-stack or IPv6-only with in-network NAT64
approach (<xref target="I-D.ietf-softwire-dual-stack-lite"></xref>,
<xref target="I-D.ymbk-aplusp"></xref>, <xref
target="I-D.boucadair-port-range"></xref>) is used, adding an AAAA
record to a server does not adversely affect existing IPv4 host
applications. Dual-stack approaches allow a smoother upgrade to IPv6,
because AAAA records are only used by IPv6-aware applications running
on IPv6-capable hosts connected to IPv6-capable networks.</t>
</section>
<section title="Troubleshooting">
<t>The in-host interaction of BIA/BIS, and the in-host ALG necessary
for some scenarios with some applications, requires accessing
information in the host regarding the state and operation of BIA/BIS
and the ALG. This increases the complexity of troubleshooting for the
network operator compared with the common approach of capturing and
analyzing traffic traversing the network. Beyond troubleshooting
historically problematic ALGs, fixing the host-based ALG may require
software changes to potentially millions of end-points.</t>
</section>
<section anchor="alg" title="Application Layer Gateways">
<section title="Standardization">
<t>There are implementations of a ALGs for a wide variety of
protocols for IPv4 to IPv4 translation. However, NAT464 needs an
IPv4 to IPv6 ALG. As demonstrated by April 2009 survey of EPSV
support on the Internet (Section 1 of <xref
target="I-D.van-beijnum-behave-ftp64"></xref>), IPv4/IPv6 ALGs are
more difficult than anticipated for even a simple and
long-established protocol such as FTP.</t>
<t>To date, only one detailed specification exists to describe the
function of an ALG <xref
target="I-D.van-beijnum-behave-ftp64"></xref> for IPv6 clients to
access IPv4 servers. Yet for BIA/BIS to be successfully deployed
with IPv6 servers, the opposite will need to be specified (IPv4
client accessing an IPv6 server). Furthermore, an ALG will need to
be standardized for every protocol that exchanges IP addresses in
its payload, including applications such as (but not limited to)
active-mode FTP44, passive mode FTP64 (work in progress, <xref
target="I-D.van-beijnum-behave-ftp64"></xref>), H.323, <xref
target="I-D.ietf-geopriv-held-identity-extensions">HELD</xref>,
RTSP, RTSPv2 (see Note, below), SAP, SIP (see Note, below), PPTP,
IPsec, and XMPP. <list style="empty">
<t>Note: Although some protocols include their own advanced NAT
traversal mechanisms (e.g., SIP can use <xref
target="I-D.ietf-mmusic-ice"></xref>, RTSPv2 can use <xref
target="I-D.ietf-mmusic-rtsp-nat"></xref>, H.325 has some NAT
traversal mechanisms), it is impossible to know if the IPv4
application running on the host implements those advanced NAT
traversal mechanisms. Thus, ALGs for protocols running on the
same port are probably still necessary.</t>
</list></t>
</section>
<section anchor="evolution"
title="Interference with Application Evolution">
<t>An ALG can interfere in undesirable ways with enhancements to
applications. For example, both Teredo (Section 3.1 of <xref
target="RFC4380"></xref>) and STUN (Section 15.2 of <xref
target="RFC5389"></xref>) needed to explicitly encode their
application payloads to avoid overly-ambitious ALGs. Thus, careful
standardization, design, and implementation of ALG behavior is
critical or else ALGs will interfere with applications. Even so,
experience demonstrates that it is unlikely that all interference
with applications can be avoided; a quick search using your favorite
search engine for "SIP ALG disable" will yield a treasure trove of
industry experience with a protocol that embeds IP addresses in its
payloads.</t>
</section>
<section anchor="encryption" title="Encrypted Application Signaling">
<t>Some application that carry IP addresses in their payloads are
encrypted (e.g., <xref target="RFC4217">FTPS</xref>, <xref
target="I-D.ietf-sip-sips">SIPS</xref>), while others are routinely
encrypted (e.g., XMPP). This encryption prevents an ALG from
modifying the application signaling messages, which means those IPv4
applications will fail if they attempt to communicate with an IPv6
server -- no matter if the ALG is inside the host or not. This is
because the application performs the TLS encryption using its own
TLS library, whereas an in-host ALG is part of the IP stack (beneath
the application).</t>
</section>
<section title="ALG interference with IPv6-aware applications">
<t>The in-network NAT64 device will operate ALGs, for various
protocols. These ALGs will necessarily rewrite addresses, even for
IPv6-aware applications. That may cause problems for those
IPv6-aware applications. [[need more detail.]]</t>
</section>
</section>
</section>
<section title="Recommendations">
<t>Of the concerns outlined in the previous section, the most
significant is that some protocols need an ALG to function correctly
when a NAT46 function is performed by BIA/BIS. Thus, limiting the PNAT
system to only NAT464 reduces this concern. This appears achievable by
having the in-host BIA/BIS function so it only performs A queries (and
never AAAA) queries.</t>
<t>If that capability is removed from BIA/BIS, PNAT should be carefully
compared with other approaches to evaluate the advantages and
disadvantages of PNAT.</t>
</section>
<section anchor="security_considerations" title="Security Considerations">
<t>TBD.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document requires no IANA actions.</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Christian Vogt for his review comments.</t>
<t>This document was produced using version &xml2rfcversion; of
xml2rfc.</t>
</section>
</middle>
<back>
<references title="Normative References">
&I-D.huang-behave-pnat;
&I-D.ietf-behave-v6v4-xlate-stateful;
&I-D.huang-behave-rfc3338bis;
&I-D.huang-behave-rfc2767bis;
&I-D.vogt-durand-virtual-ip6-connectivity;
</references>
<references title="Informative References">
&I-D.van-beijnum-behave-ftp64;
&I-D.boucadair-port-range;
&I-D.ymbk-aplusp;
&I-D.ietf-softwire-dual-stack-lite;
&I-D.ietf-mmusic-ice;
&I-D.ietf-mmusic-rtsp-nat;
&rfc3484;
&I-D.ietf-sip-sips;
&rfc4217;
&rfc4380;
&rfc5389;
&I-D.ietf-geopriv-held-identity-extensions;
&rfc2428;
&I-D.ietf-mmusic-rfc2326bis;
&rfc2326;
&rfc3947;
&rfc3715;
&I-D.ietf-mmusic-rtsp-nat-evaluation;
&rfc3920;
<reference anchor="ICE-UDP"
target="http://xmpp.org/extensions/xep-0176.html">
<front>
<title>XEP-0176: Jingle ICE-UDP Transport Method</title>
<author fullname="Joe Beda" initials="J." surname="Beda">
<organization></organization>
</author>
<author fullname="Scott Ludwig" initials="S." surname="Ludwig">
<organization></organization>
</author>
<author fullname="Peter Saint-Andre" initials="P."
surname="Saint-Andre">
<organization></organization>
</author>
<author fullname="Joe Hildebrand" initials="J." surname="Hildebrand">
<organization></organization>
</author>
<author fullname="Sean Egan" initials="S." surname="Egan">
<organization></organization>
</author>
<author fullname="Robert McQueen" initials="R." surname="McQueen">
<organization></organization>
</author>
<date month="June" year="2009" />
</front>
</reference>
&rfc4409;
&rfc3501;
&rfc1939;
&I-D.ietf-mmusic-media-path-middleboxes;
&I-D.wing-v6ops-v6app-v4server;
&I-D.saito-mmusic-sdp-ike;
&I-D.ietf-sipping-v6-transition;
</references>
<section title="To Do">
<t>Add walk throughs for:<list style="symbols">
<t>Dual-Stack Application to IPv4 Server</t>
<t>Dual-Stack Application to IPv6-only Server</t>
<t>Dual-Stack Application to Dual-Stack Server</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 21:03:35 |