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.
