213121 - method to choose between ipv4 and ipv6 needed

Status: RESOLVED DUPLICATE of bug 621558

(Core :: Networking, enhancement)

Description

[David Richardson]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

Since Mozilla can use both ipv4 and ipv6, there should be a method to disable
either protocol and to specify which one to prefer.

Example: A private network, where both ipv4 and v6 are used. There is a v4
gateway to the internet, but v6 traffic cannot get out. On this net, there is a
v6 only web server. In this example, I would want to prefer v4, but not entirely
disable v6.

Maybe something like:
Network protocols:
[X] Prefer IPv4 (default)
[ ] Prefer IPv6
[ ] IPv4 only
[ ] IPv6 only


Reproducible: Always

Steps to Reproduce:
1. Run Mozilla on a machine with an IPv6 address, but no v6 connectivity beyond
the local link.
2. Try to visit a site available over both v4 and v6 (i.e. one with both A and
AAAA DNS records).
3. Mozilla will try to use v6 to get to that site, never timing-out and using v4
instead.

Comment 1

[Darin Fisher]

mozilla should in this case failover to the V4 address.  can you please provide
a HTTP log using the steps described here:

 http://www.mozilla.org/projects/netlib/http/http-debugging.html

thanks!

Comment 2

[David Richardson]

Attachment: IPv6 enabled, but only a link local address

Using the most recent nightly, downloaded on 2003-07-21 at 18:00 GMT. I hit
three servers: www.chpc.utah.edu, www.arstechnica.com, and www.kame.net. Kame
is fully reachable over ipv6. CHPC has an v6 address, but does not serve http
over v6. ArsTechnica does not have a v6 address. Everything worked fine.

Comment 3

[David Richardson]

I suppose there was network weirdness here when I had the problem. Mozilla fell
back to ipv4 just as it should. I still think there should be a method to select
which protocols to use, and in which order, similar to openssh's '-4' and '-6'
options.

Comment 4

[Darin Fisher]

agreed... but hopefully we can agree that it isn't high priority.  the current
solution should be fine in most cases ;-)

Comment 5

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

*** Bug 230848 has been marked as a duplicate of this bug. ***

Comment 6

[Lorenzo Colitti]

I think the current method is good enough. Reasoning: 

1. Most people don't have an IPv6 address. In this case mozilla just uses IPv4.
2. If you have a link-local address but not a global address, mozilla will
(probably) try IPv6 first. The connection will fail quickly and cleanly without
a timeout and will immediately fall back to IPv4.
3. If you have a global IPv6 address, it means that you either turned it on and
configured it explicitly yourself or that you have IPv6 network infrastructure
which gives you an IPv6 address. I would argue that this means you want to use
IPv6. :)

Of course you can disable IPv6 for certain domains by setting
network.dns.ipv4OnlyDomains or disable IPv6 completely by setting
network.dns.disableIPv6 to false.

Comment 7

[Zenon Panoussis]

> 3. If you have a global IPv6 address, it means that you either turned it 
> on and configured it explicitly yourself or that you have IPv6 network 
> infrastructure which gives you an IPv6 address. I would argue that this 
> means you want to use IPv6. :)

Uhm, that's a bit too black and white. I might have configured IPv6 so that I
can access IPv6-only sites, which would otherwise be completely inaccessible,
but still prefer to use IPv4 for dual-homed sites. 

And then we have sites that serve different content on the same URL, depending
on whether the visitor arrives on 4 or 6. There are a few of these, I run one
myself. Well, it's always nice to be able to see what's on "the other side" by
switching network in the browser. Admittedly that can also be done by turning
IPv6 on and off on the machine itself, but having to do that is equivalent to
"Windows has detected that your mouse has moved. You must now reboot for the
changes to take effect."

Comment 8

[Martin von Gagern]

Maybe a good reason to prefer either protocol version is the overhead involved when using the other one. The difference between a direct connection and one involving two gateways and another protocol layer might just be noticeable. So people with native IPv6 connectivity might prefer that while users relying on 6to4 gateways would probably rather prefer IPv4 if given the choice.

Comment 9

[benc]

I think this is allplats.

Comment 10

[Andrew Allison]

IPv6 is unable to handle slow responses (see 441175, et al.). All kinds of strange things, ranging from "address not found" to up to four different displays, happen depending on the server and response time. The default setting for network.dns.disableIPv6 should be "true" until such time as IPv6 is fixed.

Comment 11

[Lorenzo Colitti]

These are not problems with IPv6, they are problems with routers, firewalls or DNS servers not behaving properly or with your ISP. So there is nothing to fix.

Comment 12

[Zenon Panoussis]

(In reply to comment #11)
> These are not problems with IPv6, they are problems with routers, firewalls or
> DNS servers not behaving properly or with your ISP. So there is nothing to fix.

Perhaps those in comment #10, but not those in my comment #7. So even if there is nothing to fix in the sense that nothing is broken, a way to select network would still be a nice and useful function. And it would make the browser more resilient to "external" problems, like those in comment #10. All in all, this should be seen as a request for enhancement; perhaps nobody will work on it while there are higher priorities, but it shouldn't be closed as a non-issue either.

Comment 13

[Leen Besselink]

Can we not add a fast-failover from IPv6 to IPv4 ?

First you get the AAAA-DNS-record and try to connect to the IPv6-address if available, in the mean time you request the A-DNS-record, if the connection to the IPv6-address hasn't happend within x-second (something really short, not like the current 90 seconds or whatever it is) you connect to the IPv4-address if that works you use that for this site (read: hostname) and try IPv6 again if IPv4 fails.

My guess it's perfectly fine to try different IP-addresses by RFC, you are allowed to use something like 2 HTTP-connections (lots of browsers use 6 or even 8 now) to a hostname anyway.

Is that a good way to handle this ? Because the current try IPv4 if IPv6 fails after 90 seconds and wait for 90 seconds again for each and every single image, css and javascript on the page is reeeally annoying.

I think people that need fine-grained control over IPv4/IPv6-usage of websites should probably install an extension to do that (ofcourse this still needs to be created).

Comment 14

[Lorenzo Colitti]

A while ago I heard that for a future version of OS X, Apple was planning to make IPv4 and IPv6 DNS lookups and connetions completely in parallel, then using the first connection to complete. This would indeed avoid various types of failures which happen when IPv6 is not properly configured, though not all - for example, it wouldn't protect against, PMTU black holes. The standard socket API doesn't lend itself particularly well to this, but it's not that hard to implement either. Not sure if Apple has implemented it already.

Comment 15

[Zenon Panoussis]

This bug is seven years old. And we are now seven years closer to IPv4 address pool exhaustion and just about a year away from it. IPv4 is not going away any time soon though. Rather, we can expect the web to start turning into address sallad, into a place of mixed address space and protocols, where v4 and v6 will be both used in parallel and equally needed. The reasoning in comment #6 will no longer be valid, while the inevitable mistakes and misconfigurations world-wide will make the annoyances of comment #13 much greater. Hence, we can expect this bug to start gaining in prominence and urgency too. 

Shouldn't there be some kind of elevator (kernel scheduler analogy) in bugzilla, that bumps up the priority of bugs a little bit every six months or so, so as to avoid that valid but low priority bugs can stay open and untouched for seven years?

Comment 16

[Matthias Versen [:Matti]]

There is an automatic failover implemented (bug 621558) and you can disable IPv6 already via about:config.
I think it's ok to mark this as dupe of bug 621558