Garmin International, Inc.

1200 E. 151st St. Olathe KS 66062-3426 United States of America nate.karstens@gmail.com

lispers.net

San Jose CA United States of America farinacci@gmail.com

Futurewei

United States of America michael.mcbride@futurewei.com

RTG pim snooping peer-to-peer collision decentralized dynamic zero-configuration This document surveys current problems with existing protocols for automatically assigning multicast IP addresses in zero-configuration (zeroconf) networking environments. It addresses key challenges, such as link-layer address collisions, hardware limitations, multicast snooping inefficiencies, and the need to avoid manual configuration. Based on these challenges, it derives requirements for a lightweight, decentralized solution for dynamically allocating unique multicast group addresses without central coordination. The document presents explicit requirements covering discovery, allocation, conflict detection and resolution, and lease management. It also evaluates considerations specific to IPv6 and IPv4 multicast address ranges, and identifies approaches that are unsuited for zeroconf deployment. This foundation serves as a reference for developing future solutions for multicast address allocation that operate autonomously within local networks.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
  • .  Requirements Language
• .  Link-Layer Address Collisions
• .  Solution Requirements
• .  IPv6 Considerations
• .  IPv4 Considerations
• .  Security Considerations
• .  IANA Considerations
• .  References
  • .  Normative References
  • .  Informative References
• .  Excluded Solutions
• Acknowledgement
• Authors' Addresses

Introduction Multicast communication is commonly used in networks that need to distribute data from one sender to multiple receivers efficiently. In some environments, such as small or isolated networks, multicast operate without centralized servers or manual configuration. These are referred to as zero-configuration (zeroconf) multicast networks. One example of such an environment is marine networks, which typically include a mix of sensors, controls, and displays. These networks vary in complexity depending on the size and design of the vessel. Devices may range from low-cost temperature or fluid sensors to high-bandwidth sources such as radar, sonar, or video feeds. Many marine networks are built on a single subnet and rely on Layer 2 Ethernet switches to connect devices. In these networks, multicast is the most efficient method for distributing sensor data to multiple displays. However, challenges arise when high-bandwidth multicast streams overload links to low-bandwidth devices. Cost-effective switches often do not support source-specific multicast (SSM) because their address table only maps destination Media Access Control (MAC) addresses. Instead, each multicast stream is assigned a unique destination multicast IP address, and IGMP/MLD snooping is used to control multicast delivery. This method introduces limitations, especially in environments where switch hardware lacks advanced multicast filtering capabilities. While marine networks illustrate these issues well, the challenges they face are not unique. Many other zeroconf multicast environments, such as industrial automation, small-scale audio-visual (AV) systems, or ad hoc sensor networks, share similar constraints. The Multicast Address Dynamic Client Allocation Protocol (MADCAP) is a method for multicast IP address allocation, but its server-based model does not suit a zeroconf environment. and both discuss similar approaches to host-based multicast IPv6 address allocation, but neither adequately prevents link-layer address collisions. Although establishes a framework to avoid multicast address collisions at both IPv6 and link layers, additional refinement is needed to put this into practice (see ). This document outlines the problem space for zeroconf multicast address allocation, describes the key limitations of current protocols, details sources of link-layer address collisions, and defines a set of requirements for decentralized, zero-configuration multicast address allocation solutions. Multicast applications deployed in a zeroconf environment can use these solutions to dynamically allocate multicast group addresses. The manner in which a multicast group address is used after allocation is outside the scope of this document. The organization of IPv6 multicast and immense volume of possible multicast addresses makes IPv6 well-suited for zeroconf multicast networks. However, IPv4 is still considered by this document for networks where transitioning to IPv6 remains impractical.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The requirements language is used in and applies to implementations conformant to the listed requirements.

