The way to make IPv6 take off is to make IPv4 addresses astronomically expensive.

It's kind of funny that doing so would have been easy years ago; but the easier it is to just transition to IPv6, the harder it is to drive up the price of IPv4, as decreasing supply of IPv4 at this point will just drive down demand. Yes, you're "making IPv6 take off" in some sense by doing so, but not in a positive-feedback loop; more in a negative feedback-loop, where the market ends up in a new equilibrium state where nobody is switching.

Which is exactly why IPv6 never should have required transitioning off of anything.

There were IPng proposals in which zero-padding an IPv4 address gave you a valid, interroutable IPng address. One network is a strict superset of the other.

Greenfield redesign was a great idea, until the ipv4 fire NATion attacked ...

> As the Internet is moving to IPv6

It's been 22 years since the first Global Unicast IPv6 allocations were made and progress has been very slow. This will not be complete until long after I am retired.

Been hearing that for decades now. Pretty sure they'll be valuable for a few more decades at the very least.

Just 1 decade ago usage was less than 1 percent, now it's nearly half. I'm not sure I'd bet decades more on them being particularly valuable when they haven't even been considered valuable for multiple decades yet.

> Just 1 decade ago usage was less than 1 percent

Yeah, because NAT64 is 11 years old:

https://datatracker.ietf.org/doc/html/rfc6146

IPv6 was useless without it. It took over 13 years for people to figure that out.

With that in mind the value of ipv4s would be worth tracking

IPv6 is not backward compatible with IPv4. That's why ipv6 - will never work. There must be new IPv8 with backward compatibility with ipv4 and easy migration to new proto without any changes in configs.

> There must be new IPv8 with backward compatibility with ipv4

How would you accomplish this? How could an IPv4-only system send a packet to an IPv8 address? IPv4 packets only have 32 bits for the destination and source IP addresses, there's no way to fit the address for any newer protocol with longer addresses in there.

Mandatory NAT64 support in every dual-stack router.

Concretely: if you're a router and you accept IPv6 packets, you must offer NAT64 services on any interface from which you accept IPv4 packets. The upgrade ripples outward from the core routers (default-free zone) in two waves. As soon as all of a router's peers support IPv6, that router can drop NAT64 and IPv4. No flag days. All coordination is between a pair of peers with a direct link.

There were IPng proposals that had this requirement (using different terms, of course). IPv6 wasted more than a decade fighting against NAT64, tooth and nail. It wasn't until they finally caved and standardized NAT64 that people took IPv6 seriously -- but by then it was too late to make it a mandatory feature of dual-stack routers and there was already hardware shipping with IPv6. The clean upgrade path was lost forever.

Next time anybody complains about the IPv6 transition taking so long, you know who to blame.

Funny that you think NAT64 is relevant. Every successful deployment I’ve worked with in the US is just dual stack. Native v6 networks with nat64 came after the big content providers got ipv6 server support for the dual stackers.

NAT64 has worse scaling than CGNAT (requires more state and moving pieces) so it was never a solution to drive adoption.

Nearly all IPv6 traffic is cell phones. And they are all behind NATs.

You got confused. If it’s ipv6 traffic it’s not behind 6to4 nat. Any stats about ipv6 on the internet are by definition not included stuff that got hit with 6to4.

What you describe is literally impossible. The ship has sailed and IPv6 usage is going up each and every year. Some countries, like the US, France, Germany, are at over 50% adoption.