Broadcasting Internet Datagrams
RFC 919

Document Type RFC - Internet Standard (October 1984; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 919 (Internet Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      Jeffrey Mogul
Request for Comments: 919                    Computer Science Department
                                                     Stanford University
                                                            October 1984


Status of this Memo

   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.
   Distribution of this memo is unlimited.


   This proposal is the result of discussion with several other people,
   especially J. Noel Chiappa and Christopher A. Kent, both of whom both
   pointed me at important references.

1. Introduction

   The use of broadcasts, especially on high-speed local area networks,
   is a good base for many applications.  Since broadcasting is not
   covered in the basic IP specification [13], there is no agreed-upon
   way to do it, and so protocol designers have not made use of it. (The
   issue has been touched upon before, e.g. [6], but has not been the
   subject of a standard.)

   We consider here only the case of unreliable, unsequenced, possibly
   duplicated datagram broadcasts (for a discussion of TCP broadcasting,
   see [11].) Even though unreliable and limited in length, datagram
   broadcasts are quite useful [1].

   We assume that 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 [10], token ring
   networks [2], etc.

   We do not assume, however, that broadcasts are reliably delivered.
   (One might consider providing a reliable broadcast protocol as a
   layer above IP.) It is quite expensive to guarantee delivery of
   broadcasts; instead, what we assume is that a host will receive most
   of the broadcasts that are sent.  This is important to avoid
   excessive use of broadcasts; since every host on the network devotes
   at least some effort to every broadcast, they are costly.

Mogul                                                           [Page 1]

RFC 919                                                     October 1984
Broadcasting Internet Datagrams

   When a datagram is broadcast, it imposes a cost on every host that
   hears it.  Therefore, broadcasting should not be used
   indiscriminately, but rather only when it is the best solution to a

   Note: some organizations have divided their IP networks into subnets,
   for which a standard [8] has been proposed.  This RFC does not cover
   the numerous complications arising from the interactions between
   subnets and broadcasting; see [9] for a complete discussion.

2. Terminology

   Because broadcasting depends on the specific data link layer in use
   on a local network, we must discuss it with reference to both
   physical networks and logical networks.

   The terms we will use in referring to physical networks are, from the
   point of view of the host sending or forwarding a broadcast:

   Local Hardware Network

      The physical link to which the host is attached.

   Remote Hardware Network

      A physical network which is 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 includes several kinds of logical network.  To avoid
   ambiguity, we will use the following terms:


      The DARPA Internet collection of IP networks.

   IP Network

      One or a collection of several hardware networks that have one
      specific IP network number.

Mogul                                                           [Page 2]

RFC 919                                                     October 1984
Broadcasting Internet Datagrams

3. Why Broadcast?

   Broadcasts are useful when a host needs to find information without
   knowing exactly what other host can supply it, or when a host wants
   to provide information to a large set of hosts in a timely manner.

   When a host needs information that one or more of its neighbors might
   have, it could have a list of neighbors to ask, or it could poll all
   of its possible neighbors until one responds.  Use of a wired-in list
   creates obvious network management problems (early binding is
   inflexible).  On the other hand, asking all of one's neighbors is
   slow if one must generate plausible host addresses, and try them
   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.)
   Fortunately, broadcasting provides a fast and simple way for a host
Show full document text