Link-Layer Address Collisions Link-layer address collisions are a key concern in multicast networks, particularly when devices rely on zero-configuration operation. Collisions occur when two or more multicast groups are assigned the same link-layer (MAC) address, leading to performance or forwarding issues. This section outlines three scenarios where such collisions can cause problems. First, many host network interfaces allow filtering of multicast traffic directly in hardware. When an application joins a multicast group, the host network stack typically programs the hardware to accept only traffic for that group. However, if two groups share the same link-layer address, the network interface cannot distinguish them. The network stack is then forced to process unwanted traffic in software, reducing performance and increasing CPU usage. Second, link-layer address collisions reduce the benefit of using multicast snooping switches on a network. indicates some switches forward multicast traffic based solely on the link-layer address, without considering the network-layer group (see the results for Q2 and Q3). Although the survey is outdated, switches with these limitations still exist in some of the target deployments. In such cases, if two multicast streams share the same MAC address, traffic may be sent to devices that did not request it. This is especially problematic when low-bandwidth links are overwhelmed by high-bandwidth streams. Additional concerns related to the overlap of IPv6 and link-layer addresses are discussed in . Third, the internal design of some switches can also contribute to collisions. For example, certain switch implementations use a hash table with fixed buckets to store forwarding entries based on MAC addresses (see ). If multiple addresses hash to the same location and the bucket fills up, additional entries may be dropped or rejected, resulting in forwarding failures. These examples highlight why a collision-resistant multicast address allocation mechanism is essential in zeroconf environments. The success of this approach depends on the capabilities of the hardware (such as the number of addresses supported by the filters in host network interfaces and the size of the tables maintained in switches/routers) and on the number of multicast groups that are subscribed to by a particular receiver. When the number of entries in the filter tables exceeds availability, a typical fallback mechanism is to bypass the filter entirely and flood traffic to the receiver. This subsequently incurs a per-packet cost for any software-based filtering that is needed.

Solution Requirements A solution intended for decentralized, zero-configuration multicast IP address assignment is expected to operate in dynamic, infrastructure-free environments. To be effective in such contexts, the solution needs to exhibit the following characteristics:

1. Unique Address Assignment: Use of the solution SHALL result in a unique address being assigned to the multicast group at both the network and link layers.
2. Resilience to Single Points of Failure: The solution SHALL be designed to minimize introduction of a single point of failure, ensuring that operation continues even if individual devices or links become unavailable.
3. Zero User Configuration: It SHALL operate without requiring user or administrator configuration, allowing seamless deployment in unmanaged networks.
4. Coexistence with Multicast Address Allocation Solutions: The design SHALL allow coexistence with other multicast IP address allocation solutions, including both manual assignment and existing dynamic protocols.
5. Single-Subnet Operation: It SHALL support operation within a single IP subnet, which is typical in link-local or isolated network environments.
6. No External Connectivity: The solution SHALL NOT require Internet access or connectivity to external infrastructure.
7. Supports Multiple Host Applications: It SHALL support multiple applications on the same host, each independently allocating multicast addresses and transmitting to those addresses.
8. Collision Detection and Resolution: The solution SHALL include mechanisms to detect and resolve multicast address collisions at both the network and link layers.

Note: In rare cases, collisions may arise after a temporary network partition, when different parts of the network allocate the same multicast address independently. Upon reconnection, such collisions SHALL be detectable and resolved gracefully by ensuring that conflicting streams are migrated to unique addresses. In addition to the above, the following characteristics are considered desirable, but are left as recommendations to allow for flexibility in solution design:

1. Multi-Subnet Support: Operation across multiple subnets is beneficial in more complex or routed environments and SHOULD be supported.
2. Standards Compatibility: The solution SHOULD aim to minimize the need for changes to existing protocols or standards that affect backwards compatibility or deployment in existing networks.
3. Cross-Platform Availability: It SHOULD use capabilities that are widely available across host platforms and operating systems.
4. Minimal Dependency on Manufacturing Data: It SHOULD avoid reliance on preloaded configuration or device-specific manufacturing data.
5. Low Overhead: The solution SHOULD minimize the volume and frequency of network traffic generated during normal operation.
6. Advertisement: The solution SHOULD describe a mechanism for advertising and discovering multicast addresses allocated for an application.
7. Network Topology: To allow compatibility with a variety of networks, the solution SHOULD work independently of the dynamics of the underlying topology and adjacencies.

IPv6 Considerations The rules for IPv6 multicast addresses, described in , are comprehensive and well-organized. These rules must be followed by any solution allocating IPv6 multicast addresses, including solutions that meet the requirements defined in this document. However, some aspects of the organization of need to be improved to ensure that a zeroconf multicast address assignment solution can coexist with other IPv6 multicast address assignment protocols. For example, explains that the last 32 bits of an IPv6 multicast address, called the group ID, are mapped directly to the Ethernet MAC address. Different parts of the group ID range are assigned based on how the address is allocated. describes two ways to assign group IDs dynamically: one where a server assigns addresses, and another where hosts assign addresses themselves. However, both methods use the same group ID range, which creates a risk of address collisions if both are used at the same time. An additional concern is that the group IDs used for this dynamic range overlap with the range used for Solicited-Node multicast addresses, a special type of multicast used by IPv6 for neighbor discovery (see ). This overlap increases the risk of unintentional conflicts with link-layer addresses. Note that focuses on 48-bit addresses on Ethernet, but similar issues would be seen on any medium that generates link-layer multicast addresses by truncating an IPv6 multicast address.

