Connected: An Internet Encyclopedia
6. Gateways and Broadcasts
Up:
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
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
6. Gateways and Broadcasts