Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!NSIPO.NASA.GOV!medin
From: medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Using the 4.2 broadcast addr with 4.3 systems
Message-ID: <8909011945.AA00826@cincsac.arc.nasa.gov>
Date: 1 Sep 89 19:45:34 GMT
References: <[A.ISI.EDU].1-Sep-89.05:34:13.CERF>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 19


Vint, I feel the same way as Phil does.  If you get a packet recieved 
via link level broadcast, you should NEVER forward it.  If it is a packet
that is trying to do directed broadcast (always questionable in 
my opinion), then that packet should have been unicast to the
gateway in question, not broadcast.  If you do things this way, you
stomp on almost all the broken cases, and still have the flexibility 
to do directed broadcast, if you think this is a good thing.  

In most implementations that don't support this, you'd probably end up
modifying device drivers, but I feel this is well worth it.  The reason 
we have so many problems with broadcasts in that in most implementations,
you end up throwing away info you hear at layer 2, and then trying
to make up for it by using some incomplete hueristic at layer 3.  This
is a case where violating layering by passing info from layer 2 to layer
3 wins big.

					Thanks,
					   Milo