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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf