RFC1112 section 7.2, RFC1122 section 3.2.2 and RFC1812 section 22.214.171.124 all prohibit sending ICMP errors in response to multicast packets. Despite this, many old router and host implementations send these packets. Known culprits include old versions of:
In addition, Cisco appears to have introduced a bug into their IOS which causes transmission of ICMP errors in response to multicast somewhere around the timeframe of IOS version 11.2(8.x). This is bug ID CSCdj43447, and is fixed in 11.1(15.4), 11.2(9.1), and 11.3(0.7). Cisco recommends that you upgrade to the latest 11.2 or 11.3 maintenance release; if any specific reccomendation is given on this page it will quickly be out of date, so please contact Cisco or check their FTP server to determine what you should be running.
We are collecting data to try to determine what machines on the MBone are suffering from this problem. This data is incomplete in two ways:
Normally, reception of an ICMP error on a connected UDP socket causes the error message to be delivered on the socket. This usually causes the next send to fail without even attempting to send the packet. In addition, systems based upon 4.3BSD-Reno and later (including 4.4BSD) do not clear socket errors on send (only on receive or getsockopt(s, SOL_SOCKET, SO_ERROR, ...)) so naïve applications can get into a situation where they can never send again if they use a connected socket solely for sending.
Because this was such a ubiquitous problem in the early days of the MBone, a workaround was added in the 3.3 release of the multicast patches for UNIX kernels. This workaround drops any incoming ICMP error in response to a packet which was destined for a multicast address (i.e. looks in the returned packet header which is part of the ICMP payload).
icmp_input() ... if (IN_MULTICAST(ntohl(icp->icmp_ip.ip_dst.s_addr))) goto badcode;
In addition, a workaround can be added to applications; if a send fails with ENETUNREACH or EHOSTUNREACH, try the send again (but don't check the return value this time). This tries at most twice to send each packet. A sufficiently high rate of ICMP error messages can foil this method as well, which is why it's better to patch the kernel (and best to not have ICMP errors coming in response to multicast in the first place!). This workaround is, of course, only appropriate when sending to a multicast address.
The most common problem is with hosts that respond incorrectly to IP multicasts. These responses typically take the form of ICMP network unreachable, redirect, or time-exceeded error messages, which are a nuisance but mostly harmless. These responses are in violation of the current IP specification and, with luck, will disappear over time.
At that time, Symbolics Lisp machines were the most common offenders.