Closed Bug 567335 Opened 15 years ago Closed 15 years ago

IPv6 / IPv4 dual-stack favors IPv4 over IPv6 connections via teredo tunnel.

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: inox, Unassigned)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100514 Ubuntu/10.04 (lucid) Firefox/3.6.4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100514 Ubuntu/10.04 (lucid) Firefox/3.6.4 Firefox 3.6.3 (Windows) / 3.6.4 (Linux). IPv4 enabled version of websites load prior top IPv6 ones when using miredo. ufw is set to accept IPv6 traffic. However, even if ufw is stopped the problem persists. The same problem occurs on Windows XP when connecting via teredo. IPv6 connectivity is present - I can connect to IPv6 only web-sites and SSH servers, can ping6, can get ubuntu distro via torrent from v6 tracker, can do anything, but... Firefox loads IPv4 versions of dual-stack websites. In about:config (Firefox) "network.dns.disableIPv6" is set to "false". I have taken further steps in my investigation. Problem occurs only when using teredo tunneling. When using native IPv6 or gw6c (http://gogonet.gogo6.com client) - everything is fine and IPv6 version is loaded at first. Reproducible: Always Steps to Reproduce: Install and run "miredo" on Linux or "netsh interface ipv6 set teredo client" to enable Teredo. You are not affected, if you: - see green "Excellent!" in Firefox at http://testmyipv6.com You are affected by this problem, if you: - see red "You are using plain old IPv4." at http://testmyipv6.com , but green "Excellent!" at http://v6.testmyipv6.com/ You have no IPv6 connectivity at all, if you: - can't load http://v6.testmyipv6.com/ Actual Results: Described above. Expected Results: Expected behavior is to load IPv6 sites prior to IPv4 - or have a choice (as suggested in other bug reports) in about:config PreferV6 [X] PreferV4 [ ] OnlyV4 [ ] OnlyV6 [ ]
Why should Gecko use IPv6 if there is a working IPv4 link ?
Severity: major → normal
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
I believe we just use the DNS results in the order the DNS server (or at least the OS APIs we call) returns then in.
dupe of bug 467497 ?
Matthias - why should I use Gecko? That's the same kind of question. It worked just fine before and is broken now - my answer. If we want smooth V4->V6 transition to be completed we need the dual-stack working out of the box for everyone. I'm not going to argue with anyone if V6 should be preferred for general public at the moment (I am for the ability to choose), but let it happen in the predictable way. Now it favors IPv4 (when on teredo) and IPv6 (when native or tunneled in other way). Boris - I am not sure if it really matters. If the AAAA record exists, it should be simply used. Any idea on how to check the DNS results are ordered? Jo - It isn't clear to me after reading the suggested report, if it really is a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=467497 Teredo is a separate IPv6 only interface. Or at least it ought to be seen as such by applications. Other tunneling clients (as gw6c) create tun device with fake IPv4 address and IPv6 only address working. Nevertheless, there shouldn't be any difference at the application level.
> Now it favors IPv4 (when on teredo) and IPv6 (when native or tunneled in other > way) We really don't make a conscious decision to "favor" one or the other in the necko code. We just use whatever getaddrinfo hands back. > If the AAAA record exists, it should be simply used. Why? For what it's worth, as I recall in practice trying to do this causes issues in various situations where the record exists but either it or the routing is misconfigured... But quite apart from that, doing that would just be wrong. getaddrinfo sorts its results, and they are supposed to be used in the given order. See http://people.redhat.com/drepper/userapi-ipv6.html and RFC 3484. > Any idea on how to check the DNS results are ordered? Write a small C program that calls getaddrinfo and then prints out the results in a human-readable format? > Nevertheless, there shouldn't be any difference at the application level. Whatever difference you're seeing is happening on the libc level or below.
In particular, depending on how teredo looks to libc, RFC 3483 section 6 rule 7 might be relevant.
Bug 467497 is a bit confusing, it's mainly talking about a flag that shouldn't be passed in Windows. But if you look at the patch, it's really about the proper use of the getaddrinfo() system call. Currently AI_ADDRCONFIG isn't used, but it should, except under Windows. Until now, Firefox wasn't using it properly, because getaddrinfo() wasn't working correctly on all operating systems. Excerpt from getaddrinfo man-page : "If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4 addresses are returned in the list pointed to by result only if the local system has at least one IPv4 address configured, and IPv6 addresses are only returned if the local system has at least one IPv6 address configured." This is supposed to do the right thing in all circumstances, even if there are fake IPv4 or IPv6 addresses (the kernel should realize that somehow). See comment 5. I'm not sure if it would help in your case, but it should bring more consistent results. There are 2 test programs in http://code.google.com/p/chromium/issues/detail?id=32522#c15
Results of both getaddr1 and getaddr2 are the same in tunneled and native scenario. Native: getaddr1 localhost ::1 127.0.0.1 getaddr2 localhost ::1 127.0.0.1 getaddr1 ip6.me 2001:4810::110 66.117.47.214 getaddr2 ip6.me 2001:4810::110 66.117.47.214 Teredo: getaddr1 localhost ::1 127.0.0.1 getaddr2 localhost ::1 127.0.0.1 getaddr1 ip6.me 66.117.47.214 2001:4810::110 getaddr2 ip6.me 66.117.47.214 2001:4810::110 getaddr1 www.ipv6.org 130.237.234.40 2001:6b0:1:ea:202:a5ff:fecd:13a6 getaddr2 www.ipv6.org 130.237.234.40 2001:6b0:1:ea:202:a5ff:fecd:13a6
OK, so in the teredo case that ipv4 addresses come before the ipv6 ones if you ask libc. Perhaps you should ask the teredo and/or libc folks why that is?
UPS! You are right:) I took only a short look (localhosts match) at them before pasting here and - funny to say - didn't notice different order in the later addresses:D I got chromium browser compiled and running today and it is also affected. Opera (for Linux) is not V6 aware at all. Thank you all for help:)
marking invalid, thanks bz for your help !
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
if you could find/file a bug report to teredo and provide the bug url here, that'd be appreciated
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.