Chapter 12. Broadcasting and Multicasting (2024)

12.1 Introduction

We mentioned in Chapter 1 that there are three kindsof IP addresses: unicast, broadcast, and multicast.In this chapter we discuss broadcasting and multicasting in moredetail.

Broadcasting and multicasting only apply to UDP,where it makes sense for an application to send a single messageto multiple recipients. TCP is a connection-oriented protocolthat implies a connection between two hosts (specified by IP addresses)and one process on each host (specified by port numbers).

Consider a set of hosts on a shared network suchas an Ethernet. Each Ethernet frame contains the source and destinationEthernet addresses (48-bit values). Normally each Ethernet frameis destined for a single host. The destination address specifiesa single interface-called a unicast. In this way communicationbetween any two hosts doesn't bother any of the remaining hostson the cable (except for possible contention for the shared media).

There are times, however, when a host wants to senda frame to every other host on the cable-called a broadcast.We saw this with ARP and RARP. Multicasting fits between unicastingand broadcasting: the frame should be delivered to a set of hoststhat belong to a multicast group.

To understand broadcasting and multicasting we needto understand that filtering takes place on each host, each timea frame passes by on the cable. Figure 12.1 shows a picture ofthis.

First, the interface card sees every frame that passesby on the cable and makes a decision whether to receive the frameand deliver it to the device driver. Normally the interface cardreceives only those frames whose destination address is eitherthe hardware address of the interface or the broadcast address.Additionally, most interfaces can be placed into a promiscuousmode whereby they receive a copy of every frame. This mode isused by tcpdump, for example.

Chapter 12. Broadcasting and Multicasting (1)

Figure 12.1 Filteringthat takes place up the protocol stack when a frame is received.

Today most interfaces can also be configured to receiveframes whose destination address is a multicast address, or somesubset of multicast addresses. On an Ethernet, a multicast addresshas the low-order bit of the high-order byte turned on. In hexadecimalthis bit looks like 01:00:00:00:00:00.(We can consider the Ethernet broadcast address, ff:ff:ff:ff:ff:ffas a special case of the Ethernet multicast address.)

If the interface card receives the frame, it is passedto the device driver. (One reason the interface card might discardthe frame is if the Ethernet checksum is incorrect.) Additionalfiltering is performed by the device driver. First, the frametype must specify a protocol that is supported (IP, ARP, etc.).Second, additional multicast filtering may be performed, to checkwhether the host belongs to the addressed multicast group.

The device driver then passes the frame to the nextlayer, such as IP, if the frame type specifies an IP datagram.IP performs more filtering, based on the source and destinationIP addresses, and passes the datagram up to the next layer (suchas TCP or UDP) if all is well.

Each time UDP receives a datagram from IP, it performsfiltering based on the destination port number, and sometimesthe source port number too. If no process is currently using thedestination port number, the datagram is discarded and an ICMPport unreachable message is normally generated. (TCP performssimilar filtering based on its port numbers.) If the UDP datagramhas a checksum error, UDP silently discards it.

The problem with broadcasting is the processing loadthat it places on hosts that aren't interested in the broadcasts.Consider an application that is designed to use UDP broadcasts.If there are 50 hosts on the cable, but only 20 are participatingin the application, every time one of the 20 sends a UDP broadcast,the other 30 hosts have to process the broadcast, all the wayup through the UDP layer, before the UDP datagram is discarded.The UDP datagram is discarded by these 30 hosts because the destinationport number is not in use.

The intent of multicasting is to reduce this loadon hosts with no interest in the application. With multicastinga host specifically joins one or more multicast groups. If possible,the interface card is told which multicast groups the host belongsto, and only those multicast frames are received.

12.2 Broadcasting

In Figure 3.9 we showed four different forms of IPbroadcast addresses. We now describe them in more detail.

Limited Broadcast

The limited broadcast address is 255.255.255.255.This can be used as the destination address of an IP datagramduring the host configuration process, when the host might notknow its subnet mask or even its IP address.

A datagram destined for the limited broadcast addressis never forwarded by a router under any circ*mstance.It only appears on the local cable.

