Implied warranty of routability? Was: Re: US CODE: Title 15, ...
Karl Denninger
karl at MCS.NET
Tue Dec 31 21:09:59 EST 1996
>
> On Fri, 31 Jan 1997, Karl Auerbach wrote:
>
> > If ARIN does not promise coordination with routing, then I would submit
> > that ARIN can not complain should some collection of ISPs decide to start
> > selling net numbers, uncordinated with ARIN, for which they will advertise
> > and exchange routing information.
>
> Of course not. Why should they care? ARIN is only a registry.
>
> > Of course chaos will result. But just like the Alternic proposals in the
> > domain name context, this kind of rogue activity is a foreseeable response
> > to the ARIN proposal, especially as ARIN choses not to guarantee that the
> > numbers it issues will be usable.
>
> Rogue activity may occur, but very little chaos will result just as little
> chaos has resulted from the Alternic's actions. Most providers will have
> the foresight to see that if even one provider does not join in the rogue
> activity, then that provider will have a competitive market advantage.
> Therefore most providers will not join in. It is not unusual for
> unregistered IP address blocks to show up on the global Internet. But when
> this occurs, it is quickly tracked down and filtered out. This is
> especially so when the address is already in use by someone else who *HAS*
> registered it. All in a day's work.
>
> Michael Dillon - Internet & ISP Consulting
> Memra Software Inc. - Fax: +1-250-546-3049
> http://www.memra.com - E-mail: michael at memra.com
Balderdash.
Just the other day 0.0.0.0/0 (yes, DEFAULT) was being propagated by a LARGE
NUMBER of national providers -- from a rogue (and unintentional) announcement
that came out of a particular firm in Virginia.
This went on for well over SIX HOURS before it was stopped. It was transiting
a large number of NATIONAL network provider's core hardware, and disrupting
connectivity to a fair number of people, some of whom were completely
clueless as to the cause. We found it because we run defaultless and ANY
instance of default appearing in announcements or anywhere on our core
is an instant five-alarm fire.
When we finally called the guilty party (after informing peers and upstream
links hours before with no effect), they had not heard ANYTHING about it as
of yet, and the announcement was ALREADY a few hours old in our tables at
that point.
Filtered out quickly my tailfeathers.
99% of the companies out there don't filter ANYTHING at that kind of level.
Try to maintain the filters on CISCO hardware to actually verify and prevent
any rogue announcements -- good luck. You just can't do an EFFECTIVE job
of this; the coordination you NEED to do so is completely non-existant
between firms to make it possible, especially in the "swamp".
Now you can get routes from only a route server, yes, and that does help.
Quite a bit. But basically all providers of any significance have exchange
point(s) where the RADB isn't used.
If the address isn't something that someone else is using, and is of
sufficient prefix size (in 206 and above) I bet it wouldn't be noticed for
months -- if ever -- until someone tried to get a so-called "official"
allocation of the same number and said "what the hell??" when they found it
already in the tables.
I bet I could announce a random "reserved" prefix and nobody would catch
it for at least 30 days -- during which time it would work perfectly, and
globally.
Yes, doing that kind of thing would be highly antisocial. But don't think
for an instant that anyone actually watches constructively for this kind of
chicanery on the net. That would be a false assumption, as I think the
little episode of the other day proves rather conclusively.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 99 Analog numbers, 77 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
More information about the Naipr
mailing list