Can anyone explain the magical 552 ip_rt_min_pmtu?
I've seen fielded equipment that was setting mtu to 512
and causing linux to set the mtu on the route to 552 thus
causing fragments. Why can't we honor the 512 mtu?
I suspect it is a long-standing bug based misunderstanding about IP
minimum MTU's. I found this while googling for "ip_rt_min_pmtu"
http://blog.gmane.org/gmane.linux.kernel/day=20030203
which reads in part:
May be the Linux box is giving up PMTU? ¿Why? it now knows MTU is
400. I have others windows boxes in the network, they work fine with
PMTU.
A MTU of 400 is illegal, IPv4 requires a minimum MTU of 576 bytes. Below
it linux uses the minimum MTU and turns off path mtu discovery (=
drops DF)
I suspect that the person who said that the MTU of 400 being illegal
confused the IP minimum, maximum reassemblable datagram size with a
minimum MTU.
IPv4 has a "minimum, maximum reassemblable datagram size" of 576 bytes.
That is, any "conforming" IPv4 implementation must be able to acccept
and reassemble IP datagrams of at least 576 bytes. Many people have
misunderstood that to be the minimum IP MTU.
From RFC 791:
Total Length: 16 bits
Total Length is the length of the datagram, measured in octets,
including internet header and data. This field allows the length of
a datagram to be up to 65,535 octets. Such long datagrams are
impractical for most hosts and networks. All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
or in fragments). It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.
The number 576 is selected to allow a reasonable sized data block to
be transmitted in addition to the required header information. For
example, this size allows a data block of 512 octets plus 64 header
octets to fit in a datagram. The maximal internet header is 60
octets, and a typical internet header is 20 octets, allowing a
margin for headers of higher level protocols.
Perhaps that is the origin of the 512, or perhaps it was emulating the
old, broken, BSDism of having a default MSS of 512 octets rather than
536 as stated in the TCP RFC(s).
IIRC the actual "minimum MTU" for IPv4 is something like 68 bytes.
Again from RFC 791:
The More Fragments flag bit (MF) is set if the datagram is not the
last fragment. The Fragment Offset field identifies the fragment
location, relative to the beginning of the original unfragmented
datagram. Fragments are counted in units of 8 octets. The
[Page 24]
September 1981
Internet Protocol
Specification
fragmentation strategy is designed so than an unfragmented datagram
has all zero fragmentation information (MF = 0, fragment offset =
0). If an internet datagram is fragmented, its data portion must be
broken on 8 octet boundaries.
This format allows 2**13 = 8192 fragments of 8 octets each for a
total of 65,536 octets. Note that this is consistent with the the
datagram total length field (of course, the header is counted in the
total length and not in the fragments).
When fragmentation occurs, some options are copied, but others
remain with the first fragment only.
Every internet module must be able to forward a datagram of 68
octets without further fragmentation. This is because an internet
header may be up to 60 octets, and the minimum fragment is 8 octets.
Every internet destination must be able to receive a datagram of 576
octets either in one piece or in fragments to be reassembled.
Hence the minimum IPv4 MTU of 68 bytes.
Now, it may be desirable for a stack to set a lower-bound on the PTMU
information it will accept from out of the blue when I has no other
assurances that the ICMP Destination Unreachable Datgram Too Big (or
whatever it is called) arrives. This would be to protect against script
kiddies making PTMU's needlessly tiny. However, that should probably be
a sysctl, and IMO default to something lower than 552 bytes.
Particularly if the stack has other sanity checks to apply against the
incoming ICMP message.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
