Date: Fri, 13 Jul 2007 12:54:40 -0700 From: Chuck Swiger <cswiger@mac.com> To: Bill Moran <wmoran@collaborativefusion.com> Cc: freebsd-net@freebsd.org, David DeSimone <fox@verio.net> Subject: Re: 6.2 mtu now limits size of incomming packet Message-ID: <A315A8C8-1BF5-4C67-86D8-073AB19E3604@mac.com> In-Reply-To: <20070713152725.6ae40056.wmoran@collaborativefusion.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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...
--
-Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A315A8C8-1BF5-4C67-86D8-073AB19E3604>