Tdesktop: Prefer IPv6 if its available

[nshopik]

Steps to reproduce

1. Open Telegram on dual-stacked host
2. Telegram tries connect via IPv4 and IPv6
3. Then drops IPv6 connection and stick to IPv4 only
   

   Expected behaviour

It should stick to IPv6 if its available and not crippled, similar to happy eyeballs RFC6555

Actual behaviour

Always prefers IPv4, only disabling IPv4 make it stick to IPv6.

Configuration

Xubuntu 16.04
4.4.0-24-generic #43-Ubuntu SMP Wed Jun 8 19:27:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

v 0.9.56 alpha

Logs

startup log
https://gist.github.com/nshopik/31528efa4cce7dbccdd7d99f5ef9e862

[XenHat]

I would like to add that Telegram will also stay on IPV4 mode regardless of the user preference when behind an ISP-provided 6to4 tunnel (Videotron Ltee in my case). I have only tested this on Windows x64 so far.

[nshopik]

@XenHat This is per design on most OSes, 2002::/16 prefix usually have lower precedence
https://tools.ietf.org/html/rfc6724#section-2.1 so it only selected to route within same prefix.

[nshopik]

@john-preston This also somewhat improve security, as CGNAT become more common, IPv4 address from which somebody logged into your account could be same as yours and you could completely ignore that by mistake.

Thus connecting via IPv6 preferably give you better track your sessions

[stek29]

Happens on OS X too by the way.

[vitorgrs]

This still happens on Windows.

[yangm97]

Still happens on macOS.

[john-preston]

Yes, currently IPv4 is preferred to IPv6, because IPv4 shows itself better, is more stable from both our side and local provider side.

[nshopik]

@john-preston Is there any practical reason why checkbox try connecting through IPv6 unchecked by default then?

Yes, currently IPv4 is preferred to IPv6, because IPv4 shows itself better, is more stable from both our side and local provider side.

I would disagree on that, since iOS version and macOS native version prefer IPv6 and work flaweless

[john-preston]

@nshopik On Windows I had several reports that when trying to connect both with IPv4 and IPv6 the first one was not working at all till the app restart, so this was moved to settings, disabled by default and on Windows it even requires app restart to change. I could not debug this issue back then and it wasn't a big problem anyway.

[yangm97]

Wouldn’t it be better to have a dropdown in which the user chooses between auto (default, telegram tries to “reliability test” both), force ipv4 and force ipv6? Multiple users from multiple ISPs have mixed results, guess that would close this case once and for all.

[nshopik]

@john-preston That's why I've suggested RFC6555 style address family selection instead dumb preference, which may cause problem. All current browsers implement it and correctly fallback to IPv4 if IPv6 in broken state.

Current IPv6 support just doesn't make sense, tdesktop support it but not enabled by default and even if you enable it still not even try connect IPv6 if IPv4 available. And as I'm rightly pointed out it make sense from security perspective when CGN comes into play to prefer IPv6 if its available and working.

[vitorgrs]

The problem is that even if you enable to use ipv6, it doesn't (unless you disable ipv4 stack on windows, which doesn't make any sense)

[stek29]

Btw, Telegram deals with IPv6 pretty weirdly -- if you log in using it you get a private IP address in "somebody logged in" message

[nshopik]

@stek29 They had issue with backend previously which report weird private IP ranges including multicast ranges, now it report correctly in active session tab at least for me it was fixed for about month

[Aokromes]

Maybe dropdown to auto (prefered ipv6) auto (prefered ipv4) ipv4 ipv6? :)

[Lefey]

Please! Add dropdown to auto (prefered ipv6) / auto (prefered ipv4) / ipv4-only / ipv6-only

[bjo81]

I have several clients which have IPv6 (no 6to4), "use IPv6" is enabled, but the connection is made via IPv4.

[kudrevatykh]

Just tested latest client and it successfully connected via IPv6

[stale[bot]]

Hey there!

This issue will be automatically closed in 7 days if there would be no activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[Kirya2k]

It's time to remove this crutch.
In networks where there is ipv6, it is already more stable than ipv4.

[ilya-fedin]

It's time to remove this crutch.

I have a feel that tdesktop won't use IPv6 until someone brave PR a RFC6555 implementation, since it seems really complicated and devs might have no time (or just too lazy) to implement.