upvote
There were indeed consistent failures to specific IPv6 endpoints, clearly identifiable through curl, while all the IPv4 endpoints were ok.

This happened with pypi (IPv6 BGP routing problem caused by a bad route from one of our peers combined with their fastly CDN not reply to us on IPv6 from the other side of the ocean for some weird reason), but also with yum and apt mirrors (seemingly random problems with the IPv6 service or firewall of the remote endpoint), and various other web resources accessed from pipelines.

The solution always was to temporarily block the bad IPv6 endpoint(s) or temporarily completely disabling IPv6 on the server itself or on the squid proxy server for workloads without direct connectivity.

Obviously it also can be the other way around, but in practice it appears to happen less often with IPv4, and if it does things get addressed quickly instead of taking hours or days or weeks.

reply
Open source download mirrors often have much better targetting for v4 than v6. Just a few days ago, I was downloading installer images to check an issue and adding -4 to the command line reduced the download time significantly.
reply
I saw HE stop routing to europe over ipv6 for an extended period of time two-ish years ago.
reply