Closed Bug 355087 Opened 18 years ago Closed 15 years ago

DNS lookup on mixed IPv6/IPv4 websites fails over to IPv4 while on a IPv6 network


(Core :: Networking, defect)

1.8 Branch
Windows Server 2003
Not set





(Reporter: unquietwiki, Unassigned)




(Keywords: qawanted)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1) Gecko/20061001 BonEcho/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1) Gecko/20061001 BonEcho/2.0

IPv6/IPv4 mixed websites resolve as IPv4 websites, and IPv6 websites cannot resolve via DNS. Using a direct IPv6 address does work however.

Reproducible: Always

Steps to Reproduce:
1. Access
2. Access http://[2001:200:0:8002:203:47ff:fea5:3085]/
3. Access http://[]/

Actual Results:  
Step 1 will produce a static turtle.
Step 2 will produce a dancing turtle.
Step 3 will produce a static turtle.

Expected Results:  
Firefox prefers IPv6 by design: it should have always loaded the IPv6 version.

I ran Ethereal to check the packet activity, and noticed 2 DNS attempts...

1 0.000000 Buffalo_16:30:fa Spanning-tree-(for-bridges)_00 STP Conf. Root = 32768/00:16:01:16:30:fa Cost = 0 Port 2 1.235898 fe80::216:1ff:fe16:30fa ff02::1 ICMPv6 Router advertisement
3 2.000253 Buffalo_16:30:fa Spanning-tree-(for-bridges)_00 STP Conf. Root = 32768/00:16:01:16:30:fa Cost = 0 Port 4 3.743475 DNS Standard query AAAA
5 3.744836 DNS Standard query response AAAA 2001:200:0:8002:203:47ff:fea5:3085
6 3.746792 DNS Standard query A
7 3.748249 DNS Standard query response A
8 3.750145 TCP 2773 > http [SYN] Seq=0 Len=0 MSS=1460
9 3.966583 TCP http > 2773 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
10 3.966641 TCP 2773 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
11 3.966787 HTTP GET / HTTP/1.1
12 4.000483 Buffalo_16:30:fa Spanning-tree-(for-bridges)_00 STP Conf. Root = 32768/00:16:01:16:30:fa Cost = 0 Port 13 4.197916 TCP [TCP segment of a reassembled PDU]
14 4.337276 TCP 2773 > http [ACK] Seq=399 Ack=1010 Win=64526 Len=0
15 4.577618 TCP [TCP segment of a reassembled PDU]
16 4.577809 TCP [TCP segment of a reassembled PDU]
17 4.577958 TCP 2773 > http [ACK] Seq=399 Ack=2981 Win=65535 Len=0
18 4.577964 HTTP HTTP/1.1 200 OK (text/html)
19 4.602843 HTTP GET /style.css HTTP/1.1
20 4.821068 TCP [TCP segment of a reassembled PDU]
21 4.821328 HTTP HTTP/1.1 200 OK (text/css)
22 4.821487 TCP 2773 > http [ACK] Seq=756 Ack=5548 Win=65535 Len=0
23 4.839667 HTTP GET /img/kame-noanime-small.gif HTTP/1.1

Apparently, Firefox preferred the second result to the 1st.
Keywords: interop
I wiped out my whole old profile (and even corrupted my bookmarks.html file, so there's about 10-20 sites I just lost track of; kept the cookies.txt though) and loaded Firefox RC1 for Windows. The error is still present, so we know this has been around a while, trunk or branch.

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1) Gecko/20060918 Firefox/2.0
Version: unspecified → 2.0 Branch
Same results under Vista RC2, using Firefox 2 RC2

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1) Gecko/20061003 Firefox/2.0
Keywords: qawanted
This is always reproductible also on XP SP2 on FF2.0, including when setting a precedence table setup to prefer ipv6 over ipv4 as per RFC 3484 :

netsh interface ipv6>show prefix
Precedence  Label    Prefix
----------  -------  --------------------------------
        40      5  2001::/32
        20      3  ::/96
        30      2  2002::/16
        50      1  ::/0
        60      0  ::1/128
        10      4  ::ffff:0:0/96

Consequence, at this time, only solution to get ipv6 from FF on a website is to connect to ipv6 only server or type the ipv6 address manually in the address bar (anybody remember an ipv6 adress here ?). Knowing that today, most ipv6 enabled servers are also ipv4 nodes for obvious compatibility purposes, this means Firefox will almost never use ipv6 :( For early ipv6 adopters this seriously deprecate Firefox as a possible choice ... (FYI, Opera got it right !)

Anybody with ipv6 skills willing to fix this one ?
Component: OS Integration → Networking
Product: Firefox → Core
QA Contact: os.integration → networking
Version: 2.0 Branch → 1.8 Branch
hm, your 3) variant should produce an malformed URL error.

As for the bug... Necko just uses the addresses in the order in which getaddrinfo returns them...
Ever confirmed: true
I've been suffering from this problem too. A few years back Firefox used to "just work" once you enabled IPv6. I seem to remember there was some controversy with glibc at some point and IIRC they decided that there were too many broken DNS servers that were silently ignoring AAAA lookups rather than returning with an error that they decided to have glibc prefer As over AAAAs if both were returned. That doesn't explain it not working on XP though, although maybe Microsoft made the same decision.

