phil@EAST.BERKELEY.EDU (Phil Lapsley) (03/20/88)
RFC 1009 defines an IP directed broadcast as a datagram with a destination of an IP (sub)network broadcast address. The packet is forwarded normally until it reaches a gateway of the destination (sub)net, at which point the gateway "bursts" the packet into a media broadcast on the local (sub)net. RFC 1009 also gives gateways the option of "protecting" their local networks by dropping directed broadcasts on the floor. Be default, a 4.3 BSD gateway machine that is final hop of a directed broadcast packet will accept the packet as if it was destined for itself, but it will not burst the packet into a media level broadcast. If DIRECTED_BROADCAST is defined when the 4.3 kernel is made, this bursting will actually occur. My question is: what gateway implementations actually use directed broadcasts in the RFC 1009 sense, and why? Phil
hedrick@athos.rutgers.edu (Charles Hedrick) (03/21/88)
We use directed broadcasts for at least two purposes: 1) Our kinetics Appletalk gateways use them to keep track of each other or of some hosts that provide services for them. (I'm a bit vague, since I'm not an expert with Kinetics. I support the main IP gateways, and I know I had to get directed broadcasts working properly in order to satisfy our Mac guys.) 2) The cisco gateways that we use have a concept of helper address. If a net doesn't have any servers on it, you can get a gateway to forward all requests of a certain class (those that would normally be used for booting: TFTP, bootp, timed, and named) to a specified address. FOr reliability reasons, we don't to provide several servers, so we use a subnet with lots of servers, and use directed broadcast onto that subnet. I have also done some experiments with sending messges warning of gateway reboots etc. by doing rwall to a broadcast addresss for each of the subnets affected. It seems to work. In general, I'd say the directed broadcast mechanism is useful, and that gateways should implement it. Note that the way you know whether to absorb the packet yourself or forward it onto the subnet is by whether it arrived as a physical broadcast or not. If it did, then it has already been broadcast, and you should process it as a host. If it arrives as a non-broadcast, then the sender wants you to put it out on the subnet as a broadcast. This must be implemented properly, or disaster will ensue.