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.