On 2/15/21 08:25, William Herrin wrote:
Well actually, that's not entirely true. One thing holding back IPv6 is the unfortunately routine need to turn it off in order to get one or another IPv4 thing back working again. Like the disney thing earlier in this thread. Or like my experience yesterday where I had to disable IPv6 to fetch files on a particular server because SLAAC was serving up invalid addresses but the app insisted on trying all 8 IPv6 addresses before it would attempt any of the IPv4 addresses. And of course I can't call my ISP and say: you're causing my Linux box to pick up bad IPv6 addresses. Front line support can barely handle IPv4 and Windows. I stuck with it for a couple hours and figured out how to disable SLAAC without disabling DHCP-PD so that I could turn IPv6 back on with addresses which worked. But really, how many people are going to do that? Most tick the IPv6 checkbox to off and are done with it. This particular problem could be quickly resolved if the OSes still getting updates were updated to default name resolution to prioritize the IPv4 addresses instead. That would allow broken IPv6 configurations to exist without breaking the user's entire Internet experience. Which would allow them to leave it turned on so that it resumes working when the error is eventually found and fixed. Prioritizing IPv6 over IPv4 for newly initiated connections is one of the trifecta of critical design errors that have been killing IPv6 for two decades. One of the two that if key folks weren't being so bull-headed about it, it would be trivial to fix.
This is not unique to IPv6. Almost every protocol (including IPv4) has some inherent design problem that keeps lists like this alive with swaths of advice and solutions.
But at its core, if money is going to stand in the way of IPv6 gaining global interest, the issues you, me and others face with SLAAC and other technical IPv6 annoyances will never receive the attention they need to get resolved.
Why fix something nobody wants to use in the first place? Mark.
