The big issue I've seen is that there are not clear wins for all the pain of IPv6. And the failure to provide a much much better ipv4 interop story out the gate (vs just trying to yell at everyone to switch) was a big big loss. So that means folks ended up having to run ipv4 to end devices in many cases and we have dual stack hell across the network.
For the 90%+ of network clients on-prem that play by the rules you are often supporting both DHCP and SLAAC on IPv6 networks (unless android has figured out DHCP).
Dual WAN redundancy on IPv6 in SMB settings is actually worse relative to a NAT and ipv6.
The subnet size /64 is stupidly large, and the number of available subnets you can easily get annoyingly small from most upstream providers.
Firewall filtering has to be modified or you get weird errors. People don't always like ICMP coming through the firewall.
It's does lots of things differently, but for what? We do prefix delegation with DHCP but can't use DHCP to assign address (we are supposed to use SLAAC) but still need DHCP for lots of other stuff? It's nonsensical - you end up with just way too much garbage.
The privacy extension stuff hits IPv6 hard. You have lots of auto-rotating addresses.
The number of times turning of IPv6 fixes weird glitches / timeouts / stalls etc is still crazy too me.
ATT (massive corp) requires end user devices request /64 subnets one by one - which most end user gear does not support.
Getting static ipv6 IP's (despite claims there are lots of them) is seriously hard from upstream providers in many cases - but IPv4 is trivial by comparison.
The list goes on.
I would have made the subnet size 32 bits. Expanded the network part. Maybe even reduced the overall size - 128 bits feel dumb with /64's as the smallest subnet? Then just go super high interop / overlay to IPv4 with great suggestions so folks could ship ipv6 only stuff (even with on device bridge to ipv4 so outbound interface is ipv6) and no new concepts unless clearly justified.
For the 90%+ of network clients on-prem that play by the rules you are often supporting both DHCP and SLAAC on IPv6 networks (unless android has figured out DHCP).
Dual WAN redundancy on IPv6 in SMB settings is actually worse relative to a NAT and ipv6.
The subnet size /64 is stupidly large, and the number of available subnets you can easily get annoyingly small from most upstream providers.
Firewall filtering has to be modified or you get weird errors. People don't always like ICMP coming through the firewall.
It's does lots of things differently, but for what? We do prefix delegation with DHCP but can't use DHCP to assign address (we are supposed to use SLAAC) but still need DHCP for lots of other stuff? It's nonsensical - you end up with just way too much garbage.
The privacy extension stuff hits IPv6 hard. You have lots of auto-rotating addresses.
The number of times turning of IPv6 fixes weird glitches / timeouts / stalls etc is still crazy too me.
ATT (massive corp) requires end user devices request /64 subnets one by one - which most end user gear does not support.
Getting static ipv6 IP's (despite claims there are lots of them) is seriously hard from upstream providers in many cases - but IPv4 is trivial by comparison.
The list goes on.
I would have made the subnet size 32 bits. Expanded the network part. Maybe even reduced the overall size - 128 bits feel dumb with /64's as the smallest subnet? Then just go super high interop / overlay to IPv4 with great suggestions so folks could ship ipv6 only stuff (even with on device bridge to ipv4 so outbound interface is ipv6) and no new concepts unless clearly justified.