Date: Fri, 13 Jul 2007 13:36:04 -0700 From: Julian Elischer <julian@elischer.org> To: Stephen.Clark@seclark.us Cc: freebsd-net@freebsd.org Subject: Re: 6.2 mtu now limits size of incomming packet Message-ID: <4697E234.1070201@elischer.org> In-Reply-To: <4697DF64.9070203@seclark.us> 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> <4697DF64.9070203@seclark.us>
next in thread | previous in thread | raw e-mail | index | archive | help
Stephen Clark wrote: > 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? not specifically but I would.. > >> 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... >> >> >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4697E234.1070201>