BEHAVE Working Group D. Wing Internet-Draft Cisco Intended status: Informational October 19, 2009 Expires: April 22, 2010 Building IPv6 Applications which Access IPv4 Servers draft-wing-v6ops-v6app-v4server-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 When an application runs on a host or network that only supports IPv6 ("IPv6-only"), it is sometimes necessary that the application communicate with IPv4 peers. When that communication involves DNS, Wing Expires April 22, 2010 [Page 1] Internet-Draft IPv6 Application to IPv4 Server October 2009 DNS64 and a 6/4 translator works well without any changes to most applications. However, when that communication does not involve DNS, it can require additional features be configured on or programmed into the IPv6 application. This document explains why this functionality is important and describes mechanisms for applications to provide such functionality. Table of Contents 1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Mechanism to Communicate with IPv4 Hosts . . . . . . . . . . . 4 3.1. Address Parsing . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Determining Translation is Needed . . . . . . . . . . . . . 5 3.2.1. Transmitting a Packet . . . . . . . . . . . . . . . . . 5 3.2.2. Receiving a Packet . . . . . . . . . . . . . . . . . . 5 3.3. Operating Differently with IPv4 or IPv6 Peers . . . . . . . 5 3.4. Sending an IPv6 Packet to an IPv4 Peer . . . . . . . . . . 5 3.4.1. Using Application-Specific Mechanism . . . . . . . . . 5 3.4.2. Using 6/4 Translator . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Informative References . . . . . . . . . . . . . . . . . . . . 6 Appendix A. HTTP IPv4 Address Literals on the Internet . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Wing Expires April 22, 2010 [Page 2] Internet-Draft IPv6 Application to IPv4 Server October 2009 1. Applicability This document applies to IPv6 hosts operating in BEHAVE's scenarios 1 ("an IPv6 network to IPv4 Internet"), and scenario 5 ("an IPv6 network to an IPv4 network") [I-D.ietf-behave-v6v4-framework]. The mechanisms described in this document are *not* necessary for most IPv6-aware applications, but are necessary for *some* IPv6-aware applications. For example, if DNS is always used to connect to hosts, the DNS64 function [I-D.ietf-behave-dns64] provides access to IPv4 hosts without pain or effort by the IPv6 application. However, if IPv4 address literals are used by the application the IPv6-only host will need to use the described mechanisms to communicate with the IPv4 peer. Said another way, applications which never use DNS (and thus do not use the DNS64 function), or applications which sometimes do not use DNS, will find value in the mechanisms described in this document. If an application always (or 'almost always') uses DNS, the mechanisms in this document are not necessary. Currently, between 0.38%-2% of the Internet's HTTP traffic would benefit from the mechanisms in this draft Appendix A. The need by other protocols are subject to further study. 2. Introduction Historically, clients and servers were expected to run as dual-stack hosts so that IPv4 could be used to communicate with IPv4 hosts and IPv6 could be used to communicate with IPv6 hosts. One subtle feature of a dual-stack host is that IPv4 is available whenever IPv4 is necessary. IPv4 is necessary when communicating with IPv4 hosts using IPv4 address literals. IPv4 address literals occur in some application protocols naturally (e.g., FTP, SIP) or because for some reason DNS wasn't used (e.g., HTTP [I-D.wing-behave-http-ip-address-literals]). Thus, the function of an IPv4-only, dual-stack, or IPv6-only application running on a IPv4-host, dual-stack, or IPv6-only host might be summarized as: If an application needs to communicate with an IPvX peer, the application uses IPvX application syntax and transmits IPvX packets. needs to be enhanced and summarized as: Wing Expires April 22, 2010 [Page 3] Internet-Draft IPv6 Application to IPv4 Server October 2009 If the application needs to communicate with an IPvX peer, the application uses IPvX application syntax and transmits IPv6 packets. The significant difference is that applications used to determine which application syntax to use based on the IP address family. With IPv6-only clients accessing IPv4 servers across an IPv6/IPv4 translator, such short-cuts will often -- but not always -- work as desired. If the IPv6 application is unable to perform this new rule, an Application Layer Gateway function needs to be implemented in the host, in CPE, or in the 6/4 translator. Such an ALG would need to perform most of the same functions described in this document. ALGs are best avoided because of the problems they cause (need to be on- path with both signaling and data traffic, require signaling traffic be unencrypted and non-integrity protected, interferes with development of new application features and functions, impossible to build an ALG for every application, complicates debugging and troubleshooting, and so on). 3. Mechanism to Communicate with IPv4 Hosts In order to provide full access from an IPv6-only host (client) to an IPv4 peer, the application must: 1. Be capable of parsing IPv4 addresses, AND 2. Determine if packet needs to be sent to a 6/4 translator, or if a packet was received via a 6/4 translator, AND 3. Determine if it needs to operate differently with an IPv4 peer versus an IPv6 peer, AND 4. Construct an IPv6 address for the 6/4 translator from an IPv4 address. These are detailed in the following subsections. 3.1. Address Parsing This requirement is easily achieved, because it is already implemented in today's applications. Applications are reasonably expected to parse IPv4 address literals (e.g., http://192.0.2.1). Unless that code is purposefully removed or disabled when the application is running on an IPv6-only host, the application will still be able to parse IPv4 address literals. Wing Expires April 22, 2010 [Page 4] Internet-Draft IPv6 Application to IPv4 Server October 2009 3.2. Determining Translation is Needed 3.2.1. Transmitting a Packet If an IPv6 application has parsed an application payload packet and found an IPv4 address and wants to communicate with that IPv4 peer, the decision is simple: the application needs to use a translator to send the packet to that IPv4 peer. 3.2.2. Receiving a Packet If an IPv6 application has received has an IPv6 packet it can examine the IPv6 prefix to determine if the peer is an IPv4 peer. If the network is using the well-known prefix, the comparison is straightforward. If the network is using the NSP prefix the application first needs to learn the network's NSP prefix (using [I-D.wing-behave-learn-prefix]) and do its comparison. (Note: 'NSP prefix' used to be called 'LIR prefix', and is an operator-specific prefix used by the operator's 6/4 translator(s). [I-D.ietf-behave-address-format]) 3.3. Operating Differently with IPv4 or IPv6 Peers Once the application has performed the steps above, the application knows if the peer is a native IPv6 peer or an IPv4 peer. With that knowledge, the application can operate as appropriate for the peer's address family -- if necessary for that protocol. Some protocols operate identically over IPv6 or IPv4 (e.g., NTP). Other protocols operate differently over IPv6 or IPv4. The operation of HTTP and FTP in such an environment has been examined ([I-D.wing-behave-http-ip-address-literals], [I-D.van-beijnum-behave-ftp64]). Examination of other protocols is for future study. 3.4. Sending an IPv6 Packet to an IPv4 Peer Once an application knows it wants to send an IPv6 packet to an IPv4 peer, it can use an application-specific mechanism or it can use the general 6/4 translator. 3.4.1. Using Application-Specific Mechanism Some applications can use a application proxy to provide access to IPv4 servers. For HTTP, this is described in [I-D.wing-behave-http-ip-address-literals]. For SIP, this is described in [I-D.ietf-sipping-v6-transition] using Wing Expires April 22, 2010 [Page 5] Internet-Draft IPv6 Application to IPv4 Server October 2009 TURN-IPv6 [I-D.ietf-behave-turn-ipv6] as the relay between IPv6 and IPv4. 3.4.2. Using 6/4 Translator Once the application determines its IPv6 network uses the well-known prefix or NSP prefix for its 6/4 translator (using [I-D.wing-behave-learn-prefix]) the application can construct a destination IPv6 address from that information. When sent, this packet will be routed to the 6/4 translator, translated to the IPv4 destination address embedded in the IPv6 packet, and routed to the IPv4 peer. For SIP, this is described in Section 6.2 of [I-D.ietf-sipping-nat-scenarios] using a 6/4 translator between IPv6 and IPv4. (However, that document does not explain how a SIP client formulates packets that will be sent to the translator and translated by it, as this document explains.) Issue: how does the application determine if its IPv6 network has a translator using the WKP prefix, if not via [I-D.wing-behave-learn-prefix]? 4. Security Considerations TBD. 5. IANA Considerations This document requires no IANA actions. 6. Informative References [Alexa] Alexa, "Top 1,000,000 Global Sites", September 2009, . [I-D.ietf-behave-address-format] Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", draft-ietf-behave-address-format-00 (work in progress), August 2009. [I-D.ietf-behave-dns64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation Wing Expires April 22, 2010 [Page 6] Internet-Draft IPv6 Application to IPv4 Server October 2009 from IPv6 Clients to IPv4 Servers", draft-ietf-behave-dns64-01 (work in progress), October 2009. [I-D.ietf-behave-turn-ipv6] Perreault, S., Camarillo, G., and O. Novo, "Traversal Using Relays around NAT (TURN) Extension for IPv6", draft-ietf-behave-turn-ipv6-07 (work in progress), October 2009. [I-D.ietf-behave-v6v4-framework] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", draft-ietf-behave-v6v4-framework-02 (work in progress), October 2009. [I-D.ietf-sipping-nat-scenarios] Boulton, C., Rosenberg, J., Camarillo, G., and F. Audet, "Best Current Practices for NAT Traversal for Client- Server SIP", draft-ietf-sipping-nat-scenarios-09 (work in progress), September 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.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-behave-http-ip-address-literals] Wing, D., "Coping with IP Address Literals in HTTP URIs with IPv6/IPv4 Translators", draft-wing-behave-http-ip-address-literals-00 (work in progress), October 2009. [I-D.wing-behave-learn-prefix] Wing, D., Wang, X., and X. Xu, "Learning the IPv6 Prefixes of an IPv6/IPv4 Translator", draft-wing-behave-learn-prefix-03 (work in progress), July 2009. Appendix A. HTTP IPv4 Address Literals on the Internet There has been some doubt that HTTP URIs on the Internet contain Wing Expires April 22, 2010 [Page 7] Internet-Draft IPv6 Application to IPv4 Server October 2009 hostnames with IPv4 address literals. This section provides some scripts which demonstrate the relatively low -- but prevalent -- existence of IPv4 address literals. An examination of Alexa's top 1 million domains [Alexa] at the end of August, 2009, showed 2.38% of the HTML in their home pages contained IPv4 address literals. This can be verified with: wget http://s3.amazonaws.com/alexa-static/top-1m.csv.zip unzip top-1m.csv.zip cat top-1m.csv | cut -d "," -f 2 | xargs -I % -n 1 -t wget -nv % -O - --user-agent="Mozilla/5.0" | grep -E "https?://[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" Of the top 1 million websites at the end of August, 2009, 3455 (0.35%) of them are IPv4 address literals (e.g., http://192.0.2.1). This can be verified with: wget http://s3.amazonaws.com/alexa-static/top-1m.csv.zip unzip top-1m.csv.zip grep -E "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" top-1m.csv | wc Author's Address Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: dwing@cisco.com Wing Expires April 22, 2010 [Page 8]