64 bits probably wouldn't be enough to let people avoid going into address conservation mode though. Heck, there are way too many ISPs allocating a single /64 in v6 land today, and there's far more space available in v6 today than there would be after 100+ years of your 64-bit space.
Having an unnecessarily large amount of addresses is a good thing, because the alternative is to have too few addresses. You don't want to have too few addresses, because if you think v6 is taking a long time to roll out... imagine how long a replacement to it would take.
They're allocating /64s because a lot of the design of IPv6 (SLAAC, for instance) makes it easy to do one /64 per customer who would have been doing IPv4 NAT. And the rest of the world bakes assumptions around this; for instance, IPv6 spam blacklists generally operate at /64 granularity because that's assumed to be one customer, so if customers get anything smaller like /96s or even /128s, unrelated customers will share spam reputation.
In a world where we kept the IPv4 worldview of NATs and just added more addresses, a 64-address space would be fine for the same reasons that /64s are fine in IPv6 today.
And the holdup on IPv6 rollout isn't related to it being a longer address space at all.
> Heck, there are way too many ISPs allocating a single /64 in v6 land today
First, ISPs are allocating them because they can. There are enough total /64 blocks for every living person to have a couple billion blocks.
Second, ISPs are allocating /64 blocks because they have to. Well, they don't have to, but there are 20 billion billion total /64 blocks. ISPs will run of capacity in their routing tables long before address blocks are exhausted.
> Having an unnecessarily large amount of addresses is a good thing
Agreed. Both 64-bit and 128-bit have unnecessarily large address spaces. But 32-bit is too few, though, and byte/word alignment is convenient. So 64-bit is convenient, unnecessarily large solution.
There's no requirement for ISPs to allocate /64 blocks. The requirement is that they allocate enough address space for all of their client's networks to use /64s. As such, all recommendations are for /56 at least (which takes up the exact same amount of space in their routing tables as /64 does: one entry).
If v6 was 64 bits in total, then ISPs would need to be allocating something closer to /48s to users at a minimum... but can you really imagine ISPs giving /48s in a 64-bit space when many of those same ISPs don't even give something larger than /64 in a 128-bit space? And this is despite the fact that a /48-in-64-bits would be 256 networks of 256 IPs each, which is far smaller than a /56's 256 networks of 2^64 IPs each? We know from v4 that 256 IPs in a network is frequently too small.
I'm just not convinced that 64 bits is enough, and I don't think we should expend this much effort deploying something that could be too small. Sure, it might be big enough with careful management, but I think it would be stupid to take the risk.
If you were arguing for an 80 bit address space then I'd have a much harder time calling it a risk, but for some reason 80 bits is an incredibly unpopular length.
It's too small. /56 should be the minimum unless there are hard technical reasons why you can't do that. My point was that a lot of ISPs seem to think that even /63 is too big, and that's in a 128-bit address space. Surely they would be even more miserly than they currently are if you removed 99.9999..% of the address space?
I was primarily thinking of residential ISPs; business ISPs tend to be a little bit better. That said, datacenters (or rather server/VPS providers) are absolutely terrible. Most of them give you no v6 allocation of your own at all. If you're lucky they let you use as many addresses as you like on your WAN segment, but good luck if you wanted to do a VPN or routed VM subnet.
Having an unnecessarily large amount of addresses is a good thing, because the alternative is to have too few addresses. You don't want to have too few addresses, because if you think v6 is taking a long time to roll out... imagine how long a replacement to it would take.