If ipv6 is not disabled and there is an ipv6 address, always try it first

ASSIGNED
Assigned to

Status

()

P3
normal
ASSIGNED
5 years ago
19 days ago

People

(Reporter: the.decryptor, Assigned: dragana)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [IPV6][necko-backlog])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Created attachment 809648 [details]
Screen Shot 2013-09-25 at 2.31.18 PM.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20130924030202

Steps to reproduce:

In recent versions of OS X, Apple provides an internal implementation of "Happy Eyeballs" in the getaddrinfo() API that often sorts perfectly working IPv6 addresses after IPv4 addresses if they are even 1ms slower to respond, this causes Firefox to simply stop using IPv6 to communicate with the host, as it seems to use the results provided directly and sees an IPv4 address first (bypassing the implementation of Happy Eyeballs in Firefox)

This can be seen in long lived connections like Gmail, where Firefox will switch from IPv6 to IPv4 randomly over the course of the day as connections are re-established, and OS X sorts the results differently.

The one upside to this is that there's no user visible breakage, it just results in an under utilisation of IPv6 connectivity as shown here: https://labs.ripe.net/Members/emileaben/hampered-eyeballs


Actual results:

1) Connect to example.org
2) OS X might return sorted address list placing IPv4 addresses first
3) Firefox connects to IPv4 address first, not attempting IPv6


Expected results:

1) Connect to example.org
2) OS X might return sorted address list placing IPv4 addresses first
3) Firefox connects to IPv6 address first anyway, then attempting IPv4 if IPv6 doesn't work
(Reporter)

Updated

5 years ago
Blocks: 136898
Summary: [OS X] System "Happy Eyeballs" leads to spurious IPv4 fallback → [OS X] System provided "Happy Eyeballs" leads to spurious IPv4 fallback from IPv6
Whiteboard: [IPV6]

Comment 1

5 years ago
I am seeing this as well.
(Assignee)

Comment 2

4 years ago
Created attachment 8447001 [details] [diff] [review]
bug920367-fix-v1.patch

This patch will always put IPv6 first, except disableIPv6 is set
Attachment #8447001 - Flags: review?(mcmanus)
Do we ignore operating system's preference on all platforms?
(Assignee)

Comment 4

4 years ago
The list received from getaddrinfo will take into account operating system's preference. If we do any rearrangement of this list we are going to ignore it. (the patch above does it).

Do we check somewhere in the code for preferences expicitly? (mPreferIPv6 is set depending on this list)
We can fix Apple problem by ignoring OS's preference or we can do an additional check of the preference.
Flags: needinfo?(mcmanus)
(In reply to Masatoshi Kimura [:emk] from comment #3)
> Do we ignore operating system's preference on all platforms?

right now, yes this is consistent
Flags: needinfo?(mcmanus)
so this has the rather global impact of preferring v6 on all platforms, all the time (which is rather broader than the title of the bug). I think the time has come to give this a try if we have some kind of metric we can watch - afterall the current code is rather agnostic as to what it is using.

dragana, do you have a suggestion on a metric? (perhaps rate of syn-retry, which I think we would need to collect?)

(sorry that this is so blast from the past - spring cleaning)
Flags: needinfo?(dd.mozilla)
Attachment #8447001 - Flags: review?(mcmanus) → review+
(Assignee)

Updated

3 years ago
Summary: [OS X] System provided "Happy Eyeballs" leads to spurious IPv4 fallback from IPv6 → If there is a ipv6 address try it first if ipv6 is not disabled
(Assignee)

Updated

3 years ago
Depends on: 1177848
Flags: needinfo?(dd.mozilla)
(Assignee)

Updated

3 years ago
Assignee: nobody → dd.mozilla
(Assignee)

Updated

3 years ago
OS: Mac OS X → All
Hardware: x86 → All
(Assignee)

Updated

3 years ago
Summary: If there is a ipv6 address try it first if ipv6 is not disabled → If ipv6 is not disabled and there is an ipv6 address, always try it first
(Assignee)

Comment 9

3 years ago
Created attachment 8656546 [details] [diff] [review]
bug920367-fix-v1.patch

rebased.
Attachment #8447001 - Attachment is obsolete: true
Attachment #8656546 - Flags: review+

Comment 10

3 years ago
If I'm reading the patch correctly, it unconditionally sorts v6 addresses above v4 ones. This is specifically against RFC 3484/6724; we should either just trust the OS resolver to do the right thing, or we should sort addresses correctly (which is a lot harder than it sounds, especially considering the system admin can specify their own custom ordering rules).

This bug report was about OS X's resolver, which I'm aware does _not_ do the right thing, but a) that means that any attempts at workarounds ought to be OS X-only, and b) since this bug was filed, the OS X resolver has been changed to give v6 a significant head-start, so the original problem of switching between v6 and v4 constantly should be mostly fixed by Apple.
(Reporter)

