Summary

  • RFC 10019 requires a future zeroconf multicast allocator to produce uniqueness at both the network and link layers, without depending on a central server, external connectivity or administrator configuration.
  • Distinct multicast IP addresses can collapse onto one Ethernet destination, while isolated segments can allocate the same group and discover the conflict only when the topology reconnects.
  • Reconciliation is complete only when the conflict is detected, one claim is migrated, receivers and forwarding state converge, the old group becomes quiet and the intended application content is verified.

Imagine a vessel whose sensor network has been divided during maintenance. On one side, a radar application selects a multicast group. On the other, a diagnostic video service independently selects the same group. Each segment is a complete observation domain at that moment. Neither allocator hears an objection, each application acquires listeners, and each local log says the address was free.

The cable is restored. The collision appears not because either history was fabricated, but because the domain in which both were true has changed. If the two streams now share one IP destination, a receiver cannot know which meaning the group was meant to carry. Even when the IP destinations differ, they may map to the same Ethernet destination and become indistinguishable to a network interface or switch that filters only at the link layer.

That is the authority problem inside RFC 10019, Zeroconf Multicast Address Allocation Problem Statement and Requirements. Published in July 2026 as an IETF Informational RFC, it does not appoint an allocator, standardise a packet format or choose a winner. It establishes the conditions a future decentralized solution must satisfy. The most important condition is that local allocation is provisional evidence, not permanent title.

One group has more than one identity

An application usually begins with an IP multicast address. Ethernet equipment does not forward that address directly. It derives a multicast Media Access Control destination from part of it, and that compression can erase distinctions that exist at the network layer.

RFC 1112 maps only the low 23 bits of an IPv4 multicast address into the Ethernet destination. IPv4 multicast has 28 variable group bits, so 32 different IP multicast addresses can produce the same Ethernet address. RFC 2464 gives IPv6 multicast an Ethernet address beginning 33:33 followed by the low 32 bits of the IPv6 destination. The IPv6 space is vastly larger, but the Ethernet projection still discards information.

RFC 10019 therefore makes dual-layer uniqueness its first requirement. An allocator that searches only its IP-group table can return a value that is unused in that table and still collides on the wire. This is not a theoretical distinction confined to an addressing diagram. It changes which packets hardware admits and where the switch sends them.

A host interface may program a hardware multicast filter when an application joins a group. If another IP group maps to the same MAC destination, the interface cannot reject the unwanted frames by that filter alone. RFC 1112 permits an implementation whose filter capacity is exhausted to open the filter and receive all multicast traffic for software to discard. Correct content can still emerge, but CPU work and packet exposure have changed.

The switch can collapse identity too. RFC 4541 records implementation differences in IGMP and MLD snooping, including equipment that uses the Ethernet destination rather than the full IP group when building forwarding behaviour. One high-rate stream can then reach a low-bandwidth receiver that asked for another group with the same MAC mapping. Finite forwarding tables add a further physical limit: unrelated addresses that land in the same internal bucket may cause an entry to be rejected or traffic to be flooded.

An allocator cannot prove these outcomes from its own return code. It can propose an IP group and derive a MAC destination. Only observations from peers, interfaces, switches and receiving applications can show whether the claim remained distinct in execution.

A partition changes the truth domain

RFC 10019's REQ-8 requires collision detection and resolution at both layers. Its note on temporary network partitions is unusually consequential. Separate parts of a network may allocate the same group independently; after reconnection, the solution must detect the collision and migrate conflicting streams to unique addresses.

The requirement invalidates a common operational shortcut: treating the first successful claim as owner forever. “First” is defined only inside an observation domain. Segment A may have a timestamp earlier than Segment B, while B was isolated and could not observe it. Clocks may not be comparable. A stream may be safety-critical on one side and disposable on the other. RFC 10019 does not resolve those policy choices.

The allocation record therefore needs more than an address and a lease time. It should preserve the address family, full multicast address, scope, derived link-layer destination, source where source-specific multicast is used, allocator and rule revision, local instance, application or stream identity, lease epoch, observation domain and a transcript hash. Without the domain, the record cannot distinguish a genuine duplicate from two locally valid histories that have just met.

Topology evidence begins reconciliation. A new bridge, restored link, merged VLAN or changed adjacency joins observation domains that were previously separate. The system must then compare exact IP claims and link-layer projections. Silence is not proof of compatibility: a listener may be offline, snooping state may not yet have converged, or a hardware filter may already have fallen back to broad reception.

