On Fri, Jan 28, 2011 at 11:19 AM, <cpolish at surewest.net> wrote: > Nico Kadel-Garcia wrote: > >> Yup. That's why it's common to drop at external firewalls and blocked >> by NAT from reaching inside your network, to protect less thoroughly >> protected and critical hosts from distributed denial of service (DDOS) >> such as the now classic "ping flood" attack. There is generally no >> good reason to allow external ICMP packets into your local network, >> except maybe to allow an external monitoring system or VPN connection >> to verify the presence of a few exposed hosts. > Many network security devices block all ICMP messages for > perceived security benefits, including the errors that are > necessary for the proper operation of PMTUD. This can result in > connections that complete the TCP three-way handshake correctly, > but then hang when data is transferred. This state is referred > to as a black hole connection. I'm not sure how the lack of PMTUD is worked around: given the number of environments for which blocking ICMP entirely is standard practice, it can't be *too* much of an issue, can it? I'm deducing, without enough proof, that the upstream ISP's routers have to handle ICMP from the other routers they speak with. But other than that, why should it be supported again? Do household network devices really need to do the path optimization supported by this? They're not multi-homed: perhaps the single gateway that they use helps avoid the issue?