From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 20:24:07 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2CFC16A402 for ; Fri, 13 Jul 2007 20:24:06 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by mx1.freebsd.org (Postfix) with SMTP id A8B4113C4B9 for ; Fri, 13 Jul 2007 20:24:06 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 19328 invoked from network); 13 Jul 2007 20:24:05 -0000 Received: from unknown (24.144.77.243) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 13 Jul 2007 20:24:05 -0000 Message-ID: <4697DF64.9070203@seclark.us> Date: Fri, 13 Jul 2007 16:24:04 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Swiger , freebsd-net@freebsd.org 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> <20070713152725.6ae40056.wmoran@collaborativefusion.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 20:24:07 -0000 Chuck Swiger wrote: >On Jul 13, 2007, at 12:27 PM, Bill Moran wrote: > > >>>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? >> >> > >Sure. RFC-791: > >"Fragmentation > > Fragmentation of an internet datagram is necessary when it > originates in a local net that allows a large packet size and must > traverse a local net that limits packets to a smaller size to reach > its destination. > > An internet datagram can be marked "don't fragment." Any internet > datagram so marked is not to be internet fragmented under any > circumstances. If internet datagram marked don't fragment >cannot be > delivered to its destination without fragmenting it, it is to be > discarded instead. > > Fragmentation, transmission and reassembly across a local network > which is invisible to the internet protocol module is called > intranet fragmentation and may be used [6]." > >RFC-879: > >" HOSTS MUST NOT SEND DATAGRAMS LARGER THAN 576 OCTETS UNLESS THEY > HAVE SPECIFIC KNOWLEDGE THAT THE DESTINATION HOST IS PREPARED TO > ACCEPT LARGER DATAGRAMS." > >"8. Maximum Packet Size > > Each network has some maximum packet size, or maximum transmission > unit (MTU). Ultimately there is some limit imposed by the > technology, but often the limit is an engineering choice or even an > administrative choice. Different installations of the same network > product do not have to use the same maximum packet size. Even >within > one installation not all host must use the same packet size (this >way > lies madness, though). > > Some IP implementers have assumed that all hosts on the directly > attached network will be the same or at least run the same > implementation. This is a dangerous assumption. It has often > developed that after a small homogeneous set of host have become > operational additional hosts of different types are introduced into > the environment. And it has often developed that it is desired to > use a copy of the implementation in a different inhomogeneous > environment. > > Designers of gateways should be prepared for the fact that >successful > gateways will be copied and used in other situation and > installations. Gateways must be prepared to accept datagrams as > large as can be sent in the maximum packets of the directly attached > networks. > Doesn't this imply if a gateway has 2 interfaces, one with an mtu of 1280 and the other with an mtu of 1500 it should accept 1500 on either interface? >Gateway implementations should be easily configured for > installation in different circumstances. > > A footnote: The MTUs of some popular networks (note that the actual > limit in some installations may be set lower by administrative > policy): > > ARPANET, MILNET = 1007 > Ethernet (10Mb) = 1500 > Proteon PRONET = 2046" > >RFC-894: > >" The minimum length of the data field of a packet sent over an > Ethernet is 1500 octets, thus the maximum length of an IP datagram > sent over an Ethernet is 1500 octets. Implementations are >encouraged > to support full-length packets. Gateway implementations MUST be > prepared to accept full-length packets and fragment them if > necessary. If a system cannot receive full-length packets, it >should > take steps to discourage others from sending them, such as using the > TCP Maximum Segment Size option [4]. > > Note: Datagrams on the Ethernet may be longer than the general > Internet default maximum packet size of 576 octets. Hosts connected > to an Ethernet should keep this in mind when sending datagrams to > hosts not on the same Ethernet. It may be appropriate to send > smaller datagrams to avoid unnecessary fragmentation at intermediate > gateways. Please see [4] for further information on this point." > >And RFCs 1122 and 1191 are also somewhat relevant. My reading of the >above is that ethernet-capable gateways must be willing to accept >packets as large as 1500 octets and fragment such traffic to meet the >MTU settings as needed, except if DF is set. If DF is set, but the >packet is addressed to the gateway itself, then it should be >delivered unfragmented even if that packet exceeded the MTU set on >the receiving interface. > >For hosts which are not network gateways, one should not assume them >to be capable of receiving packets larger than 576 octets, but the >TCP MSS option is almost universally available to indicate the >appropriate maximum size that host is willing to receive during the >3WHS setup... > > > -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)