BEHAVE Working Group D. Wing Internet-Draft Cisco Intended status: Informational October 26, 2009 Expires: April 29, 2010 Building IPv6 Applications which Access IPv4 Servers draft-wing-v6ops-v6app-v4server-01 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 29, 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 29, 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. Operating Differently with IPv4 or IPv6 Peers . . . . . . . 5 3.3. Determining IPv4 Peer . . . . . . . . . . . . . . . . . . . 5 3.3.1. Transmitting a Packet . . . . . . . . . . . . . . . . . 5 3.3.2. Receiving a Packet . . . . . . . . . . . . . . . . . . 5 3.4. Sending an IPv6 Packet to an IPv4 Peer . . . . . . . . . . 6 3.4.1. Using Application-Specific Mechanism . . . . . . . . . 6 3.4.2. Using 6/4 Translation Mechanism . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Informative References . . . . . . . . . . . . . . . . . . . . 7 Appendix A. HTTP IPv4 Address Literals on the Internet . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Wing Expires April 29, 2010 [Page 2] Internet-Draft IPv6 Application to IPv4 Server October 2009 1. Applicability This document applies to IPv6 hosts operating in scenario 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 extended to work well in an IPv6-only environment. This extension can be summarized as: Wing Expires April 29, 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 cannot be extended (for whatever reason), 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 an IPv4 address, AND 2. Determine if the applications needs to operate differently with an IPv4 peer versus an IPv6 peer, AND 3. Determine if packet needs to be sent to (or was received from) an IPv4 peer, AND 3. Send an IPv6 packet to an IPv4 peer. These are detailed in the following subsections. 3.1. Address Parsing This requirement is easily achieved, because IPv4 address parsing 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 29, 2010 [Page 4] Internet-Draft IPv6 Application to IPv4 Server October 2009 3.2. Operating Differently with IPv4 or IPv6 Peers Some protocols operate identically over IPv6 or IPv4 (e.g., NTP). Other protocols operate differently over IPv6 or IPv4, either due to IPv4 address literals appearing in the application payload or because different commands are used with IPv4 peers compared with IPv6 peers. The operation of HTTP has been examined and IPv4 address literals occasionally appear, requiring some support in the application. Alternatively, a workaround may be a reasonable approach as discussed in [I-D.wing-behave-http-ip-address-literals]. The operation of FTP has been examined and different commands are used for IPv6 peers (EPSV) than with IPv4 peers (PASV) [I-D.van-beijnum-behave-ftp64]). Analysis of other protocols is for future study, but the basic analysis is much the same: determine if the application needs to use different commands, semantics, or syntax because of the different IP address family. 3.3. Determining IPv4 Peer 3.3.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. Section 3.4 describes how the applications transmits such a packet. 3.3.2. Receiving a Packet If an IPv6 application might receive a packet directly (via an IPv6 translator) or via an application proxy. If the packet was received via an application-specific proxy, an application-specific mechanism determines if the peer is IPv4 or IPv6. If the packet was received has an IPv6 packet via a 6/4 translator 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. Wing Expires April 29, 2010 [Page 5] Internet-Draft IPv6 Application to IPv4 Server October 2009 3.4. Sending an IPv6 Packet to an IPv4 Peer Once the above steps are performed, the application has two basic mechanisms to send an IPv6 packet to an IPv4 peer. It can use an application-specific mechanism or it can use the general 6/4 translation mechanism. 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]. This HTTP proxy can be deployed an IPv4-only HTTP proxy and placed on the far side of the 6/4 translator, such that any host on the Internet could provide the service, as in: [IPv6-only client]---[6/4 translator]---[HTTP proxy]---[IPv4 peer] The HTTP proxy can also be deployed on both the IPv6 and IPv4 networks, essentially in parallel with the 6/4 translator, as in: [IPv6-only client]---[HTTP proxy]---[IPv4 peer] For SIP, this is described in [I-D.ietf-sipping-v6-transition] using a TURN-IPv6 [I-D.ietf-behave-turn-ipv6] server as the relay between IPv6 and IPv4. In such a deployment the TURN-IPv6 server is run in parallel with the 6/4 translator. In contrast, a TURN server [I-D.ietf-behave-turn] could be run on the IPv4 Internet. 3.4.2. Using 6/4 Translation Mechanism The application (or its underlying operating system) determines the IPv6 prefix (using [I-D.wing-behave-learn-prefix]). With that information, the application can construct a destination IPv6 address. When sent, that 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]? Wing Expires April 29, 2010 [Page 6] Internet-Draft IPv6 Application to IPv4 Server October 2009 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-01 (work in progress), October 2009. [I-D.ietf-behave-dns64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-dns64-02 (work in progress), October 2009. [I-D.ietf-behave-turn] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", draft-ietf-behave-turn-16 (work in progress), July 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-03 (work in progress), October 2009. [I-D.ietf-sipping-nat-scenarios] Boulton, C., Rosenberg, J., Camarillo, G., and F. Audet, Wing Expires April 29, 2010 [Page 7] Internet-Draft IPv6 Application to IPv4 Server October 2009 "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., "Learning the IPv6 Prefix of a Network's IPv6/ IPv4 Translator", draft-wing-behave-learn-prefix-04 (work in progress), October 2009. Appendix A. HTTP IPv4 Address Literals on the Internet There has been some doubt that HTTP URIs on the Internet contain 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}" Wing Expires April 29, 2010 [Page 8] Internet-Draft IPv6 Application to IPv4 Server October 2009 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 29, 2010 [Page 9]