RFC 10019

Zeroconf Multicast Address Allocation Problem Statement and Requirements 🎀

Okay bestie, this is RFC 10019 💖. It was written by N. Karstens (Garmin), D. Farinacci (lispers.net), and M. McBride (Futurewei) 💜. It's published by the Internet Engineering Task Force (IETF) as an Informational document, dated July 2026, with ISSN 2070-1721 📅. It is not a standards track spec, so it's just here for information 🙈. The title block doesn't list any Obsoletes or Updates entries, so it isn't replacing or changing any other RFC 🦋.

Abstract ✨

Okay so this doc is a tour of what's going wrong with protocols that try to hand out multicast IP addresses automatically in zeroconf (zero-configuration) networks 🌸. The villains are link-layer address collisions, hardware limits, inefficient multicast snooping, and the fact that people shouldn't have to configure everything by hand 😭. From all that drama, it pulls out requirements for a lightweight, decentralized fix that dynamically allocates unique multicast group addresses with no central coordinator 👑.

It lays out explicit requirements for discovery, allocation, conflict detection and resolution, and lease management ✨. It also looks at what's different about IPv6 and IPv4 multicast address ranges 🌈, and calls out approaches that are just not it for zeroconf 💀. Basically, it's the foundation for future solutions that can run on their own inside local networks 🧚.

Status of This Memo 🦋

This one is not an Internet Standards Track specification. It's published for informational purposes only 📚.

It's a product of the IETF, which means it represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for that 💅.

You can find the current status, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc10019 🌈.

Copyright Notice 💅

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 🙈. Code Components pulled out of this doc have to include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Revised BSD License 💜.

Table of Contents 🧚

   1.  Introduction
     1.1.  Requirements Language
   2.  Link-Layer Address Collisions
   3.  Solution Requirements
   4.  IPv6 Considerations
   5.  IPv4 Considerations
   6.  Security Considerations
   7.  IANA Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Appendix A.  Excluded Solutions
   Acknowledgement
   Authors' Addresses

1. Introduction 🌸

Multicast is the go-to when a network needs to get data from one sender to lots of receivers efficiently 🦋. In some places, like small or isolated networks, multicast has to run without centralized servers or manual configuration 🫶. These are called zero-configuration (zeroconf) multicast networks ✨.

One example is marine networks 🌊, the kind with a mix of sensors, controls, and displays on a boat. Depending on the size and design of the vessel, they can be more or less complicated 💅. Devices range from cheap temperature or fluid sensors all the way up to high-bandwidth stuff like radar, sonar, or video feeds 📡. A lot of marine networks sit on a single subnet and use Layer 2 Ethernet switches to connect everything 🧜.

In these networks, multicast is the most efficient way to send sensor data to several displays ✨. But things get messy when high-bandwidth multicast streams overload links going to low-bandwidth devices 😭. Budget-friendly switches often don't support source-specific multicast (SSM), because their address table only maps destination Media Access Control (MAC) addresses 🙈. So each multicast stream gets its own unique destination multicast IP address, and IGMP/MLD snooping [RFC4541] is used to control delivery 🎀. That approach has limits, especially where the switch hardware lacks advanced multicast filtering capabilities 💀.

Marine networks show these issues really well, but they aren't the only ones with this problem 🌈. Lots of other zeroconf multicast environments, like industrial automation, small-scale audio-visual (AV) systems, or ad hoc sensor networks, share similar constraints 🧚.

The Multicast Address Dynamic Client Allocation Protocol (MADCAP) [RFC2730] is a method for multicast IP address allocation, but its server-based model doesn't suit a zeroconf environment 🙅. [RFC3306] and [RFC4489] both discuss similar approaches to host-based multicast IPv6 address allocation, but neither one adequately prevents link-layer address collisions 💔. Then [RFC3307] sets up a framework to avoid multicast address collisions at both IPv6 and link layers, but it still needs more refinement before anyone can put it into practice (see Section 4) 🔧.

