408881 - Re-enable IPv6 on Mac OS

Status: RESOLVED FIXED

(Core :: Networking, defect, P3)

Description

[David Luyer]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

As OS X 10.4+ getaddrinfo intelligently determines if it should return IPv6
addresses or not, the patch originally in:

   https://bugzilla.mozilla.org/attachment.cgi?id=143443

is no longer relevant for Firefox 3.  This patch should be reverted, returning
MacOS X to the same behavior as Linux and Windows.

(It is not exactly clear how this is done, but OS X 10.4 completely
refuses to return IPv6 results to getaddrinfo even if explicitly
requested, until it has been able to reach another device via IPv6;
even configuring a global IPv6 address and unreachable IPv6 next hop
does not trick it to return IPv6 addresses prematurely.)

Firefox 3 does not support versions before OS X 10.4, so it will not
experience this issue.  Please revert the change, which is still present
here:

   http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/init/all.js#1802

Also, the context in the original bug is now incorrect.  Safari in 10.4 and
later now do IPv6 first when available.

Reproducible: Always

Steps to Reproduce:
1.  Enable IPv6 on a MacOS X system
2.  Access IPv6+IPv4 site with Safari - see IPv6 content
3.  Access same site with Firefox - see IPv4 content
Actual Results:  
IPv6 content is not accessed without explicitly changing preferences.

Expected Results:  
IPv6 content should be automatically returned on IPv6-connected systems.

Comment 1

[David Luyer]

Attachment: Reversion patch

Comment 2

[Lorenzo Colitti]

Confirming. David and I looked at this together, and 10.4 does seem to be much smarter about when to make AAAA queries.

Since Firefox 3 will be around for a long while yet, it would seem to be a good idea to include this fix in it. Nominating for blocker status.

CCing Darin and wtc for feedback.

Comment 3

[Damon Sicore (:damons)]

+'ing with P3.

Comment 4

[Lorenzo Colitti]

Who can review this? biesi, do you have time to take a look?

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 293725 [details] [diff] [review]
Reversion patch

awesome

Comment 6

[Lorenzo Colitti]

Cool! Can you check in too? Neither of us has CVS access.

Comment 7

[Reed Loden [:reed]]

Checking in modules/libpref/src/init/all.js;
/cvsroot/mozilla/modules/libpref/src/init/all.js,v  <--  all.js
new revision: 3.717; previous revision: 3.716
done

Comment 8

[Reed Loden [:reed]]

This patch caused necko's test_dns_service.js test to fail due to the test checking to make sure localhost resolved to "127.0.0.1". It seems that when IPv6 is enabled on the Mac, localhost resolves to "::1". I changed the test so that either answer is acceptable.

 function run_test() {
   var dns = Components.classes["@mozilla.org/network/dns-service;1"]
                       .getService(Components.interfaces.nsIDNSService);
   var rec = dns.resolve("localhost", 0);
-  do_check_eq(rec.getNextAddrAsString(), "127.0.0.1");
+  var answer = rec.getNextAddrAsString();
+  do_check_true(answer == "127.0.0.1" || answer == "::1");
 }

Comment 9

[Wan-Teh Chang]

Yes, "::1" is the IPv6 loopback address, so your change to the
test is correct.

Comment 11

[David Luyer]

I see Bug 429746 has been added as a dependency.

Bug 429746 is not a FF bug IMHO.  Firefox is corrected to behaving as Safari behaves; http://localhost on OS X with v6 enabled translates to ::1 which is inaccessible in this case (most likely due to an apache configuration error).  The case was broken with Safari but working with FF2 only because FF2 ignored IPv6.