> Please cite an exact RFC reference.
No need to cite RFC, this is plain sillogism.
A. Datagram protocols do not work with mtus not allowing to send
512 byte frames (even DNS).
B. Accoutning, classification, resource reervation does not work on
fragmented packets.
-> IP suite is not full functional with low MTUs and must be eliminated.
Current setting of min_adv_mss to 536 is actually occasional.
I tested pmtu discovery on local clients using mtu 296 and did not
change the value to less fascist after this. I happened to be not
mistake, I found some fun talking to people, which suffer of superstition
that "mtu 296 is good for..." (latency for example) 8)8)8)
> to put it back together. Our handling of DF on syn frames is also broken
> due to that misassumption, but fortunately only for crazy mtus like 70.
Right observation. It stops to work even earlier: at mtu<128.
It is strict limit. Pardon, discussing marginal cases is useless.
If someone has device with mtu of 128, let him to put it back to the place,
where he found it.
Preventing DoSes requires to block pmtu discovery at 576 or at least 552.
More practical question is mtu=296. There exist old myth that this value
is good for PPP. This is nothing but myth. 14% of overhead.
I would prefer that minimal MTU on internet stayed on 576, which
is already fact.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/