The Gorgon's Knot. Was: Re: Verio Peering Question

E.B. Dreger eddy+public+spam at noc.everquick.net
Wed Oct 3 14:42:12 UTC 2001


> Date: Wed, 3 Oct 2001 11:02:44 +0200 (CEST)
> From: Iljitsch van Beijnum <iljitsch at muada.com>

> Filtering on prefix size is a pretty absurd idea. A network is

[ snip anecdotes: a.root-servers.net & www.cnn.com ]

And eBay's /24, /23, and /22 blocks; see one of my earlier posts.
Yes, I agree... I probably should reverse myself: filtering > /24
is _not_ acceptable.  My reasoning was that, if some idiot
announces each dialup /32, their upstream would want to use
filters.  Prefixes shorter than /24 could quickly chew up 100K
routes (I'm too lazy to do the math, but anyone following this
thread is more than capable), but I'd consider the probability to
be rather low.

Providers are pretty good about distribute-list and filter-list
checks... if you want to advert more than space they provide, you
contact them out-of-band.  Maybe we do something similar re
prefix length.

Sure, I'd love to move the route count problem to the edge.  But
the whole reason that places filter is because they think that
the edge _isn't_ doing a good enough job.  Perhaps we should
enforce prefix length adverts top-down, in the same manner that
IP space utilization is enforced?

Now, Verio's policy wouldn't be so bad if it correlated with
something official from RIRs.  e.g.:

* Globally-routable /32 in 126/8
* Globally-routable /27-/30 in 125/8
* ... /24-/26 in 124/8

My complaint is that Verio is taking rather great liberties in
their filtering that, IMHO, _do not_ correlate well with
allocations.  Good idea in an ideal world, but they need to
operate in reality.

If we can change reality... all the power to them.  I'll turn
totally pro-filtering if we can accurately say "this is the
shortest globally-routable prefix allowed in _this_ netblock".

Wait a second... swamp /24s haven't all been returned yet.  No,
the above paragraph just won't work.  We could require
justification of existing netblocks... no, that would mean pain
for everyone, not just new allocations.

I guess that we'll keep going along Status Quo Road until we
run out of IPv4 space, then go on a big witch-hunt.  Anyone care
to mark my words on this?  (I only hope that I'm wrong!)

> On the other hand, filterers do have a point: why are there so
> many /24s in the global routing table? But then again, this
> also happens to a lesser degree for larger blocks. Have a look
> at the 24.x.y.z space, this is pretty ridiculous.

No kidding.

FWIW, we advert three routes: /22, /22, /23.  A couple of /24s
will be announced soon.  Like Jeff, we'd gladly renumber, into a
single /20 in our case.  When we're through getting beaten up by
ARIN and get a PI /20, we'll do just that.  In the mean time,
we'll keep advertising 3x as many routes as we should.

I know of another place that is renumbering into a PI /19, and
will finally give up about 8-10 longer prefixes.  More table
pollution.

Current IP allocation policies are just not conduceive to
efficient routing tables.  We little guys can't get portable
space, and upstreams must use theirs efficiently.  Result?
Routing table fragmentation.  Pre-CIDR days, anyone?

> Obviously, some networks don't care about the size of the
> routing table and announce hundreds of routes. Other networks
> do, and filter the easy targets. (And some networks manage to
> fall into both categories.) The result being that a group that
> didn't cause the problem suffers and the problem is not really
> solved.

Yup.

[ snip regional-routing discourse ]

> Even better would be if the RIRs would divvy up the world in 10
> - 20 regions, and allocate a /8 - /10 to each. That way, the
> routers don't have to know all individual routes to some remote
> region, but they can simply forward the traffic to a part of
> the network that does know the region-specific routes.

Aggregation at its finest. :-)

Furthermore, if one could _know_ that a given netblock was in a
specific geographical location, one could more easily correlate
latency with netblocks.  Sure, 202/7 is APNIC territory.  Alas,
that's just a best case under the current scenario.

> If anybody bothers to reply to this, you will see that there
> are numerous reasons why this isn't "the" solution. However, it

Anyone with The Solution is free to flame anything I have said.
All public lartings will be accepted.

> may help some people some of the time, and it doesn't impact
> those who don't want to use it.  And, more importantly: it
> doesn't require universal cooperation. Just the RIR's.

Even that could be difficult. :-(  But it's definitely orders of
magnitude better than universal cooperation.

> Iljitsch van Beijnum


Eddy

---------------------------------------------------------------------------
Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
---------------------------------------------------------------------------

Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist at brics.com>
To: blacklist at brics.com
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.  Do NOT
send mail to <blacklist at brics.com>, or you are likely to be blocked.




More information about the NANOG mailing list