Date: Fri, 13 Jul 2007 16:24:04 -0400 From: Stephen Clark <Stephen.Clark@seclark.us> To: Chuck Swiger <cswiger@mac.com>, freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet Message-ID: <4697DF64.9070203@seclark.us> In-Reply-To: <A315A8C8-1BF5-4C67-86D8-073AB19E3604@mac.com> 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> <A315A8C8-1BF5-4C67-86D8-073AB19E3604@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4697DF64.9070203>