Closed Bug 621558 Opened 11 years ago Closed 10 years ago

Implement "happy eyeballs" IPv6 autodetection at TCP open, or similar


(Core :: Networking: HTTP, enhancement)

Not set





(Reporter: usenet, Assigned: Biesinger)


(Blocks 1 open bug)


(Keywords: dev-doc-complete)


(1 file)

At the moment, many dual-stack environments are wholly or partially broken, presenting problems for seamless IPv6 deployment. Long timeouts are bad for users, making the system appear to be broken. "Happy Eyeballs: Successful Introduction of New Technology to HTTP" suggests the use of overlapped attempts to resolve names for and to open IPv4 and IPv6 sockets to HTTP-like network endpoints as a way to autodetect IPv6 operation in a dual-stack environment, without significantly degrading performance if that environment is broken.

Support for this, or something similar, in the core networking code would greatly ease the development of practical IPv6 interoperability in Mozilla products. The Internet-Draft describes a number of heuristics that may be possible to improve upon over time -- if this code were to be implemented centrally, this would also provide a good place to implement these new heuristics.
Duplicate of this bug: 657426
The canary build of Google Chrome implements a variant of parallel connect
that reduces latency of broken IPv6 connections from 20 / 75 seconds to 300

In many cases (e.g., for hostnames you've already been before), it
preconnects anyway, so by the time you've hit enter, there is no latency hit
at all.
Blocks: IPv6
Assignee: nobody → honzab.moz

for discussion of the current state of this functionality in Google Chrome.
Blocks: 662740
Assignee: honzab.moz → cbiesinger
Chrome's implementation works quite nicely.  Given a "broken user" configuration with respect to IPv6, the failover is almost not noticeable; yet there is still a good 300ms bias towards preferring IPv6 (versus the future of IPv4 and NAT).
Attachment #543434 - Flags: review? → review?(mcmanus)
Comment on attachment 543434 [details] [diff] [review]

>@@ -1315,16 +1316,19 @@ nsHalfOpenSocket::SetupStreams(nsISocket
>     PRUint32 tmpFlags = 0;
>     if (mTransaction->Caps() & NS_HTTP_REFRESH_DNS)
>         tmpFlags = nsISocketTransport::BYPASS_CACHE;
>     if (mTransaction->Caps() & NS_HTTP_LOAD_ANONYMOUS)
>         tmpFlags |= nsISocketTransport::ANONYMOUS_CONNECT;
>+    if (isBackup)
>+        tmpFlags |= nsISocketTransport::DISABLE_IPV6;

Please add a comment.  The purpose of disabling IPv6 on the backup connection
is not obvious at all.
With this patch, is backup connection disabled for IPv6 only hosts?
Comment on attachment 543434 [details] [diff] [review]

Review of attachment 543434 [details] [diff] [review]:

I think a comment in ::SetupStreams pointing to happy eyeballs, and we're all set.

This is great. This kind of code also makes me very glad we're on rapid releases.
Attachment #543434 - Flags: review?(mcmanus) → review+
(In reply to comment #7)
> With this patch, is backup connection disabled for IPv6 only hosts?

Yes. I see no good way around that; fortunately, IPv6-only hosts are rare on the current internet.

Comment added and pushed:
Closed: 10 years ago
Resolution: --- → FIXED
After being asked about this in private mail and thinking about it some more, I came to the conclusion that fixing the IPv6-only issue is actually not too hard. Filed bug 669159
Duplicate of this bug: 199333
Duplicate of this bug: 662544
This was added for Firefox 7.
Documentation updated:

Also, a brief note about "happy eyeballs" is added at the top of the nsIDNSService page.

Mentioned on Firefox 7 for developers as well.
This implementation not exaclty "happy-eyeball". I would call it quick fall-back to IPv4. Can make enable/disable user configurable?
Blocks: 679090
I would like to reopen this bug.  Please see Bug 679090 (I've provided logs).  I *think* the problem is that after 250ms this code assumes that IPv6 is broken, when it's not.

As a result, before I can navigate any ipv6-only site I have to reload many times, until my DNS server resolves all queries from its cache and Firefox (based on the response time) decides that the IPv6 stack is sane.

From where I am, resolving the first time took 561 msec.  Sometimes it takes longer.  For IPv4 times are more or less the same.  I think this type of "happy eyeball" based on fixed times just doesn't work.

By the way, on the same machine, under the same conditions and delays chromium does show

Could we reverse this patch (it can still be easily done on trunk) until we can better assess the impact?
Blocks: 680466
This doesn't seem to work. I tried both Firefox 7.0b4 (20110902161802) and Aurora 8.0a2 (20110907042004).

To reproduce, set up a broken IPv6 connection with the following commands:

sudo ip tunnel add sit1 mode sit local any remote
sudo ip addr add 2001:db8::1 dev sit1
sudo ip link set sit1 up
sudo ip -6 route add default dev sit1 metric 1

Then launch Firefox and try to go to, or

Expected: page loads quickly after 300ms.
Actual: page hangs for many seconds before loading.

(To clean up: sudo ip tunnel del sit1)
Resolution: FIXED → ---
Looks like fast-fallback was disabled due to bug 679090. Leaving this bug as reopened until it's re-enabled.
we have bug 684893 for getting it re-enabled
Blocks: 684893
We don't need 2 bugs. Use 684893 for new work.
No longer blocks: 684893
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Blocks: 684893
Duplicate of this bug: 213121
You need to log in before you can comment on or make changes to this bug.