The fact that there are still providers that haven't finished (or even started) their deployments is exactly why extra time wouldn't be helpful. They've had years and years to deploy v6; the only reason for not being done by now is that they've been procrastinating.

We've already bought these people an extra 10-20 years with pervasive NAT and over-aggressive address conservation. Buying them an extra 2 years would just lead to another 2 years of procrastination. Enough is enough. It's time they got a move on, and if they have to suffer through some (more) pain to get there then they only have themselves to blame.

I'd've loved to see ARIN put a "you can only get v4 space if you show us that you're doing a serious v6 deployment too" policy on their last /8. Bit late for that now though.

None of this will fix anything, because the v4 space just plain isn't big enough. It doesn't matter how you slice and dice it: there ain't enough of it.

You might be able to buy some extra time this way, but we've had more than enough time already. "More time" isn't what we need at this point.

*twitch*

"class C"?? 10/8 is class A. It's almost as far away as you can get from the class C ranges!

Spammers are already using it.

I only had to look at 3 emails in my spam folder before I found one that was delivered over v6.

Not really:

"What's the DNS IP?"

"It's at 53"

"Got it!"

and everybody involved in the conversation understands that the IP is 2001:db8:42::53, since the company's allocation is 2001:db8:42::/48. Heck, this is less bits to remember than 203.0.113.42 + 10.10.10.1, so if anything you're describing a problem with v4, not v6.

Everything larger than a /23 is getting denied now. Once they allocate the 55 remaining /23s (probably in a week or two), everything larger than a /24 will be denied. When they allocate the last 430 of those (in... 1-2 months?) then they'll be denying everything.

For reasons which are wrong or don't make sense.

Sorry, my bad. You linked the IANA runout, APNIC is here. (For completeness, RIPE is here and LACNIC is here.)

The real picture is that IP addresses are allocated hierarchically and there are multiple entities at all levels except the root, all of which run out separately.

IANA (the root of the tree, the people who allocate addresses to the regional registries) ran out of /8s in Feb 2011. The regional registries (there are five of them; these are the people that allocate addresses to ISP) have their allocated pools of /8s which ran out at different times: APNIC ran out in Apr 2011 (that's the story you linked), RIPE in 2012, LACNIC in 2014 and ARIN just now. (AFRINIC still has a few years to go, although they won't if everybody tries to get their addresses from there.)

Then there are the ISPs, who allocate addresses to their customers. ISPs will tell you that "we have plenty of addresses left" -- except the ones who don't -- but at some point all ISPs (or perhaps more importantly, your ISP) are going to move into the "don't" category.

And finally, ISP customers (i.e. you) allocate addresses to networks. Except you've probably never experienced this, because we've been short on v4 addresses for long enough that many ISPs don't (can't) give you enough IPs for your networks, and haven't for years and years. You probably grew up with this and consider it normal; it's not.

I don't know when you're going to go from "we seem to be trucking on just fine" to realizing that we have a problem -- I'd say we already do, since lots of people waste lots of time and money due to NAT, but perhaps for you it'll take your ISP giving you an RFC 1918 address on your upstream before you realize. Or maybe you have infinite time and money and don't mind the headaches caused by many layers of NAT and all the workarounds needed to deal with them, and you don't mind paying programmers to write workarounds into software, and you don't care about all the things we could've had if the internet had been up to providing them. But hopefully I've shed some light on the highly-complicated reality of "guy A allocates to guy B who allocates to guy C".

Which is what... two years worth of IPs? That's not going to solve anything. No amount of reallocating or reclaiming or reshuffling is going to save v4, because v4 is just plain too small.

We might be able to buy some extra time that way, but we've had plenty of time to handle things already. More time isn't going to help at this point.

The addresses aren't there. v4 is just plain too small. Freeing up a few /8s won't change that: there are more than 2^32 devices connected to the internet, so no matter how many blocks you reclaim, it's still not going to be big enough.

That's not what it says. It says that the capacity at 200 cycles is 1.5x a current cell. No mention is made of the point at which the capacity of these cells drops below the capacity of regular cells, if indeed such a point even exists: it's entirely possible these cells have roughly the same performance vs cycle curve as current cells after 200 cycles, just with a generally higher capacity.

I suppose you might raise the question of why they limited their testing to 200 cycles rather than more, but I note that if each charge/discharge cycle takes 4 hours then 2000 cycles would take almost a year to complete.

~3.8 GB, apparently.

What?

No, SLAAC isn't used with link-locals -- link-local addresses are assigned automatically by the host. It's used with whatever the network range on the segment is, which will usually be a global unicast range, or sometimes ULA. That's where it's supposed to be used, it's a normal way to do v6 and it works just fine.

Maybe. But on the other hand, even active servers spend a lot of their time idle (the paper says server utilization "rarely exceeds 6%"), and I bet a lot of these "comatose" servers are actually long-forgotten old hardware, or machines that nobody can be bothered to decommission -- it's possible that on average they're older than active servers and thus eating a lot more power.