Fallback to IPv4 if IPv6 is enabled but no connection can be established

[evgeni]

From: Debian Bug #740356
Version: 1.1.1

When I have InternetServerUseIpv6=1 in my config, but no IPv6 connectivity at all, internet games fail with "The server name could not be resolved." after pressing the "internet game" button. If I enable teredo tunneling (using the miredo package), I get either "The connection to the server was lost." or "Connection timed out.". Internet games work just fine over IPv6, when I am connected to my "normal" (HE.net provided) IPv6 tunnel.

I think enabling IPv6 should not mean IPv4 is disabled and the connection should fall back to IPv4 if there was a problem connecting over v6.

[lotodore]

The server is using dual stack sockets (http://en.wikipedia.org/wiki/IPv6#Dual_IP_stack_implementation), so if IPv6 is enabled on the server it will accept both IPv4 and IPv6 connections. However, on the client it will be either IPv4 or IPv6. A fallback would be wrong there, because if someone chooses IPv6 and it works, he/she will assume that IPv6 is working.

[evgeni]

I beg to disagree :)

Let's take Firefox for an example: if I set network.dns.disableIPv6 to false, thus enabling the usage of IPv6, I do not disable IPv4.

By enabling IPv6 in a software, I usually expect it to use both protocols (or, well, actually, the one that works, as I do not care (as a pure user) whether my packets flow old-school or not). Other software has explicit force switches for either protocol (e.g. ssh) and does dualstack by default.

[lotodore]

Firefox has DNS responses as guidance on whether to use IPv6 or IPv4. A single connection still will be either IPv6 or IPv4.

If a IPv6 connection fails you cannot tell whether this is a reason to switch to IPv4 or if something different went wrong. Client side fallback is generally a bad idea in my opinion. There is also no RFC which recommends this behaviour, to my knowledge (on client side, mark my words). In contrast, there are several reasons against this: If the TCP connection over IPv6 does not work, it will often timeout. This is a long process. If the client tries IPv6 first and then IPv4, it will take like 30 seconds to connect and the user will think it is simply slow. One might cut the timeout, but this just simulates everything is fine while it is not.

The point is: If you don't have an IPv6 internet connection, simply don't enable the checkbox. It is as easy as this. Instead of writing tickets for strange workarounds here, it would be more helpful to request IPv6 support from your provider :-).

[rickysarraf]

But errors like "The server name could not be resolved." or "Connection timed out." give no hint of the issue being related to IPv6.

For some years ahead, users are going to have a setup with a mix of IPv4 and IPv6. It would be more obvious if you propagated the protocol failure into what you display.

Even the basic ping command decided to include a ping6 for IPv6.

[evgeni]

@lotodore any update on this?

[lotodore]

Sorry for the delay. I've added different error messages, if the connection attempt is unsuccessful with IPv6. Is that OK with you?

[lotodore]

As there was no more feedback, I'm closing this issue. Please reopen if you'd suggest a different solution.

[Roger-WIN]

I have used http://ipv6-test.com/ and it said that my browser didn't support fallback, even though I was using the latest Google Chrome and Windows 10. The current situation is that some websites can't be accessed after I enable IPv6. I think that's because they don't support IPv6. And now I don't know what to do.

[q4z1]

@Roger-WIN : I am not sure how this is related to the pokerth client.
The current game-server provider does not support ipv6 at the moment - so you have to disable ipv6 in the game client.