Re: Start accepting longer prefixes as IPv4 depletes?

[Mohacsi Janos <mohacsi () niif hu>]

Dear Iljitsh,

	Do you plan to put /28 into the DFZ routing table? You thought 
about routing table capacity of the today's routers.., I think prefix 
length around /22 is accepted, but blindly accepting any /24 prefix is not 
a reality today. What about the stability of the routing table without 
aggregation? Do you consider BGP churning?
	Do you think adopting LISP or similar architectures to reduce the 
problems mentioned above?


Janos Mohacsi
Head of HBONE+ project
Network Engineer, Deputy Director of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

On Wed, 8 Dec 2010, Iljitsch van Beijnum wrote:

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