Comment 53 for bug 24828

I have serious doubts that blacklisting IPv6 really solves the problem. glibc's getaddrinfo() will still query AAAA regardless, unless AI_ADDRCONFIG flag is set. And it is very often *not* set, if only because it is a "proprietary" GNU extension.

In other words, the problem is now fixed merely for some applications, but surely not all of them, and particularly probably a bunch of apps in Ubuntu universe.

IMHO, the proper solution would rather go along the lines of what MacOS X does, i.e. only try AAAA if there is any non-loopback non-link-local IPv6 address (and only try A is there is any non-loopback IPv4 address). That means hacking glibc, and has nothing to do with the *kernel* IPv6 plugin. Also, I think it is much less likely that an application will want to resolve AAAA in absence of IPv6 connectivity, than it is likely that some Ubuntu users will want IPv6 connectivity, even though both are uncommon situation in any case.

Finally, adding such a blacklist looks like an incoming source of headaches if IPv6 is to ever be restored, and a nice source of Ubuntu bashing from advanced users once Feisty is released.

To sum up, the real problems are that glibc only checks IPv6 connectivity if AI_ADDRCONFIG is set (this is a trivial hack to sysdeps/posix/getaddrinfo.c), and then glibc's check_pf considers IPv6 is available even if there is only ::1 or fe80::something which is clearly wrong (this is a not-so-trivial to make_request from sysdeps/unix/sysv/linux/check_pf.c).

My 0,02€. Regards.