RFC 919

RFC 919: BROADCASTING INTERNET DATAGRAMS 📡

okay bestie, this is RFC 919 💖 It's from October 1984 and it's written by Jeffrey Mogul from the Computer Science Department at Stanford University 🎓 It's a Network Working Group document, and it's a proposed protocol for the ARPA-Internet community that's asking people to discuss it and suggest improvements ✨ The header doesn't list any RFCs it obsoletes or updates, so it's a standalone proposal 🌸

Status of this Memo

we're proposing simple rules for broadcasting Internet datagrams on local networks that support broadcast 🦋 the rules also cover how to address broadcasts and how gateways should handle them 💅

this RFC suggests a proposed protocol for the ARPA-Internet community and asks for discussion and suggestions for improvements 🫶 distribution of this memo is unlimited, so share it with everyone 🌈

Acknowledgement

this proposal came out of discussions with several people, and J. Noel Chiappa and Christopher A. Kent both get a huge shoutout 🙌 they both pointed the author at important references, so they're literally why this exists 💜

1. Introduction ✨

broadcasts, especially on high-speed local area networks, are a great base for lots of applications 🚀 the thing is, broadcasting isn't covered in the basic IP specification [13], so there's no agreed-upon way to do it. protocol designers haven't used it because of that 😭 (the issue has come up before, e.g. [6], but it's never been the subject of a standard 🙈)

we're only looking at unreliable, unsequenced, possibly duplicated datagram broadcasts here. if you want to know about TCP broadcasting, check out [11] 💖 even though datagram broadcasts are unreliable and limited in length, they're still super useful [1] 🍓

we assume the data link layer of the local network supports efficient broadcasting ⚡ most common local area networks do, for example Ethernet [7, 5], ChaosNet [10], token ring networks [2], etc. 🌐

