[30157] in North American Network Operators' Group
Re: RFC 1918
daemon@ATHENA.MIT.EDU (ww@shadowfax.styx.org)
Mon Jul 17 10:56:17 2000
From: ww@shadowfax.styx.org
To: Stephen Kowalchuk <skowalchuk@diamonex.com>
Cc: nanog@merit.edu
In-Reply-To: Your message of "Mon, 17 Jul 2000 10:24:25 EDT."
<39731719.9F93DA7D@diamonex.com>
Date: Mon, 17 Jul 2000 10:39:22 -0400
Message-Id: <20000717143922.C081C745F@shadowfax>
Errors-To: owner-nanog-outgoing@merit.edu
>>>>> "Stephen" == Stephen Kowalchuk <skowalchuk@diamonex.com> writes:
Stephen> Why on earth would anyone object to filtering RFC 1918
Stephen> traffic?
I think this thread is beginning to get a bit long, but...
Imagine that you inherit a network where RFC1918 addresses are used on
most or all backbone links. Because it's reasonably difficult to get
real addresses from ARIN for a company starting from scratch, this is
perfectly plausible (need customers to justify address space -> need
network to get customers -> must build network before address space is
acquired). But, like most things that are intended to be temporary,
these private addresses on backbone links are likely to become
semi-permanent. Now everybody who does a traceroute to or from one of
your customers sees an RFC1918 address or two.
"Don't build it like that in the first place" is not a very usefull
answer -- sometimes there is no choice. Migrating the addresses of the
whole backbone could take some time, so what to do in the
meantime? Do you start filtering in the core of your network? Do
you start making the 7507s in your transit path process switch each
packet in the 30Mb of traffic that they're forwarding?
Sometimes filtering them out is just impractical untill you can buy a
Juniper M40 ;)
-w
--
Will Waites \________
ww@shadowfax.styx.org\____________________________
Idiosyntactix Ministry of Research and Development\