An unanswered question is: if a host is multihomedand a process sends a datagram to the limited broadcast address,should the datagram be sent out each connected interface thatsupports broadcasting? If not, an application that wants to broadcastout all interfaces must determine all the interfaces on the hostthat support broadcasting, and send a copy out each interface.

Most BSD systems treat 255.255.255.255 as an aliasfor the broadcast address of the first interface that was configured,and don't provide any way to send a datagram out all attached,broadcast-capable interfaces. Indeed, two applications that sendUDP datagrams out every interface are routed(Section 10.3) and rwhod (the serverfor the BSD rwho client). Both ofthese applications go through a similar start-up procedure todetermine all the interfaces on the host, and which ones are capableof broadcasting. The net-directed broadcast address correspondingto that interface is then used as the destination address fordatagrams sent out the interface.

The Host Requirements RFC takes no stand on the issueof whether a multihomed host should send a limited broadcast outall its interfaces.

Net-directed Broadcast

The net-directed broadcast address has a hostID of all one bits. A class A net-directed broadcast address isnetid.255.255.255, where netid is the class A network ID.

A router must forward a net-directed broadcast, butit must also have an option to disable this forwarding.

Subnet-directed Broadcast

The subnet-directed broadcast address hasa host ID of all one bits but a specific subnet ID. Classificationof an IP address as a subnet-directed broadcast address requiresknowledge of the subnet mask. For example, if a router receivesa datagram destined for 128.1.2.255, this is a subnet-directedbroadcast if the class B network 128.1 has a subnet mask of 255.255.255.0,but it is not a broadcast if the subnet mask is 255.255.254.0(0xfffffe00).

All-subnets-directed Broadcast

An all-subnets-directed broadcast addressalso requires knowledge of the destination network's subnet mask,to differentiate this broadcast address from a net-directed broadcastaddress. Both the subnet ID and the host ID are all one bits.For example, if the destination's subnet mask is 255.255.255.0,then the IP address 128.1.255.255 is an all-subnets-directed broadcast.But if the network is not subnetted, then this is a net-directedbroadcast.

Current feeling [Almquist 1993] is that this typeof broadcast is obsolete. It is better to use multicasting thanan all-subnets-directed broadcast.

[Almquist 1993] notes that RFC 922 requires thatan all-subnets-directed broadcast be sent to all subnets, butno current routers do so. This is fortunate since a host thathas been misconfigured without its subnet mask sends all its "local"broadcasts to all subnets. For example, if the host with IP address128.1.2.3 doesn't set a subnet mask, then its broadcast addressnormally defaults to 128.1.255.255. But if the subnet mask shouldhave been set to 255.255.255.0, then broadcasts from this misconfiguredhost appear directed to all subnets.

The first widespread implementation of TCP/IP, the4.2BSD system in 1983, used a host ID of all zero bits for thebroadcast address. One of the earliest references to the broadcastIP address is IEN 212 [Gurwitz and Hinden 1982], and it proposedto define the IP broadcast address as a host ID of one bits. (lENsare the Internet Experiment Notes, basically predecessorsto the RFCs.) RFC 894 [Hornig 1984] commented that 4.2BSD useda nonstandard broadcast address, but RFC 906 [Finlayson 1984]noted that there was no Internet standard for the broadcast address.The RFC editor added a footnote to RFC 906 acknowledging the lackof a standard broadcast address, but strongly recommended thata host ID of all one bits be used as the broadcast address. AlthoughBerkeley adopted the use of all one bits for the broadcast addresswith 4.3BSD in 1986, some operating systems (notably SunOS 4.x)continued to use the nonstandard broadcast address through theearly 1990s.

12.3 Broadcasting Examples

How are broadcasts sent and what do routers and hostsdo with broadcasts? Unfortunately this is a hard question to answerbecause it depends on the type of broadcast address, the application,the TCP/IP implementation, and possible configuration switches.First, the application must support broadcasting. If we execute

sun % ping 255.255.255.255 /usr/etc/ping: unknown host 255.255.255.255

