BEHAVE Working Group D. Wing
Internet-Draft Cisco
Intended status: Informational C. Byrne
Expires: August 28, 2010 T-Mobile USA
February 24, 2010
Concerns with IPv4 Applications Accessing IPv6 Servers (NAT46)
draft-wing-behave-v4app-v6server-02
Abstract
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.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wing & Byrne Expires August 28, 2010 [Page 1]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. PNAT Walk-Through . . . . . . . . . . . . . . . . . . . . . . 4
2.1. FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Outgoing Connection: FTP Passive Mode . . . . . . . . 4
2.1.2. Incoming connection: FTP Active Mode . . . . . . . . . 7
2.2. RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1. IPv4 Client to IPv4 Server (peer to peer) . . . . . . 11
2.2.2. IPv4 client to IPv4 Server (client/server) . . . . . . 12
2.2.3. IPv4 Client to IPv6 Server . . . . . . . . . . . . . . 12
2.3. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6. email protocols (SMTP, IMAP, POP) . . . . . . . . . . . . 14
2.7. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3. Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Interference with IPv6 Deployment . . . . . . . . . . . . 15
3.2. Troubleshooting . . . . . . . . . . . . . . . . . . . . . 15
3.3. Application Layer Gateways . . . . . . . . . . . . . . . . 16
3.3.1. Standardization . . . . . . . . . . . . . . . . . . . 16
3.3.2. Interference with Application Evolution . . . . . . . 16
3.3.3. Encrypted Application Signaling . . . . . . . . . . . 17
3.3.4. ALG interference with IPv6-aware applications . . . . 17
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. To Do . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Wing & Byrne Expires August 28, 2010 [Page 2]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
1. Introduction
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 ([I-D.ietf-softwire-dual-stack-lite], [I-D.ymbk-aplusp],
[I-D.boucadair-port-range]). 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.
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
[I-D.huang-behave-pnat] by extending existing in-host translation
Bump-in-the-API ("BIA", [I-D.huang-behave-rfc3338bis]) or Bump-in-
the-Stack ("BIS", [I-D.huang-behave-rfc2767bis]), and uses an in-
network stateful NAT64 access IPv4 servers. The other approach,
Virtual IPv6 Connectivity [I-D.vogt-durand-virtual-ip6-connectivity],
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.
PNAT provides two features for IPv4 applications, which are analyzed
in detail in the sections below:
o 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 [I-D.ietf-behave-v6v4-xlate-stateful] to translate the IPv6
packets back to IPv4 packets.
o 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.
Wing & Byrne Expires August 28, 2010 [Page 3]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
2. PNAT Walk-Through
2.1. FTP
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.
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.
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.
The following table summarizes the notes in the subsequent sections:
+-----------+------------+---------+-------------+----------------+
| Direction | Server | result | in-host ALG | in-network ALG |
+-----------+------------+---------+-------------+----------------+
| Outgoing | IPv4 | succeed | no | no |
| Outgoing | IPv6 | fail | no | no |
| Outgoing | dual-stack | fail | no | no |
| Incoming | IPv4 | succeed | required | required |
| Incoming | IPv6 | succeed | required | no |
| Incoming | dual-stack | succeed | required | no |
+-----------+------------+---------+-------------+----------------+
Table 1: Summary of PNAT Walk-Through
2.1.1. Outgoing Connection: FTP Passive Mode
This demonstrates how an outgoing connection is performed with BIA/
BIS with an application containing an IP address in the application
payload.
Wing & Byrne Expires August 28, 2010 [Page 4]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
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).
2.1.1.1. IPv4 Application to IPv4 Server (NAT464)
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.
+-----------------+ +---------+
|IPv4 FTP +------| < IPv6 > +-----+- < IPv4 > |IPv4 FTP |
| client | HBT +-<network>--|NAT64| -<network>--+ server |
| using | | +-----+ +---------+
| PASV | |
+----------+------+
Figure 1: FTP, IPv4 client to IPv4 server (FTP passive mode)
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.
Notes:
o This scenario is transparent to the application.
Wing & Byrne Expires August 28, 2010 [Page 5]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
o No Application-Layer Gateway (ALG) is needed.
o 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.
o 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.
2.1.1.2. IPv4 Application to IPv6 Server (NAT46)
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.
+-----------------+ +---------+
|IPv4 FTP +------| < IPv6 > |IPv6 FTP |
| client | HBT +-<network>--| server |
| using |w/FTP | +---------+
| PASV | ALG |
+----------+------+
Figure 2: FTP, IPv4 client to IPv6-only server (FTP passive mode)
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.
Notes:
Wing & Byrne Expires August 28, 2010 [Page 6]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
o Not transparent to application.
o This scenario needs an FTP ALG in the host
o There is no in-network translation, and there is no need for in-
network ALG.
o The BIA/BIS function creates additional state in the host for the
IPv4/IPv6 mappings.
2.1.1.3. IPv4 Application to Dual-Stack Server (NAT46)
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.
+-----------------+ +--------------+
|IPv4 FTP +------| < IPv6 > |dual-stack FTP|
| client | HBT +-<network>--| server |
| using |w/FTP | +--------------+
| PASV | ALG |
+----------+------+
Figure 3: FTP, IPv4 client to dual-stack server (FTP passive mode)
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, Section 2.1.1.2, and has
the same requirement for an in-host FTP ALG.
Notes:
o The same Notes from Section 2.1.1.2, above, apply to this
scenario.
o This walk-through assumes the application and the host stack both
prefer IPv6 over IPv4, which is the default ([RFC3484]).
2.1.2. Incoming connection: FTP Active Mode
This demonstrates how an incoming connection is performed with BIA/
BIS with an application containing an IP address in the application
payload.
Active mode FTP is the 'normal' mechanism popular before the
widespread deployment of IPv4 NATs and firewalls. In this mode, the
Wing & Byrne Expires August 28, 2010 [Page 7]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
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.
2.1.2.1. IPv4 Application to IPv4 Server (NAT464)
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.
+-----------------+ +---------+
|IPv4 FTP +------| < IPv6 > +-----+- < IPv4 > |IPv4 FTP |
| client | HBT +-<network>--|NAT64| -<network>--+ server |
| using | | +-----+ +---------+
| PASV | |
+----------+------+
Figure 4: FTP, IPv4 client to IPv4 server (FTP active mode)
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
Wing & Byrne Expires August 28, 2010 [Page 8]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
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.
Notes:
o As with NAT44, this requires an Application Layer Gateway.
o 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
o 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.
o 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.
2.1.2.2. IPv4 Application to IPv6-only Server (NAT46)
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.
+-----------------+ +---------+
|IPv4 FTP +------| < IPv6 > |IPv6 FTP |
| client | HBT +-<network>--| server |
| using |w/FTP | +---------+
| PASV | ALG |
+----------+------+
Figure 5: FTP, IPv4 client to IPv6-only server (FTP active mode)
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
Wing & Byrne Expires August 28, 2010 [Page 9]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
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
[RFC2428] 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.
Notes:
o As with NAT44, this requires an Application Layer Gateway (ALG).
o One ALG is necessary in the host.
2.1.2.3. IPv4 Application to Dual-Stack Server (NAT46)
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.
+-----------------+ +--------------+
|IPv4 FTP +------| < IPv6 > |dual-stack FTP|
| client | HBT +-<network>--| server |
| using |w/FTP | +--------------+
| PASV | ALG |
+----------+------+
Figure 6: FTP, IPv4 client to dual-stack server (FTP active mode)
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, Section 2.1.2.2, and
also succeeds.
Notes:
Wing & Byrne Expires August 28, 2010 [Page 10]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
o The same Notes from Section 2.1.1.2 apply to this scenario.
o This walk-through assumes the application and the host stack both
prefer IPv6 over IPv4, which is the default ([RFC3484]).
2.2. RTSP
Real Time Streaming Protocol (RTSP [RFC2326]) 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.
However, RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] includes NAT traversal
built into the RTSP client and RTSP server itself
[I-D.ietf-mmusic-rtsp-nat] which uses a technique derived from ICE
[I-D.ietf-mmusic-ice]. 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 [I-D.ietf-mmusic-rtsp-nat-evaluation]
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 Section 3.3.3. The general concern of ALG
interference with application evolution discussed in Section 3.3.2.
2.2.1. IPv4 Client to IPv4 Server (peer to peer)
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.
+-----------------+ +-----------------+
|IPv4 RTSP +------| |------+ IPv4 RTSP|
| client | HBT +--<IPv6 network>--+HBT | server |
| |w/RTSP| |w/RTSP| |
| | ALG | |ALG | |
+----------+------+ +------+----------+
Figure 7: RTSP, IPv4 client to IPv4 server (peer to peer)
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
Wing & Byrne Expires August 28, 2010 [Page 11]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
operating as the RTSP server uses an IPv6-to-IPv4 ALG, which rewrites
the RTSP signaling messages from IPv6 to IPv4.
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.
2.2.2. IPv4 client to IPv4 Server (client/server)
An IPv4 RTSP client might want to stream data from an IPv4 RTSP
server on an IPv4 network, as depicted in the following figure.
+-----------------+ +-----+ +---------+
|IPv4 RTSP +------| < IPv6 > +NAT64+- < IPv4 > |IPv4 RTSP|
| client | HBT +-<network>--| with| -<network>--+ server |
| | | | RTSP| +---------+
| | | | ALG |
+----------+------+ +-----+
Figure 8: RTSP, IPv4 client to IPv4 server (client/server)
To accomplish this, the HBT in the host realizes it is sending
packets to a NAT64 (e.g., because it matches the network's NAT64
prefix (NSP or WKP)), and does not invoke its own ALG. The in-
network RTSP ALG, implemented in conjunction with the network's NAT64
device, rewrites the RTSP signaling messages from IPv6 to IPv4.
Note: It is almost always the case the RTSP media receiver and
RTSP client have the same IP address, and the RTSP server and RTSP
media server have the same IP address. In the unlikely case this
isn't true, the dis-association of the ALG from the host's
translator causes a 3-party referral, which will fail.
Emerging standards for streaming RTSP media (e.g.,
[I-D.ietf-mmusic-rtsp-nat]) are using RTSPv2 and RTSP's own NAT
traversal, would reasonably be expected to use IPv6, and could
have different IP addresses for the RTSP client/media receiver,
and the RTSP server/media server.
2.2.3. IPv4 Client to IPv6 Server
An IPv4 RTSP client might want to stream data from an IPv6 server, as
depicted in the following figure.
Wing & Byrne Expires August 28, 2010 [Page 12]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
+-----------------+ +---------+
|IPv4 RTSP +------| < IPv6 > |IPv6 RTSP|
| client | HBT +-<network>--+ server |
| |w/RTSP| +---------+
| | ALG |
+----------+------+
Figure 9: RTSP, IPv4 client to IPv6 server
To accomplish this, the IPv4 host needs an RTSP ALG, because it won't
understand the IPv6 addresses provided by the IPv6 RTSP server.
2.3. XMPP
Extensible Messaging and Presence Protocol (XMPP [RFC3920]) 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 [ICE-UDP]. 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 [I-D.wing-v6ops-v6app-v4server] 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.
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.
2.4. IPsec
Many residential-grade NATs implement "IPsec Passthru" for a variety
of reasons. These create a variety of problems [RFC3715], 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 [RFC3715].
Thus, in a large NAT environment, IPsec applications will need to use
IPsec-over-UDP [RFC3947] rather than IPsec-over-IP (protocol 50) and
Wing & Byrne Expires August 28, 2010 [Page 13]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
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.
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
peer-to-peer IPsec [I-D.saito-mmusic-sdp-ike] (which standardizes a
similar mechanism), means use of IPsec is likely to increase in peer-
to-peer scenarios.
2.5. SIP
Most SIP networks deploy SBCs to assist with IPv4 NAT traversal
("media latching", described in Section 5 of
[I-D.ietf-mmusic-media-path-middleboxes]), 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.
+-------------+ +---------+
|IPv4 SIP +---+ < IPv6 > +---+ < IPv4 > |IPv4 SIP |
|endpoint |HBT+--<network>--+SBC+--<network>--+ endpoint|
+---------+---+ +---+ +---------+
However, if an SBC is not present, the IPv4-only SIP endpoint would
need its SIP peer to support ICE [I-D.ietf-sipping-v6-transition], as
shown in the figure below.
+-------------+ +---------+
|IPv4 SIP +---+ < IPv6 > +-----+ < IPv4 > |IPv4 SIP |
|endpoint |HBT+--<network>--+NAT64+--<network>--+ endpoint|
+---------+---+ +-----+ | w/ ICE |
+---------+
2.6. email protocols (SMTP, IMAP, POP)
SMTP Submission [RFC4409], IMAP [RFC3501], and POP3 [RFC1939] 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.
Wing & Byrne Expires August 28, 2010 [Page 14]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
2.7. HTTP
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).
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.
3. Concerns
3.1. Interference with IPv6 Deployment
We assume that BIA/BIS prefer IPv6 addresses over IPv4 addresses, as
is common today [RFC3484]. 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 Section 3.3).
By comparison, if a dual-stack or IPv6-only with in-network NAT64
approach ([I-D.ietf-softwire-dual-stack-lite], [I-D.ymbk-aplusp],
[I-D.boucadair-port-range]) 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.
3.2. Troubleshooting
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
Wing & Byrne Expires August 28, 2010 [Page 15]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
changes to potentially millions of end-points.
3.3. Application Layer Gateways
3.3.1. Standardization
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 [I-D.van-beijnum-behave-ftp64]), IPv4/IPv6
ALGs are more difficult than anticipated for even a simple and long-
established protocol such as FTP.
To date, only one detailed specification exists to describe the
function of an ALG [I-D.van-beijnum-behave-ftp64] 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,
[I-D.van-beijnum-behave-ftp64]), H.323, HELD
[I-D.ietf-geopriv-held-identity-extensions], RTSP, RTSPv2 (see Note,
below), SAP, SIP (see Note, below), PPTP, IPsec, and XMPP.
Note: Although some protocols include their own advanced NAT
traversal mechanisms (e.g., SIP can use [I-D.ietf-mmusic-ice],
RTSPv2 can use [I-D.ietf-mmusic-rtsp-nat], 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.
3.3.2. Interference with Application Evolution
An ALG can interfere in undesirable ways with enhancements to
applications. For example, both Teredo (Section 3.1 of [RFC4380])
and STUN (Section 15.2 of [RFC5389]) 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.
Wing & Byrne Expires August 28, 2010 [Page 16]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
3.3.3. Encrypted Application Signaling
Some application that carry IP addresses in their payloads are
encrypted (e.g., FTPS [RFC4217], SIPS [I-D.ietf-sip-sips]), 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).
3.3.4. ALG interference with IPv6-aware applications
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.]]
4. Recommendations
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.
If that capability is removed from BIA/BIS, PNAT should be carefully
compared with other approaches to evaluate the advantages and
disadvantages of PNAT.
5. Security Considerations
TBD.
6. IANA Considerations
This document requires no IANA actions.
7. Acknowledgements
Thanks to Christian Vogt for his review comments.
Wing & Byrne Expires August 28, 2010 [Page 17]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
This document was produced using version 1.35pre1 of xml2rfc.
8. References
8.1. Normative References
[I-D.huang-behave-pnat]
Huang, B. and H. Deng, "Prefix NAT: Host based IPv6
translation", draft-huang-behave-pnat-01 (work in
progress), February 2010.
[I-D.huang-behave-rfc2767bis]
Huang, B., Deng, H., and T. Savolainen, "Dual Stack Hosts
using the "Bump-In-the-Stack" Technique (BIS)",
draft-huang-behave-rfc2767bis-01 (work in progress),
February 2010.
[I-D.huang-behave-rfc3338bis]
Huang, B., Deng, H., and T. Savolainen, "Dual Stack Hosts
Using "Bump-in-the-API" (BIA)",
draft-huang-behave-rfc3338bis-01 (work in progress),
February 2010.
[I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers",
draft-ietf-behave-v6v4-xlate-stateful-08 (work in
progress), January 2010.
[I-D.vogt-durand-virtual-ip6-connectivity]
Vogt, C. and A. Durand, "Virtual IPv6 Connectivity for
IPv4-Only Networks",
draft-vogt-durand-virtual-ip6-connectivity-03 (work in
progress), October 2009.
8.2. Informative References
[I-D.boucadair-port-range]
Boucadair, M., Levis, P., Bajko, G., and T. Savolainen,
"IPv4 Connectivity Access in the Context of IPv4 Address
Exhaustion: Port Range based IP Architecture",
draft-boucadair-port-range-02 (work in progress),
July 2009.
[I-D.ietf-geopriv-held-identity-extensions]
Winterbottom, J., Thomson, M., Tschofenig, H., and R.
Wing & Byrne Expires August 28, 2010 [Page 18]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
Barnes, "Use of Device Identity in HTTP-Enabled Location
Delivery (HELD)",
draft-ietf-geopriv-held-identity-extensions-03 (work in
progress), February 2010.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-mmusic-media-path-middleboxes]
Stucker, B. and H. Tschofenig, "Analysis of Middlebox
Interactions for Signaling Protocol Communication along
the Media Path",
draft-ietf-mmusic-media-path-middleboxes-02 (work in
progress), March 2009.
[I-D.ietf-mmusic-rfc2326bis]
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, "Real Time Streaming Protocol 2.0
(RTSP)", draft-ietf-mmusic-rfc2326bis-22 (work in
progress), July 2009.
[I-D.ietf-mmusic-rtsp-nat]
Goldberg, J., Westerlund, M., and T. Zeng, "A Network
Address Translator (NAT) Traversal mechanism for media
controlled by Real-Time Streaming Protocol (RTSP)",
draft-ietf-mmusic-rtsp-nat-09 (work in progress),
January 2010.
[I-D.ietf-mmusic-rtsp-nat-evaluation]
Westerlund, M. and T. Zeng, "The evaluation of different
NAT traversal Techniques for media controlled by Real-time
Streaming Protocol (RTSP)",
draft-ietf-mmusic-rtsp-nat-evaluation-02 (work in
progress), January 2010.
[I-D.ietf-sip-sips]
Audet, F., "The use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", draft-ietf-sip-sips-09 (work
in progress), November 2008.
[I-D.ietf-sipping-v6-transition]
Camarillo, G., "IPv6 Transition in the Session Initiation
Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work
in progress), August 2007.
Wing & Byrne Expires August 28, 2010 [Page 19]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
Y., and R. Bush, "Dual-stack lite broadband deployments
post IPv4 exhaustion",
draft-ietf-softwire-dual-stack-lite-03 (work in progress),
February 2010.
[I-D.saito-mmusic-sdp-ike]
Saito, M., Wing, D., and M. Toyama, "Media Description for
IKE in the Session Description Protocol (SDP)",
draft-saito-mmusic-sdp-ike-06 (work in progress),
November 2009.
[I-D.van-beijnum-behave-ftp64]
Beijnum, I., "IPv6-to-IPv4 translation FTP
considerations", draft-van-beijnum-behave-ftp64-06 (work
in progress), October 2009.
[I-D.wing-v6ops-v6app-v4server]
Wing, D., "Building IPv6 Applications which Access IPv4
Servers", draft-wing-v6ops-v6app-v4server-01 (work in
progress), October 2009.
[I-D.ymbk-aplusp]
Bush, R., "The A+P Approach to the IPv4 Address Shortage",
draft-ymbk-aplusp-05 (work in progress), October 2009.
[ICE-UDP] Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J.,
Egan, S., and R. McQueen, "XEP-0176: Jingle ICE-UDP
Transport Method", June 2009,
<http://xmpp.org/extensions/xep-0176.html>.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions
for IPv6 and NATs", RFC 2428, September 1998.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
Wing & Byrne Expires August 28, 2010 [Page 20]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
(NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217,
October 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
RFC 4409, April 2006.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
Appendix A. To Do
Add walk throughs for:
o Dual-Stack Application to IPv4 Server
o Dual-Stack Application to IPv6-only Server
o Dual-Stack Application to Dual-Stack Server
Authors' Addresses
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Email: dwing@cisco.com
Wing & Byrne Expires August 28, 2010 [Page 21]
Internet-Draft Concerns with v4 Apps to v6 Servers February 2010
Cameron Byrne
T-Mobile USA, Inc.
Email: cameron.byrne@t-mobile.com
Wing & Byrne Expires August 28, 2010 [Page 22]