This doc outlines the problem space for zeroconf multicast address allocation, describes the key limitations of current protocols, details where link-layer address collisions come from, and defines requirements for decentralized, zero-configuration multicast address allocation solutions 🗺️. Multicast apps deployed in a zeroconf environment can use these solutions to dynamically allocate multicast group addresses ✨. How a multicast group address gets used after allocation is outside this doc's scope 🙈.

IPv6 is well-suited for zeroconf multicast networks, thanks to how IPv6 multicast is organized and its immense pool of possible multicast addresses 👑. Still, this doc considers IPv4 too, for networks where moving to IPv6 just isn't practical yet 🌸.

1.1. Requirements Language 💜

Here's the important bit: 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎯.

The requirements language gets used in Section 3, and it applies to implementations that conform to the listed requirements 🫶.

2. Link-Layer Address Collisions 🫶

Link-layer address collisions are a huge concern on multicast networks, especially when devices rely on zero-configuration operation 💥. A collision happens when two or more multicast groups get assigned the same link-layer (MAC) address, and that leads to performance or forwarding problems 😩. This section walks through three scenarios where that can cause trouble 🔍.

First up, lots of host network interfaces can filter multicast traffic right in hardware 🛠️. When an app joins a multicast group, the host network stack usually programs the hardware to accept only traffic for that group 🎯. But if two groups share the same link-layer address, the network interface can't tell them apart 😵. So the network stack has to process the unwanted traffic in software, which hurts performance and ramps up CPU usage 🔥.

Second, link-layer address collisions make multicast snooping switches way less useful on a network 🙃. Section 4 of [RFC4541] notes that 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) 🕵️. The survey is outdated, but switches with these limitations still exist in some of the target deployments 🦖. In that case, if two multicast streams share the same MAC address, traffic can end up going to devices that never asked for it 🙅. That's especially rough when low-bandwidth links get overwhelmed by high-bandwidth streams 😭. Additional concerns related to the overlap of IPv6 and link-layer addresses are discussed in Section 3 of [RFC4541] 📚.

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 [US6690667B1]) 🪣. If multiple addresses hash to the same location and the bucket fills up, additional entries may be dropped or rejected, which means forwarding failures 💔.

These examples highlight why a collision-resistant multicast address allocation mechanism is essential in zeroconf environments 💖. How well this works depends on the capabilities of the hardware (like how many addresses the filters in host network interfaces support, and how big the tables in switches and routers are) and on how many multicast groups a particular receiver subscribes to 🎀. When the number of entries in the filter tables exceeds what's available, a typical fallback is to bypass the filter entirely and flood traffic to the receiver 🌊. That then adds a per-packet cost for any software-based filtering that's still needed 🥲.

3. Solution Requirements ✨

okay so this section is where the RFC gets real about what a solution actually needs to do 🫶 the whole goal is decentralized, zero-configuration multicast IP address assignment, which means it has to work in dynamic, infrastructure-free environments 🌸 no DHCP server to lean on, no admin hovering over everything. to be effective there, the solution needs to have these vibes:

