[48570] in North American Network Operators' Group
Re: Bogon list
daemon@ATHENA.MIT.EDU (Chris Woodfield)
Fri Jun 7 13:43:51 2002
Date: Fri, 7 Jun 2002 13:40:17 -0400
From: Chris Woodfield <rekoil@semihuman.com>
To: North America Network Operators Group Mailing List <nanog@merit.edu>
Cc: "Stephen J. Wilcox" <steve@opaltelecom.co.uk>,
Stephen Griffin <stephen.griffin@rcn.com>,
"Sean M. Doran" <smd@clock.org>
In-Reply-To: <20020607165508.0AC3CAC@proven.weird.com>
Errors-To: owner-nanog-outgoing@merit.edu
--wac7ysb48OaltWcw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Well, the biggest offender in this respect by far was @home, and you know w=
hat=20
happened to THEM...
-C
On Fri, Jun 07, 2002 at 12:55:08PM -0400, Greg A. Woods wrote:
>=20
> [ On Friday, June 7, 2002 at 10:26:53 (+0100), Stephen J. Wilcox wrote: ]
> > Subject: Re: Bogon list
> >
> > RFC1918 does not break path-mtu, filtering it does tho..=20
>=20
> So, in other words inappropriate use of RFC 1918 does not break Path MTU
> Discovery! You can't still have your cake and have eaten it too. One
> way or another RFC 1918 addresses must not be let past the enterprise
> boundaries. Lazy and/or ignorant people don't always meet all the
> requirements of RFC 1918, but it's only their lack of compliance that
> _may_ allow Path-MTU-discovery to continue working for their networks
> for _some_ people _some_ of the time.
>=20
> However any enterprise also using RFC 1918, but using it correctly (or
> customers of such an enterprise), and thus who are also carefully
> protecting their use from interference by outside parties, will be
> filtering inbound packets with source addresses in the RFC 1918 assigned
> networks, and so as a result they _will_ experience Path-MTU-discovery
> failure (i.e. at any time it's necessary it literally cannot work) when
> attempting to contact (and sometimes be contacted by, depending on the
> application protocol in use) any host on or behind the lazy and/or
> ignorant operator's network(s).
>=20
> (and no, I'm not sorry if I've yet again offended anyone who might be
> mis-using RFC 1918 addresses for public nodes -- you should all know
> better by now! How many _years_ has it been?)
>=20
> > > 2) Not believe in filtering RFC1918 sourced traffic at enterprise bou=
ndaries
> > > (of which an exchange would be a boundary)
> >=20
> > What for? You'll find many more much more mailicious packets coming from
> > legit routable address space.
>=20
> If you have any IP address level trust relationsips on your internal
> LANs then you _MUST_ (if you want those trust relationships to be valid)
> filter all foreign packets with source addresses appearing to be part of
> your internal LANs.
>=20
> > For p2p you can use unnumbered.. it wont work on exchanges but i agree
> > they shouldnt be rfc1918.=20
>=20
> On this we can agree! :-)
>=20
> --=20
> Greg A. Woods
>=20
> +1 416 218-0098; <gwoods@acm.org>; <g.a.woods@ieee.org>; <woods@roboha=
ck.ca>
> Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weir=
d.com>
--wac7ysb48OaltWcw
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9APAAqP/YiunDNcERApcDAKDvdTd0O3fE8rIMgROPqA9jxGGp3wCfVX9b
utfFPWXUheAvuMVZMUHgY/E=
=JeZB
-----END PGP SIGNATURE-----
--wac7ysb48OaltWcw--
