apt's IPv4 fallback in case of a malfunctioning IPv6 connection works horribly

[T-artem]

I kindly request that Ubuntu developers stop drinking so much Kool-Aid and realize not everyone in this world has a working IPv6 connection and an IPv4 fallback must be used in case an IPv6 request takes too much time:

# time apt-get update
Hit:1 http://de.archive.ubuntu.com/ubuntu xenial InRelease
Hit:2 http://de.archive.ubuntu.com/ubuntu xenial-updates InRelease
Hit:3 http://de.archive.ubuntu.com/ubuntu xenial-backports InRelease
0% [Connecting to security.ubuntu.com (2001:67c:1560:8001::11)]^C

real 6m10.351s
user 0m0.056s
sys 0m0.020s

What the fuck??? My server doesn't have a working IPv6 connection. The apt-get update command apparently never completes. Could there be a sane timeout before apt switches to IPv4?

Why the Internet is full of requests how to disable IPv6 support in apt when it takes a few seconds to fix this problem in the first place?

Why the fuck there are such crucial bugs in the first place? Could you for fuck's sake make your software usable and bugs-free before trying to add a ton of barely working new shiny features?

Of course, there's this nice thread

https://unix.stackexchange.com/questions/9940/convince-apt-get-not-to-use-ipv6-method

which fixes this issue, but why the fuck am I supposed to start googling from the get go after installing a brand new release of Ubuntu

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.2 LTS
Release: 16.04
Codename: xenial

Also why the fuck are you sending a password reset URL which uses plain HTTP? Are you fucking insane?

What the fuck is this shit?

http://login.launchpad<email address hidden>

What the fuck is wrong with you people?

[David Kalnischkies (donkult)]

Thanks for your well written bugreport and a very happy Christmas to you, too, sir. Please proceed to the checkout counter and accept a full refund and our sincere apologizes.

Unfortunately, I am neither a ubuntu developer, nor do I drink kool-aid apart from the seasonal appropriate hot cocoa, but as an APT developer who is paid splendidly by the many thanks of people like you for investing his freetime it feels like my obligation to pay back some times:

Its not our fault that you misconfigured your system and throw money out the window. APT wouldn't be using IPv6 if your system wouldn't say that it is available. Talk to your ISP: You pay them a lot for your router and network usage presumably. Enough to make non-broken IPv6 available to you – you will need it sooner than later.

APT also performs fallbacks – not quickly, we are working on that, but it eventually does: Too quick and naive a fallback and we break for systems which have high latency, but otherwise working configuration. So, as this "bugreport" adds exactly nothing to improve the situation expect perhaps "helping" that I and other volunteers are never going to look at bugs written by "fucking insane morons" I am closing as "opinion" for fucks sake.

P.S.: apt isn't launchpad either. These guys likely wouldn't appreciate the nice ton of your message either, through.

[T-artem (t-artem)]

> Its not our fault that you misconfigured your system and throw money out the window.

That's what wrong with you, Mr. David. For some reasons you believe that if a configured resolver returns an AAAA record and there's literally any IPv6 address attached to the NIC, then surely IPv6 must be working. Guess what? IPv6 requires a working IPv6 route (which is _not_ present on our systems), it also requires a configured address which doesn't start with the fe80 prefix (again, globally routable IPv6 addresses are not present on our systems). I guess checking for these two prerequisites is way too difficult and counter-intuitive for you distinguished Debian/Ubuntu developers.

More importantly though is that implementing a fallback after a certain timeout is way beyond your ego and your magical world of technology where all people have magically received globally routable IPv6 addresses.

It's weird that some other Linux favours like Fedora implement fallbacks after a certain timeout, and so do many other OSes like *BSD, Windows and even Android.

However it's obvious that Debian and Ubuntu are above all of that and implementing such pesky requests from users is just not worth your time.

> APT also performs fallbacks – not quickly, we are working on that, but it eventually does: Too quick and naive a fallback and we break for systems which have high latency, but otherwise working configuration.

I would have believed that, sir, but a 20 to 30 minutes fallback (last time I waited for more than 10 minutes) is certainly not something a sane person would have ever thought of. I cannot think of any Internet connection which might be usable beyond a standard 300 seconds IPv4 connection attempt timeout. Perhaps, though Debian/Ubuntu developers believe networking standards don't apply to them.

I would have agreed to all your reasoning however the mentioned thread at stackexchange dot com has literally hundreds of likes and hundreds of thousands of views, which indicates that IPv6 is still not in a shape where you should even *default* to it.