Conflict closure requires an explicit survivor and loser. The losing stream needs a replacement that is distinct at both layers. Advertisement and discovery must lead receivers to it. Forwarding and interface filters must converge. The old sender must stop, stale membership must age out, and an application-level canary must confirm that the new destination carries the intended content rather than merely packets of the right shape.

Temporarily advertising old and new bindings can reduce interruption. Moving receivers before stopping the old sender can preserve continuity. Those are useful operating patterns, not algorithms specified by RFC 10019. A publication that says “RFC-compliant migration” without naming its arbitration, overlap and withdrawal policy is claiming more than the document supplies.

Decentralized does not mean evidence-free

The requirements deliberately constrain central authority. A solution must minimize single points of failure, require no user configuration, work on one subnet without Internet access and support multiple applications on one host. It must coexist with manual or other dynamic allocation where that is possible. Desirable properties include low overhead, discovery, cross-platform implementation and independence from changing topology.

RFC 2730 defines MADCAP, a client/server protocol for multicast-address leases. That model can be useful where a server is available, but it is not by itself the infrastructure-free answer sought by RFC 10019. Replacing a global authority with one indispensable local controller would move the single point of failure rather than remove it.

Decentralization also does not mean that every participant has equal power to displace another. A deployment still needs a bounded conflict policy. It may consider oldest observable claim, application priority, operator policy or a deterministic identifier. None of those tie-breaks is mandated by the RFC. The policy must be local, visible and replayable; otherwise a forged conflict announcement can become an authority to force repeated renumbering.

The security section is narrow but decisive. Accidental or malicious collisions can cause denial of service or traffic misdirection. A solution must detect and resolve them and should prevent unauthorized address use, but the security mechanism is outside scope. A conflict packet is therefore not self-authenticating merely because the protocol expects conflicts. Operators need to bind claims to local instances and applications, rate-limit displacement, retain the triggering evidence and distinguish failure from attack.

IPv6 reduces pressure, not accountability

RFC 10019 prefers IPv6 for new dynamic multicast designs. IPv4's 23-bit Ethernet mapping and constrained multicast space make collision avoidance harder. Where IPv4 is necessary, the document recommends careful use of the Administratively Scoped Block described by RFC 5771 and warns that coexistence with other allocation mechanisms may be impossible. Manual configuration or restriction to one mechanism can be the honest answer.

IPv6 provides a much larger address space and explicit scope semantics in RFC 4291. Yet scope is a forwarding boundary, not a lease, identity or authorization grant. Different IPv6 groups can still share a 33:33 Ethernet destination. More space lowers one probability; it does not turn an allocator's result into delivery proof.

RFC 3307 set earlier allocation guidance for IPv6 multicast group IDs. RFC 10028 later separates ranges for MADCAP, host-allocated source-specific multicast, Private Use, Experimental Use and Solicited-Node addresses. That range repair reduces one coexistence class. It does not define the decentralized discovery, arbitration and partition-healing mechanism RFC 10019 calls for.

Source-specific multicast narrows channel identity to (S,G). RFC 8815 explains the operational preference for SSM and the bounded cases that remain for ASM. Preserving the source dimension is important evidence. It still does not stop two group addresses from sharing an Ethernet destination, prove that hardware enforced the source, or show that the intended application consumed the right stream.

Allocation ends before delivery begins

RFC 10019 explicitly places use of the group after allocation outside scope. That sentence protects the requirements document from pretending to solve the whole service. It also defines the evidence gap operators must close themselves.

An IGMP or MLD membership report says something about group interest observed at a point. It does not authenticate the listener, establish its business authorization, prove that a switch programmed every path or confirm that the receiver decoded the intended data. A forwarding-table entry shows installed state, not the packet that actually crossed it. A packet counter shows traffic, not its producer or meaning.

The irreducible chain is longer: allocation intent; observation domain; IP-layer uniqueness; link-layer uniqueness; receiver membership; switch and NIC state; packet fingerprint; application outcome; and withdrawal of the old epoch. Each link has its own scope and clock. Compressing the chain into allocated=true transfers decision power to the component with the least visibility.

This is where Heng Lu's running-code principle becomes operational. The registry or allocator record remains essential provenance, but it cannot outrank the switch, interface and application observations that reveal what executed. Minimum Initial Specification supports a thin common contract—dual-layer uniqueness, decentralization, conflict resolution—without centralizing every tie-break, lease policy or migration sequence. Reality Layers separates the formal address claim from the physical compression and finite tables that determine who receives traffic.