RFC 922

Status of this Memo 🎀

okay so the whole point of this one is simple rules for broadcasting Internet datagrams 📡. It covers how to broadcast on local networks that support broadcast, how to address those broadcasts, and how gateways should handle them 🚪.

This RFC suggests a proposed protocol for the ARPA-Internet community, and it's literally asking for discussion and suggestions for improvements 🗣️. Distribution of this memo is unlimited 🌈.

Acknowledgement 🫶

this proposal came out of talking things through with a bunch of other people, especially J. Noel Chiappa and Christopher A. Kent, who both pointed the author at important references 📚✨.

1. Introduction ✨

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

we're only looking at unreliable, unsequenced, possibly duplicated datagram broadcasts here. (For a discussion of TCP broadcasting, see [10].) Even though they're unreliable and limited in length, datagram broadcasts are quite useful [1] 💖.

we assume the data link layer of the local network supports efficient broadcasting 🔥. Most common local area networks do support broadcast, for example Ethernet [7, 5], ChaosNet [9], token ring networks [2], etc. 🧚

we do not assume broadcasts are reliably delivered, though 🙈. (One might consider providing a reliable datagram broadcast protocol as a layer above IP.) It's super expensive to guarantee delivery of broadcasts, so instead we assume that a host will receive most of the broadcasts that are sent 🌸. This matters because it helps avoid excessive use of broadcasts. 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 should not be used indiscriminately. It should only be used when it's the best solution to a problem 🫵.

2. Terminology 🦋

okay this part is important, because broadcasting depends on the specific data link layer in use on a local network. So we have to talk about it using both physical networks and logical networks 🧠.

These are the terms for physical networks, from the point of view of the host sending or forwarding a broadcast:

• Local Hardware Network: the physical link 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 (transitively) connected by gateways.

The IP world has several kinds of logical network 🌈. So to avoid confusion, we're going to use these terms:

• Internet: the DARPA Internet collection of IP networks.
• IP Network: one or a collection of several hardware networks that have one specific IP network number.
• Subnet: a single member of the collection of hardware networks that compose an IP network. Host addresses on a given subnet share an IP network number with hosts on all other subnets of that IP network, but the local-address part is divided into subnet-number and host-number fields to show which subnet a host is on 🍓. We don't assume a particular division of the local-address part, and this could vary from network to network.

Introducing a subnet level into the addressing hierarchy is at variance with the IP specification [12], but as addressable subnets keep multiplying, it's obvious that a broadcasting scheme should support subnetting 👑. For more on subnets, see [8].

in this paper, "host address" means the host-on-subnet address field of a subnetted IP network, or the host-part field otherwise 💜.

An IP network can be a single hardware network or a collection of subnets. From the point of view of a host on another IP network, it shouldn't matter which one it is ✨.

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 large set of hosts quickly ⚡.

when a host needs info that one or more of its neighbors might have, it could keep a list of neighbors to ask, or poll all of its possible neighbors until one responds 🤔. Using a wired-in list causes obvious network management problems, because early binding is inflexible 😤. On the other hand, asking all of your neighbors is slow if you have to generate plausible host addresses and try them one by one until one works. On the ARPANET, for example, there are roughly 65 thousand plausible host numbers 💀. Most IP implementations have used wired-in lists (for example, addresses of "Prime" gateways.) But honestly, broadcasting gives a host a fast and simple way to reach all of its neighbors 🫶.

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

one way to view broadcasting is as an imperfect substitute for multicasting, which is sending messages to a subset of the hosts on a network 🎯. In practice, broadcasts are usually used where multicasts are what's actually wanted. Datagrams get broadcast at the hardware level, but filtering software in the receiving hosts gives the effect of multicasting 🧚‍♀️.

for more examples of broadcast applications, see [1, 3] 📚.

4. Broadcast Classes 🎀

there are several classes of IP broadcasting:

