idnits 2.17.1
draft-vyncke-http-server-64aware-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 329.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 340.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 347.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 353.
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 :
----------------------------------------------------------------------------
== There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses
in the document. If these are example addresses, they should be changed.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (September 17, 2008) is 5693 days in the past. Is
this intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force E. Vyncke
3 Internet-Draft Cisco Systems
4 Intended status: Informational September 17, 2008
5 Expires: March 21, 2009
7 IPv6 Connectivity Check and Redirection by HTTP Servers
8 draft-vyncke-http-server-64aware-00
10 Status of this Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on March 21, 2009.
35 Abstract
37 Rather than forcing the client to decide whether IPv4 or IPv6 is more
38 convenient to reach a web server; this document proposes to let the
39 web server check whether there is IPv6 connectivity to the client;
40 then the web server can do a HTTP redirect to the force the client to
41 use IPv6.
43 This is done easily by a script within the server HTML pages and does
44 not require any change in the client applications or configuration.
45 The client still can control whether he/she wants to enabled IPv6.
47 This draft could be discussed on the Applications Discuss mailing
48 list, https://www.ietf.org/mailman/listinfo/apps-discuss.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
54 2. Verifying IPv6 Connectivity and Redirection . . . . . . . . . . 3
55 2.1. How can this be done? . . . . . . . . . . . . . . . . . . . 3
56 2.1.1. Example of HTML and Ecmascript Code . . . . . . . . . . 4
57 2.1.2. Proof of Concept . . . . . . . . . . . . . . . . . . . 5
58 2.2. Benefits of this Technique . . . . . . . . . . . . . . . . 5
59 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 6
60 3.1. Improving the User's Experience . . . . . . . . . . . . . . 6
61 3.2. Extension to only measure the amount of IPv6 capable
62 client . . . . . . . . . . . . . . . . . . . . . . . . . . 6
63 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
65 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
66 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7
67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
68 Intellectual Property and Copyright Statements . . . . . . . . . . 9
70 1. Introduction
72 It is often claimed that web servers are not dual-stack because the
73 IPv6 has poor connectivity. Therefore, little to no web servers are
74 dual-stacks; it is common to find the same content on www.example.com
75 (for IPv4 access) and on ipv6.example.com (for IPv6 access).
77 The drawback of this setup is that once a user uses www.example.com,
78 then all his/her communication will be over IPv4. This document
79 proposes that the web server MAY run a dynamic and transparent check
80 for the IPv6 connectivity between the client and the server and if
81 there is IPv6 connectivity, then the client MAY be transparently
82 redirected to the IPv6 server, i.e. ipv6.example.com.
84 The check and the redirect can easily be done by a script within the
85 server HTML pages and MUST NOT require any change in the client
86 applications or configuration. The client still can control whether
87 he/she wants to enabled IPv6.
89 1.1. Requirements Language
91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
93 document are to be interpreted as described in RFC 2119 [RFC2119].
95 2. Verifying IPv6 Connectivity and Redirection
97 2.1. How can this be done?
99 The procedure can be described as:
101 1. the IPv4 web server has a start page which includes a small
102 transparent image which is located on the ipv6.example.com web
103 server. Note: this kind of image is often used on web sites to
104 count access or as a spacer; it is usually a 1 by 1 pixel image.
106 2. the HTML SRC tag includes two events: onload() and onerror()
107 which are commonly implemented in browsers.
109 3. if the client has only access to IPv4: the image will fail to
110 load but the overall aspect of the web page will not be affected
111 as the size of the error is only 1 by 1 pixel. The onerror()
112 event is also triggered which could lead to change the web page
113 content (see the code example (Section 2.1.1)) or even replace
114 the 1x1 image by another 1x1 image reachable over IPv4.
116 4. if the client has also access to IPv6 (i.e. it has the IPv6
117 protocol installed and has a valid IPv6 connectivity), then the
118 image will load and the onload() event will be triggered. The
119 script code associated with the onload() can force an immediate
120 redirect of the client to the IPv6 web content.
122 All the above is only implemented in the HTTP server and does not
123 require any change in the client even if the actual script is done by
124 the client browser.
126 The redirect is also mostly transparent to the user.
128 The IPv6 connectivity works independently whether the client has
129 configured IPv4 or IPv6 as his/her preferred protocol. For instance,
130 it will work with Teredo [RFC4380] tunnels even if those are usually
131 configured as less preferrable than IPv4.
133 2.1.1. Example of HTML and Ecmascript Code
135 Here is an example in HTML [HTML] and in ECMAscript ECMA-262
136 [ECMA-262] (also known as Javascript). It demonstrates two things
137 which occur when IPv6 connectivity is detected (see the function
138 IPv6Image()):
140 1. the appearance of the web page is changed (a text about IPv6 is
141 displayed) and could now differ from the IPv4 only web page; this
142 step is optional;
144 2. a immediate redirection to http://ipv6.example.com is executed;
145 this is the core step.
147 Here is the HTML image tag which MUST include the onload() event and
148 MAY include the onerror() event. It MAY be followed by a HTML span
149 element which is used to display the result of the IPv6 connectivity
150 check.
152
155 Checking whether you have IPv6 access...
156 The example below implements the mandatory onload() event handler,
157 IPv6Image(), which redirects to the IPv6 version of the web site and
158 the optional onerror() event handler, NoIPv6Image(), which is
159 triggered when IPv6 connectivity does not exist (in this example, it
160 is used to display a message).
162
179 2.1.2. Proof of Concept
181 There is a very simple proof of concept of this technique. It is
182 hosted on a web server at the University of Liege in Belgium and can
183 be reached via the following URI:
185 http://sigma.hec.be/~evyncke/family/ip.php: the normal dual-stack
186 URI.
188 http://193.190.125.15/~evyncke/family/ip.php: if you would like to
189 check the technique as if your browser preferred IPv4.
191 http://[2001:6a8:2c80:1::15]/~evyncke/family/ip.php: if you would
192 like to check the technique as if your browser preferred IPv6.
194 2.2. Benefits of this Technique
196 The main benefit of this technique is that there is nothing to
197 install or to configure at the client side. Nevertheless, the client
198 has still the possibility to use only IPv4 by configuring his/her
199 protocol stacks.
201 Another benefit is that there is basically little connectivity risk
202 associated with this procedure, the client is redirect to the IPv6
203 version of the web server only if a HTTP transaction has been
204 completed successfully over IPv6. This transaction is a normal HTTP
205 transaction with full TCP handshake and HTTP protocol, so, it
206 includes several IPv6 datagrams of varying size. Therefore, if it is
207 successful then the IPv6 connectivity between the client and the
208 server has been proven.
210 Note: if Path MTU Discovery is a concern, the 1x1 pixel image could
211 changed to a larger one as long as it is kept transparent. As soon
212 as the larger image exceeds 1,500 bytes, Path MTU discovery will need
213 to be successful to display the image and to trigger the intrinsic
214 event 'onload()'.
216 3. Extensions
218 This section briefly describes potential extensions of this
219 technique.
221 3.1. Improving the User's Experience
223 By using another script associated to the onload() event, the user
224 experience could be improved:
226 The default page can dynamically be updated to reflect the
227 availability of IPv6 connectivity;
229 A pop-up window can be displayed asking the user whether he/she
230 wants to be redirect to the IPv6 version of the web server;
232 A HTTP [RFC2616] can be used by the web server to remember the
233 user's decision.
235 3.2. Extension to only measure the amount of IPv6 capable client
237 Rather then taking the drastic decision of redirecting its client to
238 its IPv6 content, the web server can simply log the result of the
239 connectivity check:
241 o IPv4 client with no IPv6 connectivity;
243 o IPv4 client with IPv6 connectivity.
245 This can be achieved by loading the 1x1 image over IPv6 but the image
246 source is no more a static image file but rather a server script
247 (PHP, Perl, etc.) which is called with the IPv4 address of the client
248 as an argument. Even if the server script execution (used to
249 generate the image) is initiated over IPv6, it can retrieve the
250 original IPv4 address from the HTTP query and log the association
251 between the IPv4 and IPv6 addresses.
253 The PHP [PHP] code fragment below shows how it can be done. This
254 fragment is run when the dual-stack client connects to
255 www.example.com; it collects the client IPv4 address with the help of
256 $_SERVER['REMOTE_ADDR'] and passes it as an argument to the
257 1x1pixel.php server script which is accessed over IPv6.
259
264 4. Acknowledgements
266 This I-D is based on some discussions with Chip Popoviciu.
268 5. IANA Considerations
270 This memo includes no request to IANA.
272 6. Security Considerations
274 No security issue has been identified.
276 Note: this technique requires to enable script execution on the
277 client browser; this setting is sometimes deemed less secure than
278 preventing the execution of any script by the browser.
280 7. Normative References
282 [ECMA-262]
283 ECMA, "ECMAScript Language Specification", 1999, .
287 [HTML] W3C, "HTML 4.01 Specification", 1999,
288 .
290 [PHP] The PHP Group, "PHP: Hypertext Preprocessor",
291 .
293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
294 Requirement Levels", BCP 14, RFC 2119, March 1997.
296 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
297 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
298 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
300 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
301 Network Address Translations (NATs)", RFC 4380,
302 February 2006.
304 Author's Address
306 Eric Vyncke
307 Cisco Systems
308 De Kleetlaan, 6A
309 Diegem, B-1831
310 Belgium
312 Phone: +32 2 778 4677
313 Email: evyncke@cisco.com
315 Full Copyright Statement
317 Copyright (C) The IETF Trust (2008).
319 This document is subject to the rights, licenses and restrictions
320 contained in BCP 78, and except as set forth therein, the authors
321 retain all their rights.
323 This document and the information contained herein are provided on an
324 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
325 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
326 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
327 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
328 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
329 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
331 Intellectual Property
333 The IETF takes no position regarding the validity or scope of any
334 Intellectual Property Rights or other rights that might be claimed to
335 pertain to the implementation or use of the technology described in
336 this document or the extent to which any license under such rights
337 might or might not be available; nor does it represent that it has
338 made any independent effort to identify any such rights. Information
339 on the procedures with respect to rights in RFC documents can be
340 found in BCP 78 and BCP 79.
342 Copies of IPR disclosures made to the IETF Secretariat and any
343 assurances of licenses to be made available, or the result of an
344 attempt made to obtain a general license or permission for the use of
345 such proprietary rights by implementers or users of this
346 specification can be obtained from the IETF on-line IPR repository at
347 http://www.ietf.org/ipr.
349 The IETF invites any interested party to bring to its attention any
350 copyrights, patents or patent applications, or other proprietary
351 rights that may cover technology that may be required to implement
352 this standard. Please address the information to the IETF at
353 ietf-ipr@ietf.org.