idnits 2.17.1 draft-wing-v6ops-v6app-v4server-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2009) is 5295 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-behave-address-format' is defined on line 276, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-01 == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-02 == Outdated reference: A later version (-11) exists of draft-ietf-behave-turn-ipv6-07 == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-03 == Outdated reference: A later version (-15) exists of draft-ietf-sipping-nat-scenarios-09 == Outdated reference: A later version (-02) exists of draft-wing-behave-http-ip-address-literals-00 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE Working Group D. Wing 3 Internet-Draft Cisco 4 Intended status: Informational October 26, 2009 5 Expires: April 29, 2010 7 Building IPv6 Applications which Access IPv4 Servers 8 draft-wing-v6ops-v6app-v4server-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 29, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 When an application runs on a host or network that only supports IPv6 47 ("IPv6-only"), it is sometimes necessary that the application 48 communicate with IPv4 peers. When that communication involves DNS, 49 DNS64 and a 6/4 translator works well without any changes to most 50 applications. However, when that communication does not involve DNS, 51 it can require additional features be configured on or programmed 52 into the IPv6 application. This document explains why this 53 functionality is important and describes mechanisms for applications 54 to provide such functionality. 56 Table of Contents 58 1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Mechanism to Communicate with IPv4 Hosts . . . . . . . . . . . 4 61 3.1. Address Parsing . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Operating Differently with IPv4 or IPv6 Peers . . . . . . . 5 63 3.3. Determining IPv4 Peer . . . . . . . . . . . . . . . . . . . 5 64 3.3.1. Transmitting a Packet . . . . . . . . . . . . . . . . . 5 65 3.3.2. Receiving a Packet . . . . . . . . . . . . . . . . . . 5 66 3.4. Sending an IPv6 Packet to an IPv4 Peer . . . . . . . . . . 6 67 3.4.1. Using Application-Specific Mechanism . . . . . . . . . 6 68 3.4.2. Using 6/4 Translation Mechanism . . . . . . . . . . . . 6 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 71 6. Informative References . . . . . . . . . . . . . . . . . . . . 7 72 Appendix A. HTTP IPv4 Address Literals on the Internet . . . . . . 8 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Applicability 77 This document applies to IPv6 hosts operating in scenario 1 ("an IPv6 78 network to IPv4 Internet") and scenario 5 ("an IPv6 network to an 79 IPv4 network") [I-D.ietf-behave-v6v4-framework]. 81 The mechanisms described in this document are *not* necessary for 82 most IPv6-aware applications, but are necessary for *some* IPv6-aware 83 applications. For example, if DNS is always used to connect to 84 hosts, the DNS64 function [I-D.ietf-behave-dns64] provides access to 85 IPv4 hosts without pain or effort by the IPv6 application. However, 86 if IPv4 address literals are used by the application the IPv6-only 87 host will need to use the described mechanisms to communicate with 88 the IPv4 peer. 90 Said another way, applications which never use DNS (and thus do not 91 use the DNS64 function), or applications which sometimes do not use 92 DNS, will find value in the mechanisms described in this document. 93 If an application always (or 'almost always') uses DNS, the 94 mechanisms in this document are not necessary. 96 Currently, between 0.38%-2% of the Internet's HTTP traffic would 97 benefit from the mechanisms in this draft Appendix A. The need by 98 other protocols are subject to further study. 100 2. Introduction 102 Historically, clients and servers were expected to run as dual-stack 103 hosts so that IPv4 could be used to communicate with IPv4 hosts and 104 IPv6 could be used to communicate with IPv6 hosts. One subtle 105 feature of a dual-stack host is that IPv4 is available whenever IPv4 106 is necessary. IPv4 is necessary when communicating with IPv4 hosts 107 using IPv4 address literals. IPv4 address literals occur in some 108 application protocols naturally (e.g., FTP, SIP) or because for some 109 reason DNS wasn't used (e.g., HTTP 110 [I-D.wing-behave-http-ip-address-literals]). 112 Thus, the function of an IPv4-only, dual-stack, or IPv6-only 113 application running on a IPv4-host, dual-stack, or IPv6-only host 114 might be summarized as: 116 If an application needs to communicate with an IPvX peer, the 117 application uses IPvX application syntax and transmits IPvX 118 packets. 120 needs to be extended to work well in an IPv6-only environment. This 121 extension can be summarized as: 123 If the application needs to communicate with an IPvX peer, the 124 application uses IPvX application syntax and transmits IPv6 125 packets. 127 The significant difference is that applications used to determine 128 which application syntax to use based on the IP address family. With 129 IPv6-only clients accessing IPv4 servers across an IPv6/IPv4 130 translator, such short-cuts will often -- but not always -- work as 131 desired. 133 If the IPv6 application cannot be extended (for whatever reason), an 134 Application Layer Gateway function needs to be implemented in the 135 host, in CPE, or in the 6/4 translator. Such an ALG would need to 136 perform most of the same functions described in this document. ALGs 137 are best avoided because of the problems they cause (need to be on- 138 path with both signaling and data traffic, require signaling traffic 139 be unencrypted and non-integrity protected, interferes with 140 development of new application features and functions, impossible to 141 build an ALG for every application, complicates debugging and 142 troubleshooting, and so on). 144 3. Mechanism to Communicate with IPv4 Hosts 146 In order to provide full access from an IPv6-only host (client) to an 147 IPv4 peer, the application must: 149 1. Be capable of parsing an IPv4 address, AND 151 2. Determine if the applications needs to operate differently 152 with an IPv4 peer versus an IPv6 peer, AND 154 3. Determine if packet needs to be sent to (or was received from) 155 an IPv4 peer, AND 157 3. Send an IPv6 packet to an IPv4 peer. 159 These are detailed in the following subsections. 161 3.1. Address Parsing 163 This requirement is easily achieved, because IPv4 address parsing is 164 already implemented in today's applications. Applications are 165 reasonably expected to parse IPv4 address literals (e.g., 166 http://192.0.2.1). Unless that code is purposefully removed or 167 disabled when the application is running on an IPv6-only host, the 168 application will still be able to parse IPv4 address literals. 170 3.2. Operating Differently with IPv4 or IPv6 Peers 172 Some protocols operate identically over IPv6 or IPv4 (e.g., NTP). 173 Other protocols operate differently over IPv6 or IPv4, either due to 174 IPv4 address literals appearing in the application payload or because 175 different commands are used with IPv4 peers compared with IPv6 peers. 177 The operation of HTTP has been examined and IPv4 address literals 178 occasionally appear, requiring some support in the application. 179 Alternatively, a workaround may be a reasonable approach as discussed 180 in [I-D.wing-behave-http-ip-address-literals]. 182 The operation of FTP has been examined and different commands are 183 used for IPv6 peers (EPSV) than with IPv4 peers (PASV) 184 [I-D.van-beijnum-behave-ftp64]). 186 Analysis of other protocols is for future study, but the basic 187 analysis is much the same: determine if the application needs to use 188 different commands, semantics, or syntax because of the different IP 189 address family. 191 3.3. Determining IPv4 Peer 193 3.3.1. Transmitting a Packet 195 If an IPv6 application has parsed an application payload packet and 196 found an IPv4 address and wants to communicate with that IPv4 peer, 197 the decision is simple: the application needs to use a translator to 198 send the packet to that IPv4 peer. Section 3.4 describes how the 199 applications transmits such a packet. 201 3.3.2. Receiving a Packet 203 If an IPv6 application might receive a packet directly (via an IPv6 204 translator) or via an application proxy. If the packet was received 205 via an application-specific proxy, an application-specific mechanism 206 determines if the peer is IPv4 or IPv6. 208 If the packet was received has an IPv6 packet via a 6/4 translator it 209 can examine the IPv6 prefix to determine if the peer is an IPv4 peer. 210 If the network is using the well-known prefix, the comparison is 211 straightforward. If the network is using the NSP prefix the 212 application first needs to learn the network's NSP prefix (using 213 [I-D.wing-behave-learn-prefix]) and do its comparison. 215 3.4. Sending an IPv6 Packet to an IPv4 Peer 217 Once the above steps are performed, the application has two basic 218 mechanisms to send an IPv6 packet to an IPv4 peer. It can use an 219 application-specific mechanism or it can use the general 6/4 220 translation mechanism. 222 3.4.1. Using Application-Specific Mechanism 224 Some applications can use a application proxy to provide access to 225 IPv4 servers. For HTTP, this is described in 226 [I-D.wing-behave-http-ip-address-literals]. This HTTP proxy can be 227 deployed an IPv4-only HTTP proxy and placed on the far side of the 228 6/4 translator, such that any host on the Internet could provide the 229 service, as in: 231 [IPv6-only client]---[6/4 translator]---[HTTP proxy]---[IPv4 peer] 233 The HTTP proxy can also be deployed on both the IPv6 and IPv4 234 networks, essentially in parallel with the 6/4 translator, as in: 236 [IPv6-only client]---[HTTP proxy]---[IPv4 peer] 238 For SIP, this is described in [I-D.ietf-sipping-v6-transition] using 239 a TURN-IPv6 [I-D.ietf-behave-turn-ipv6] server as the relay between 240 IPv6 and IPv4. In such a deployment the TURN-IPv6 server is run in 241 parallel with the 6/4 translator. In contrast, a TURN server 242 [I-D.ietf-behave-turn] could be run on the IPv4 Internet. 244 3.4.2. Using 6/4 Translation Mechanism 246 The application (or its underlying operating system) determines the 247 IPv6 prefix (using [I-D.wing-behave-learn-prefix]). With that 248 information, the application can construct a destination IPv6 249 address. When sent, that packet will be routed to the 6/4 250 translator, translated to the IPv4 destination address embedded in 251 the IPv6 packet, and routed to the IPv4 peer. 253 For SIP, this is described in Section 6.2 of 254 [I-D.ietf-sipping-nat-scenarios] using a 6/4 translator between IPv6 255 and IPv4. (However, that document does not explain how a SIP client 256 formulates packets that will be sent to the translator and translated 257 by it, as this document explains.) 259 Issue: how does the application determine if its IPv6 network has 260 a translator using the WKP prefix, if not via 261 [I-D.wing-behave-learn-prefix]? 263 4. Security Considerations 265 TBD. 267 5. IANA Considerations 269 This document requires no IANA actions. 271 6. Informative References 273 [Alexa] Alexa, "Top 1,000,000 Global Sites", September 2009, 274 . 276 [I-D.ietf-behave-address-format] 277 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 278 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 279 draft-ietf-behave-address-format-01 (work in progress), 280 October 2009. 282 [I-D.ietf-behave-dns64] 283 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 284 "DNS64: DNS extensions for Network Address Translation 285 from IPv6 Clients to IPv4 Servers", 286 draft-ietf-behave-dns64-02 (work in progress), 287 October 2009. 289 [I-D.ietf-behave-turn] 290 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 291 Relays around NAT (TURN): Relay Extensions to Session 292 Traversal Utilities for NAT (STUN)", 293 draft-ietf-behave-turn-16 (work in progress), July 2009. 295 [I-D.ietf-behave-turn-ipv6] 296 Perreault, S., Camarillo, G., and O. Novo, "Traversal 297 Using Relays around NAT (TURN) Extension for IPv6", 298 draft-ietf-behave-turn-ipv6-07 (work in progress), 299 October 2009. 301 [I-D.ietf-behave-v6v4-framework] 302 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 303 IPv4/IPv6 Translation", 304 draft-ietf-behave-v6v4-framework-03 (work in progress), 305 October 2009. 307 [I-D.ietf-sipping-nat-scenarios] 308 Boulton, C., Rosenberg, J., Camarillo, G., and F. Audet, 309 "Best Current Practices for NAT Traversal for Client- 310 Server SIP", draft-ietf-sipping-nat-scenarios-09 (work in 311 progress), September 2008. 313 [I-D.ietf-sipping-v6-transition] 314 Camarillo, G., "IPv6 Transition in the Session Initiation 315 Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work 316 in progress), August 2007. 318 [I-D.van-beijnum-behave-ftp64] 319 Beijnum, I., "IPv6-to-IPv4 translation FTP 320 considerations", draft-van-beijnum-behave-ftp64-06 (work 321 in progress), October 2009. 323 [I-D.wing-behave-http-ip-address-literals] 324 Wing, D., "Coping with IP Address Literals in HTTP URIs 325 with IPv6/IPv4 Translators", 326 draft-wing-behave-http-ip-address-literals-00 (work in 327 progress), October 2009. 329 [I-D.wing-behave-learn-prefix] 330 Wing, D., "Learning the IPv6 Prefix of a Network's IPv6/ 331 IPv4 Translator", draft-wing-behave-learn-prefix-04 (work 332 in progress), October 2009. 334 Appendix A. HTTP IPv4 Address Literals on the Internet 336 There has been some doubt that HTTP URIs on the Internet contain 337 hostnames with IPv4 address literals. This section provides some 338 scripts which demonstrate the relatively low -- but prevalent -- 339 existence of IPv4 address literals. 341 An examination of Alexa's top 1 million domains [Alexa] at the end of 342 August, 2009, showed 2.38% of the HTML in their home pages contained 343 IPv4 address literals. This can be verified with: 345 wget http://s3.amazonaws.com/alexa-static/top-1m.csv.zip 346 unzip top-1m.csv.zip 347 cat top-1m.csv | 348 cut -d "," -f 2 | 349 xargs -I % -n 1 -t wget -nv % -O - --user-agent="Mozilla/5.0" | 350 grep -E "https?://[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" 352 Of the top 1 million websites at the end of August, 2009, 3455 353 (0.35%) of them are IPv4 address literals (e.g., http://192.0.2.1). 354 This can be verified with: 356 wget http://s3.amazonaws.com/alexa-static/top-1m.csv.zip 357 unzip top-1m.csv.zip 358 grep -E "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" 359 top-1m.csv | wc 361 Author's Address 363 Dan Wing 364 Cisco Systems, Inc. 365 170 West Tasman Drive 366 San Jose, CA 95134 367 USA 369 Email: dwing@cisco.com