A large part of the problem with IPv6 is that most developers and SA's don't have a lot of knowledge about it. This is why everything new is still built with IPv4 in mind, instead of thinking forward to IPv6. I think we could easily blame lack of IPv6 support at cloud providers to lack of knowledge with the developers and SA's they attract.

If more developers and SA's would have access to IPv6 at home, the practical knowledge of how to work with IPv6 would build up more quickly. I would experiment with it more, and build up more knowledge.

Unfortunately, my ISP does not support IPv6. This severely limits experimentation with it, since all experimentation is locked behind my home network.

> Unfortunately, my ISP does not support IPv6. This severely limits experimentation with it, since all experimentation is locked behind my home network.

You probably know about this already, but there are free IPv6 tunnel brokers you can use to experiment. I previously used Hurricane Electric's tunnel, back before Comcast had native IPv6 support: https://www.tunnelbroker.net/

A more practical challenge, Hurricane Electric is a 6in4 tunnel, not layered over TCP nor UDP. Some ISP-provided residential gateway devices (AT&T) don’t support 6in4, not even if you configure your device as a “DMZ” with a public IP address. Also, I frequently find myself in situations with IPv4 NAT and no public IPv4 addresses at all.

The only free IPv6 tunnel service that supported UDP was SixXS, which shut down in 2017.

Nowadays, AT&T supports IPv6 natively, and I went through an annoying amount of effort to bypass their gateway device and control the entire /60 instead of being limited to a /64 and being limited by their NAT. https://github.com/jaysoffian/eap_proxy