[30073] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: RFC 1918

daemon@ATHENA.MIT.EDU (Bennett Todd)
Fri Jul 14 16:24:17 2000

Date: Fri, 14 Jul 2000 15:54:15 -0400
From: Bennett Todd <bet@rahul.net>
To: "Steven M. Bellovin" <smb@research.att.com>
Cc: nanog@merit.edu
Message-ID: <20000714155415.K19521@oven.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="u3W6riq+uV6J42Ub"
Content-Disposition: inline
In-Reply-To: <20000714194722.AD3EA35DC2@smb.research.att.com>; from smb@research.att.com on Fri, Jul 14, 2000 at 03:47:22PM -0400
Errors-To: owner-nanog-outgoing@merit.edu



--u3W6riq+uV6J42Ub
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

2000-07-14-15:47:22 Steven M. Bellovin:
> No -- 1918 addresses would only break PMTU if folks did ingress or
> egress filtering for 1918 addresses.

Wouldn't RFC 1918 addrs on router links only threaten to break
PMTU --- even in the face of 1918 addr filtering --- if one of
the routers with an rfc 1918 interface addr did routing between
interfaces with different MTUs? As best I can see, PMTU discovery
should work fine traversing RFC 1918 links, and the only addrs
that need to be passed on out are those of routers where the MTU
decreases along the path, which would only be routers with different
MTUs on different interfaces.

-Bennett

--u3W6riq+uV6J42Ub
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5b2/nL6KAps40sTYRAk4UAJ0RNZ/1xywH2RCVDy2+I8PbXshstwCfRGeG
LOF85/RdaTTJxDv86xec7Nw=
=P7BQ
-----END PGP SIGNATURE-----

--u3W6riq+uV6J42Ub--


home help back first fref pref prev next nref lref last post