Using Multicast Addressing

Just as with mailing lists, there are several different groups that users or applications can subscribe to. The range of multicast addresses starts with 224.0.0.0 and goes through 239.255.255.255. As you can see, this range of addresses falls within IP Class D address space based on classful IP assignment. This is denoted by the first four bits in the first octet being set to 1110. Just as with regular IP addresses, there are some addresses that can be assigned and there are ranges of reserved addresses.

It is important to recognize that the reserved addresses are categorized. Table 8.1 depicts some of the reserved addresses and their corresponding categories. For a full listing of these assignments, you can go to www.iana.org/assignments/multicast-addresses.

Table 8.1: IP Multicast Reserved Addresses

Address	Purpose	Reserved Category
224.0.0.0-224.0.0.18	Use by network protocols	Local-link
224.0.0.1	All hosts	Local-link
224.0.0.2	All routers	Local-link
224.0.0.19-224.0.0.255	Unassigned	Local-link
224.0.1.0-224.0.1.255	Multicast applications	Misc. applications
224.0.1.1	NTP	Misc. applications
224.0.1.8	NIS+	Misc. applications
224.0.1.39	Cisco-RP-Announce	Misc. applications
224.0.1.40	Cisco-RP-Discovery	Misc. applications
224.0.1.80-224.0.1.255	Unassigned	Misc. applications
224.0.0.10	EIGRP	Local-link
239.0.0.0-239.255.255.255	Private multicast domain	Administratively scoped

Each address range is managed by the Internet Address Number Authority (IANA). Due to the limited number of multicast addresses, there are very strict requirements for new assignments within this address space. The 239.0.0.0-239.255.255.255 range is equivalent in purpose to the private networks defined by RFC 1918.

The difference between the IP multicast ranges of 224.0.0.0-224.0.0.255 and 224.0.1.0- 224.0.1.255 is that addresses in the first range will not be forwarded by an IP router. Both ranges of addresses are used by applications and network protocols. The first group, classified as local- link, is meant to remain local to the subnet or broadcast domain on which the system resides. The second group is a global address that can be routed and forwarded across multiple IP routers.

Mapping IP Multicast to Ethernet

Multicast addressing began on MAC addresses. Growth needs required that there be a way to use multicast across routers instead of limiting it to the physical segment where hosts were located. In regular unicast, MAC addresses are layer 2 addresses, and in order for the local host to reach remote hosts, layer 3 logical IP addresses are used to route data to the destination. After the packet reaches the remote subnet, the ARP is used to find the MAC address of the host. By using an existing ARP table, or via an ARP request, the MAC address that is associated to the layer 3 IP address is found and the packet is forwarded to the destination host.

IP multicast generates a MAC address based on the layer 3 IP multicast address. The MAC frame has a standard prefix of 24 bits. This prefix, 01-00-5e, is used for all Ethernet multicast addresses. This leaves another 24 bits for use in creating the multicast MAC address. When the MAC address is generated, the 25th bit (or high order bit) is set to 0 and then the last 23 bits of the IP address are mapped to the remaining 23 bits of the MAC address. Figure 8.4 depicts how this looks.

Figure 8.4: IP multicast mapped to MAC multicast

Note 

MAC addresses are made up of two sets of addresses, each with 24 bits. The first set is an address reserved for a particular manufacturer. The second set identifies a particular device by that manufacturer. This is why Cisco devices always seem to have one of a small number of 'first halves.' Multicast MAC addresses use 01-00-5E for the vendor code, with the device code based on the IP address.

Let's look at some examples of mapping layer 3 multicast addresses to layer 2 multicast addresses. A local IP multicast address is 224.0.0.1. Refer to Figure 8.5 to see how this is mapped. The conversion from binary to hexadecimal reveals the MAC multicast address. The prefix was 01-00-5e. The last 23 bits, including the high order bit, give you 00-00-01. Put them together and you get 01-00-5e-00-00-01 as the MAC address.

Figure 8.5: Example 1 for mapping IP multicast to MAC multicast addresses

Now let's try one a little bit harder. Suppose, for example, you have the IP multicast address of 225.1.25.2 (follow along in Figure 8.6). Part of the 225 octet falls within the Class D mask. However, there is one bit that is not masked. By looking carefully at the location of the bit, you see that it is part of five lost bits and is not mapped to the layer 2 MAC multicast address.

Figure 8.6: Example 2 for mapping IP multicast to MAC multicast addresses

Convert the octets from decimal into binary so you can get a clear picture of what the last 23 bits are. Here you would see the following address (the last 23 bits are indicated in bold font): 11100001.00000001.00011001.00000010. Also, as you can see, Figure 8.6 depicts the last 23 bits that are mapped to the free spaces of the multicast MAC address. After the mapping has occurred in binary, convert the binary value to hex and you have the new MAC multicast address.

After you do the math and map the last 23 bits, the MAC address becomes 01-00-5e-01-19- 02. The easiest way to map layer 3 to layer 2 manually is to do the math and make the binary conversion so you can see what the last 23 bits of the layer 3 IP address are. After you have that number, all you have to do is insert it into the MAC address and then calculate the remaining 3 hex octet values. The first three octets is always the same, 01-00-5e.

It is important that you spend time studying this procedure and the steps needed to convert a layer 3 IP multicast address to a layer 2 MAC multicast address.

There is one last method of determining the last 23 bits, but this method works only on some addresses. Keep in mind that the highest value you can get in the second octet is 127 and still have it be included in the 23 bits that will map to the MAC address. You know that the last two octets (3 and 4) will map no matter what. So you have 7 bits from the second octet, and 16 bits from the last two octets, for a total of 23 bits. After your value goes above 127 in the second octet, you have to break down the octet into binary so you can see the values of the first seven fields.

Layer 3 to Layer 2 Overlap

By the time you've done a few of these conversions, you'll notice that there is a problem with this conversion scheme. By not using all available bits for a Class D address, you can not get an accurate map of layer 3 to layer 2 addresses. If you look at properties of a Class D address, you will see that the high order bit lies in the first octet and is in the 16's value position. This leaves 28 bits for host specification. However, by using only 23 bits of the layer 3 IP address, you leave five bits out of the mapping. This causes an overlap of 2⁵, or 32 layer-3 addresses for every one layer-2 address. With a ratio of 32:1, you can expect to see a significant amount of address ambiguity. It is safe to say that any IP addresses that have the same values in the last 23 bits will map to the same MAC multicast address.

For example, 224.0.1.1 and 225.128.1.1 map to the same MAC address. Figure 8.7 shows why this is true. You can see that the bits that differ between 224.0.1.1 and 225.128.1.1 are all within the lost five bits. The last 23 bits are equivalent.

Figure 8.7: Multicast addressing overlap

The impact of this overlap can be significant. The overlap creates a window for multiple multicast groups' data to be forwarded to and processed by machines that didn't intentionally subscribe to the multiple groups. To give another example, a machine that subscribes to multicast group 224.2.127.254 would be given a MAC address of 01-00-5e-02-7f-fe. This host also processes packets that come from multicast group 225.2.127.254 because the layer 2 MAC address is identical.

The problem this creates is that the end host must now process packets from both multicast groups even though it is interested only in data from 224.2.127.254. This causes unwanted overhead and processor interrupts on the host machine.