Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!hpcc05!hpcuhb!hpda!hpcupt1!hpindwa!raj
From: raj@hpindwa.HP.COM (Rick Jones)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Question on forwarding broadcasts
Message-ID: <36540012@hpindwa.HP.COM>
Date: 29 Sep 90 19:50:51 GMT
References: <1990Sep28.143945.7440@ultra.com>
Organization: Hewlett-Packard, Cupertino CA
Lines: 64

>
>I have a little "IP forwarding of broadcasts" question.  The following
>...
>Anyway, consider:
>
>    +------------+    +------------------------+    +------------+
>    |   Host A   |    |     Default Router     |    |   Host B   |
>    |            |    |                        |    |            |
>    | 192.40.1.1 |    | 192.40.1.2  192.40.2.2 |    | 192.40.2.1 |
>    +------+-----+    +------+----------+------+    +-----+------+
>           |                 |          |                 |
>===========#=================#==========#=================#===========
>                               Ethernet
>
>where both Host A and Host B are configured to forward things they
>cannot handle to the Default Router.  Note that there are TWO
>DIFFERENT NETWORKS active on a SINGLE ETHERNET CABLE (192.40.1 and
>192.40.2).  (This is of course key to the problem, but it is a
>perfectly legal configuration, no?) 
>...
>Finally, note that saying "Host B should recognize this is a broadcast
>from the destination address and not forward it" is NOT a solution,
>since it appears to Host B to be a perfectly legal DIRECTED broadcast
>to network 192.40.1 from somewhere else, and as far as Host B knows,
>he is the only way for that directed broadcast to get through; he HAS
>to forward it.
>

Well, you might put it that way, but since it was sent on a LL broadcast
address, it really isn't a directed broadcast, as those are supposed
to stay unicast until they reach the destination (sub)network. At that
point, they become 'plain-old' broadcasts and the usual rules apply.

>Any comments/suggestions/flames?  Are there non-BSD implementations
>out there that handle this?  Mods to BSD?  Future plans from vendors?
>Anything else?
>

First, is it really necessary for the hosts to be doing any forwarding
in the first place - are they routers themselves? If not, by all
means, disable gateway functionality. There are non-BSD
implementations that do handle this situation - I happen to work on
one ;-) (but we fixed it for a different reason ;-) and I'm certain
that by the time this gets out, someone will have pointed at the
apropopriate mods to BSD code. BTW - IP really doesn't need to know
what the LL address was, just a boolean saying whether or not it was
unicast.  However, it might need to become 'smarter' in the face
of IP multicasting ???  

Apart from a) disabling forwarding on the hosts, or b) getting the
mods put in, or c) going to a different box, your only other
alternative might be to split the network onto separate wires - fun,
huh ;-) I'd suggest that you push your vendor(s) to get you code that
is more in line with the RFC's - beg, cajole, threaten, or whatever,
because that is really the solution you appear to need.

>    Wayne Hathaway               domain: wayne@Ultra.COM

rick jones

___   _  ___
|__) /_\  |    Richard Anders Jones   | MPE/XL Networking Engineer
| \_/   \_/    Hewlett-Packard  Co.   | Even MPE can do the right thing!
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply