BEHAVE Working Group D. Wing Internet-Draft Cisco Intended status: Informational C. Byrne Expires: August 15, 2010 T-Mobile USA February 11, 2010 Concerns with IPv4 Applications Accessing IPv6 Servers (NAT46) draft-wing-behave-v4app-v6server-01 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 15, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Wing & Byrne Expires August 15, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3. Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1. Interference with IPv6 Deployment . . . . . . . . . . . . 15 3.2. Troubleshooting . . . . . . . . . . . . . . . . . . . . . 15 3.3. Application Layer Gateways . . . . . . . . . . . . . . . . 15 3.3.1. Standardization . . . . . . . . . . . . . . . . . . . 15 3.3.2. Interference with Application Evolution . . . . . . . 16 3.3.3. Encrypted Application Signaling . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 Appendix A. To Do . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Wing & Byrne Expires August 15, 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 15, 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 15, 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 +---|NAT64| ---+ 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 15, 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 +---| 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 15, 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 +---| 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 15, 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 +---|NAT64| ---+ 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 15, 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 +---| 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 15, 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 +---| 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 15, 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 +----+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 15, 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 +---| with| ---+ server | | |w/RTSP| | RTSP| +---------+ | | ALG | | ALG | +----------+------+ +-----+ Figure 8: RTSP, IPv4 client to IPv4 server (client/server) 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. 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. +-----------------+ +---------+ |IPv4 RTSP +------| < IPv6 > |IPv6 RTSP| | client | HBT +---+ 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. Wing & Byrne Expires August 15, 2010 [Page 12] Internet-Draft Concerns with v4 Apps to v6 Servers February 2010 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 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. Wing & Byrne Expires August 15, 2010 [Page 13] Internet-Draft Concerns with v4 Apps to v6 Servers February 2010 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+----+SBC+----+ 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+----+NAT64+----+ 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. 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 Wing & Byrne Expires August 15, 2010 [Page 14] Internet-Draft Concerns with v4 Apps to v6 Servers February 2010 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 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. Wing & Byrne Expires August 15, 2010 [Page 15] Internet-Draft Concerns with v4 Apps to v6 Servers February 2010 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. 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). Wing & Byrne Expires August 15, 2010 [Page 16] Internet-Draft Concerns with v4 Apps to v6 Servers February 2010 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. 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-00 (work in progress), October 2009. Wing & Byrne Expires August 15, 2010 [Page 17] Internet-Draft Concerns with v4 Apps to v6 Servers 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-00 (work in progress), October 2009. [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-00 (work in progress), October 2009. [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. Barnes, "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)", draft-ietf-geopriv-held-identity-extensions-02 (work in progress), December 2009. [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] Wing & Byrne Expires August 15, 2010 [Page 18] Internet-Draft Concerns with v4 Apps to v6 Servers February 2010 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. [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. Wing & Byrne Expires August 15, 2010 [Page 19] Internet-Draft Concerns with v4 Apps to v6 Servers February 2010 [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, . [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 (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 Wing & Byrne Expires August 15, 2010 [Page 20] Internet-Draft Concerns with v4 Apps to v6 Servers February 2010 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 Cameron Byrne T-Mobile USA, Inc. Email: cameron.byrne@t-mobile.com Wing & Byrne Expires August 15, 2010 [Page 21]