On Sat, 8 May 2004, Masataka Ohta wrote:
I recommend that, to avoid long initial delay and intermediate
lack of communication after path changes of, PMTUD should turnd
off by default and should be activated only on extreme
conditions.
Just the opposite, unless you want to lose connectivity with a number of
web servers that want to send big packets with DF turned on.
Further, it should be noted that PMTUD is so unreliable that
no applications rely on it, which means that even under
extreme conditions rational operators won't turn on PMTUD.
It is not true that no applications rely on PMTU. A number of commercial
products and applications do rely on PMTU to work, and will do an PATH MTU
discovery, and send the MTU sized packets with DF (don't frag). If you
have a smaller MTU somewhere that was not discovered, such DF marked
packets will be dropped.
This is the first I have heard that path mtu discovery software was
unreliable. I have only heard that those that block ICMP echo have had
problems. This doesn't make PMTU unreliable. It makes the concept of
blocking ICMP echo unwise.
I suggest, that if you want to use security by obscurity, that you use
NAT, and that you permit ICMP echo to the NAT device.
--Dean
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf