rfc-919

Broadcasting Internet Datagrams

J.C. Mogul
date1984-10 streamLegacy statusINTERNET STANDARD pages8 canonicalhttps://www.rfc-editor.org/rfc/rfc919 doi10.17487/RFC0919
This RFC proposes 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 (17)

design-rationale §7

All-ones was chosen as the broadcast host number because it is unlikely to be assigned to a real host, making conflicts rare. This choice was first proposed in IEN-212. The few hosts already assigned all-ones host numbers are expected to renumber.

ip

design-rationale §7

All-zeros in an IP address field is used as a notational convention meaning 'unspecified' or 'this network', complementary to all-ones meaning broadcast. For example, 36.0.0.0 denotes network 36, while 36.255.255.255 denotes all hosts on network 36. All-zeros source addresses appear legitimately in ICMP Information Request datagrams.

ip

design-rationale §3

Broadcasting is treated as an imperfect substitute for multicasting: packets are broadcast at the hardware layer, but filtering in receiving hosts achieves the effect of multicast. It is most useful for gateway discovery, ARP-style address resolution, and reaching servers (name, time) without wired-in addresses.

ip

design-rationale §1

Broadcasts are assumed not to be reliably delivered; providing reliability is left to higher-layer protocols. The RFC assumes only that a host will receive most broadcasts sent. Broadcast reliability guarantees are considered too expensive relative to their benefit.

ip

design-rationale §3

Wired-in neighbor lists create network management inflexibility, and polling all possible IP addresses is prohibitively slow (up to ~65,000 on ARPANET). Broadcasting provides a fast, simple mechanism for reaching all neighbors without early binding or exhaustive polling.

ip

interoperability-note §7.1

ARP servers that incorrectly map broadcast IP addresses to hardware broadcast addresses cause forwarding loops. Networks with heterogeneous hosts that disagree about the broadcast address are especially vulnerable, as non-compliant hosts re-broadcast received datagrams, potentially exponentially amplifying traffic.

ip

interoperability-note §1

This RFC explicitly does not address the complications arising from interactions between subnets and broadcasting; those are treated separately in RFC-922. Implementors deploying broadcasts on subnetted IP networks must consult RFC-922 in addition to this document.

ip

normative-requirement §4 MUST

A host must discard data-link-layer broadcast datagrams whose IP destination is a specific unicast address not belonging to the host, without producing error messages or becoming confused.

ip

normative-requirement §5 MUST

A host's IP receiving layer must compare incoming destination addresses against all possible broadcast addresses for that host, in addition to its own unicast addresses. Without this modification, broadcast datagrams would be incorrectly discarded.

ip

normative-requirement §7.1 MUST NOT

An ARP server should never respond to an ARP request whose target address is a broadcast address. Such a request comes from a host that does not recognize the broadcast address as such; honoring it would almost certainly cause a forwarding loop, potentially generating T**N spurious re-broadcasts for N non-compliant hosts with TTL T.

ip

normative-requirement §6 SHOULD NOT

If a gateway receives a broadcast datagram on the hardware network to which it is addressed, the gateway should not forward it but should treat itself as a destination (e.g., processing the datagram as a routing table update).

ip

normative-requirement §6 SHOULD

If a gateway receives a directed broadcast for a network to which it is not connected, it should forward it via the normal routing mechanism rather than broadcasting it locally.

ip

normative-requirement §7 MUST NOT

The address 255.255.255.255 denotes a local hardware network broadcast and must not be forwarded by gateways. It may be used by hosts that do not yet know their own network number (e.g., to query a server for it).

ip

normative-requirement §6 MUST NOT

The primary rule for gateways to avoid infinite broadcast loops: a gateway must never retransmit a broadcast datagram on the same hardware network from which it was received. Simply avoiding repeating one's own prior transmissions is insufficient when multiple gateways share a hardware network.

ip

protocol-element §4

Four classes of IP broadcasting are defined: (1) single-destination datagram sent as a data link layer broadcast but not an IP broadcast; (2) broadcast to all hosts on the local IP network using a distinguished host-number; (3) directed broadcast to all hosts on a remote IP network, routed normally to a gateway then broadcast locally; and (4) broadcast to the entire Internet, considered not useful and undesirable.

ip

protocol-element §7

The IP broadcast host number is all-ones bits in the host-number field. The address 255.255.255.255 denotes a local hardware network broadcast. A directed broadcast to a specific network uses the network prefix with all-ones in the host-number field (e.g., 36.255.255.255 for net 36).

ip

security-consideration §4

For reasons of performance or security, a gateway may choose not to forward broadcasts. It may be advisable to prohibit broadcasts into or out of an autonomous group of networks to prevent potential denial-of-service (every host bears cost for each broadcast received) and unintended information leakage.

ip, security