idnits 2.17.1 draft-wing-behave-http-46-relay-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 5297 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-03 -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: Standards Track October 26, 2009 5 Expires: April 29, 2010 7 Relaying HTTP from IPv4 to IPv6 8 draft-wing-behave-http-46-relay-02 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 As IPv6-only hosts become commonplace, it is desirable to still have 47 IPv4 clients access those IPv6-only hosts. Due to the size of the 48 IPv4 and IPv6 address spaces, this has proven difficult using pure IP 49 address translation. Rather than trying to support all IP protocols, 50 or even all TCP or UDP applications, this document proposes a 51 mechanism for an IPv4 HTTP client to connect to an IPv6-only HTTP 52 server. 54 Terminology 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in [RFC2119]. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. Approch 1: HTTP Relay . . . . . . . . . . . . . . . . . . . 3 65 2.2. Approach 2: Redirection . . . . . . . . . . . . . . . . . . 4 66 2.2.1. User Experience Considerations . . . . . . . . . . . . 6 67 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 72 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 Two of the scenarios considered by the BEHAVE working group are 78 Scenario 2, "the IPv4 Internet to an IPv6 network" and Scenario 6, 79 "an IPv4 network to an IPv6 network" 80 [I-D.ietf-behave-v6v4-framework]. A difficulty with these scenario 81 is that one IPv4 address is consumed for every IPv6 server, using a 82 1:1 mapping. This 1:1 mapping can be economized by temporarily 83 mapping an IPv4 address to an IPv6 address 84 [RFC2766][I-D.perkins-sourceipnat]. However, such economizing can 85 cause some IPv6 hosts to be inaccessible when all of the available 86 IPv4 addresses are temporarily in the process of completing their 87 flow assignments, even though many different IPv6 destinations remain 88 typically available at each IPv4 address via flow assignments that 89 have already been completed. 91 To avoid this problem, the mechanism described in this paper solves 92 the problem only for HTTP initiated from the IPv4 network towards the 93 IPv6 network, and uses features of HTTP to provide access to the HTTP 94 server. 96 The mechanism described in this paper requires at least one IPv4 TCP 97 port be routed to the IPv6 host's HTTP server. This is possible with 98 stateful NAT64 translation (with a configured static mapping), 99 stateless NAT64 translation, and port- mapped stateless NAT64 100 translation. 102 2. Operation 104 Two approaches are proposed. The approaches can be deployed at the 105 same time on the same network, and appear different to the users of 106 typical web browsers. 108 2.1. Approch 1: HTTP Relay 110 The simpliest method is to perform an HTTP relay function, similar to 111 a reverse HTTP proxy. The relay would listen for incoming HTTP 112 requests, for many FQDNs, on the IPv4 network. Using HTTP's "host:" 113 header it would relay the HTTP request to the appropriate host on the 114 IPv6 network. 116 The first few steps, where the in-home PC communicates with the HTTP 117 relay, are out of scope of this paper. This might be done via a 118 customer portal web page, for example. 120 <-subscriber-> <--Internet-> 121 <---------IPv6-------------->|<---------IPv4---------------> 122 in-home | 123 in-home HTTP server HTTP DNS 124 PC on port 80 relay server HTTP client 125 | | | | | 126 [ |--Webcam has IP=A, port=B-->| ] | | 127 [ |<-Ok, I will redirect there-| ] | | 128 | | | | | 129 | ... ... ... ... 130 | | |<--A?-----| 131 | | | |---A----->| 132 | | |<-TCP SYN, SYNACK, ACK->| 133 | | |<-HTTP GET--------------| 134 | |<---TCP SYN---------| | | 135 | |----TCP SYNACK----->| | | 136 | |<---TCP ACK---------| | | 137 | |<---HTTP GET--------| | | 138 | |<---data----------->|----------------------->| 139 | | | | | 141 Figure 1: HTTP Proxy, IPv4 client to IPv6 server 143 Notes: 145 o A drawback of this method is that all HTTP traffic goes through 146 the HTTP relay. This approach is constrained by the HTTP relay's 147 bandwidth, packets per second, and maximum number of sessions. 149 o The HTTP relay can be operated by anyone on the Internet, 150 including the ISP providing access service. 152 2.2. Approach 2: Redirection 154 To avoid the costs of TCP relaying, the service provider can also 155 provide HTTP redirection. The HTTP redirector uses the HTTP "host:" 156 header and its knowledge of the static IPv4/IPv6 mapping in the 6/4 157 NAT to respond with an HTTP redirect message containing a Location 158 header pointing to the IPv4 address and port that maps to the 159 requested IPv6 host. If the HTTP client indicated it supports 160 HTTP/1.1, a 307 redirect SHOULD be used; for HTTP/1.0, a 302 redirect 161 SHOULD be used. 163 Compared with the previous approach, only the initial HTTP 164 transaction occurs with the HTTP redirector. Subsequent HTTP traffic 165 is through the 6/4 NAT itself. Because the HTTP redirection can be 166 to a specific port, approximately 64K IPv6 hosts can be served in 167 this manner. However, the redirection changes the web browser's 168 address bar, which can make this approach unappealing; see also 169 Section 2.2.1. 171 The first few steps, where the in-home PC communicates with the 6/4 172 NAT to acquire a permanent mapping and communicates this mapping to 173 the HTTP redirector, are out of scope of this paper. Some 6/4 174 translation mechanisms would not require that step (e.g., port-mapped 175 stateless translation). These steps might be done with a customer 176 portal web page, for example. 178 <---subscriber---> <--Internet-> 180 (IE, Firefox, 181 in-home Safari, Opera) 182 in-home HTTP server 6/4 HTTP DNS unmodified 183 PC on port 80 NAT redirector server HTTP client 184 | | | | | | 185 [ |---give me a port->| | ] | | 186 [ |<--IP=A, port=B----| | ] | | 187 [ |--Webcam has IP=A, port=B-->| ] | | 188 [ |<-Ok, I will redirect there-| ] | | 189 | | | | | | 190 | ... ... ... ... ... 191 | | | |<--A?-----| 192 | | | | |---A----->| 193 | | | |<-TCP SYN, SYNACK, ACK->| 194 | | | |<---HTTP GET------------| 195 | | | |----HTTP 30x redirect-->| 196 | | | |<-TCP FIN, FINACK, ACK->| 197 | ||--TCP SYNACK-------------------->| 199 | || 202 | | | | | | 204 Figure 2: HTTP Redirection, IPv4 client to IPv6 server 206 Notes: 208 o The most optimal performance is obtained if the HTTP clients 209 support HTTP/1.1 persistent connections and the in-home HTTP 210 server uses relative URIs. In this way, the TCP connection from 211 the HTTP client to HTTP server only hits the HTTP redirector once. 213 o The HTTP redirector can be operated by anyone on the Internet, 214 including the ISP providing access service. 216 2.2.1. User Experience Considerations 218 A drawback of redirection is the URL displayed in the address bar 219 changes. It can reduce the professional appearance of a website to 220 have the URL displayed in the browser re-written to include a port 221 number or a name associated with the ISP's 6/4 translater, rather 222 than a pretty domain name. It is possible to obscure this 223 redirection from most web browsers using frames. 225 For example, the following frame redirects the user to a long URI 226 without changing the URI seen on the address bar of most browsers: 228 229 230 231 232 234 3. Security Considerations 236 Logging on the HTTP server works differently if the HTTP connection 237 is relayedSection 2.1, because all connections appear to come from 238 the ISP's HTTP relay device. The IP address of the original client 239 could be conveyed using the de facto standard X-Forwarded-For [XFF] 240 header. 242 4. IANA Considerations 244 This document does not require any IANA action. 246 5. Acknowledgements 248 The mechanism described in this draft is based on existing "web 249 redirection" services provided by a number of services on the 250 Internet (e.g., [DynDNS]), extended to describe similar operation 251 with IPv4/IPv6 translators. 253 Thanks to Patrik Faltstrom and Bob Van Zant for their review 254 comments. 256 6. References 257 6.1. Normative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 6.2. Informative References 264 [DynDNS] DynDNS, "Web Redirection", September 2009, 265 . 267 [I-D.ietf-behave-v6v4-framework] 268 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 269 IPv4/IPv6 Translation", 270 draft-ietf-behave-v6v4-framework-03 (work in progress), 271 October 2009. 273 [I-D.perkins-sourceipnat] 274 Perkins, C., "Translating IPv4 to IPv6 based on source 275 IPv4 address", draft-perkins-sourceipnat-01 (work in 276 progress), October 2009. 278 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 279 Translation - Protocol Translation (NAT-PT)", RFC 2766, 280 February 2000. 282 [XFF] Wikipedia, "Description of X-Forwarded-For header", 283 October 2009, 284 . 286 Author's Address 288 Dan Wing 289 Cisco Systems, Inc. 290 170 West Tasman Drive 291 San Jose, CA 95134 292 USA 294 Email: dwing@cisco.com