[Webkit-unassigned] [Bug 145162] New: ipv4 fallback fails for hung ipv6 connections

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=145162

            Bug ID: 145162
           Summary: ipv4 fallback fails for hung ipv6 connections
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: Macintosh
                OS: Mac OS X 10.10
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: seth at codecopse.net

Created attachment 253371
  --> https://bugs.webkit.org/attachment.cgi?id=253371&action=review
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 (https://en.wikipedia.org, http appears to work fine inasmuch as I can get and follow the redirect to https):

    # time curl -m 10 -6 --trace - https://en.wikipedia.org     
    == Info: Rebuilt URL to: https://en.wikipedia.org/
    == 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 - https://en.wikipedia.org  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 - https://google.com
    == Info: Rebuilt URL to: https://google.com/
    == 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 - https://google.com  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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150519/4569f162/attachment-0001.html>