IPv4 Considerations In IPv4, multicast addresses can sometimes cause conflicts at the data link layer. For example, as explained in , this happens with Ethernet because only the lower 23 bits of an IPv4 multicast address are used to generate the Ethernet multicast address. Since an IPv4 multicast address is 32 bits and starts with a fixed 4-bit prefix (leaving 28 bits), this means up to 2^(28-23) = 32 different multicast IP addresses can map to the same Ethernet address. As a result, devices may receive multicast traffic they didn't ask for. The address allocation guidelines in did not account for this type of collision when they were created. Because of this limitation, the recommended approach for new designs that need dynamic multicast IP address assignment is to use IPv6 instead of IPv4. However, if using IPv4 is necessary, then multicast addresses SHOULD be chosen carefully from within the Administratively Scoped Block (239.0.0.0/8). Additionally, solutions for zeroconf multicast address allocation SHOULD try to avoid using addresses that may already be in use by other applications on the same network, to minimize the risk of conflicts. Zeroconf coexistence with other IPv4 multicast address allocation solutions may not be possible; in that case, it may be necessary to require manual configuration or to limit the solutions that are deployed.

Security Considerations Zeroconf multicast address allocation mechanisms are vulnerable to accidental or malicious address collisions, which may lead to denial of service or misdirection of traffic. Solutions derived from these requirements SHALL include measures for collision detection and conflict resolution [REQ-8], and SHOULD include measures to prevent unauthorized address use. Specific security mechanisms are outside the scope of this document.

IANA Considerations This document has no IANA actions.

References Normative References This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK] This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] This memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered. This memo provides information for the Internet community. This document provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes RFC 3171 and RFC 3138 and updates RFC 2780. This memo documents an Internet Best Current Practice. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers. [STANDARDS-TRACK] This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows the use of Interface Identifiers (IIDs) to allocate multicast addresses. When a link-local unicast address is configured at each interface of a node, an IID is uniquely determined. After that, each node can generate its unique multicast addresses automatically without conflicts. The alternative method for creating link-local multicast addresses proposed in this document is better than known methods like unicast-prefix-based IPv6 multicast addresses. This memo updates RFC 3306. [STANDARDS-TRACK] Intel Corp United States Patent 6690667B1

Excluded Solutions The way multicast IP addresses are mapped to link-layer multicast addresses is already defined in existing standards, such as for IPv4 over Ethernet and for IPv6 over Ethernet. These standards specify a fixed prefix used in creating the Ethernet multicast address. Changing this prefix would open the door to new solutions, but those are not being considered here for practical reasons. One idea is to reduce the size of the fixed prefix, which would leave more bits available for the group ID. This would make address collisions less likely. Another idea is to create a new protocol that dynamically maps multicast IP addresses to link-layer addresses, similar to how DHCP assigns IP addresses. This protocol could work locally on a subnet, and routers could adjust the mapping for incoming multicast traffic at the network edge. However, these ideas would require significant changes to how network devices handle multicast traffic. Since existing hardware and operating systems are built around the current standards, it's unlikely that such changes would be widely supported anytime soon. Another potential solution for IPv4 was to assign 32 separate, non-overlapping address ranges to avoid collisions altogether (e.g., assign 224.0.0.254, 224.128.0.254, 225.0.0.254, etc.). However, this was rejected because discourages new allocations, given how limited the IPv4 multicast address space already is.

Acknowledgement Special thanks to the National Marine Electronics Association for their contributions in developing marine industry standards and their support for this research. Thanks also to the members of the PIM Working Group for their early brainstorming sessions and review of this document, and to for his review and suggestions.

Authors' Addresses Garmin International, Inc.

1200 E. 151st St. Olathe KS 66062-3426 United States of America nate.karstens@gmail.com

lispers.net

San Jose CA United States of America farinacci@gmail.com

Futurewei

United States of America michael.mcbride@futurewei.com