One of the big challenges with IPv6 remains that many of the knows-just-enough-about-networking people, like support staff, often never received any IPv6 training (or, for that matter, even enough IPv4 training that they don't need to Google things that come up in real life). Another is that the weird, awful, everyone-hostile corporate "solutions" often break IPv6 in stupid ways (like load balancers and logging tools being unable to cope with minor changes and requiring a full configuration rework).

Things have definitely gotten better over time, though. The massive 90s style corporate networks will probably never transition, but smaller and more modern companies don't have that issue.

Apple mandating that apps are IPv6 compatible and various government legislation forcing companies to make their shitty middleware IPv6-compatible has improved things quite a bit so far. As uptake keeps rising, the need for technologies like STUN and TURN will slowly start decreasing, and as a result more and more people will end up in "untested" situations where not having IPv6 and falling back to legacy paths starts becoming a problem.

A networking dude (he clutched his smartphone all the time) typed "spedtes" in my browser and was deeply confused when the server wasn't found. He tried several times more with slightly different spelling to the same effect, he literally couldn't even what went wrong.

Here's an example of a potential security hole caused by lack of ipv6 knowledge:

I've been setting up Snapcast (open-source multi-room audio), and needed to move the server to a different machine. While I was setting up the new system, I told it to only bind to localhost. Somehow this only affects the ipv4 networking stack, as some of my clients started automatically connecting to the new server even before I had finished all my testing.

Turns out that it was advertising some kind of ipv6 link-local address that showed up in autodiscovery. In my case there wasn't any harm, but this type of thing could very easily result in a major security vulnerability.

Localhost doesn't appear on autodiscovery. Whatever you ran into had nothing to do with IPv6, but rather with your application not binding to the address you were telling it to bind to. On IPv6, localhost binds to ::1, not anything reachable by any other address. Furthermore, whatever you set up automatically seems to have added itself to your server's firewall, which is equally troubling.

The address my clients were finding automatically was a link-local address (fe80...). Can't say exactly what happened but it was very surprising since I didn't even know these addresses existed.

I'm sure it's totally my fault but that's the point: folks who know how ipv4 works may have huge blind spots for ipv6.

I don't see how this generalizes into a security hole caused be lack of IPv6 knowledge. It just sounds like a random bug in Snapcast (great program!). If a user configures a program to only bind to loopback, but the program binds to other interfaces as well, that's a bug in the program.

There are sure to be dozens or hundreds of vulnerabilities like this, that's what I'm saying. I'm not even sure it's a bug in snapcast - very possible I configured it wrong without realizing.

Without knowing exactly what happened here, it could be hundreds, dozens, or zero other such vulnerabilities.

The usual convention for configuring listening interfaces usually involves listing IP addresses or interface names. There's very little room for misconfiguration here, although it's possible. More likely to be a bug in Snapcast (it's almost certainly not an issue in the Linux kernel).

Moreover, this general problem (i.e. configuring listening interfaces) is not/should not be different between IPv4 and IPv6. So introducing IPv6 should not™ incur any additional risk at this level.

But as said, it's hard to get more concrete without knowing exactly what happened in your case.

Facebook is (AIUI) 100% IPv6-only on their internal network, and has been for many years:

* https://engineering.fb.com/2017/01/17/production-engineering...

* https://www.internetsociety.org/blog/2014/09/facebook-launch...

IPv4 is actually the "leftover" stuff they have to deal with at the front end.

But they are an eye-balls heavy service, with a lot of mobile devices, which also tend to be IPv6-native.

It also just takes actual policy will. Somebody has to actually say "No" when the supplier who promised an IPv6 product says afterwards actually they meant IPv6 "ready" and they should have put an asterisk because really only the next version will be "ready", and er, so the product they've delivered doesn't actually work with IPv6 but that's fine right?

"No". Not every human is psychologically prepared to do that. They want to acquiesce, to go along to get along, you need somebody to be firm. "No".

I have found that it is incredibly satisfying to whip out the “no” card.

I have also found that an uncomfortable number of people do not consider it appropriate in any way shape or form. Even when it’s ultimately your call and no one else’s.

Folks don’t really like waves. They like looking at them from the shore, but freak out when it’s their turn to hang 10

Just wait until someone starts remembering the other archaic terms like ‘fraud’, ‘indictment’, etc.

Suppliers doing that kind of trick is what really killed GOSIP, and why the new v6 mandates in USGOV do not allow waivers for vendors, only for individual specific use cases

From my time there, this is for the internal prod network. Corporate networking was dual stack (which was pretty useful because it was common for v4 or v6 to break, but usually not at the same time)

That's why ipv6 migration should be government mandated. Then it becomes just the cost of doing business