The main problem wasn't all the smaller features but one big one in particular that can't be split into smaller pieces, the new addressing scheme. They wanted to replace all the existing addresses, which meant replacing all the routes. Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack.

> Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack.

Sure, "make the addresses bigger" would have required providing DHCPv6, DNS AAAA records, and various other protocol updates for protocols that embedded IP addresses. And making changes to the protocol header at the same time (e.g. removing the redundant checksum) were also a good idea.

It didn't require pushing SLAAC instead of DHCP.

It didn't require recommending (though fortunately not requiring) IPsec for all IPv6 stacks.

It didn't require changing the address syntax to use colons, causing pain for all protocols that used `IP:port` or similar.

It didn't require mandating link-local addresses for every interface.

It didn't require adding a mandatory address-collision-detection mechanism.

And I'm sure I'm forgetting a few.

Yeah. I didn't like any of those proposed changes, especially the colons. You also didn't mention how NAT6 isn't a thing by default.

It didn't require removing ARP and inventing Neighbor Discovery that embeds the hardware addresses into the IP address.

It didn't require the Ruby Goldberg "on link" network mechanism.

It didn't require multicast instead of broadcasts for local network discovery.

It didn't require using DNS config (of all things) to specify V4/V6 priority.

It didn't require adding a "flow label" that is nobody to this day knows how to use properly.

The list of fails is ridiculous.