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 .
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.
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.
From what I've gleaned, the use of Google ads catches the use case of people who don't actively use Google -- based on the delta in metrics between Google's stats and APNIC's, I would suspect that Google isn't quite as popular globally as you think it is (but their ad platform is!).
- APNIC ran out in 2011, but has a new-LIR pool remaining
- RIPE ran out in 2012, but has a new-LIR pool remaining (part of which is that /8 you mentioned)
- LACNIC ran out in 2014, but has a new-LIR pool remaining
- ARIN ran out in 2015, and does not have a new-LIR pool
- AFRINIC is the only RIR with a general-use pool available
As akvadrako says, there's a secondary market, except the current pricing is around 16+USD/IP, with the semi-obvious minimum of a /24 (so, 4000+USD). Given that (in ARIN region) that /24 would have cost you 250USD up-front, it's a marked increase.
I'd half agree with this; for those who are actively working on this, yes, the low-hanging fruit are all done, but there's still plenty of low-hanging fruit in organizations where no one's bothered to pick them.
b) You're ultimately still right that it enables connectivity to IPv4-only resources, but depending on the IPv6 client device, you may NEED to use a DNS 'A' record to get the traffic to use NAT64/DNS64, rather than trying to connect to a bare IPv4 address.
a) You missed Belgium. (Common oversight, due to the size on the map.)
b) Google's stats have something of a US-centric bias; https://stats.labs.apnic.net/ipv6/ is a little less biased (which also shows Belgium and India in the lead).
As others have said, most major operating systems implemented RFC4941 (IPv6 Privacy Extensions) years ago. Unless you're using unmaintained OSes (in which case you shouldn't be complaining about security), what privacy implications are you calling out?
What privacy erosion/easier tracking are you talking about that wasn't remedied by the very wide deployment of RFC4941 (IPv6 Privacy Extensions) in operating systems?
https://clintonwhitehouse1.archives.gov/
https://clintonwhitehouse2.archives.gov/