1452028 - Firefox does not always prefer IPv6, broken network.http.fast-fallback-to-IPv4 handling

Status: VERIFIED FIXED

(Core :: Networking: DNS, defect, P2)

Description

[r01opd9cujmm]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180319220116

Steps to reproduce:

Background:
OS: Linux x86-64
Network: IPv4 and IPv6 Dual Stack. NAT64/DNS64 is used. (The NAT64 server has a different IPV4 address.)
My location: Asia-Pacific region

1. Use Firefox Nightly version 2018-04-05-22-00-26-mozilla-central. (or any newer version)
2. Set `network.http.fast-fallback-to-IPv4` to `false`, and `network.http.fallback-connection-timeout` to a high value (such as `200`).
3. Go to some IPv4-only websites. Preferably, choose websites that have servers close to you, such that connecting to the website via IPv4 is considerably faster than via IPv6/NAT64.


Actual results:

Despite the fact that the website can be connected by IPv6 (using NAT64/DNS64), Firefox does not always connect via IPv6.

If I browse Amazon Japan, it detects my actual location (This item can be delivered to (a country in the Asia-Pacific region)). 

This bug appears after https://hg.mozilla.org/integration/mozilla-inbound/rev/2f4395f5ca24 is applied.


Expected results:

Always try IPv6 first before trying IPv4.

For example, using the NAT64/DNS64 service by Go6lab, when I browse Amazon Japan, it detects the location of the NAT64 server (This item can be delivered to Slovenia).

Another example is images that shows your IPv4 address, such as http://ip.ntrqq.net/images/misaka.png?wd=5p2l5LiA5Y%2BR6LSv56m%2F5LiA5YiH55qE6LaF55S156OB54Ku5ZCnCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg5aSp5omNVjE%3D . The last good revision (mozilla-central), 48f43d2ad95ec075addce039f7fe7dcd8edbaf61 , always shows the IPv4 address of the NAT64 server, which can prove that Firefox is connecting via IPv6/NAT64. Later revisions shows my real IPv4 address.

Comment 1

[Cristina Badescu [:cbadescu], Experiments QA]

I don't have the necessary expertise to debugg further this issue. I am assigning a component to this issue in order to involve the development team and get an opinion on this.

Comment 2

[Honza Bambas (:mayhemer)]

I've recently made some changes around ipv6, will look.

Comment 3

[Honza Bambas (:mayhemer)]

(P2, is likely to be a recent regression)

Comment 4

[Honza Bambas (:mayhemer)]

Aha!  I completely broke handling of fast-fallback-to-IPv4 preference.  Valentin missed that during review completely ;)


An easy fix.

Comment 5

[Honza Bambas (:mayhemer)]

Attachment: v1

Thanks for the report and finding a regression range!


Valentin: note the line I have removed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2f4395f5ca24#l6.39

Comment 6

[Valentin Gosu [:valentin] (he/him)]

Comment on attachment 8967787 [details] [diff] [review]
v1

Review of attachment 8967787 [details] [diff] [review]:
-----------------------------------------------------------------

Ooops. Thanks for fixing it :)

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/10a300d81060
Bring back network.http.fast-fallback-to-IPv4 preference, regression from bug 1430659. r=valentin

Comment 8

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/10a300d81060

Comment 9

[Honza Bambas (:mayhemer)]

Reporter, I will kindly ask you to verify this bug, if possible.  The Nightly 2018-04-16 you can download today should contain the fix.  Thanks.

Comment 10

[r01opd9cujmm]

(In reply to Honza Bambas (:mayhemer) from comment #9)
> Reporter, I will kindly ask you to verify this bug, if possible.  The
> Nightly 2018-04-16 you can download today should contain the fix.  Thanks.

Oops, thanks for reminding me.

Comment 11

[Honza Bambas (:mayhemer)]

(In reply to r01opd9cujmm from comment #10)
> Oops, thanks for reminding me.

Thank you and thank you for this report!