Date: Fri, 13 Jul 2007 15:27:25 -0400 From: Bill Moran <wmoran@collaborativefusion.com> To: David DeSimone <fox@verio.net> Cc: freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet Message-ID: <20070713152725.6ae40056.wmoran@collaborativefusion.com> In-Reply-To: <20070713180840.GB8392@verio.net> References: <46967C5C.5040505@seclark.us> <469772DA.1000700@gmail.com> <46977741.8090301@seclark.us> <20070713093408.b8a92c23.wmoran@collaborativefusion.com> <4697A60C.4090409@seclark.us> <20070713130402.ed2f79ce.wmoran@collaborativefusion.com> <20070713180840.GB8392@verio.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In response to David DeSimone <fox@verio.net>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Bill Moran <wmoran@collaborativefusion.com> wrote: > > > > Let's flip the question around a bit: why would you _want_ the TCP > > stack to accept frames larger than the stated MTU? > > If I receive a 64K frame and the TCP checksum checks out, and the > sequence numbers match, and it passes my firewall state, why NOT receive > it? It is obviously valid, even if I cannot understand how my interface > could have received it. The packet is here, so do something useful with > it. But it's not here yet. The problem is that it doesn't pass a basic sanity check at the media layer, so it would be dropped before it ever starts seeing checks at the TCP or IP layer. > I agree with others that MTU means "limit what I transmit". It does not > mean "limit what someone else can transmit to me." Interesting viewpoint. I disagree with it, but I can't quote any standard or otherwise to support my view. You didn't either. Does anyone know of a publicised, authoritative standard that would clear this up? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070713152725.6ae40056.wmoran>