Comment 11

3 years ago
I haven't had a chance to try 10.11 personally, but I've got a friend who's running it (And also has IPv6, lucky) and they can't reproduce the bad behavior I'm seeing.

This isn't needed for Linux and Windows, but even with the changes in 10.11 I'm inclined to think that Firefox should be smarter here. I'm not sure if there's a way to read the OS level preference, but if IPv6 is enabled at the OS/adapter level and IPv4 isn't specifically preferred, then Firefox should at least try a IPv6 address first, even if it's sorted behind IPv4 addresses.
(Assignee)

Comment 12

3 years ago
This is an experiment. It is going to be just in Nightly for some time and if it is to annoying for to many people it is going to be out in a day :)

We are just interested to see how many broke ipv6 are there. 

Bug 1177848 added a bit of telemetry for this and I want to see how bad it is going to be.

Comment 13

3 years ago
There's a few cases where you should be preferring v4. If the server uses 6to4 or Teredo, then native v4 will give a better experience to that server. If they're ULA and the client doesn't have a ULA address, then the connection will probably fail over v6 anyway. If the _client_ only has 6to4/Teredo, then v4 will give a better experience to most servers. (getaddrinfo() handles all these cases by default.) And if the user has configured an override (e.g. "always prefer v6 even if 6to4/Teredo", "always prefer v4", or "prefer v6 except for a few specific hosts") then they must've had a reason for it.

(User config goes in /etc/gai.conf for Linux and somewhere in the registry for Windows; you can view it with `netsh interface ipv6 show prefixpolicies`.)

Also, I'm not sure what this will tell us about broken v6. In its current form, it'll just cause a lot of v6 connection failures on v4-only hosts (except not on Windows, because Windows doesn't do AAAA queries unless it thinks you have v6 or you explicitly ask for them to happen), and if you restrict it only to hosts with v6 available then you'll be matching getaddrinfo()'s behavior for most queries anyway.
we should do this in 48
Whiteboard: [IPV6] → [IPV6][necko-active]

Comment 15

3 years ago
Comment 14 says "we should do this in 48". Pray, what is "this"? 

As per http://www.test-ipv6.com/faq_avoids_ipv6.html, Firefox does try an IPv6 address and falls back to IPv4 if the 300ms timer expires. I just filed Bug 1271079 asking that there be an ability to either (i) disable Happy Eyeballs, and (ii) configure the timeout.

I am behind a he.net tunnel and for some reason I keep getting a surly panda instead of a running unicorn at http://ismyipv6working.com/. I can confirm that till at least 6 months back, Firefox did show me the running unicorn.

Also http://www.test-ipv6.com/ gives me a 10/10

For a change the Microsoft browsers behave as intended.
Whiteboard: [IPV6][necko-active] → [IPV6][necko-backlog]

Comment 16

2 years ago
I have a router at

C:\>nslookup lede.lan
Server:  UnKnown
Address:  fe80::0123:45ff:fe67:89ef

Name:    lede.lan
Addresses:  fd0c:4920:b75a::1
          192.168.1.1

When I visit the webinterface at https://lede.lan, SixOrNot indicates the connection is over 4 (orange). If I turn 4 off and refresh, the page will load fine over 6 (green). Since I observe the same issue with the ping command, does FF inherit this behavior from Windows? Are these actions according to the specs?
(Assignee)

Comment 17

2 years ago
(In reply to scineram from comment #16)
> I have a router at
> 
> C:\>nslookup lede.lan
> Server:  UnKnown
> Address:  fe80::0123:45ff:fe67:89ef
> 
> Name:    lede.lan
> Addresses:  fd0c:4920:b75a::1
>           192.168.1.1
> 
> When I visit the webinterface at https://lede.lan, SixOrNot indicates the
> connection is over 4 (orange). If I turn 4 off and refresh, the page will
> load fine over 6 (green). Since I observe the same issue with the ping
> command, does FF inherit this behavior from Windows? Are these actions
> according to the specs?

Firefox does not change anything. A OS does DNS look up and returns a list of addresses. The firefox will try the first address first. This is a OS decision.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.