Start accepting longer prefixes as IPv4 depletes?

Wed Dec 8 19:12:45 UTC 2010

On 08/12/2010 20:30, Iljitsch van Beijnum wrote:
> 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.)

This was discussed at length during the policy discussions at the recent 
AfriNIC conference. The soft landing policy was passed with a provision 
to allocate blocks as small /27. Warning labels were pasted all over 
this but were ultimately overlooked in favour of getting the policy 
adopted ASAP.

> 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.

For one think the /24 limit places a barrier to entry on de-aggregation. 
I don't think that there will be a shortage of prefixes post exhaustion. 
/24s will be easy to carve out of larger allocations for 
trading/redistribution.

On the operational side I have come across people who carry partial 
tables on their networks to avoid spending money on upgrades. One way 
that they seem to be pruning their tables is to drop long prefixes (just 
dropping /24 makes a big difference) I suspect that this will happen 
more as people focus their effort and CPU cycles on making IPv6 work.

> 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.

Its too late to really be thinking along the lines this kind of 
structured address allocation IMO. If we ever were to get to /28 
allocations they would most likely be from many recovered fragments of 
address space.

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

I suspect that the operational community would not stand behind this :-)

-- 
Graham Beneke