Bogon list

Wed Jun 5 03:14:58 UTC 2002

[[ What's with the huge CC list everyone?  Aren't we all subscribers?  Do
y'all enjoy getting multiple copies of replies?   I don't!  ;-) ]]

[ On Tuesday, June 4, 2002 at 18:33:23 (-0700), Sean M. Doran wrote: ]
> Subject: Re: Bogon list
>
> | Why treat exchange subnets differently to any other bit of backbone 
> | infrastructure? 
> 
> Oh, I wholeheartedly agree.  I would love them all to use RFC 1918
> addresses, because it is VERY VERY VERY rare that anything outside
> the scope in which the 1918 local use addresses are unique actually
> has to communicate with backbone infrastructure of any type.

"has to" and "can" in this context are two very different things.....

If everyone filtered source and destination bogons A.S.A.P.P.....

> In short, ping & traceroute are about the only interaction anyone
> will ever have with a router that is not under their control, 
> excepting error messages (which is the usual way at least traceroute works), 
> and it is NOT WORTH THE ADDRESS CONSUMPTION just to facilitate this.

I'm not so sure I agree (traceroute can be fun), _BUT_, if such routers
were to always use only one unique-to-themselves canonical routable
address in all valid error messages that they generate then there
wouldn't be such a problem.  Providers would at the same time enjoy the
benefits of hiding all the niggling interface details while not borking
tools that the little guys a the edge have used to point the finger from
time immemorial....

> Regrettably, IP sux in the confusing of "where" and "what", so
> the only way to know who sent you the error ICMP datagram except
> by the source address.

Indeed, but IIRC there's nothing which says a router has to emit error
replies using the source address of the interface the undeliverable
packet arrived on, is there?  If a given router uses a single
unique-to-itself canonical globally routable source address for all ICMP
error replies it generates then the output of the likes of traceroute
and even ping will still be meaningful and useful.  No important
information is lost, at least not from the point of view of everyone
_without_ a login on the router in question at least (and if you can
login to the router then I should hope you can figure out what interface
the undeliverable packets are arriving on without any external help!).

Isn't there even an IOS command to "make it so", or am I dreaming
visions of some as-yet unimplemented BSD-based router feature again?

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods at acm.org>;  <g.a.woods at ieee.org>;  <woods at robohack.ca>
Planix, Inc. <woods at planix.com>; VE3TCP; Secrets of the Weird <woods at weird.com>