[ppml] ppml 2002-7
steve at rovingplanet.com
Tue Feb 11 14:28:28 EST 2003
To me, it seems that the biggest issue that 2002-7 seems to address is
trying to multihome small blocks that aren't located in the old Class C
space. It seems that most providers that do filtering, they filter on
old Class boundries. In the old Class C space, they'll accept /24's
because of people using old swamp space. So suppose you have block
192.0.0.0/23, your block won't likely get filtered, but suppose you have
126.96.36.199/23, what good is it to multihome if nobody would accept
small route? Basically it makes sense to allocate a specific block just
for small organizations that want to multihome, that providers will
accept /24's and shorter from (allocate it from the old Class C range
I doubt anyone will have to adjust their filters). I just don't see
causing the routing table to explode in size. What's exploding the
routing table is stuff like someone announcing a /18 as 64 /24's (look
This is essentially one of my points. The whole idea of aggregating only
works well for the provider that "owns" the base block. As an example,
there are many /24 that I see from old class A's. They may be
aggregated by the base providers but the other providers can't aggregate
unless other adjoining bit wise networks are also present. Upstreams
can't filter without potentially blackholing traffic (something I have
observed more then once much to the chagrin of that provider). So in
practice what it comes down to is that the /24 is seen by the world.
So I go back. Aggregation can't be an issue. What is the real issue with
allowing small (or otherwise) multi-homed organizations to have assigned
a single /24 (or even smaller) of their own?
It really sounds like the reason to deny is based on address space.
Again if the Network/AS pair is being seen by the world anyway why set
an arbitrary /24. As was commented already, I have also seen single
digit usage of a /24 because the /24 was all that could be announced.
More information about the ARIN-PPML