BEHAVE Working Group D. Wing Internet-Draft Cisco Intended status: Informational C. Byrne Expires: April 22, 2010 T-Mobile USA October 19, 2009 Concerns with IPv4 Applications Accessing IPv6 Servers (NAT46) draft-wing-behave-v4app-v6server-00 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 April 22, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Bump-in-the-Stack and Bump-in-the-API allow IPv4 applications to access IPv6 servers. This is done by using in-host NAT46 translator. Wing & Byrne Expires April 22, 2010 [Page 1] Internet-Draft Concerns with v4 Apps to v6 Servers October 2009 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. PNAT Walk-Through . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Outgoing Connection: FTP Passive Mode . . . . . . . . . . 4 2.1.1. IPv4 Application to IPv4 Server (NAT464) . . . . . . . 5 2.1.2. IPv4 Application to IPv6-only Server (NAT46) . . . . . 6 2.1.3. IPv4 Application to Dual-Stack Server (NAT46) . . . . 6 2.2. Incoming connection: FTP Active Mode . . . . . . . . . . . 7 2.2.1. IPv4 Application to IPv4 Server (NAT464) . . . . . . . 7 2.2.2. IPv4 Application to IPv6-only Server (NAT46) . . . . . 8 2.2.3. IPv4 Application to Dual-Stack Server (NAT46) . . . . 9 3. Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Interference with IPv6 Deployment . . . . . . . . . . . . 10 3.2. Troubleshooting . . . . . . . . . . . . . . . . . . . . . 10 3.3. Application Layer Gateways . . . . . . . . . . . . . . . . 10 3.3.1. Standardization . . . . . . . . . . . . . . . . . . . 10 3.3.2. Interference with Application Evolution . . . . . . . 11 3.3.3. Encrypted Application Signaling . . . . . . . . . . . 11 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. To Do . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Wing & Byrne Expires April 22, 2010 [Page 2] Internet-Draft Concerns with v4 Apps to v6 Servers October 2009 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. 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 to provided to 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, but it is believed to have similar needs for ALG assistance to support complex protocols. PNAT provides two features, 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 April 22, 2010 [Page 3] Internet-Draft Concerns with v4 Apps to v6 Servers October 2009 2. PNAT Walk-Through 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. Although FTP is shown, other more complex protocols (e.g., SIP, XMPP) also require incoming and/or outgoing connections (depending on the sort of session being established) and encounter similar issues. FTP was chosen because it is well-understood and because the FTP data connection can be outgoing (from the client) or incoming (to the client). 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. 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 April 22, 2010 [Page 4] Internet-Draft Concerns with v4 Apps to v6 Servers October 2009 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. 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. 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. 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. Wing & Byrne Expires April 22, 2010 [Page 5] Internet-Draft Concerns with v4 Apps to v6 Servers October 2009 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. 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, and no IPv4 address and no A record. 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: o Not transparent to application. o This scenario fails for some applications, unless those applications have an Application Layer Gateway 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.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. The IPv4 FTP application does a gethostaddr() call for ftp.example.com. This is intercepted by the BIA/BIS in the host, and Wing & Byrne Expires April 22, 2010 [Page 6] Internet-Draft Concerns with v4 Apps to v6 Servers October 2009 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, and fails for the same reason. Notes: o The same Notes from Section 2.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. 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 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.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. 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 Wing & Byrne Expires April 22, 2010 [Page 7] Internet-Draft Concerns with v4 Apps to v6 Servers October 2009 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. 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.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 AAA record. It has no IPv4 address and no A record. The IPv4 FTP application does a gethostaddr() call for ftp.example.com. This is intercepted by the BIA/BIS in the host, and Wing & Byrne Expires April 22, 2010 [Page 8] Internet-Draft Concerns with v4 Apps to v6 Servers October 2009 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 [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.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. 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.2.2, and also succeeds. Notes: o The same Notes from Section 2.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]). Wing & Byrne Expires April 22, 2010 [Page 9] Internet-Draft Concerns with v4 Apps to v6 Servers October 2009 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. 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 that 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 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 effect existing IPv4 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. To date, only one detailed specification exists to describe the function of an ALG [I-D.van-beijnum-behave-ftp64]. Yet for BIA/BIS Wing & Byrne Expires April 22, 2010 [Page 10] Internet-Draft Concerns with v4 Apps to v6 Servers October 2009 to be successfully deployed with IPv6 servers, ALGs 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), 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]). 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. 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. Wing & Byrne Expires April 22, 2010 [Page 11] Internet-Draft Concerns with v4 Apps to v6 Servers October 2009 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. 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. [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, "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-02 (work in progress), October 2009. [I-D.vogt-durand-virtual-ip6-connectivity] Wing & Byrne Expires April 22, 2010 [Page 12] Internet-Draft Concerns with v4 Apps to v6 Servers October 2009 Vogt, C. and A. Durand, "Virtual IPv6 Connectivity for IPv4-Only Networks", draft-vogt-durand-virtual-ip6-connectivity-02 (work in progress), July 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-01 (work in progress), October 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-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-08 (work in progress), July 2009. [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-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-01 (work in progress), July 2009. [I-D.van-beijnum-behave-ftp64] Beijnum, I., "IPv6-to-IPv4 translation FTP Wing & Byrne Expires April 22, 2010 [Page 13] Internet-Draft Concerns with v4 Apps to v6 Servers October 2009 considerations", draft-van-beijnum-behave-ftp64-05 (work in progress), July 2009. [I-D.ymbk-aplusp] Bush, R., "The A+P Approach to the IPv4 Address Shortage", draft-ymbk-aplusp-04 (work in progress), July 2009. [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. [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. [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 April 22, 2010 [Page 14] Internet-Draft Concerns with v4 Apps to v6 Servers October 2009 Cameron Byrne T-Mobile USA, Inc. Email: cameron.byrne@t-mobile.com Wing & Byrne Expires April 22, 2010 [Page 15]