Why is ARIN (etc.) allocating such large blocks of IPv6 addresses?
Solution 1:
The main reason is that stateless address autoconfiguration as per RFC4862 requires a /64 network to work properly. Add to that the assumption that one will want more than a single subnet at one's installation and the difficulty of routing arbitrary multiples of a /64, and the automatic tendency seems to be to assign a /56, or if lazy, a /48.
Oddly, I'm already seeing the first signs of parsimony in the UK. I've had v6 in my home office for a couple of years, now, but recently changed provider. The old one gave me a /56 automatically; the new one gave me a /64, but when I mentioned that I was subnetting happily upgraded me to a /56 without charge.
My guess is that the base allocation will stabilise at a /64 once v6 becomes common, with anyone who has a half-decent reason for it getting a /56.
Solution 2:
I imagine that routing smaller blocks creates problems for BGP routing - the more smaller blocks, the more routing ALL routers which don't carry a default route need to carry.
Also, while the driving force behind IPV6 is increased address space, IPv6 has a lot of advantages over IPv4. (More efficient routing, simplified network configuration, no more requirement for NAT - if you call that an advantage, better security - IPSec is baked into it)
My impression (and its nothing more then that, although I am on the fringe of the ISP community) is that there is no point in scrounding IPv4 addresses as it will only delay the inevitable - sooner or later the Internet is going to need to IPv6, no point in prolonging the agony by stretching IPv4 further then it has to be. Those who need to invest in upgrading infrastructure will hit the same walls regardless - they may as well hit them now.
Solution 3:
I feel like this was generally answered sufficiently (there are 240 trillion /48 allocations, which means every human on earth can receive 30,0000 /48 allocations and we still won't be out). But I will note that 2011's RFC 6177 changed the recommendation for ISPs and RIRs from "provide customer sites a minimum of /48" to "provide customer sites something shorter than a /64, probably a /56, but use judgement"
To quote the RFC:
While the /48 recommendation does simplify address space management for end sites, it has also been widely criticized as being wasteful.
I would disagree with this. Again, there are 240 trillion /48 allocations. Human extinction will proceed us running out. /48s offer way more address space than most sites need, but it's not really wasteful. It continues:
At the same time, it might be tempting to give home sites a single
/64, since that is already significantly more address space compared with today's IPv4 practice. However, this precludes the expectation that even home sites will grow to support multiple subnets going forward. Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single/64, but does not recommend that every home site be given a/48either.....
A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space.
The RFC also recommends only breaking up allocations on even nibbles, so /60, /56, /52, /48, etc. A /60 provides end users with up to 16 subnets, which is ok, but way less than the 255 subnets 192.168.0.0/16 private addressing on IPv4 allows. It's not hard to imagine a home user needing more than 16 subnets. Most won't, but it's not hard to imagine.
- assigning a longer prefix to an end site, compared with the existing prefixes the end site already has assigned to it, is likely to increase operational costs and complexity for the end site, with insufficient benefit to anyone.
I've seen some ISPs are finally getting around to deploying IPv6 for home users, but they're only providing /64 and they aren't providing static prefixes. This means home users can't run more than 1 subnet on IPv6, and that's distressing. It's fairly common for homes to have 1 subnet for most devices and 1 subnet for Guest Wifi. I'd encourage another subnet for IoT smarthome devices since those things seem to have so many firmware bugs that you hardly want them to be able to access the internet, but certainly don't wan them with access to your LAN. With only a /64, a home user would have to either: pick which subnet is IPv6 capable and use IPv4 + NAT for the other subnets or use IPv6 - IPv6 NAT.
I feel like a /128 is reasonable for a single server in some instances, and a /64 in others. But a /64 is never reasonable for a site, and while RFC6177 gives ISPs more leeway, we probably could have stuck with the "always give at least a /48 to end user sites" from 2001's RFC 3177 without harm.