> That's only true for smalltime home networks. Try to merge 2 company IPv4 networks with overlapping RFC1918 ranges like 10.0.0.0/8. We'll talk again in 10 years when you are done sorting out that mess ;)

Look, I've been doing IPv6 for 20 years, starting with a 6to4 tunnel and then moving to HE.net before getting native connectivity. I'm probably one of the first people who started using Asterisk for SIP on an actual IPv6-enabled segmented network.

I _know_ all the pitfalls of IPv6 and IPv4. And at this point, I'm 100% convinced that NAT+IPv4 is not just an accidental artifact but a better solution for most practical purposes.

> What you skipped are the really stupid problems with DHCPv6 which make it practically useless in many situations: DHCPv6 by default doesn't include the MAC address in requests.

Yes. DUIDs were another stupid idea. As I said, IPv6 is a cascade of recursive WTFs at every step of the way.

And let me re-iterate, I'm not interested in academic "but acshually" reasons. I know that you can run IPv4 with DHCP giving out publically routable IPv4 addresses to every host in the internal network without NAT. Or that you can do NAT on IPv6 or laboriously type static IPv6 addresses in your config.

What matters is the actual operational practice. Do you want a challenge? Try to do this:

1. An IPv6 network for a small office with printers, TVs, and perhaps a bunch of smart lightbulbs.

2. With two Internet uplinks. One of them a cellular modem and another one a fiber connection.

3. You want failover support, ideally in a way that does not interrupt Zoom meetings or at least not for more than a couple of seconds.

4. No NAT (because otherwise why bother with IPv6?).

Go on, try that. This is something that I can do in 10 minutes using an off-the-shelf consumer/prosumer router and IPv4. With zero configuration for the clients, apart from typing the WiFi password.