• Single-destination datagrams broadcast on the local hardware net: a datagram is destined for a specific IP host, but the sending host broadcasts it at the data link layer, maybe to avoid having to do routing 🙃. Since this isn't an IP broadcast, the IP layer isn't really involved, except that a host should discard a datagram that isn't meant for it without getting flustered (i.e., printing an error message) 😌.
• Broadcast to all hosts on the local hardware net: a distinguished value for the host-number part of the IP address means broadcast instead of a specific host. The receiving IP layer must be able to recognize this address as well as its own 🔥. Still, it might be useful to tell broadcasts apart from non-broadcasts at higher levels, especially in gateways. This is the most useful case of broadcast 👑. It lets a host discover gateways without wired-in tables, it's the basis for address resolution protocols, and it's also handy for reaching utilities like name servers, time servers, etc., without needing wired-in addresses 🌸.
• Broadcast to all hosts on a remote hardware network: it's occasionally useful to send a broadcast to all hosts on a non-local network. For example, to find the latest version of a hostname database, to bootload a host on a subnet without a bootserver, or to monitor the timeservers on the subnet ⏰. This case works the same as local-network broadcasts. The datagram gets routed by normal mechanisms until it reaches a gateway attached to the destination hardware network, and then it gets broadcast 🛰️. This class is also known as "directed broadcasting", or quaintly as sending a "letter bomb" [1] 💣.
• Broadcast to all hosts on a subnetted IP network (Multi-subnet broadcasts): a distinguished value for the subnet-number part of the IP address is used to mean "all subnets". Broadcasts to all hosts of a remote subnetted IP network work just like directed broadcasts to a single subnet 🧩.
• Broadcast to the entire Internet: this is probably not useful, and almost certainly not desirable 🙅‍♀️.

for reasons of performance or security, a gateway may choose not to forward broadcasts. In particular, it may be a good idea to ban broadcasts into or out of an autonomous group of networks 🔒.

5. Broadcast Methods 🌈

a host's IP receiving layer must be modified to support broadcasting 🛠️. Without broadcasting, a host works out whether it's the recipient of a datagram by matching the destination address against all of its IP addresses. With broadcasting, a host has to compare the destination address not only against its own addresses, but also against the possible broadcast addresses for that host 👀.

the problem of how best to send a broadcast has been discussed a lot [1, 3, 4, 13, 14] 🤓. Since we're assuming that problem is already solved at the data link layer, an IP host that wants to send either a local broadcast or a directed broadcast only needs to specify the right destination address and send the datagram as usual. Any sophisticated algorithms only need to live in gateways 💅.

broadcasting to all hosts on a subnetted IP network is apparently somewhat harder 😳. But even then, the best known algorithms need no extra complexity in non-gateway hosts, which is lowkey iconic ✨. A good broadcast method will meet these additional criteria:

• No modification of the IP datagram format.
• Reasonable efficiency in terms of the number of excess copies generated and the cost of paths chosen.
• Minimization of gateway modification, in both code and data space.
• High likelihood of delivery.

the algorithm that looks best is the Reverse Path Forwarding (RPF) method [4] 👑. RPF isn't optimal in cost or reliability, but it's still quite good, and it's extremely simple to implement, needing no additional data space in a gateway 🫶🎀.

6. Gateways and Broadcasts 🌸

okay so the hard part of broadcasts is basically all in the gateways 🫶 If a gateway gets a directed broadcast for a network it isn't connected to, it just forwards it the normal way. Otherwise, it's got extra work to do 💅

6.1. Local Broadcasts

when a gateway gets a local broadcast datagram, there are a few different things it might have to do with it. The situation is unambiguous, but if you're not careful you can accidentally create infinite loops 😭

what the gateway does depends on a few things: the subnet the datagram came in on, the destination network, and the gateway's own addresses 🦋

• The primary rule for avoiding loops is "never broadcast a datagram on the hardware network it was received on". It's not enough to just avoid repeating datagrams the gateway has heard from itself, because loops can still happen if there are several gateways on one hardware network 🙈
• If the datagram is received on the hardware network it's addressed to, it should not be forwarded. The gateway should still count itself as a destination of the datagram, for example, if it's a routing table update.
• Otherwise, if the datagram is addressed to a hardware network the gateway is connected to, 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 pick a subsequent gateway and send the datagram along to it 🧚

6.2. Multi-subnet broadcasts

when a gateway gets a broadcast meant for all subnets of an IP network, it must use the Reverse Path Forwarding algorithm to decide what to do ✨ The method is simple: the gateway forwards copies of the datagram along all connected links, but only if the datagram arrived on the link that's part of the best route between the gateway and the source of the datagram. Otherwise, the datagram should be discarded 💀

this algorithm can be improved if some or all of the gateways swap extra information among themselves. That can happen transparently, so other hosts and even other gateways won't notice. See [4, 3] for details 🎀

6.3. Pseudo-Algol Routing Algorithm

this is a pseudo-Algol description of the routing algorithm a gateway should use 👑 The algorithm is shown in figure 1. Here's what the terms mean:

• RouteLink(host): a function that takes a host address as a parameter and returns the first-hop link from the gateway to the host.
• RouteHost(host): same as above, but it returns the first-hop host address.
• ResolveAddress(host): returns the hardware address for an IP host.
• IncomingLink: the link the packet arrived on.
• OutgoingLinkSet: the set of links the packet should be sent on.
• OutgoingHardwareHost: the hardware host address to send the packet to.
• Destination.host: the host-part of the destination address.
• Destination.subnet: the subnet-part of the destination address.
• Destination.ipnet: the IP-network-part of the destination address.

