Closed Bug 1452028 Opened 2 years ago Closed 2 years ago

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

Categories

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

61 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla61
Tracking Status
firefox61 --- fixed

People

(Reporter: r01opd9cujmm, Assigned: mayhemer)

References

Details

(Keywords: regression, Whiteboard: [necko-triaged])

Attachments

(1 file)

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.
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.
Component: Untriaged → Networking: DNS
Product: Firefox → Core
I've recently made some changes around ipv6, will look.
Assignee: nobody → honzab.moz
Priority: -- → P3
Whiteboard: [necko-triaged]
(P2, is likely to be a recent regression)
Priority: P3 → P2
Aha!  I completely broke handling of fast-fallback-to-IPv4 preference.  Valentin missed that during review completely ;)


An easy fix.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: Firefox does not always prefer IPv6 → Firefox does not always prefer IPv6, broken network.http.fast-fallback-to-IPv4 handling
Attached patch v1Splinter Review
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
Attachment #8967787 - Flags: review?(valentin.gosu)
Comment on attachment 8967787 [details] [diff] [review]
v1

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

Ooops. Thanks for fixing it :)
Attachment #8967787 - Flags: review?(valentin.gosu) → review+
Keywords: checkin-needed
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/10a300d81060
Bring back network.http.fast-fallback-to-IPv4 preference, regression from bug 1430659. r=valentin
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/10a300d81060
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
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.
Flags: needinfo?(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.
Status: RESOLVED → VERIFIED
Flags: needinfo?(r01opd9cujmm)
(In reply to r01opd9cujmm from comment #10)
> Oops, thanks for reminding me.

Thank you and thank you for this report!
You need to log in before you can comment on or make changes to this bug.