Re: ICMP responses to broadcasts


J. Noel Chiappa (JNC@XX.LCS.MIT.EDU)
Mon 28 Apr 86 12:49:50-EDT


        Let's go back to basic philosophy on this one, and see if we
can clear it up.

        I don't see why anyone would send a (local) broadcast packet
to a (local) non-broadcast address, or vice versa. (Note that I don't
include remote directed broadcast.) It's a slightly suspicious thing
to do. (The only good reason I can think of to do anything like this
is if you're on a net where you don't know where gateways are. You
send out a broadcast packet, and hope for ICMP Redirects. There will
soon be a new ICMP message for finding gateways, so that will fix
that.)
        If anyone else can think of any good reasons to do such a
thing, please reply to me (privately), and I'll sum up the responses,
along with any places where a need is pointed out. I'd prefer to fix
any such needs with explicit mechanisms, and outlaw this kludge.

        The problem then reduces to a much simpler one; you have a
broken packet: what do you do? Now, it's a known fact that dropping
broken things silently makes tracking down problems real hard; it's
also known that having everyone do something when a error happens
usually causes the universe to go berserk.
        In addition, whatever generated the bogus packets may not be
in any shape to take automatic error messages, or make any use of
them. The solution that seems to address all these is to notify
'network central', whoever or wherever that is. On the other hand,
there may be a human debugging some code, and he might be able to use
an error message right away, rather than 3 weeks later when the
'network central' sends out their monthly report and notes these
crazy packets they saw several weeks ago. So, here's my philosophy on
what to do.

        If the packet was a local hardware broadcast, and you are a
host, drop it: let the gateways (which will also have the packet)
figure out what to do. The gateways will have more smarts to limit the
amount of berserkness in the response, as well as limiting the number
of responses in case they do get it wrong.
        If you are a gateway, things get complicated, and I'm not sure
I have figured out all the cases right here off the top of my head.
For instance, if the source looks like it was on an attached wire,
send an ICMP error to the source (making sure it wasn't a broadcast),
since the guy created a bad packet. I guess we need a new ICMP error
type for this. However, if the source wasn't local, then either the
packet has a bad source address or a gateway blew it; there's not much
you can do. Log the message for the network wizards to ponder and drop
it.

        If the packet was not a hardware broadcast, and you are a host,
it's probably OK to send an ICMP error message since you were the only
one to receive it. I guess the same goes for gateways here.

        We still have the problem of what to do with packets that are
in error and *really* broadcast, and I guess they get handled in much
the same way as the case above for ones which were hardware broadcast.
In no circumstances should hosts reply to messages which were hardware
broadcast!
        I guess the same set of strategies will apply to multicast
packets, when they eventually arrive in service everywhere. Also,
gateways should always notify 'network central' whenever they notice
anything wrong; there may not be a human or intelligent automaton
getting the message, and the guys who run the net are the ultimate
safety belt. In general, remember: there are more ways to lose than we
can plan for in advance, so the ultimate fallback is to "do nothing
and notify the humans".

        I hope this puts a few heavy duty nails in the coffin of this
one.

        Noel
-------



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:06 GMT