Connected: An Internet Encyclopedia
RFC 919 - 6. Gateways and Broadcasts

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 919
Prev: 5. Broadcast Methods
Next: 7. Broadcast IP Addressing - Proposed Standards

### 6. Gateways and Broadcasts

Most of the complexity in supporting broadcasts lies in gateways. If a gateway receives a directed broadcast for a network to which it is not connected, it simply forwards it using the usual mechanism. Otherwise, it must do some additional work.

When a gateway receives a local broadcast datagram, there are several things it might have to do with it. The situation is unambiguous, but without due care it is possible to create infinite loops.

The appropriate action to take on receipt of a broadcast datagram depends on several things: the subnet it was received on, the destination network, and the addresses of the gateway.

- The primary rule for avoiding loops is "never broadcast a datagram on the hardware network it was received on". It is not sufficient simply to avoid repeating datagrams that a gateway has heard from itself; this still allows loops if there are several gateways on a hardware network.

- If the datagram is received on the hardware network to which it is addressed, then it should not be forwarded. However, the gateway should consider itself to be a destination of the datagram (for example, it might be a routing table update.)

- Otherwise, if the datagram is addressed to a hardware network to which the gateway is connected, it should be sent as a (data link layer) broadcast on that network. Again, the gateway should consider itself a destination of the datagram.

- Otherwise, the gateway should use its normal routing procedure to choose a subsequent gateway, and send the datagram along to it.

Next: 7. Broadcast IP Addressing - Proposed Standards

Connected: An Internet Encyclopedia
RFC 919 - 6. Gateways and Broadcasts