IP Multicast - Addressing (Part 2)

As promised, here is the second article on IP Multicast. This one specifically cover the addressing, which evolved in parallel to the high number of standards that define what multicast is today. I tried to compile a list that is as comprehensive as possible; if you find something that I omitted, please let me know, I will be glad to update this article accordingly. I hope this article will help you to quickly and efficiently review all or specific part of the multicast addressing.

Content Update(s)

2015-04-15:  The IPv6 multicast to Ethernet MAC address mapping section has been updated in order to equally cover IPv4 and IPv6 multicast technologies.

IPv4 Host Group Addresses

Figure 1 - IPv4 Multicast Address Format
IPv4 Multicast Address Format

The Internet Assigned Numbers Authority (IANA) is the organization responsible for managing DNS root nameservers and for allocating parameters values for fields in protocols defined by the IETF RFCs, such as ICMP type codes. The IANA is also responsible for managing and delegating IPv4 and IPv6 addresses to Regional Internet Registries (RIRs).

The IANA reserved the Class D IP addresses for multicast, in other words, all addresses whose the high-order four bits are 1110. By converting these four bits in decimal, you get a value of 224, therefore all IPv4 addresses who falls within the 224/4 or to range are considered multicast host group addresses.

Unlike the unicast addresses assignments were block of addresses are delegated to RIRs, the multicast addresses are assigned directly by the IANA. The IANA also define several multicast addresses ranges:

IPv4 Multicast Address Ranges
Dotted Decimal Range CIDR Range Description - 224.0.0/24 Local Network Control Block - 224.0.1/24 Internetwork Control Block - AD-HOC Block - 224.1/16 Reserved - 224.2/16 SDP/SAP Block - 224.3/16, 224.4/16 AD-HOC Block II - RFC5771 - RFC5771 - 232/8 Source-Specific Multicast (SSM) Block - 233/8 GLOP Block - 233.252/14 AD-HOC Block III - 234/8 Unicast-Prefix-based IPv4 Multicast Addresses - 239/8 Administratively Scoped Block

Here, the most important ranges worth noting are:

Local Network Control Block
This block of multicast address from to is reserved for network control applications and his scope is link-local only. This range is typically used by dynamic routing protocols like OSPF and RIP, but equally by multicast routing protocols like DMVRP and PIM. All packets whose destination addresses falls within this block must not be forwarded. To prevent routers forwarding them, the Time-to-Live (TTL) header field of packets is set to value of 1. In this range, two particular multicast group addresses are worth mentioning:
  • - All systems on this subnet (including routers)
  • - All routers on this subnet
