PMTUD for IPv4 Multicast - How?

Mon Aug 31 16:12:16 UTC 2015

I recently discovered that my routers weren't generating ICMP Type 3 Code 4
(unreachable, DF-bit) messages in response to too-big IPv4 multicast
packets with DF=1.

At first, I thought this was a bug, but then learned that RFCs 1112, 1122
and 1812 all specify that ICMP unreachables not be sent in response to
multicast packets.

RFC1981 (PMTUD for IPv6), on the other hand, is explicit that PMTUD works
for multicast flows, that the path MTU for a multicast flow is the smallest
MTU available anywhere in the distribution tree, and that a single
multicast packet may provoke many ICMP unreachables from routers along the
tree.

Further complicating matters, the default Linux behavior (ip_no_pmtu_disc =
0) sets the DF bit on all packets unless the application is explicit
(setsockopt()) that DF be cleared. This behavior strikes me as a
troublesome assumption (that the application will interpret unreachables)
in the case of unicast UDP sockets, and downright broken (because traffic
will be dropped silently) in the case of multicast UDP sockets.

I'm struggling to grok the rationale behind not sending unreachables in
response to multicast packets. It seems to me that our networks put IPv4
multicast speakers in a position where it's impossible for them to do the
right thing.

Does anybody understand why PMTUD for IPv4 multicast flows is disabled in
routers?

Is there a secret lever to enable it in Cisco IOS?

What should a responsible IPv4 multicast application do when receivers are
flung far and wide with un-knowable MTUs in the transit path?

Thanks,

/chris