[ppml] ppml 2002-7

[Alec H. Peterson]

--On Tuesday, February 11, 2003 11:19 -0600 Forrest 
<forrest at almighty.c64.org> wrote:

>
> 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
> 192.0.0.0/23, your block won't likely get filtered, but suppose you have
> 12.100.100.0/23, 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
> 205.145.0.0).

But this is entirely the point behind the objections to allocating /24s 
again.

We used to allocate /24s, and now we have a horrible mess of unaggregatable 
space (the swamp, 205/8 is pre-/19 space).  Current allocation policy has 
not stopped people from announcing /24s, but it at least allows people to 
aggregate to a certain degree and still be able to reach the entire 
Internet.

If we do allocate /24s, even from existing swamp space, eventually we'll 
run out and we'll have to create a new swamp.  It seems to me that this 
would be failing to learn from previous mistakes.

And as far as people announcing 64 /24s instead of the /18, that space can 
in fact be aggregated (assuming it is indeed a /18 allocation).  A service 
provider could filter those and be OK.

Alec

--
Alec H. Peterson -- ahp at hilander.com
Chief Technology Officer
Catbird Networks, http://www.catbird.com