ICMP errors in response to multicast

RFC1112 section 7.2, RFC1122 section 3.2.2 and RFC1812 section 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:

It may not list machines which do have this problem
The measurement technique relies on getting multicast packets to machines which have this problem. Since these machines may simply be present on a network which has multicast enabled, it's hard to find a way to get packets to them. We use two techniques: One other measurement technique which would be useful but has not yet been tried:
It may list machines which have been fixed
Because of the measurement problem, this list contains all machines that we have ever received ICMP errors from. If an individual machine was fixed, it will remain on the list. This is the reason for the "latest" column in the table.

Ramifications of the problem

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).

              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.


Last modified Tue Apr 7 11:58:59 PDT 1998
Bill Fenner <fenner@research.att.com>