Yeah, hobbyist niche sites like these:

https://clintonwhitehouse1.archives.gov/

https://clintonwhitehouse2.archives.gov/

Backward compatibility was never really the problem; the problem is that forward compatibility with ANY successor protocol (without modifying IPv4) is a fundamental impossibility.

But at least a reasonable facsimile eventually came out with NAT64.

(You can also do NAT46, but it requires one IPv4 address for every IPv6 destination you want to be reachable from the IPv4 Internet, so it doesn't scale very well.)

Additionally, their fixed-wireless product gives you a physical CPE that does the CLAT (NAT46) side of the 464XLAT.

To the local network, it looks like there's native IPv4, but it's translated to IPv6 by the gateway, and sent to the "nearest" NAT64 PoP to be translated back and sent along its merry way.

2.7 - 4.0 years, by my math, so I would agree with your assessment.

...but that's based on pre-IANA-runout rates, though, and doesn't account for the pent-up backpressure of demand. So probably a lot less, in reality.

Not even remotely worth the effort, even if there were a legal pretext for "reclaiming" IPv4 space (there isn't; there's already precedent denying it).

Anyone who's ever had to delegate DNS authority on anything other than an 8-bit boundary can understand the value of that feature.

At face value, yeah, that's replacing "8" with "4," but from a practical perspective, delegating authority for a customer IPv4 /25 requires, at minimum, 128 records. (Granted, there's also no practical need to be stingy about IPv6 allocations -- that IPv4 /25 customer could simply receive an IPv6 /48.)

I would firmly expect to see a lot more formulaic reverse (and presumably forward) DNS responses, where needed, since filling files with records you need to store on disk (and in memory) doesn't scale well. The tech has existed for years; I wrote my own implementation years ago, but these days I'd use something like PowerDNS with https://github.com/wttw/regexdns .

This is pretty remarkable, given that RFC 1883 is only 30 years old.

This. "Vibes," vs. data.

It officially started becoming scarce in 2011, when IANA, and then APNIC, depleted their IPv4 "free" pools, FWIW. Things have only gotten worse from there.

Cloud computing doesn't mitigate IPv4 issues, it just moves it around. The big cloud providers buy up any IPv4 space they can, leaving less for everyone else. The difference is that they then get to collect rent, by the hour, on any IPs their customers use.

Load balancers...yeah, actually that is a valid approach to reduce IPv4 use, assuming you mean the "reverse proxy" variety of load balancer. Cloudflare's proxy service is doing exactly this, on a pretty huge scale. (CLoudflare can then send the traffic on to an IPv6-only server, regardless of the client's protocol.) The downside is, like cloud, consolidating a lot of infrastructure into the hands of a small number of companies.

> And if I'm reading the ARIN fees correctly, it only costs $4000 annually for a "/16" allocation:

For better or worse, you're not; that's for IPv4 /16. For IPv6 /16, it'd be the X-Large service category, so $16,000/year.

And for $256,000/year you can... exhaust the entirety of 2000::/3?

Yeah, that's not okay. Either the price needs to go up a lot or they need to include factors other than money in the allocation criteria.

> they need to include factors other than money in the allocation criteria

They already do, and simply being able to pay the fee does nothing to qualify you for an allocation: https://www.arin.net/participate/policy/nrpm/#6-ipv6

At least, in theory. I'm not going to attempt to defend the Capital One allocation.

They might have included them in the published policy, but it seems they aren't in whatever policy they're actually following.

It seems more likely to me that ARIN is following the text of published policy, but Capital One found a way to interpret it that violates its spirit. My guess is that they're treating each customer debit/credit card as a serving site that qualifies for a /48. To address this, ARIN should fix the policy, not raise fees.

It's ARIN's job to call BS on BS justifications, otherwise they're not following the policy, they're following whatever they allow. "The purpose of a system is what the system does" and all.

That's an interesting idea for how they justified it. There might be something like 4 billion active credit/debit cards in the US (but they probably weren't all issued by Capital One).

I have been working with IP based networks for over 20 years, and specifically IPv6 networks for over 17 of those. IPv6 is the main reason I got my current job, FWIW.

> The use of NAT64 is helping many organisations to delay migrating to IPv6.

That's...not how NAT64 works. NAT64 is fairly dependent upon deploying IPv6, like T-Mobile's 11+ million IPv6-only users who use their NAT64 platform.

I do agree that from a purist's point of view, it's not ideal, but it enables network operators to stay largely single-stack (on v6), while still facilitating access to the IPv4 internet.