intending to send a broadcast on the local cable,it doesn't work. But the problem here is a programming problemin the application (ping). Most applicationsthat accept either a dotted-decimal IP address or a hostname callthe function inet_addr(3) to convertthe dotted-decimal character string to its 32-bit binary IP address,and if this fails, assume the character string is a hostname.Unfortunately this library function returns -1 to indicate anerror (such as a character other than a digit or decimal pointin the string), but the limited broadcast address (255.255.255.255)also converts into -1. Most programs then assume that the characterstring is a hostname, look it up using the DNS (Chapter 14), andend up printing an error such as "unknown host."

If we fix this programming shortfall in the pingprogram, however, the results are often not what we expect. Onsix different systems tested by the author, only one handled thisas expected and generated a broadcast packet on the local cable.Most looked up the IP address 255.255.255.255 in the routing table,applied the default route, and sent a unicast packet to the defaultrouter. Eventually the packet was thrown away

A subnet-directed broadcast is what we should beusing. Indeed, in Section 6.3 we sent datagrams to the IP address140.252.13.63 for the bottom Ethernet in our test network (insidefront cover), and got replies from all the hosts on the Ethernet.The subnet-directed broadcast address associated with each interfaceis the value used with the ifconfigcommand (Section 3.8). If we ping that address, the result iswhat we expect:

sun % arp -aARP cache is empty

sun % ping 140.252.13.63 PING 140.252.13.63: 56 data bytes 64 bytes from sun (140.252.13.33):icmp_seq=0. time=4. ms 64 bytes frombsdi (140.252.13.35): icmp_seq=0. time=172. ms 64 bytes from svr4 (140.252.13.34): icmp_seq=0. time=192. ms

64 bytes from sun (140.252.13.33): icmp_seq=l. time=1. ms 64 bytes from bsdi (140.252.13.35):icmp_seq=l. time=52. ms 64 bytes from svr4 (140.252.13.34): icmp_seq=l. time=90. ms

^? typeinterrupt key to stop --140.252.13.63 PING Statistics-- 2 packets transmitted, 6 packetsreceived, -200% packet loss round-trip (ms) min/avg/max = 1/85/192

sun % arp -a check ARP cache again svr4 (140.252.13.34) at 0:0:c0:c2:9b:26 bsdi (140.252.13.35) at 0:0:c0:6f:2d:40

IP looks at the destination address (140.252.13.63),determines that it is the subnet-directed broadcast address, andsends the datagram to the link-layer broadcast address.

We mentioned in Section 6.3 that this type of broadcastmeans all the hosts on the local network, including the sender.We see here that we do get a reply from the sending host (sun)in addition to the other hosts on the cable.

In this example we've also shown the ARP cache beforeand after the ping of the broadcastaddress. This is to show the interaction between broadcastingand ARP. "The ARP cache is empty before we execute ping,but full afterward. (That is, there is one entry for every otherhost on the cable that responded to the echo request.) How didthis happen when we said that the Ethernet frame is sent to thelink-layer broadcast address (0xffffffff)?The sending of these frames by sun does not require ARP.

If we watch ping usingtcpdump, we see that it is the recipientsof the broadcast frames that generate an ARP request to sun,before they can send their reply. This is because the reply isunicast. We said in Section 4.5 that the receiver of an ARP request(sun in this example) normally adds the requestor's IP addressand hardware address to its ARP cache, in addition to sendingan ARP reply. This is on the assumption that if the requestoris about to send us a packet, we'll probably want to send somethingback.

Our use of ping is somewhatspecial because the type of programming interface that it uses(called "raw sockets" on most Unix implementations)always allows a datagram to be sent to the broadcast address.What if we use an application that was not designed to supportbroadcasting, such as TFTP? (We cover TFTP in more detail in Chapter 15.)

`bsdi % tftp`	start the client
`tftp> connect 140.252.13.63`	specify the IP address of the server
`tftp> get temp.foo`	and try to fetch a file from the server
`tftp: sendto: Permission denied`
`tftp> quit`	terminate the client

Here we get an error immediately, and nothing issent on the cable. What's happening here is that the sockets APIdoesn't allow a process to send a UDP datagram to the broadcastaddress unless the process specifically states that it plans tobroadcast. This is intended to prevent users from mistakenly specifyinga broadcast address (as we did here) when the application wasnever intended to broadcast.

With the sockets API the application must set theSO_BROADCAST socket option beforesending a UDP datagram to a broadcast address.

