IP and MAC Addressing
In this article we will go over the basics of multicast IP and MAC addressing.
In summary, multicast IPs are taken from the 224.0.0.0/4 range. Each IP represents a multicast group. 239.0.0.0/8 is the “private” administratively scoped range.
Multicast MAC addresses are in the range 0100.5e00.0000 through 0100.5e7f.ffff. The last 23 bits of the multicast IP address are mapped to the MAC address.
Multicast IP Addresses
The entire Class D space (224.0.0.0/4) was reserved for multicast. It is important to note that while we will group multicast ranges into subnet notation, multicast has no notion of subnets. You cannot summarize/aggregate multicast addresses like you do with unicast routing. If you see multicast address space represented in CIDR notation, it is simply to group the IPs together.
Each multicast address is really a group identifier. In a way, a multicast IP is similar to a radio station frequency. When you want to listen to 101.1FM, you turn your radio to this channel. Your radio then listens for “multicast traffic” destined for 101.1 and plays it. In this scenario, an IP address such as 239.1.101.1 is like the FM channel 101.1. A multicast IP simply represents a group, in which all interested receivers “tune” to this group. The equivalent of “tuning a radio” on a host would be to program the NIC to listen for traffic destined to a multicast group IP, for example 239.1.101.1.
Multicast addresses have been assigned in the following major groups:
Link-local (224.0.0.0/24)
Network protocol/application (224.0.1.0/24)
Source Specified Multicast (232.0.0.0/8)
Administratively scoped (239.0.0.0/8)
Link-local (224.0.0.0/24)
IP addresses in this range are assigned to network protocols that only operate on a network segment. Router software is programmed to not forward traffic in the 224.0.0.0/24 range out any link besides the link where it is generated. Usually as an extra precaution, network protocol traffic has a TTL set to 1 to further ensure it is never forwarded past the local link.
You will likely recognize some of the protocols that have been assigned a multicast IP address in this range:
Protocol/Usage | IP address |
All Hosts | 224.0.0.1 |
All Multicast Routers | 224.0.0.2 |
All OSPF Routers | 224.0.0.5 |
OSPF DR Routers | 224.0.0.6 |
EIGRP Routers | 224.0.0.10 |
VRRP | 24.0.0.18 |
This should intuitively make sense from your understanding of these routing protocols. OSPF Hellos do not propagate beyond the link where they are generated.
Network protocols/applications (224.0.1.0/24)
These applications use a multicast address in the 224.0.1.0/24 range and can be forwarded beyond the local link. You don’t see these too much in the real world, but some common protocols are NTP (224.0.1.1), Cisco-RP-Announce (224.0.1.39) and Cisco-RP-Discovery (224.0.1.40). We will explore the last two protocols later in this series.
Source-Specific Multicast (232.0.0.0/8)
This is a range reserved for SSM (Source-Specific Multicast). In SSM, a receiver knows which source it wants to receive multicast traffic from. We will explore this topic in a future article.
GLOP (233.0.0.0/8)
This was an experimental range, which as far as I understand, was not actually put to use. The idea is that an AS could use their 16 bit ASN as the second and third octects to achieve their own /24 group of publically unique multicast group addresses. For example, ASN 32283 would be able to use 233.126.27.0/24. (The easiest way to do this is convert the ASN to hex, which will produce four hex digits. Convert each of the two hex digits back to decimal.)
The problem with this was that it did not support 32 bit ASNs. With only 256 multicast address groups available, it also was not enough for large scale providers.
Administratively scoped range (239.0.0.0/8)
This is analagous to RFC1918 unicast addresses but for multicast addresses. You are free to use any IP address in this range as long as the traffic is bound to your local domain. In our labs we will frequently use multicast addresses from this range. It is similar to using RFC1918 unicast addresses.
Multicast MAC Addresses
Multicast IPs must be mapped to a MAC address. But no single host “owns” the IP and can respond an ARP request. Also, multicast is not broadcast so it can’t use a MAC of FFFF.FFFF.FFFF, as only hosts interested in the traffic on the LAN should receive and process the multicast traffic. So how do we map multicast IPs to MAC addresses?
The solution was to define a 25-bit multicast MAC address prefix of 0100.5eXX.XXXX. The 7th hex digit can be in the range 0-7. So the usable MAC addresses for multicast are 0100.5E00.0000 through 0100.5e7f.ffff
A MAC address is 48 bits in length. 48-25 = 23 bits which are available for mapping a multicast IP address onto a multicast MAC address. The problem is that there are 28 bits that can uniquely identify a multicast IP address. The multicast IP address range is 224.0.0.0/4, so 32 bits - 4 bits = 28 bits that need to map onto 23 bits available in the MAC address.
The last 23 bits of the multicast IP address are mapped onto the MAC address. This leaves 5 bits unmapped, so there are 32 (2^5) multicast IP addresses that have the same corresponding MAC address.
Some examples will help explain this. Let’s look at the mapping of the multicast address 239.101.1.23 to the MAC 0100.5e65.0117
You can visually see how the 5 lost bits, no matter their value, always result in the same multicast MAC address. This is why there are 2^5 possible multicast IPs that map to the same multicast MAC address.
For fun take a look at this calculator: http://www.dqnetworks.ie/toolsinfo.d/multicastaddressing.html
It shows you all the possible multicast IPs that map to the given MAC address:
Is this mapping ambiguity an issue?
In the real world, you are unlikely to see this mapping ambiguity as an issue. Let’s say a host is subscribing to 239.101.1.23. The danger is that they could receive traffic for the 31 other multicast IPs that share the MAC address. However, even if the host receives multicast traffic for 233.101.1.23 for example, it will simply drop it. The only negative is the fact that the host processes the packet enough to parse the IP header and notice that it is not interested in the traffic. Other non-ambiguous multicast traffic is dropped one step earlier, because the NIC is not listening to frames with the destination MAC address.
A quick note on the broadcast/multicast bit
Notice that the MAC address 0100.5exx.xxxx contains a 1 in the 8th bit. (This is the 1 in 0100.5exx.xxxx).
This bit signifies that the frame is either broadcast or multicast. A unicast MAC address cannot have a 1 here, it must be set to 0. This bit allows a switch to easily differentiate a unicast frame from broadcast/multicast. If a switch is not preforming multicast snooping, it actually treats the multicast frame as broadcast, forwarding it out all ports in the VLAN.
Last updated
