<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - ipv4 fallback fails for hung ipv6 connections"
href="https://bugs.webkit.org/show_bug.cgi?id=145162">145162</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>ipv4 fallback fails for hung ipv6 connections
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>Product</th>
<td>WebKit
</td>
</tr>
<tr>
<th>Version</th>
<td>528+ (Nightly build)
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Macintosh
</td>
</tr>
<tr>
<th>OS</th>
<td>Mac OS X 10.10
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>Normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P2
</td>
</tr>
<tr>
<th>Component</th>
<td>Page Loading
</td>
</tr>
<tr>
<th>Assignee</th>
<td>webkit-unassigned@lists.webkit.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>seth@codecopse.net
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=253371" name="attach_253371" title="Screenshot of stuck loading progress">attachment 253371</a> <a href="attachment.cgi?id=253371&action=edit" title="Screenshot of stuck loading progress">[details]</a></span>
Screenshot of stuck loading progress
My network presents a peculiar failure mode when using IPv6: It almost always allows successful connection establishment (over a 6to4 tunnel), but frequently hangs in the middle of e.g. an SSL handshake. WebKit's response to this behavior is to wait forever in the early stages of page load – see attached screenshot. I am able to work around the problem by simply disabling IPv6 altogether, but that seems counterproductive to the overall ip6 adoption effort.
Steps to Reproduce:
1. Recreate the network environment that hangs ip6 traffic for established connections, but allows ip4 traffic to flow normally
I suspect this is possible with some permutation of `ip6tables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j DROP`
See below for some example curl/nc output that hopefully demonstrates the desired scenario
2. Attempt to load a page
Effect: Safari waits forever for the dropped packets
Desired Behavior: In preference order:
1. Some "Happy Eyeballs" heuristic that incorporates time to first byte (which the non-hung IPv4 connection will always win).
2. Safari times out the stalled connection and retries over IPv4, which loads the page normally.
3. A mechanism to control IPv6 connectivity on a page-by-page basis; i.e. a {white,black}list of sites that allows me to manually force certain websites to prefer IPv4.
4. A mechanism to disable IPv6 connectivity for all of Safari, which allows me to continue to use
Thanks! Please let me know if I can provide any additional detail.
Example curl of a failing website (<a href="https://en.wikipedia.org">https://en.wikipedia.org</a>, http appears to work fine inasmuch as I can get and follow the redirect to https):
# time curl -m 10 -6 --trace - <a href="https://en.wikipedia.org">https://en.wikipedia.org</a>
== Info: Rebuilt URL to: <a href="https://en.wikipedia.org/">https://en.wikipedia.org/</a>
== Info: Hostname was NOT found in DNS cache
== Info: Trying 2620:0:861:ed1a::1...
== Info: Connected to en.wikipedia.org (2620:0:861:ed1a::1) port 443 (#0)
== Info: Operation timed out after 0 milliseconds with 0 out of 0 bytes received
== Info: Closing connection 0
curl: (28) Operation timed out after 0 milliseconds with 0 out of 0 bytes received
curl -m 10 -6 --trace - <a href="https://en.wikipedia.org">https://en.wikipedia.org</a> 0.01s user 0.01s system 0% cpu 10.016 total
This in opposition to a network route that works:
# time curl -m 10 -6 --trace - <a href="https://google.com">https://google.com</a>
== Info: Rebuilt URL to: <a href="https://google.com/">https://google.com/</a>
== Info: Hostname was NOT found in DNS cache
== Info: Trying 2607:f8b0:400a:806::200e...
== Info: Connected to google.com (2607:f8b0:400a:806::200e) port 443 (#0)
== Info: TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
== Info: Server certificate: *.google.com
== Info: Server certificate: Google Internet Authority G2
== Info: Server certificate: GeoTrust Global CA
=> Send header, 74 bytes (0x4a)
<snip>
== Info: Connection #0 to host google.com left intact
curl -m 10 -6 --trace - <a href="https://google.com">https://google.com</a> 0.04s user 0.01s system 4% cpu 1.074 total
nc -z demonstrates no such problem:
# time nc -z6 en.wikipedia.org 443
Connection to en.wikipedia.org port 443 [tcp/https] succeeded!
nc -z6 en.wikipedia.org 443 0.00s user 0.00s system 2% cpu 0.196 total
# time nc -z6 google.com 443
Connection to google.com port 443 [tcp/https] succeeded!
nc -z6 google.com 443 0.00s user 0.00s system 2% cpu 0.217 total</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>