[30133] 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)
Sun Jul 16 12:33:12 2000

Date: Sun, 16 Jul 2000 12:29:39 -0400
From: Bennett Todd <bet@rahul.net>
To: North America Network Operators Group Mailing List <nanog@merit.edu>
Message-ID: <20000716122939.C578@oven.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="7qSK/uQB79J36Y4o"
Content-Disposition: inline
In-Reply-To: <20000714200630.A29379@eiv.com>; from smcmahon@eiv.com on Fri, Jul 14, 2000 at 08:06:30PM -0400
Errors-To: owner-nanog-outgoing@merit.edu



--7qSK/uQB79J36Y4o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

2000-07-14-20:06:30 Shawn McMahon:
> On Fri, Jul 14, 2000 at 07:42:08PM -0400, Greg A. Woods wrote:
> > Unfortunately an increasing number of Internet users, with servers I
> > might add, are now behind DSL lines that have <1500-byte MTUs.....
> [...]
> So what are we going to do, folks; are we going to react to people
> who are in this situation by saying "oh, well; guess I'm walled
> off from you, too bad, so sad, dump that $50 connection and get a
> T1 or get off my Internet", or are we going to adapt?

What kind of adaptation is necessary?

Traditionally that sort of thing hasn't been a problem; that's what
fragmentation is for.

If Path MTU Discovery is working it's even less of a problem: if
there's a link MTU in the middle of a path that's smaller than the
MTUs of the final links at each end, then Path MTU Discovery will
find out and adjust the session MTU to fit.

The only place where this is a problem is where people are trying to
run Path MTU Discovery, and so have servers that are initiating
sessions with packets with the Don't Frag bit set, and then have
firewalls or load balancers or something blocking the ICMP Must Frag
error returns.

And to haul this back to the original thread, I've still heard no
claim made that there's an operational problem introduced by using
RFC 1918 addrs for endpoints of router-router links where neither
router routes traffic over interfaces with different MTUs.

If people don't want whiners niggling them about the RFC 1918 addrs
showing up in traceroutes, they should just put RFC 1918 filters on
their borders, so that the whiners simply won't get returns to their
traceroutes.

-Bennett

--7qSK/uQB79J36Y4o
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

iD8DBQE5ceLzL6KAps40sTYRAoUyAJwK2NsRDvL2v63R2eskEzADdb2GZQCfTnbD
prpGnZkns5HcSobR6NhuDTs=
=tqTj
-----END PGP SIGNATURE-----

--7qSK/uQB79J36Y4o--


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