Start accepting longer prefixes as IPv4 depletes?

[Iljitsch van Beijnum <iljitsch () muada com>]

(My apologies if this has been discussed before, I haven't been keeping up with NANOG as well as I should lately.)

As the IPv4 address space depletes, various types of use that requires IPv4 addresses will get harder. In some cases, 
this is unavoidable: if you want to connect a million broadband users you need a million addresses. But for hosting 
activities you don't need that much space. In fact, often people have to be very creative to qualify for a /24 (/20 
even in ARIN-land?) just so they have a large enough assignment that they can announce it in BGP and expect it to be 
reachable. But you really don't need a /20 or even a /24 to host websites or the like.

Why not move away from that /24 requirement and start allowing /28s or a prefix length like that in the global routing 
table? This will allow content people to stay on IPv4 longer with fewer compromises, so we don't have to start thinking 
about NAT46 solutions in the near future. (NAT46 is really best avoided.)

There are two issues:

1. Growth of the routing table. My answer to this is: although a smaller table would be good, we've been living with 
16% or so growth for a decade before the IPv4 crunch, if going to < /28 instead of < /24 allows this growth to continue 
some more years there is no additional harm. And there is no evidence that /28s will create more growth than 
unconstrained /24s like we had before the IPv4 crunch.

2. People who think it's neat to deaggregate their /16 into 256 /24 will now go for 4096 /28s. To avoid this, the new 
/28s should come from separate ranges to be identified by the RIRs. So /28 would only be allowed for this new space 
that is given out as /28, not for anything that already exists and was thus given out as much bigger blocks.

Thoughts?

I'm hoping to get some modest support here before jumping into the RIR policy shark tanks.