Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!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: Question on forwarding broadcasts
Message-ID: <9009290709.AA01015@cincsac.arc.nasa.gov>
Date: 29 Sep 90 07:09:56 GMT
References: <1990Sep28.143945.7440@ultra.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 51


Wayne, this is a typical problem in many host AND router implementations.

In your example, Host B should not forward the broadcast under any
circumstances if it is received via a MAC layer broadcast.  True, few BSD's
do this.  Few IP implementations do this.  Some do however (I think of 
Phil Karn's KA9Q code).  It's not that hard after all.  I seem to remember
talking to Mike Karels one day about this, and that he was planning to
add a couple bits that get passed along with the packet from the driver to
IP so that you could tell if it was received via broadcast or multicast.  
I'm not sure that 4.3-Reno does this, but I'm sure someone out there can
answer the question.

Trying to use the destination IP address to determine if the packet was
transmitted via MAC layer broadcast is a heuristic.  The link layer knows
everything IP needs to make the proper decisions.  Then most implementations
throw away this very good information and then attempt to fake it by looking
at the destination IP address.  It works as long as nobody is doing anything
strange, but it's certainly not robust, and one misconfigured host can
trash the network.  It's certainly not a good design.  As a rule, it's 
a bad idea to throw away known good information.  You almost always need
it again soon.

Your case about the directed broadcast brings up a touchy subject. 
My personal opinion is that directed broadcasts are universally bad.  In the
cases where this sort of thing is handy, Internet Multicasting should 
be used.  I know this isn't supported by many routers, but with work on
adding Multicast support to OSPF, we should see some progress in this area
soon.  

Nonetheless, if you are one of the people who believe in directed broadcasts,
I'll say you should still never forward a broadcast received by MAC layer
broadcast, but may forward it if received via unicast.  That is, I believe if
someone is really wanting to do a directed broadcast, he should unicast the 
packet to his router, and not be so crass as to broadcast it.  This still 
prevents broadcast storms, but it depends on the router where the directed
broadcast entered the network to make sure the right thing is done.  It's
not as robust as dropping the packet, but should still prevent most mischief.

In any case, if your router implementation forwards broadcasts under these
conditions, I claim it violates RFC 1009.  And it'll certainly violate 
the son-of-1009 being worked on now!  So all you router vendors, get with
it!  You'll be glad you did, and so will your customers.

We in the Internet community should always remember that we aren't building
research experiments.  We're building the infrastructure that all kinds
of people are using to get their jobs done.  If we build in things that
aren't robust, many people will suffer.

						Thanks,
						   Milo