Internetwork Control Block
Very similar to the Local Network Control Block above, all multicast group addresses that falls within the to range must be used for protocol control traffic. However, unlike the former block, these group addresses can be forwarded through routers. An example of a protocol using this multicast address range is the Network Time Protocol (NTP), who use the multicast group address. NTP clients listen to this multicast group address to discover NTP servers and later use them to synchronize their clock.
RFC5741 Reserved Block
This block is certainly one of the most important block to remember. The IANA delegated the two ranges to, and to to the IETF and in particular to RFC 5741. All multicast addresses falling within this range are subject to the standards defined in the RFC document. Most of these standards and associated ranges are already defined in this article, therefore if your multicast application doesn't fall within any of these blocks, you can safely use the two ranges defined above. You will, in this way avoid using the wrong block and it may save you precious troubleshooting time.
Source-Specific Multicast (SSM) Block
This block is exclusively available to SSM applications, where multicast traffic is forwarded only to receivers from only those multicast sources for which the receivers have expressed interest. The inherent benefit of this group is to allow the reuse of multicast group addresses for several applications. The main drawback is the additional states the network must maintain to forward traffic to these groups. In fact, multicast routers must maintain states for each source and group pairs (S,G) signalled and/or forwarded on your network.
GLOP Block (RFC3080)
The multicast group addresses in the to range are statically-assigned from a two-bytes Autonomous System Number (ASN) and are of global scope. This yields 256 globally unique multicast addresses per autonomous system. Unfortunately, GLOP addresses cannot work with 4-bytes ASN. To calculate the multicast group addresses for your ASN, you can proceed as follow:
  1. convert the 16-bits AS number to hexadecimal format (e,g. AS3306 becomes 0xCEA).
  2. place the result in the middle two octets of the IPv4 multicast group address (e,g. 233.0C.EA.0/24).
  3. finally covert them back to decimal format (e,g.
Unicast-Prefix-based IPv4 Multicast Address Block (RFC6034)
This block provides a range of multicast group addresses to every organizations that has a global unicast address space. Taking the example of an organization that has been assigned the global unicast address space, that organization can use the multicast group address for its sole and exclusive use, without having to coordinate with any others parties. This allocation scheme is way more efficient than GLOP addressing, and allows organizations with 4-bytes ASN to get their own multicast group address.
Administratively Scoped Block (RFC2365)
Multicast group addresses that falls within the to range can be given organization-specific administrative scopes. In other words, within an autonomous system or organization, an administrator can define the forwarding scope of the multicast packets, so traffic can be confined to a particular area or region of the network. This can be done for security, resource conservation or for any others administrative purposes. Routers are configured so the administrative scopes are defined at the interface-level, and when configured this way, they are called 'Boundary Routers'. Traditionally, scoping was achieved using the Time-to-Live (TTL) header fields of the multicast packets, unfortunately this method is very limited due to the nature of today's networks and is prone to errors. Within this block, two additional sub-blocks are defined, namely:
  • - IPv4 Local Scope
  • - IPv4 Organization Local Scope

IPv6 Host Group Addresses

The IPv6 multicast operation is very similar to the IPv4 counterpart. Similarly to IPv4, IPv6 multicast group addresses are directly delegated by the IANA, however, the multicast address format is a bit more evolved. Section 4.7 of RFC 4291 defines multicast addresses as so:

An IPv6 multicast address is an identifier for a group of interfaces (typically on different nodes). An interface may belong to any number of multicast groups.

RFC 4291 - IP Version 6 Addressing Architecture

As we can read, this definition is pretty close to what we already know from IPv4, excepted the word 'interface' here is frequently used. This is because in IPv6, all types of addresses are assigned to interfaces, not nodes. A node can have one or multiple interfaces, and any of that node interfaces' unicast addresses may be used. It's an important fact to remember, because it is often a source of confusion to people new to IPv6.

IPv6 multicast addresses have the following format:

Figure 2 - IPv6 Multicast Address Format
IPv6 Multicast Address Format

As you can see, multicast addresses can be easily distinguished from unicast because the first byte is set to binary 11111111 or hexadecimal 0xFF. Following is a 4 bits flags header field used to indicates the type the multicast address belongs to and its properties.

Figure 3 - IPv6 Multicast Address - Flag Header Field Format
IPv6 Multicast Address - Flag Header Field Format

Following the flags field, the scope header field is a 4 bits long header field used to indicates the scope of the multicast group. This field can have the following values:

IPv6 Multicast Addresses Scopes
Field Value (hex) Definition / Meaning
0 Reserved
1 Interface-Local scope
2 Link-Local scope
3 Reserved
4 Admin-Local scope
5 Site-Local scope
8 Organization-Local scope
E Global scope
F Reserved
Interface-local scope
This scope spans only a single interface and is used for loopback transmission of multicast traffic. An example of application is interprocess communication within a node.
Link-Local scope
This scope is intended for transmission of multicast traffic to the link-local segment only. Traffic spans the exact same region as the corresponding unicast address scope of the same name. A very good candidate for this scope is a dynamic routing protocol traffic. By example, OSPFv3 is using the multicast groups addresses 'ff02::5' and 'ff02::6' respectively to send OSPF LSAs to non-designated and designated routers (DR). In the link-local scope range, two notable addresses are worth mentioning:
  • ff02::1 - All nodes on the local network segment.
  • ff02::2 - All routers on the local network segment.
Admin-Local scope
This scope is the smallest scope that must be administratively configured, that is, not automatically derived from physical connectivity or other, non-multicast related configuration.
Site-Local scope
This scope is intended to span a single site. It is up to the administrator to define the boundary of a site; this is usually defined at the interface-level of a router.
Organization-Local scope
This scope is intended to span multiples sites, all belonging to a single organization. This scope is the IPv6 equivalent of the 'IPv4 Organization Local Scope' or range.
Global scope
As the name implies, the global scope is used to send multicast traffic across networks belonging to different organizations or autonomous systems. At this time of writing, there is no widespread deployment of a global IPv6 multicast internet, however, some Internet Service Providers (ISPs) and National Research and Education Networks (NRENs) are already exchanging national and regional multicast traffic over IPv6.

Finally, the Group ID header field identifies the multicast group. This header field is 112 bits long, therefore there should be plenty of address space for all your multicast needs. This addressing space has been further used to enable new multicast features like Embedded-RP.

Ethernet MAC-Layer Multicast

Prior to sending unicast traffic, a host must know the MAC address of the destination host. The latter address identifies a single host and must be unique on the Ethernet segment. To discover and learn the destination addresses, Ethernet hosts sends Address Resolution Protocol (ARP) requests, or use the Neighbour Discovery (ND) process in IPv6 networks.

For IP multicast, the delivery mechanism is significantly different. The multicast group address at the network-layer is mapped to the destination MAC address at the data-link layer. Multicast receivers always listens for the multicast traffic on the mapped destination MAC address by programming their Network Interface Card (NIC) or by running in promiscuous mode. When a switch receive a Ethernet frame with the broadcast/multicast bit set to 1, it forward that frame out all ports, excepted out the port the frame came in.

Figure 4 - IPv4 Address To Ethernet MAC Address Mapping
IPv4 Address To Ethernet MAC Address Mapping

In IPv4 networks, the lower 23 bits of the multicast group address are mapped to a MAC address whose the Organizationally Unique Identifier (OUI) is 01:00:5e. This OUI is actually registered and owned by the IANA, as are the allocation of Class D IP addresses. Here, only 23 bits over the 28 bits of the Group ID header field is effectively copied to the Ethernet destination MAC address, which results in a 32:1 ratio. This ratio means that for 32 multicast groups addresses, only a single unique destination MAC address does exists. If two hosts subscribe for different multicast groups whose address only differs in the first 5 bits, they will both receive the multicast traffic of these groups. This overlap may results in sub-optimal use of resources like bandwidth and CPU cycles, therefore, you may want to ensure your applications' multicast groups don't overlap at the data-link layer.

In IPv6 networks, the right-most 4 octets of the multicast group address are copied to the destination MAC address 33:33:00:00:00:00. The example below shows a IPv6 multicast to Ethernet MAC addressing mapping for a solicited-node multicast group address of FF02::1:FFB3:E650.

Figure 5 - IPv6 Multicast To Ethernet MAC Address Mapping
IPv6 Multicast To Ethernet MAC Address Mapping

As for IPv4, you may want to avoid mapping the multicast applications' group addresses to the same destination Ethernet MAC address. To ensure the multicast group addresses don't overlap at the data-link layer, use host group addresses whose the last 4 octets are of different values.

This conclude the second part of my multicast articles. I do hope I will get more time in the future to write a third, if not a fourth part, which will respectively cover the operation, implementation and troubleshooting of IP multicast.

About the author Nicolas Chabbey

Nicolas Chabbey is a Network Engineer certified with Cisco Systems and Juniper Networks. He has begun his career in 2003, and has designed, implemented and maintained networks for enterprises and service providers. When he is not behind a computer, he is riding his mountain bike across the Swiss alps.

Previous Home Next


blog comments powered by Disqus