[mod.protocols.tcp-ip] Lisp machines don't receive network level broadcasts right, causing net mayhem

DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) (07/10/86)

    Date: Thu, 10 Jul 86 13:28:47 EDT
    From: jnc@brubeck.proteon.com

	    Hosts shouldn't be forwarding packets (or sending redirects)
    anyway. It is a complete bug that the LISP machine are even presuming
    to do either.

I agree there is a bug with broadcast packets.  But... if a non-gateway
host receives a non-broadcast packet that is not for it, why shouldn't
it BOTH forward it and send a redirect?  How is the sender to know that
it is sending packets to the wrong place?

P.s., it looks like your mail sending program didn't tack on
@proteon.com to the bug-cgw CC recipient.

-------

JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") (07/19/86)

	(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
occurred.

	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.

	Noel
-------

gds@SRI-SPAM.ARPA (The lost Bostonian) (08/05/86)

    From: jnc@brubeck.proteon.com

	    Hosts shouldn't be forwarding packets (or sending redirects)
    anyway. It is a complete bug that the LISP machine are even presuming
    to do either.

  I agree there is a bug with broadcast packets.  But... if a non-gateway
  host receives a non-broadcast packet that is not for it, why shouldn't
  it BOTH forward it and send a redirect?  How is the sender to know that
  it is sending packets to the wrong place?

Why not use the icmp parameter problem message?  Rather than dropping
the packet on the floor, or worsening the problem by forwarding the
packet or sending a redirect (question:  what does the host redirect
to?), it seems a reasonable way to let the sender know about the
problem, and it costs the same as sending a redirect.  All the ip
implementations will have to be taught to do something with the
parameter problem type, besides just accept it.

--gregbo