ICMP errors in response to multicast

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

• AIX 2.2.1
• Banyan VINES servers
• MacTCP 1.1.1
• Interactive UNIX
• UNISYS
• Ether.Route TCP
• Ascend Routers
• Lantronix
• ELSA MicroLink LANCOM

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:

• Send to a random group. This relies on DVMRP's broadcast and PIM-DM's flooding behavior to get packets to all multicast routers and transit LAN's. This helps to find multicast routers in DVMRP or PIM-DM domains that are suffering from this problem. It also reaches hosts and unicast-only routers on transit LAN's.
• Send to the SAP group. This is a group that many people should be joined to, so should be able to get traffic onto actual leaf LAN's. This helps to expose some of the devices that are not multicast routers (e.g. unicast-only routers or hosts).

One other measurement technique which would be useful but has not yet been tried:

• Send to popular multicast sessions, such as the IETF or NASA Shuttle mission.

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

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.

History

• The MULTICAST 1.2 release, released in 1989, discussed the problem:

  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.

• Occasional discussions cropped up on the MBone mailing list. The first such in the archives was in November 1992.
• The 3.3 multicast release, in 1994, contained much the same wording except the common offenders mentioned were IBM RT AIX 2.2.1, MacTCP 1.1.1 and Banyan VINES servers.
• The diligent efforts of Steve Casner and others on the MBone mailing list led to the elimination of ICMP error sources on the MBone in 1996 or so. The problem is enjoying a recent resurgence, as noted on the MBone mailing list in November 1997.