[ppml] ppml 2002-7

Forrest forrest at almighty.c64.org
Tue Feb 11 12:19:48 EST 2003

On Tue, 11 Feb 2003, CJ Wittbrodt wrote:

>     >
>     > There is little credible engineering reason to deny allowing an
>     > organization to own a small public block.  I have not seen any research
>     > done that would suggest that doing this would impact routing table size.
>     The routing table size isn't really the main argument against this.  It's 
>     the _structure_ of the routing table, in terms of ability to aggregate.
>     Right now, ARIN only allocates /20 and longer blocks.  This means that 
>     service providers could filter routes they receive on this boundary (in 
>     ARIN blocks anyway) to help control the size of the routing table in their 
>     network.  If ARIN allocates longer blocks, this ties the hands of service 
>     providers.
> Don't you mean ARIN allocates /20 or shorter length blocks?  
> Anyway, I have been doing some work with some students at UCLA.  The current
> results say that around 48% of allocated blocks are advertised identically 
> to how they're allocated (same prefix length, not fragments).  Around
> 40% of the allocated blocks are advertised in one or modes of fragmentation
> (combinations of aggregates and fragments). This means that an ISP could
> get great benefit from being able to filter out the fragments of shorter
> provider blocks.   I am presenting this at NANOG so fee free to look at my 
> slides.
> ---CJ

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 the 
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, your block won't likely get filtered, but suppose you have, what good is it to multihome if nobody would accept your 
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 and 
I doubt anyone will have to adjust their filters).  I just don't see this 
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 at


More information about the ARIN-PPML mailing list