Re: IPv4 Address Pool Has Been Expanded Significantly
No, v6 didn't "ignore" backwards compatibility. v6 CAN'T DO backwards compatibility because v4 doesn't support it. There's no way to do complete bi-directional transparent backwards compatibility with v4. Nothing can be backwards compatible in that manner with existing, unmodified v4 nodes. It's not possible.
v6 isn't transparently backwards compatible with v4. Neither is EzIP, for the same reasons.
You need to decide whether you consider EzIP to be backwards compatible or not. If you think it is, then you also think that v6 is backwards compatible, because v6 uses the exact same mechanisms (dual stack, NAT, tunnelling) that EzIP does to be compatible with v4.
Do those mechanisms count as backwards compatibility or not? I'll let you decide. But either both v6 and EzIP are backwards compatible, or they both are not. You can't have it both ways. Not when they use the same methods.
If you don't believe me then you're welcome to learn v6 and see for yourself. If you're not going to do that, then you're going to have to rely on other people who do know it. Either way, please stop using your own preconceptions of what v6 can and cannot do, because they're wrong.
Re: peering, I'm talking about direct peering agreements between end-user ISPs and big content networks - people like Google, Netflix, Akamai. These people all push huge amounts of traffic, and they all do v6. Peering between end-user ISPs and content providers effectively takes that traffic off of the public internet (and it's the public internet that the article is talking about).
If so, how could anything like IPv6 that is built on top of lots of RFCs afterwards be simpler?
By not requiring that it be run as an overlay network. v6 can run as an overlay, but it also supports running natively, and running natively is way simpler than requiring a fully operational v4 internet and then running on top of it forever.
The number of RFCs isn't the important part. You'll find that going from a draft idea to something with completely defined behavior that can be implemented correctly everywhere requires thinking about and defining a bazillion things you never thought you'd need to deal with. That's what those RFCs represent. (That, plus 20 years' worth of further development on core internet protocols.)
Please be specific. I can reiterate the deployment conditions of EzIP for you. [...] There is really no "difficulty" in deployment to speak of.
Great to hear there's no difficulty! v6 can be deployed in exactly the same way. For example, you can deploy dual-stack routers without affecting anything in anybody's current internet setup. The various forms of NAT cover communicating between protocol versions. 6to4 covers the "give every existing IP more IPs" aspect (although it gives a trillion trillion IPs per v4 IP, rather than just 256M).
And, you have not made clear enough description about why EzIP isn't better, except by statements of your own words.
What else can I give? The way v6 works is public knowledge, and you're free to go and verify anything I've said.