Looking at the getaddrinfo manual page (on my Arch linux box with glibc 2.6.1), it seems that there is a "hints" parameter which can specify what types of response getaddrinfo should return, which seems to include indicating a preference for IPv6 AAAA records. Maybe if the mozilla network.dns.disableIPv6 variable is set to false, then this hint could be set to prefer IPv6 AAAA records. 

I've done a bit more investigating. Here's what I've found :

* the getaddrinfo hints option I suggested earlier doesn't seem to have an option that prefers AAAA records over As if the AAAA records exist.

* it seems that firefox is using the first socket address structure in the returned list for getaddrinfo. For domain names with both an A and AAAA records, the A record always seem to be the first in the list. Maybe in the past this wasn't the case, which was why firefox just worked when IPv6 was enabled.

* I can't seem to find any way to change that order. I've come across a getaddrinfo configuration file called /etc/gai.conf which seems to be specifying preferences for IPv6 addresses when multiple are returned, but doesn't seem to have the option of influencing the decision between A verses AAAA.

* I've hacked up the example client program on the getaddrinfo manual page just to show the outcome of lookups, by walking through the supplied list of sockaddr structures in the order they are supplied :

[mark@ubu getaddrinfo]$ ./a.out

        rp->ai_family == AF_INET,
        rp->ai_family == AF_INET6, 2001:200:0:8002:203:47ff:fea5:3085

[mark@ubu getaddrinfo]$ ./a.out

        rp->ai_family == AF_INET,
        rp->ai_family == AF_INET6, ::1

[mark@ubu getaddrinfo]$ 

When I ran a tcpdump against the DNS lookups that this program triggers, I got a bit of a surprise - it's doing the AAAA lookup first.:

[root@ubu ~]# tcpdump -n -i lo
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
21:53:27.269299 IP > 39353+ AAAA? (30)
21:53:27.270955 IP > 39353 1/2/5 AAAA[|domain]
21:53:27.271672 IP > 18980+ A? (30)
21:53:27.272692 IP > 18980 1/2/5 A (199)

Maybe the way to solve this would be to have firefox prefer AAAA answers if disableIPv6 is false and an AAAA answer is returned by getaddrinfo. Reading through the getaddrinfo page, it would seem that setting the AI_ADDRCONFIG flag would also be the right thing to do, if it isn't being done already.
I got the same problem using firefox on Linux, with glib 1.2.10.
As Mark Smith pointed out, it seems that firefox is using the first socket address structure in the returned list for getaddrinfo.

Using a similar test program against names with both ipv4 and ipv6 associated addresses, I got the v6 firstly and the v4 secondly for most servers (such as or, and firefox indeed use ipv6 for theses servers. But my problem comes using my personnal DNS server : for some reason, I always get the v4 firstly ond the v6 secondly, and firefox always uses ipv4. But, on another computer on my LAN (which uses an up-to-date glibc/firefox), with the same DNS server, I got the v6 first and the v4 then, so firefox uses ipv6.

I don't think that the DNS lookups IP version order is important, here it always do the AAAA firstly and then the A, whereas the getaddrinfo list order differ from my DNS server to other servers.

So for the moment the IP version choice is made by getaddrinfo. I don't know if there is a way to change it's beheaviour... Actually, the sorting order must follow the RFC 3484, section 6, which is quite obscur to me.

I also suggest that firefox should prefer AAAA answers if disableIPv6 is false and an AAAA answer is returned by getaddrinfo, that sounds obvious to me.
Maybe I could write that patch if I got the time.
I have this problem too... but reading RFC 3484 section 6 it *MAY* just be right in my case to use the IPv4 address preferentially: my IPv6 connection is using 6to4, thus my local IPv6 address is in the 2002::/16 prefix: the implementation knows this prefix and, as the rule 7 states it MAY use a concept of interface preference and give a 6to4 interface lower preference.

In my case, specifically, the WinXP64 box on which I encounter the problem is NOT using a 6to4 interface... my FreeBSD home server is, the WinXP64 box got his IPv6 address automatically by the server's RTADV. Of course, being in the 6to4 prefix anyway, he "knows" that address is tunneled for sure even if the 6to4 virtual interface is not local.
BTW: I can confirm this is happening on FreeBSD-7 too.
Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv: Gecko/20071223 Firefox/
I forgot I posted this issue 2 years back. Firefox 3 seems to have fixed it on both Windows & Linux.
I'm using Minefield and the behaviour is still the same here: - static turtle
http://[2001:200:0:8002:203:47ff:fea5:3085]/ - dancing turtle

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081024 Minefield/3.1b2pre ID:20081024032143
Keywords: interop
I'm observing this same behaviour.  Firefox 3.0.10 running on CentOS 5.3.
The order that the addresses are returned in depends on the system, and in the particular case of 6to4 or Teredo addresses (2002::/16 or 2001:0::/32) many systems prefer IPv4, since it's likely to lead to better performance.

Resolving invalid. If someone with a working global unicast IPv6 address is able to reproduce, please reopen.
Closed: 15 years ago
Resolution: --- → FIXED
Resolution: FIXED → INVALID
You need to log in before you can comment on or make changes to this bug.