Not all systems enforce this restriction. Some implementationsallow any process to broadcast UDP datagrams, without requiringthe process to say so. Others are more restrictive and requirea process to have superuser privileges to broadcast.

12.4 Multicasting

IP multicasting provides two services for an application.

Delivery to multiple destinations. There aremany applications that deliver information to multiple recipients:interactive conferencing and dissemination of mail or news tomultiple recipients, for example. Without multicasting these typesof services tend to use TCP today (delivering a separate copyto each destination). Even with multicasting, some of these applicationsmight continue to use TCP for its reliability.
Solicitation of servers by clients. A disklessworkstation, for example, needs to locate a bootstrap server.Today this is provided using a broadcast (as we'll see with BOOTPin Chapter 16), but a multicast solution would impose less overheadon the hosts that don't provide the service.

In this section we'll take a look at multicast addresses,and the next chapter looks at the protocol used by multicastinghosts and routers (IGMP).

Multicast Group Addresses

Figure 12.2 shows the format of a class D IP address.

Chapter 12. Broadcasting and Multicasting (2)

Figure 12.2 Formatof a class D IP address.

Unlike the other three classes of IP addresses (A,B, and C), which we showed in Figure 1.5, the 28 bits allocatedfor the multicast group ID have no further structure.

A multicast group address is the combinationof the high-order 4 bits of 1110 and the multicast group ID. Theseare normally written as dotted-decimal numbers and are in therange 224.0.0.0 through 239.255.255.255.

The set of hosts listening to a particular IP multicastaddress is called a host group. A host group can span multiplenetworks. Membership in a host group is dynamic-hosts may joinand leave host groups at will. There is no restriction on thenumber of hosts in a group, and a host does not have to belongto a group to send a message to that group.

Some multicast group addresses are assigned as well-knownaddresses by the IANA (Internet Assigned Numbers Authority). "Theseare called permanent host groups. This is similar to thewell-known TCP and UDP port numbers. Similarly, these well-knownmulticast addresses are listed in the latest Assigned NumbersRFC. Notice that it is the multicast address of the group thatis permanent, not the membership of the group.

For example, 224.0.0.1 means "all systems onthis subnet," and 224.0.0.2 means "all routers on thissubnet." The multicast address 224.0.1.1 is for NTP, theNetwork Time Protocol, 224.0.0.9 is for RIP-2 (Section 10.5),and 224.0.1.2 is for SGI's (Silicon Graphics) dogfight application.

Converting Multicast Group Addresses to Ethernet Addresses

The IANA owns an Ethernet address block, which inhexadecimal is 00:00:5e. This isthe high-order 24 bits of the Ethernet address, meaning that thisblock includes addresses in the range 00:00:5e:00:00:00through 00:00:5e:ff:ff:ff. The IANAallocates half of this block for multicast addresses. Given thatthe first byte of any Ethernet address must be 01to specify a multicast address, this means the Ethernet addressescorresponding to IP multicasting are in the range 01:00:5e:00:00:00through 01:00:5e:7f:ff:ff.

Our notation here uses the Internet standard bitorder, for a CSMA/CD or token bus network, as the bits appearin memory. This is what most programmers and system administratorsdeal with. The IEEE documentation uses the transmission orderof the bits. The Assigned Numbers RFC gives additional detailson the differences between these representations.

This allocation allows for 23 bits in the Ethernetaddress to correspond to the IP multicast group ID. The mappingplaces the low-order 23 bits of the multicast group ID into these23 bits of the Ethernet address. This is shown in Figure 12.3.

Since the upper 5 bits of the multicast group IDare ignored in this mapping, it is not unique. Thirty-two differentmulticast group IDs map to each Ethernet address. For example,the multicast addresses 224.128.64.32 (hex e0.80.40.20)and 224.0.64.32 (hex e0.00 40.20)both map into the Ethernet address 01:00:5e:00:40:20.

Since the mapping is not unique, it implies thatthe device driver or the IP module in Figure 12.1 must performfiltering, since the interface card may receive multicast framesin which the host is really not interested. Also, if the interfacecard doesn't

Chapter 12. Broadcasting and Multicasting (3)

Figure 12.3 Mappingof a class D IP address into Ethernet multicast address.

provide adequate filtering of multicast frames, thedevice driver may have to receive all multicast frames, and performthe filtering itself.

LAN interface cards tend to come in two varieties.One type performs multicast filtering based on the hash valueof the multicast hardware address, which means some unwanted framescan always get through. The other type has a small, fixed numberof multicast addresses to listen for, meaning that when the hostneeds to receive more multicast addresses than are supported,the interface must be put into a "multicast promiscuous"mode. Hence, both types of interfaces still require that the devicedriver perform checking that the received frame is really wanted.

Even if the interface performs perfect multicastfiltering (based on the 48-bit hardware address), since the mappingfrom a class D IP address to a 48-bit hardware address is notone-to-one, filtering is still required.

Despite this imperfect address mapping and hardwarefiltering, multicasting is still better than broadcasting.

Multicasting on a single physical network is simple.The sending process specifies a destination IP address that isa multicast address, the device driver converts this to the correspondingEthernet address, and sends it. The receiving processes must notifytheir IP layers that they want to receive datagrams destined fora given multicast address, and the device driver must somehowenable reception of these multicast frames. This is called "joininga multicast group." (The reason we use the plural "receivingprocesses" is because there are normally multiple receiversfor a given multicast message, either on the same host or on multiplehosts, which is why we're using multicasting in the first place.)When a multicast datagram is received by a host, it must delivera copy to all the processes that belong to that multicast group.This is different from UDP where a single process receives anincoming unicast UDP datagram. With multicasting it is possiblefor multiple processes on a given host to belong to the same multicastgroup.

But complications arise when we extend multicastingbeyond a single physical network and pass multicast packets throughrouters. A protocol is needed for multicast routers to know ifany hosts on a given physical network belong to a given multicastgroup. This protocol is called the Internet Group ManagementProtocol (IGMP) and is the topic of the next chapter.

Multicasting on FDDI and Token Ring Networks

FDDI networks use the same mapping between the classD IP address and the 48-bit FDDI address [Katz 1990]. Token ringnetworks normally use a different mapping, because of limitationsin most token ring controllers [Pusateri 1993].

12.5 Summary

Broadcasting is sending a packet to all hostson a network (usually a locally attached network) and multicastingis sending a packet to a set of hosts on a network. Basicto these two concepts is an understanding of the different typesof filtering that occur when a received frame passes up a protocolstack. Each layer can discard a received packet for differentreasons.

There are four types of broadcast addresses: limited,net-directed, subnet-directed, and all-subnets-directed. The mostcommon is subnet-directed. The limited broadcast address is normallyseen only when a system is bootstrapping.

Problems occur when trying to broadcast through routers,often because the router may not know the subnet mask of the destinationnetwork. The results depend on many factors: which type of broadcastaddress, configuration parameters, and so on.

A class D IP address is called a multicast groupaddress. It is converted to an Ethernet address by placing itslower 23 bits into a fixed Ethernet address. The mapping is notunique, requiring additional filtering by one of the protocolmodules.

Exercises

12.1 Does broadcastingincrease the amount of network traffic?

12.2 Consider 50 hostson an Ethernet: 20 running TCP/IP and 30 running some other protocolsuite. How are broadcasts from one protocol suite handled by hostsrunning the other protocol suite?

12.3 You login to a Unixsystem that you've never used before and want to find the subnet-directedbroadcast address for all attached interfaces that support broadcasting.How can you do this?

12.4 If we pingthe broadcast address with a large packet size, as in

sun % ping 140.252.13.63 1472 PING 140.252.13.63; 1472 data bytes 1480 bytes from sun (140.252.13.33): icmp_seq=0. time=6. ms 1480 bytes from svr4 (140.252.13.34): icmp_seq=0. time=84. ms 1480 bytes from bsdi (140.252.13.35): icmp_seq=0. time=128. ms

it works, but increasing the packet size by 1 bytegives us the following error:

sun % ping 140.252.13.63 1473 PING 140.252.13.63: 1473 data bytes sendto: Message too long

What's going on?

12.5 Redo Exercise 10.6assuming the eight RIP messages are multicast instead of broadcast(assume RIP Version 2 is being used). What changes?