What makes you *default* to IPv6 in a world where there are countries with zero connected IPv6 endpoints? What makes you *default* to IPv6 in a world where there are hundreds of ISPs which don't provide IPv6 routing for their clients?

Why does my wonderful Ubuntu/Debian distro must be configured around the things which must work out of the box? You strive to make Linux a first class desktop OS, yet you do everything to make your potential users endure as much pain and suffering as possible because ... you can?

[T-artem (t-artem)]

The tone of my message is quite pertinent considering the severity of this issue and the its age. It's not like a random wish or a random bug hardly anyone can face. It's a question of lost productivity.

[Julian Andres Klode (juliank)]

Look, we are actively working on support for a subset of the happy eyes RFC that works around issues like that. Your system is still likely configured wrongly somewhere, though. I and many others run apt on IPv4+IPv6 systems with non-routable IPv6 and we do not have a problem.

Note that this is not a problem of apt. Your system is configured to try IPv6 first, so any application not implementing happy eyeballs has the same issue. Some applications only try the first address returned by getaddrinfo() - they will fail hard on your system. The key takeaway is to configure your network and/or NSS settings correctly so all applications work.

[T-artem (t-artem)]

I've already worked around this problem, thank you very much.

Most end users are *not* IT pros to even understand what's wrong with their systems: they rightfully presume that Ubuntu sucks/doesn't work on their PCs not because it inherently sucks or it's unusable but because you insist on the things which might not work as you believe they should and everything goes tits up.

You see, guys, you all speak like lunatics:

I tell you that Ubuntu/Debian should not default to IPv6 ever - you say fix your systems.
I tell you that sane timeouts should be introduced - you say fix your systems.
I tell you that you're breaking various RFCs by having insane defaults - you say fix your systems.

I've even given you a perfect reproducible bug report: run Ubuntu on a system which has an IPv6 address but lacks a an IPv6 route and you still insist that the world should bend over for you. It will not. A sane OS should not assume anything.

Your ends users must not lose their shit over the things you decided for them and for the entire world.

And while we're arguing you still actively choose to neglect the stackexchange topic which clearly indicates that you're doing something wrong for a *ton* of your users.

Please don't bother any more. Your attitude towards making Ubuntu (and Debian, since I'm perfectly sure this bug applies to Debian as well) usable in real world use cases is perfectly clear - you don't give a flying f-word. You'll resort to blaming the user, the world, the position of the stars above one's head but you won't admit that something might not be suitable for common use cases your users are facing every freaking day.

This bug report according to you is invalid. So be it. Let Ubuntu users google. After all it won't be a true Linux distro without a lot of tinkering.

Amen.

[Julian Andres Klode (juliank)]

It works totally fine for millions of users. I have never seen a single network where it does not work. I've heard about it in a few bug reports, like this one. AFAIUI that involves a globally routable IPv6 address, but no actual IPv6 connectivity to the hosts. Which is not normal. Hence the suggestion to fix that.

As mentioned before, we're actively working on adding "happy eyeball's" - fast fallback from IPv6 to IPv4 - but this takes time, and more bug reports about it do not help. It's just distracting.

[Julian Andres Klode (juliank)]

See bug #1308200 for a useful bug report.

[T-artem (t-artem)]

The useful bug report has stayed without any action on your part for three years. It's serious enough that it's forced hundreds of people to seek for a workaround. Its resolution is a simple and easy fix. Yet, let's discuss my tone. At least I've made you change the status of the original bug report to NEW.

Please prove me wrong and fix it in under a month because I'm afraid it will take a few years. I'd be amazed if you pushed the fix into 16.04 LTS without making people wait for 18.04.

Cheers!

[Julian Andres Klode (juliank)]

The solution is extremely complicated. It requires a short (300ms) timeout when falling back from IPv6 to IPv4 and then waiting on _both_. And then properly reporting errors, so it reports failures for the correct IP addresses.

I basically had a working prototype in July, but I had to abandon it, because it did not pass CI. I think its error reporting also was fairly shaky.

Re 16.04, I don't think we'll see a fix there. The changes are fairly complex, and it only affects a tiny minority of users (*), and there is a much easier workaround to apply. Also, this not only affects APT if your libc is configured to prefer IPv6 on a system without real IPv6 connectivity - some apps just try the first address (IPv6 then), they will hard-fail quickly.

(*) If someone ever can explain to me what causes this, please do so. This should not happen. If you have a globally routable IPv6 address and just drop the IPv6 traffic somewhere down the route, your network is broken IMO. Don't expect everyone to add workarounds for that.