Background
In the past, versions 1.0 through 1.2 of Apple's EtherTalk software have caused excessive broadcast traffic when used on a large number of Macintoshes on an Ethernet network. Apple has fixed this problem with the EtherTalk 2.0 version of the software by using multicast addressing.
Ethernet Broadcast Traffic
All nodes on an Ethernet local area network listen to broadcast packets that are addressed to the general-purpose broadcast address FF-FF-FF-FF-FF-FF. EtherTalk 1.0 used this address for all AppleTalk name lookups, Routing Table Maintenance Protocol traffic between routers, and other types of AppleTalk broadcast packets. Large sites like universities and research labs found this to be a problem, because all of their non-Apple hardware had to accept Apple's packets, read them, then discard them. This translated into lost machine cycles on VAXs, Suns, and so on. In some extreme cases, Sun diskless workstations can crash if they're booting and take a broadcast packet at the wrong time.
Ethernet Multicast Addressing
Ethernet addresses actually have two parts. The first 24 bits (written as xx-xx-xx) are a vendor code. Apple's codes are 08-00-07, 00:05:02, and 00:A0:40. The second 24 bits designate a unique machine with that vendor code. If a certain bit in the first byte of the vendor code is turned on, the address is said to be a "multicast address" and ALL Ethernet interface boards with that vendor code will receive the packet. (Apple's multicast vendor code is 09-00-07).
An Ethernet interface board can be programmed to accept only packets with certain multicast addresses. These are the only packets which are passed to the higher level protocols; the hardware rejects all others. This results in a significant efficiency, because it means that the Ethernet interface board will only interrupt the main CPU when "useful" packets are received.
EtherTalk 2.0
EtherTalk 2.0 no longer sends all AppleTalk broadcasts to the general-purpose Ethernet broadcast address. When EtherTalk 2.0 needs to send a packet to all EtherTalk 2.0 nodes, it sends to the multicast address 09-00-07-FF-FF-FF. All EtherTalk 2.0 nodes are registered to receive these packets.
In addition, EtherTalk 2.0 uses a range of other multicast addresses for its Name Binding Protocol (NBP) lookups. This range includes 09-00-07-00-00-00 through 09-00-07-00-00-FC. If there is a service (like a print spooler, or even Responder) registered on a Macintosh, the Macintosh will listen to NBP packets addressed to an address in the NBP multicast range. The Macintosh's zone name determines which address the Macintosh listens to. For example, if a file server is in zone "foo", it might expect file server client software to send lookup requests to the multicast address 09-00-07-00-00-27.
The Ethernet hardware does not pass lookups for a different zone (different multicast address) onto the EtherTalk software. A file server in a different zone would receive lookup requests to a different multicast address.
(Actually, there isn't an exact one-to-one mapping between zone names and multicast addresses. The Zone Information Protocol on routers assigns multicast addresses to zones, but because of the hash function used, there may sometimes be more than one zone assigned to one multicast address, but this is not likely.)
The important thing to understand is that in almost all cases, nodes are no longer disturbed by broadcast traffic that has no relevance to them. This leaves the CPU available for more important tasks.
Improvements for Multi-Vendor Environments
As discussed above, multicast addressing reduces the amount of processing that Macintoshes need to do because NBP lookups are sent to multicast addresses instead of to the general-purpose Ethernet address. However, the biggest improvement that EtherTalk 2.0 offers is that non-AppleTalk nodes are no longer disturbed by general-purpose Ethernet broadcasts generated by AppleTalk devices. When Macintoshes only run EtherTalk 2.0, they no longer send general-purpose Ethernet broadcasts.
Non-AppleTalk nodes, (i.e. Suns, VAXs, and so on) do not register to receive packets sent to Apple's multicast address 09-00-07-FF-FF-FF or Apple's NBP range of multicast addresses, 09-00-07-00-00-00 through 09-00-07-00-00-FC. Non-AppleTalk nodes no longer need to spend machine cycles reading Apple-specific Ethernet broadcasts only to learn that they didn't need to. Many large customers, especially university, government, and Fortune 500 business accounts have become more amenable to placing Macintoshes on their Ethernet networks.
Note: TokenTalk 2.0 also uses multicast addressing. The concept is the same: non-AppleTalk nodes on the Token Ring will not be disturbed by Apple-specific broadcasts. The exact implementation of Token-Ring, multicast addressing is different than the Ethernet implemenation.