Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!mordor!sri-spam!nike!ucbcad!ucbvax!SRI-SPAM.ARPA!gds
From: gds@SRI-SPAM.ARPA (The lost Bostonian)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Lisp machines don't receive network level broadcasts right, causing net mayhem
Message-ID: <8608050230.AA05544@sri-spam.arpa>
Date: Mon, 4-Aug-86 22:30:20 EDT
Article-I.D.: sri-spam.8608050230.AA05544
Posted: Mon Aug  4 22:30:20 1986
Date-Received: Tue, 5-Aug-86 23:19:21 EDT
References: <860710153354.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 21
Approved: tcp-ip@sri-nic.arpa


    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