rfc-922

Broadcasting Internet datagrams in the presence of subnets

J.C. Mogul
date1984-10 streamLegacy statusINTERNET STANDARD pages12 canonicalhttps://www.rfc-editor.org/rfc/rfc922 doi10.17487/RFC0922
We propose simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

also

Extracted elements (20)

design-rationale §7

All-ones was chosen as the broadcast host number because it is unlikely to be assigned to a real host, and the local network layer can always map any IP address to a data link broadcast address, making the specific choice somewhat arbitrary. First proposed in IEN-212.

ip

design-rationale §3

Broadcasts are described as an imperfect substitute for multicasting: datagrams are broadcast at the hardware layer, but filtering in receiving hosts produces the effect of multicast. The document explains this tradeoff explicitly to motivate why broadcast should not be used indiscriminately.

ip, multicast

design-rationale §5

Reverse Path Forwarding (RPF) was selected as the multi-subnet broadcast algorithm because, while suboptimal in cost and reliability, it is extremely simple to implement and requires no additional data space in a gateway — satisfying the design goal of minimizing gateway complexity.

ip

design-rationale §7

RFC 922 deliberately separates the broadcast addressing scheme from any assumption about the specific subnet/host field division, so a host can broadcast to a remote subnetted network (e.g., 36.255.255.255) without knowing how the 24-bit local-address part is divided. This was a non-obvious choice that avoids requiring hosts to know remote subnet masks.

ip

interoperability-note §7.1

If not all hosts on a network share the same understanding of what constitutes a broadcast address, ARP interactions can cause problems. A host that does not recognize 255.255.255.255 as a broadcast may send an ARP request for it, and an incorrectly implemented ARP server that responds will trigger forwarding loops.

ip

interoperability-note §2

The introduction of a subnet level in the IP addressing hierarchy is at variance with the base IP specification (RFC 791), which does not define subnetting. RFC 922's broadcast scheme is explicitly designed to accommodate subnetting as defined in RFC 917.

ip

normative-requirement §6.1 MUST NOT

A gateway that receives a local broadcast datagram on the hardware network to which the datagram is addressed must not forward it, but should treat itself as a destination (e.g., for routing table updates).

ip

normative-requirement §4 SHOULD

A host must discard datagrams not addressed to it (unicast or broadcast) without generating error messages or becoming confused when such datagrams arrive as link-layer broadcasts carrying a specific unicast destination IP address.

ip

normative-requirement §5 MUST

A host's IP receiving layer must compare incoming destination addresses against both its own unicast addresses and all possible broadcast addresses for that host, in order to recognize and accept broadcast datagrams.

ip

normative-requirement §7.1 MUST NOT

An ARP server must never respond to an ARP request whose target address is a broadcast address. Honoring such a request would indicate the querying host does not recognize the broadcast address, and responding would almost certainly cause a forwarding loop, potentially generating T^N spurious rebroadcasts for N confused hosts with TTL T.

ip, security

normative-requirement §6.2 SHOULD

For multi-subnet broadcasts, a gateway should forward copies of the datagram on all connected links if and only if the datagram arrived on the link that is part of the best route back to the source (Reverse Path Forwarding). If not, the datagram must be discarded as a duplicate from another gateway.

ip

normative-requirement §7 MUST NOT

The address 255.255.255.255 (limited broadcast) must not be forwarded by gateways. It is intended for use on the local hardware network only, such as by hosts that do not yet know their network number.

ip

normative-requirement §6.1 MUST NOT

The primary rule for gateways to avoid broadcast loops is: never retransmit a broadcast datagram on the hardware network it was received on. Simply avoiding repetition of self-originated datagrams is insufficient because multiple gateways on the same network can still create loops.

ip

protocol-element §4

Five broadcast classes are defined: (1) single-destination datagrams sent as link-layer broadcasts, (2) local hardware network broadcast using all-ones host number, (3) directed broadcast to a remote hardware network, (4) multi-subnet broadcast using all-ones subnet number, and (5) Internet-wide broadcast (deemed undesirable).

ip

protocol-element §7

IP broadcast addressing uses all-ones in the host-number field to denote 'all hosts'. The address 255.255.255.255 denotes a local hardware network broadcast, while a network-prefixed address like 36.255.255.255 denotes a directed broadcast to all hosts on that IP network.

ip, multicast

protocol-element §7

The all-ones value in the subnet-number field denotes 'all subnets', enabling a host to broadcast to all subnets of a remote IP network without knowing the specific subnet/host field division. For example, 36.255.255.255 covers all subnets of network 36 regardless of how the local-address is partitioned.

ip

protocol-element §7

The 'all zeros' convention is used notionally to refer to networks rather than hosts (e.g., 36.0.0.0 means network 36), while 'all ones' means broadcast to all hosts on that network (e.g., 36.255.255.255). All-zeros source addresses may appear in ICMP Information Request datagrams from hosts that do not yet know their network number.

ip

security-consideration §1

Directed broadcasts (sending to all hosts on a remote network) pose an amplification risk: a single datagram arriving at a gateway is replicated to every host on the target network. The document notes that broadcasts impose a cost on every host that hears them and should not be used indiscriminately.

ip, security

security-consideration §4

For reasons of performance or security, a gateway may choose not to forward broadcasts. Banning broadcasts into or out of an autonomous group of networks (e.g., an organizational boundary) is cited as a potentially good idea.

ip, security

state-machine §6.3

Gateway routing algorithm (Pseudo-Algol, Figure 1): If the destination IP network is locally connected, check subnetting. For all-subnets broadcast, apply Reverse Path Forwarding — forward on all links except incoming if the datagram arrived on the best return path to source, else discard. For subnet-specific or unicast, forward to the appropriate outgoing link. If the destination is non-local, forward via normal routing.

ip