we do not assume broadcasts are reliably delivered. (someone could build a reliable broadcast protocol as a layer above IP, but that's a different story 🧚) guaranteeing delivery of broadcasts is super expensive, so what we assume instead is that a host will receive most of the broadcasts that get sent. this matters because we don't want broadcasts used too much. every host on the network puts at least some effort into every broadcast, so they're costly 💸

when a datagram is broadcast, it costs every host that hears it something. so broadcasting shouldn't be used indiscriminately 🙅‍♀️ it should only be used when it's the best solution to a problem 💅

⚠️ aside: some organizations have split their IP networks into subnets, and there's a standard [8] proposed for that. this RFC doesn't cover the many complications that come from mixing subnets and broadcasting. if you want the full tea, see [9] 🫠

2. Terminology 📚

broadcasting depends on the specific data link layer being used on a local network, so we have to talk about it using both physical networks and logical networks 🎀

for physical networks, these are the terms we'll use, from the point of view of the host sending or forwarding a broadcast:

• Local Hardware Network: the physical link that the host is attached to 🔌
• Remote Hardware Network: a physical network that's separated from the host by at least one gateway 🛣️
• Collection of Hardware Networks: a set of hardware networks that are (transitively) connected by gateways 🕸️

the IP world has several kinds of logical network, so to avoid confusion, we'll use these terms:

• Internet: the DARPA Internet collection of IP networks 🌍
• IP Network: one hardware network, or a collection of several hardware networks, that have one specific IP network number 🦋

3. Why Broadcast? 📣

broadcasts are useful when a host needs to find information without knowing exactly which other host can supply it, or when a host wants to hand information to a big set of hosts in a timely way ⭐

if a host needs info that one or more of its neighbors might have, it could keep a list of neighbors to ask, or it could poll every possible neighbor until one responds 🤔 using a wired-in list causes obvious network management problems, since early binding is inflexible 🙄 asking all of your neighbors is slow, though, if you have to generate plausible host addresses and try them one by one until something works 😩 on the ARPANET, for example, there are roughly 65 thousand plausible host numbers. most IP implementations used wired-in lists (for example, addresses of "Prime" gateways) 🧾 luckily, broadcasting gives a host a fast and simple way to reach all of its neighbors ✨

a host might also broadcast to give all of its neighbors some information 📢 for example, a gateway might announce its presence to other gateways 🚪

one way to think about broadcasting is as an imperfect substitute for multicasting, which is sending messages to a subset of the hosts on a network 🎯 in practice, broadcasts often get used when multicasts are what's really wanted. packets are broadcast at the hardware level, but filtering software in the receiving hosts gives the effect of multicasting 🪄

for more examples of broadcast applications, check out [1, 3] 💜

---

to be continued in part 2 (Section 4, Broadcast Classes, onward) 🦋✨

7. Broadcast IP Addressing ✨

okay bestie, so if different IP implementations are gonna get along, there has to be one special number that means "all hosts" 🫶 that's literally the whole point 💖

the local network can always turn an IP address into a data link layer address, so picking the IP "broadcast host number" is kinda arbitrary 🦋 for simplicity, you want one that's not likely to get assigned to a real host 🌸 the number with all ones in its bits is perfect for this, and it was first proposed in [6] 👑 in the few cases where a host already got an address with an all-ones host part, it doesn't seem too much to ask that it gets renumbered 🙈

the address 255.255.255.255 means a broadcast on a local hardware network, and it must not be forwarded 🚫 hosts that don't know their network number can use it when they're asking some server for that info 🧚

so a host on net 36, for example, can:

• broadcast to all of its immediate neighbors by using 255.255.255.255
• broadcast to all of net 36 by using 36.255.255.255

(Note that unless the network has been broken up into subnets, these two methods have identical effects. 💅)

if "all ones" in a field of an IP address means "broadcast," then "all zeros" could be seen as meaning "unspecified" 🌈 there's probably no reason for those addresses to show up anywhere except as the source address of an ICMP Information Request datagram 🙃 but as a notational convention, we refer to networks (not hosts) using addresses with zero fields 💜 so 36.0.0.0 means "network number 36" and 36.255.255.255 means "all hosts on network number 36" ✨

---

7.1. ARP Servers and Broadcasts 🎀

the Address Resolution Protocol (ARP) described in [12] can cause problems if it's implemented incorrectly 😭 this gets extra messy when broadcasts are used on a network where not all hosts agree on what a broadcast address is 💀 the temptation is there to modify the ARP server so it gives you the mapping between an IP broadcast address and the hardware broadcast address 👀

this temptation must be resisted 🚫 an ARP server should never respond to a request whose target is a broadcast address 🙅‍♀️ a request like that can only come from a host that doesn't recognize the broadcast address as one, so honoring it would almost certainly lead to a forwarding loop 🌀 if there are N such hosts on the physical network that don't recognize this address as a broadcast, then a datagram sent with a Time-To-Live of T could potentially give rise to T**N spurious re-broadcasts 😱 that's a whole disaster, periodt 💀

---

8. References 📚

1. David Reeves Boggs. Internet Broadcasting. Ph.D. Th., Stanford University, January 1982.
2. D.D. Clark, K.T. Pogran, and D.P. Reed. "An Introduction to Local Area Networks". Proc. IEEE 66, 11, pp1497-1516, 1978.
3. Yogan Kantilal Dalal. Broadcast Protocols in Packet Switched Computer Networks. Ph.D. Th., Stanford University, April 1977.
4. Yogan K. Dalal and Robert M. Metcalfe. "Reverse Path Forwarding of Broadcast Packets". Comm. ACM 21, 12, pp1040-1048, December 1978.
5. The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specifications. Version 1.0, Digital Equipment Corporation, Intel, Xerox, September 1980.
6. Robert Gurwitz and Robert Hinden. IP - Local Area Network Addressing Issues. IEN-212, Bolt Beranek and Newman, September 1982.
7. R.M. Metcalfe and D.R. Boggs. "Ethernet: Distributed Packet Switching for Local Computer Networks". Comm. ACM 19, 7, pp395-404, July 1976. Also CSL-75-7, Xerox Palo Alto Research Center, reprinted in CSL-80-2.
8. Jeffrey Mogul. Internet Subnets. RFC-917, Stanford University, October 1984.
9. Jeffrey Mogul. Broadcasting Internet Packets in the Presence of Subnets. RFC-922, Stanford University, October 1984.
10. David A. Moon. Chaosnet. A.I. Memo 628, Massachusetts Institute of Technology Artificial Intelligence Laboratory, June 1981.
11. William W. Plummer. Internet Broadcast Protocols. IEN-10, Bolt Beranek and Newman, March 1977.
12. David Plummer. An Ethernet Address Resolution Protocol. RFC-826, Symbolics, September 1982.
13. Jon Postel. Internet Protocol. RFC 791, ISI, September 1981.
14. David W. Wall. Mechanisms for Broadcast and Selective Broadcast. Ph.D. Th., Stanford University, June 1980.
15. David W. Wall and Susan S. Owicki. Center-based Broadcasting. Computer Systems Lab Technical Report TR189, Stanford University, June 1980.