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
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
(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
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+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/10a300d81060 Bring back network.http.fast-fallback-to-IPv4 preference, regression from bug 1430659. r=valentin
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.
(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
(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.