A friend of mine sent me an interesting problem:
I noticed recently that my IOS routers aren't sending ICMP (unreachable; frag needed) messages in response to too-big IPv4 multicast packets with DF-bit set. They're just dropping these packets silently, breaking PMTUD.
Unfortunately, that’s not a bug but a FAD (Functions-as-Designed).
A quick Google search found this document which pointed me to section 7.2 of RFC 1112 (yeah, multicast is really THAT old):
An ICMP error message (Destination Unreachable, Time Exceeded, Parameter Problem, Source Quench, or Redirect) is never generated in response to a datagram destined to an IP host group.
The same document also describes why RFC 1112 prohibits sending ICMP error messages in response to multicast datagrams. The processing done on ICMP error replies by the *nix socket API might block the sender socket if an error comes back from a single receiver or if TTL expires when traversing a particularly long branch of the multicast tree – not exactly a good idea in multicast environment.
- You should never get ICMP error messages in response to IP multicast packets;
- Path MTU discovery doesn’t work with IP multicast;
- Sending multicast packets with DF bit set is a bad idea unless you’re OK with some receivers never getting them;
- ICMP echo reply to a multicast echo request is perfectly legal (because it’s not an ICMP error message).