• [REQ-1] Unique Address Assignment: using the solution SHALL result in a unique address being assigned to the multicast group at both the network and link layers 💖
• [REQ-2] Resilience to Single Points of Failure: the solution SHALL be designed so it doesn't introduce a single point of failure, which means operation keeps going even if individual devices or links drop out 🦋
• [REQ-3] Zero User Configuration: it SHALL operate without needing any user or administrator configuration, so it can be deployed smoothly on unmanaged networks ✨
• [REQ-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 🤝
• [REQ-5] Single-Subnet Operation: it SHALL support operation within a single IP subnet, which is super typical in link-local or isolated network environments 🌈
• [REQ-6] No External Connectivity: the solution SHALL NOT require Internet access or connectivity to external infrastructure 🙅‍♀️
• [REQ-7] Supports Multiple Host Applications: it SHALL support multiple applications on the same host, with each one independently allocating multicast addresses and transmitting to those addresses 👑
• [REQ-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: okay this one is important 🙈 in rare cases, collisions can show up after a temporary network partition, when different parts of the network allocate the same multicast address on their own. when the network reconnects, those collisions SHALL be detectable and resolved gracefully, meaning the conflicting streams get migrated to unique addresses 💅

so on top of all that, there's a list of characteristics that are considered desirable, but the RFC leaves them as recommendations so solution designers have room to be flexible 🧚

• [CONS-1] Multi-Subnet Support: operation across multiple subnets is beneficial in more complex or routed environments, and it SHOULD be supported 🌸
• [CONS-2] Standards Compatibility: the solution SHOULD aim to minimize the need for changes to existing protocols or standards that would affect backwards compatibility or deployment in existing networks 🎀
• [CONS-3] Cross-Platform Availability: it SHOULD use capabilities that are widely available across host platforms and operating systems 💜
• [CONS-4] Minimal Dependency on Manufacturing Data: it SHOULD avoid relying on preloaded configuration or device-specific manufacturing data 🍓
• [CONS-5] Low Overhead: the solution SHOULD minimize the volume and frequency of network traffic it generates during normal operation 🦋
• [CONS-6] Advertisement: the solution SHOULD describe a mechanism for advertising and discovering multicast addresses that were allocated for an application 📣
• [CONS-7] Network Topology: so it stays compatible with a variety of networks, the solution SHOULD work independently of the dynamics of the underlying topology and adjacencies 🌊

4. IPv6 Considerations

the IPv6 multicast address rules in [RFC3307] are honestly comprehensive and super well-organized 📚 any solution allocating IPv6 multicast addresses has to follow them, including solutions that meet the requirements in this document. BUT some parts of how [RFC3307] is organized need some love so a zeroconf multicast address assignment solution can actually coexist with other IPv6 multicast address assignment protocols 🥺

for example, Section 2 of [RFC3307] explains that the last 32 bits of an IPv6 multicast address, called the group ID, get mapped directly to the Ethernet MAC address 🧠 different parts of the group ID range are assigned depending on how the address gets allocated. Section 4.3 of [RFC3307] describes two ways to assign group IDs dynamically: one where a server does the assigning, and another where hosts assign addresses themselves. the catch is that both methods use the same group ID range, so if both are in use at the same time, there's a risk of address collisions 😭

there's also a concern that the group IDs used for this dynamic range overlap with the range used for Solicited-Node multicast addresses. those are a special kind of multicast that IPv6 uses for neighbor discovery (see Section 2.7.1 of [RFC4291]). that overlap makes unintentional conflicts with link-layer addresses more likely 💀

Note that [RFC3307] focuses on 48-bit addresses on Ethernet, but similar issues would show up on any medium that generates link-layer multicast addresses by truncating an IPv6 multicast address 🫠

5. IPv4 Considerations

in IPv4, multicast addresses can sometimes cause conflicts at the data link layer 😩 as Section 6.4 of [RFC1112] explains, this happens with Ethernet because only the lower 23 bits of an IPv4 multicast address are used to generate the Ethernet multicast address. an IPv4 multicast address is 32 bits and starts with a fixed 4-bit prefix, leaving 28 bits. so that means up to 2^(28-23) = 32 different multicast IP addresses can map to the same Ethernet address. the result? devices may receive multicast traffic they never asked for 🙈

the address allocation guidelines in [RFC5771] didn't account for this type of collision when they were created. because of that limitation, the recommended approach for new designs that need dynamic multicast IP address assignment is to use IPv6 instead of IPv4 🌷

that said, if IPv4 is necessary, multicast addresses SHOULD be chosen carefully from within the Administratively Scoped Block (239.0.0.0/8). solutions for zeroconf multicast address allocation SHOULD also try to avoid addresses that may already be in use by other applications on the same network, to cut down on 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 which solutions get deployed 🥲

6. Security Considerations 🚨

okay this one is serious, bestie 😤 zeroconf multicast address allocation mechanisms are vulnerable to accidental or malicious address collisions, and those can 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 they SHOULD include measures to prevent unauthorized address use. specific security mechanisms are outside the scope of this document, so don't come looking for them here 🔐

7. IANA Considerations

this document has no IANA actions 🌙

8. References 📚

8.1. Normative References

[RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
           RFC 1112, DOI 10.17487/RFC1112, August 1989,
           <https://www.rfc-editor.org/info/rfc1112>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
           Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
           <https://www.rfc-editor.org/info/rfc2464>.

[RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
           Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002,
           <https://www.rfc-editor.org/info/rfc3307>.

[RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
           Architecture", RFC 4291, DOI 10.17487/RFC4291, February
           2006, <https://www.rfc-editor.org/info/rfc4291>.

[RFC4541]  Christensen, M., Kimball, K., and F. Solensky,
           "Considerations for Internet Group Management Protocol
           (IGMP) and Multicast Listener Discovery (MLD) Snooping
           Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
           <https://www.rfc-editor.org/info/rfc4541>.

[RFC5771]  Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
           IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
           DOI 10.17487/RFC5771, March 2010,
           <https://www.rfc-editor.org/info/rfc5771>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2. Informative References

[RFC2730]  Hanna, S., Patel, B., and M. Shah, "Multicast Address
           Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
           DOI 10.17487/RFC2730, December 1999,
           <https://www.rfc-editor.org/info/rfc2730>.

[RFC3306]  Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
           Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,
           August 2002, <https://www.rfc-editor.org/info/rfc3306>.

[RFC4489]  Park, J., Shin, M., and H. Kim, "A Method for Generating
           Link-Scoped IPv6 Multicast Addresses", RFC 4489,
           DOI 10.17487/RFC4489, April 2006,
           <https://www.rfc-editor.org/info/rfc4489>.

[US6690667B1]
           Warren, D., "Switch with adaptive address lookup hashing
           scheme", United States Patent 6690667B1, 10 February 2004,
           <https://patents.google.com/patent/US6690667B1/en>.

Appendix A. Excluded Solutions 🧩

the way multicast IP addresses get mapped to link-layer multicast addresses is already defined in existing standards, like [RFC1112] for IPv4 over Ethernet and [RFC2464] for IPv6 over Ethernet. those standards specify a fixed prefix that gets used when creating the Ethernet multicast address. changing that prefix would open the door to new solutions, but they aren't being considered here for practical reasons 🙃

one idea is to reduce the size of the fixed prefix, which would leave more bits free for the group ID. that would make address collisions less likely 📉 another idea is to create a new protocol that dynamically maps multicast IP addresses to link-layer addresses, kind of like how DHCP assigns IP addresses. that protocol could work locally on a subnet, and routers could adjust the mapping for incoming multicast traffic at the network edge 🌐

but these ideas would need 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 so collisions could be avoided altogether (e.g., assign 224.0.0.254, 224.128.0.254, 225.0.0.254, etc.). however, this was rejected because [RFC5771] discourages new allocations, given how limited the IPv4 multicast address space already is 💔

Acknowledgement ✨

okay, big thank-you to the National Marine Electronics Association 🌊 they've done so much work building marine industry standards, and they supported this research too. literally iconic of them 💙

also a huge shoutout to the members of the PIM Working Group 🫶 they helped with early brainstorming sessions and reviewed this document, and Gunter van de Velde gets a special thanks for his review and suggestions. you all made this so much better 💖

Authors' Addresses 🦋

here's who wrote this, and how to reach them 💌

Nate Karstens
Garmin International, Inc.
1200 E. 151st St.
Olathe, KS 66062-3426
United States of America
Email: nate.karstens@gmail.com


Dino Farinacci
lispers.net
San Jose, CA
United States of America
Email: farinacci@gmail.com


Mike McBride
Futurewei
United States of America
Email: michael.mcbride@futurewei.com