wayne@ultra.com (Wayne Hathaway) (09/28/90)
I have a little "IP forwarding of broadcasts" question. The following
example configuration is absurdly contrived, of course, but it is the
simplest that will illustrate the problem. The problem did surface in
a much more complex (and realistic) situation, but I don't want to
bore everybody with that.
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?)
Now assume a user on Host A does a broadcast to network 192.40.1 (its
own network). No problem, Host A simply puts the message out with the
Ethernet MAC layer broadcast address, and it is picked up by everybody
on network 192.40.1. But Host B will also pick up this message, and
will find that it is not destined for him. Host B will then forward
it to the Default Router over network 192.40.2. The Default Router
will receive this forwarded packet, and will see that it is a
broadcast for a directly-connected network, so he will broadcast it
out on network 192.40.1, by putting it out with the Ethernet MAC layer
broadcast address. But Host B will also pick up this message, and
will find ... [repeat as needed].
Clearly what Host B SHOULD do with the "misdelivered broadcast" is say
"This is not for me AND it came in as a MAC layer broadcast; therefore
just discard it (do NOT forward it)." But unfortunately that requires
IP to know what MAC layer address a datagram came in on, and (at least
in any BSD-derivative implementation I know of) that information is
not available to IP.
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.
Any comments/suggestions/flames? Are there non-BSD implementations
out there that handle this? Mods to BSD? Future plans from vendors?
Anything else?
[This IS a real problem in any situation where there are multiple
independent networks or subnets active on a single cable, and we in
particular have a lot of those situations. Any real live help will be
most appreciated!]
Wayne Hathaway domain: wayne@Ultra.COM
Ultra Network Technologies uucp: ...!ames!ultra!wayne
101 Daggett Drive phone: 408-922-0100 x132
San Jose, CA 95134 direct: Hey, you!smb@cs.purdue.EDU (Scott Ballew) (09/29/90)
In article <1990Sep28.143945.7440@ultra.com> wayne@ultra.com (Wayne Hathaway) writes:
<I have a little "IP forwarding of broadcasts" question.
<
<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?)
<
<Now assume a user on Host A does a broadcast to network 192.40.1 (its
<own network). No problem, Host A simply puts the message out with the
<Ethernet MAC layer broadcast address, and it is picked up by everybody
<on network 192.40.1. But Host B will also pick up this message, and
<will find that it is not destined for him. Host B will then forward
<it to the Default Router over network 192.40.2.
Hold it! In your configuration, Host B should NOT be forwarding ANY
packets at all, unless it is configured as a gateway. Now, assuming
that Host B IS a gateway and has another network connected behind it,
the answer is found in (I believe) the gateway's requirements RFC (RFC
1009). Somewhere it says that if a datagram is received via a media
broadcast that is not destined for a local broadcast address (ie, one
of Host B's own broadcast addresses), then it should be quietly
discarded.
Scott Ballew
Cypress Network Operations Center
Purdue University Department of Computer Sciencesvjs@rhyolite.wpd.sgi.com (Vernon Schryver) (09/29/90)
In article <1990Sep28.143945.7440@ultra.com>, wayne@ultra.com (Wayne Hathaway) writes: > ... [description of having 2 logical networks on 1 cable deleted] >... > Clearly what Host B SHOULD do with the "misdelivered broadcast" is say > "This is not for me AND it came in as a MAC layer broadcast; therefore > just discard it (do NOT forward it)." But unfortunately that requires > IP to know what MAC layer address a datagram came in on, and (at least > in any BSD-derivative implementation I know of) that information is > not available to IP. I think this is available in 4.3BSD-Reno. I think it is required by the Host Requirements RFCs. It is or will soon be available from at least one vendor. >... > 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. >... > Wayne Hathaway domain: wayne@Ultra.COM > Ultra Network Technologies uucp: ...!ames!ultra!wayne What about using any of the zillions of routing protocols instead of static, default routes? Even RIP should work. I thought some people say directed broadcasts are or should be illegal. Vernon Schryver, Silicon Graphics, vjs@sgi.com
medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) (09/29/90)
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
smoot@cs.utexas.edu (Smoot Carl-Mitchell) (09/29/90)
In article <70667@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > >What about using any of the zillions of routing protocols instead >of static, default routes? Even RIP should work. > >I thought some people say directed broadcasts are or should be illegal. > > >Vernon Schryver, Silicon Graphics, vjs@sgi.com Routing has little to do with this problem. It looks like a variation of the famous broadcast storm problem inherent in 4.2BSD based TCP/IP implementations. The rule is a host which is not configured as a router should *NEVER* forward an IP packet which has a different destination address. 4.2BSD has the unfortunate feature of having IP forwarding turned on for any host. This has since been fixed in 4.3BSD. Obviously if more than one host forwards such a misdirected broadcast then network meltdown can occur very rapidly. An amusing variation on this problem is to get a packet sniffer and send an ICMP echo request packet using the Ethernet and IP broadcast address at about 0.5 sec intervals and watch the growth in ICMP traffic as all the hosts on the ethernet reply to this request all at once. Needless to say on a CSMA/CD network the collison rate also goes thru the roof. The corollary rule is never build an application which sends a broadcast packet which expects more than one host to reply to the broadcast. -- Smoot Carl-Mitchell, Texas Internet Consulting smoot@tic.com, smoot@cs.utexas.edu
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (09/30/90)
In article <11858@medusa.cs.purdue.edu>, smb@cs.purdue.EDU (Scott Ballew) writes: > Hold it! In your configuration, Host B should NOT be forwarding ANY > packets at all, unless it is configured as a gateway. ... Right! I wish I had said that. (I did think it; trust me.) Don't the Host Requirements say the same? For various reasons, I bet the original poster is running workstations with two interfaces, one ethernet and one other kind. I bet the workstations have either 4.2BSD or 4.3BSD TCP/IP, where having two interfaces turns on IP forwarding. If so, the easy solution is to set the kernel variable ipforwarding to 0. That can be done with adb on some systems and by editing configuration files on some other systems. Vernon Schryver, vjs@sgi.com.
raj@hpindwa.HP.COM (Rick Jones) (09/30/90)
> >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
wayne@ultra.com (Wayne Hathaway) (10/01/90)
Thanks to all who responded to my "Question on forwarding broadcasts"
posting. Two quickies.
One, I apologize for over-simplifying the picture. In the real life
situation both hosts do in fact have other network connections, so
they really SHOULD be forwarding packets. If I had drawn a couple
more lines it would have been clearer.
But mostly, I should have read RFC 1009 more carefully, 'cause sure
enough, there it is right on page 36:
In general, a gateway must not forward a datagram which
arrives via local network broadcast, and must not send
an ICMP error message when dropping the datagram. A
discussion of the rules will be found in Appendix A;
see also [50].
(Interesting that this specific situation does NOT seem to be
mentioned anywhere in Appendix A, however!)
Now the only question is when the support for the above requirement
(that is, Data Link telling IP whether a packet arrived via broadcast
or multicast) will get out in the various host implementations. And
THAT is what I should/would have asked, if I had read RFC 1009 better!
Anyway, apologies for the wasted net bandwidth on red herrings. Now,
about the REAL question ... ?
Wayne Hathaway domain: wayne@Ultra.COM
Ultra Network Technologies uucp: ...!ames!ultra!wayne
101 Daggett Drive phone: 408-922-0100 x132
San Jose, CA 95134 direct: Hey, you!