Subject: ICMP destination unreachable errors

From: Colin Perkins <[email-masked]>
Date: Tue, 30 Jun 1998 15:22:45 +0100

Hi,

We've been running an Mbone session this afternoon, and have been suffering
from floods of ICMP "destination unreachable" messages, which seem to be
triggered by multicast traffic flow.

The hosts sourcing these packets are
	192.215.199.2
	128.32.120.110	(f8-1-0.inr-110-cory.Berkeley.EDU)
	192.70.138.202	(vcu-router.networkvirginia.net)
	132.168.255.254	(hiphop.ceng.cea.fr)
	137.132.12.34
Does anyone know what is causing this, and how we might avoid it in future?

Regards,
Colin

---

From: [email-masked] (Jeremy Hall)
Date: Tue, 30 Jun 1998 11:32:36 -0400 (EDT)

Hi,

My first reaction would be that it is a misconfigured firewall that will
allow joins to propogate, but will deny multicast traffic.

_J

---

From: Bill Fenner <[email-masked]>
Date: Tue, 30 Jun 1998 09:47:27 PDT

Sounds like the problem described at

http://sandbox.parc.xerox.com/~fenner/mcast/icmp.html

although only one of the routers you see is listed in my list, my data
collection method is fairly flawed.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Tue, 30 Jun 1998 10:09:50 PDT

>allow joins to propogate, but will deny multicast traffic.

RFC 1112, 1122, and 1812 all explicitly forbid ICMP errors in response
to multicast traffic.  A firewall that can be configured to send such
errors is extremely broken.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Tue, 30 Jun 1998 10:09:50 PDT

Bill

---

From: Hugh LaMaster <[email-masked]>
Date: Tue, 30 Jun 1998 10:11:04 -0700 (PDT)

> triggered by multicast traffic flow.

It is triggered on the sending side by multicast traffic
traversing the same LAN as some broken host or device, and, on the
receiving side by the fact that you have joined a multicast
group being subjected to this.

There are many causes of brokeness.  Old Banyan Vines servers,
certain stand-alone printer interfaces, etc.

> The hosts sourcing these packets are

I notice also ea-gw.kth.se (130.237.1.9) is being particularly
noisy on 224.2.0.1 right now, while we are on the subject.
Every 15 seconds on average, anyone who happens to be joined 
to that group is getting "icmp: host 224.2.0.1 unreachable" 
sent back to the host in response to the normal vat session 
membership traffic.  While no doubt it is misconfigured,
there is no excuse whatever for whichever OS it is running
to be barking in response to multicast.  I'm curious as to
what this system is.

> Does anyone know what is causing this, and how we might avoid it in future?

Any host sending ICMP host or port unreachable messages in response 
to multicast traffic is hopelessly broken and needs to be put 
out of its misery :-)  Seriously, a host behaving in such a way 
really is broken and either needs to be taken off of the net or to have
its OS upgraded ASAP if that is possible.  (It isn't possible for
certain obsolete network interfaces with built in network stacks.
Those devices need to be decommissioned ASAP.)  Some of these
systems date back about ten years before many people really thought
about either routed multicast or the futility of sending ICMP
host and port unreachables in most cases.  And ICMP source quenches.
(While monitoring ICMP traffic, I just noticed a Mac sending
bursts of 20 ICMP source quench messages to a host.  That is
silly.  But, with multicast, the error is much more serious. 
There is never any reason to send ICMP in response to multicast 
traffic received.  Discarded multicast should always be silently
discarded.  Period.

As for what should be done to avoid it: well, people shouldn't
write broken software, of course, but, in particular, ICMP
tends to be overused by people who don't realize that that 
silence is golden in IP.  Personally, I doubt the utility
of routers sending ICMP host unreachable messages in most cases;
silence works just as well most of the time and doesn't cause
problems.  But, sending anything in response to multicast
is a sign of seriously broken software.

As always, additions/deletions/corrections/comments welcome.

--
 Hugh LaMaster, M/S 233-21,    ASCII Email: [email-masked]
 NASA Ames Research Center     Or:          [email-masked]
 Moffett Field, CA 94035-1000  No Junkmail: USC 18 section 2701
 Phone: 650/604-1056           Disclaimer:  Unofficial, personal *opinion*.