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 , 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. , 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 .) Even though unreliable and limited in length, datagram broadcasts are quite useful .
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 , token ring networks , 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.
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 problem.
Note: some organizations have divided their IP networks into subnets, for which a standard  has been proposed. This RFC does not cover the numerous complications arising from the interactions between subnets and broadcasting; see  for a complete discussion.