Re: Lisp machines don't receive network level broadcasts right, causing net mayhem

J. Noel Chiappa (JNC@XX.LCS.MIT.EDU)
Sat 19 Jul 86 00:00:27-EDT

        (For those who are lost, this is about the incident I reported
where broadcast RIP packets from a subnet gateway were being reforwarded
by all of a certain class of machine which didn't recognize them as
broadcast, causing a massive jamup on the net.)
        I sent a message out to TCP-IP a few months (28 April if you want
to look it up in the archives) ago in which I discussed a similar topic
at length. (The question there was when to send ICMP Error packets).
The general philosophy behind the answer here is the same. Had the
algorithm about 'hosts not doing anything with wrong packets that were
broadcast' been followed by the hosts here, the problem would not have

        If a host receives what looks to it like a misdirected packet,
it got it either because a gateway was confused or some host was. In
the first case, things are really in trouble anyway; reforwarding it
could just cause a loop or other serious problems. In the second, I
don't think that you should encourage broken behaviour on the part of
hosts; if they didn't send the packet to the right place they should
be fixed.
        The real problem is that in practice usually when a host sees
a packet it doesn't recognize it's not because the packet was sent to
the wrong place, but because there is some strange address in there
the host didn't recognize. In this case it was a subnet broadcast
address, and a host that didn't recognize that it was on a subnetted
net. In the future it might be multicast addresses, or whatever.
In either case, doing anything except ignoring it is the wrong thing.
Yes, maybe in .001% of the cases, forwarding the packet on is the
right thing, but in the rest it's the wrong (and usually disastrous)
thing to do. Clearly, the cost/benefit analysis says that forwarding
the packet is the wrong thing.


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