BEGIN
   IF Destination.ipnet IN AllLinks THEN
      BEGIN
         IF IsSubnetted(Destination.ipnet) THEN
            BEGIN
               IF Destination.subnet = BroadcastSubnet THEN
                  BEGIN      /* use Reverse Path Forwarding algorithm */
                     IF IncomingLink = RouteLink(Source) THEN
                        BEGIN IF Destination.host = BroadcastHost THEN
                              OutgoingLinkSet <- AllLinks -
                           IncomingLink;
                           OutgoingHost <- BroadcastHost;
                           Examine packet for possible internal use;
                        END
                     ELSE  /* duplicate from another gateway, discard */
                        Discard;
                  END
               ELSE
                  IF Destination.subnet = IncomingLink.subnet THEN
                     BEGIN           /* forwarding would cause a loop */
                        IF Destination.host = BroadcastHost THEN
                           Examine packet for possible internal use;
                        Discard;
                     END
                  ELSE BEGIN    /* forward to (possibly local) subnet */
                        OutgoingLinkSet <- RouteLink(Destination);
                        OutgoingHost <- RouteHost(Destination);
                     END
            END
         ELSE BEGIN         /* destined for one of our local networks */
               IF Destination.ipnet = IncomingLink.ipnet THEN
                  BEGIN              /* forwarding would cause a loop */
                     IF Destination.host = BroadcastHost THEN
                        Examine packet for possible internal use;
                     Discard;
                  END
               ELSE BEGIN                     /* might be a broadcast */
                     OutgoingLinkSet <- RouteLink(Destination);
                     OutgoingHost <- RouteHost(Destination);
                  END
            END
      END
   ELSE BEGIN                    /* forward to a non-local IP network */
         OutgoingLinkSet <- RouteLink(Destination);
         OutgoingHost <- RouteHost(Destination);
      END
   OutgoingHardwareHost <- ResolveAddress(OutgoingHost);
END

Figure 1: Pseudo-Algol algorithm for routing broadcasts by gateways

---

7. Broadcast IP Addressing - Conventions 💖

if different IP implementations are going to be compatible, there must be a convention, a distinguished number that means "all hosts" and "all subnets" 🍓

since the local network layer can always map an IP address to a data link layer address, picking the IP "broadcast host number" is kind of arbitrary. For simplicity, it should be one that's not likely to be given to a real host. The number with all bits set to one has that property, and this assignment was first proposed in [6]. In the few cases where a host was given an address with an all-ones host-number part, it doesn't seem like too much to ask for renumbering 🙏

the "all subnets" number is also all ones. That means a host that wants to broadcast to all hosts on a remote IP network doesn't need to know how the destination address is split into subnet and host fields, or even whether it's split at all 🦋 For example, 36.255.255.255 might mean all the hosts on a single hardware network, or all the hosts on a subnetted IP network with 1 byte of subnet field and 2 bytes of host field, or any other possible split.

the address 255.255.255.255 means a broadcast on a local hardware network that must not be forwarded. A host might use it when it doesn't know its network number and is asking some server for it 🧚

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

it can do this without knowing whether the net is subnetted. If it isn't, both addresses have the same effect. A robust application might try the first address, and if no response comes back, try the second. See [1] for a discussion of these "expanding ring search" techniques 💜

if using "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 notation convention, we refer to networks (as opposed to hosts) using addresses with zero fields. For example, 36.0.0.0 means "network number 36", while 36.255.255.255 means "all hosts on network number 36" ✨

7.1. ARP Servers and Broadcasts

the Address Resolution Protocol (ARP) described in [11] can cause problems if it's implemented incorrectly, especially when broadcasts are used on a network where not all hosts agree on what a broadcast address is 🙈 The temptation exists to change the ARP server so it provides 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 cause T**N spurious re-broadcasts 💀

---

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, November 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, BBN, 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. David A. Moon. Chaosnet. A.I. Memo 628, Massachusetts Institute of Technology Artificial Intelligence Laboratory, June 1981.
10. William W. Plummer. Internet Broadcast Protocols. IEN-10, BBN, March 1977.
11. David Plummer. An Ethernet Address Resolution Protocol. RFC-826, Symbolics, September 1982.
12. Jon Postel. Internet Protocol. RFC-791, ISI, September 1981.
13. David W. Wall. Mechanisms for Broadcast and Selective Broadcast. Ph.D. Th., Stanford University, June 1980.
14. David W. Wall and Susan S. Owicki. Center-based Broadcasting. Computer Systems Lab Technical Report TR189, Stanford University, June 1980. 🎀