Summary

  • An application may choose a random multicast group ID only after turning the resulting Ethernet destination into an mDNS PTR claim, probing it, announcing it and continuously watching for conflict.
  • A network component can append -veto to the claimant’s first label, creating a record that always wins the mDNS tie-break and makes the losing application stop its stream and select again.
  • The mechanism is in IETF Last Call, not an approved standard; it assumes cooperating participants and supplies no authentication for conflict or veto messages.

The application chooses first. The switch can still have the last word.

That is the most consequential design choice in draft-ietf-pim-ipv6-zeroconf-assignment-12, posted on 22 September and in IETF Last Call until 6 October 2026. The proposal aims to let applications allocate link-scoped IPv6 multicast addresses on networks without a central allocator. Yet it does not pretend that random choice alone settles ownership. It builds a contest procedure around the address, then gives infrastructure an explicit veto when the collision exists below the IPv6 layer.

The draft is not an RFC. Its requested number space and names remain requests: the group-ID block 0x90000000-0x9FFFFFFF, the .arpa name eth-addr.arpa, and the special-use domain below 9.3.3.3.3.eth-addr.arpa. Datatracker still marks the IANA review as needed. A DNS Directorate review found revision 12 ready, but that review is evidence about the document’s maturity, not approval or deployment.

A claim begins with two addresses

For a new stream, the application selects a random 28-bit group ID from the proposed block. It combines that value with the interface identifier of the intended source under RFC 4489, producing a link-scoped IPv6 multicast address. RFC 2464 then supplies the corresponding Ethernet destination.

Those are not redundant representations. Many IPv6 multicast destinations can collapse onto the same 32-bit Ethernet suffix. The new procedure therefore coordinates the object the local wire will actually filter: the Ethernet destination.

It reverses that address nibble by nibble into a domain name. The draft’s example turns 33:33:9A:BC:DE:F0 into 0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa. A PTR record at that name points to an application identifier followed by the host name. Multiple applications on one host can consequently make distinct claims.

The application probes for a record with the same owner name using mDNS. If a simultaneous claimant wins the RFC 6762 tie-break, the loser returns to random selection. If probing completes without conflict, the application announces its PTR record, begins answering queries and starts a continuous query for later conflicts. Only then may it transmit.

This is implicit availability. Silence is treated as permission to proceed. It is not evidence that every relevant observer heard the probe.

Persistence is a preference, not a lease

The chosen group ID is stored so a stable network can settle on stable assignments. On restart, however, storage does not let the application skip the process. It must reconstruct the addresses, probe, announce and resume continuous monitoring.

That requirement draws an important line. The stored value says, “this worked in an earlier observation domain.” It does not say, “this address belongs to me.” A switch may have been replaced. A partition may have healed. Another application may have chosen the same ID while the first device was offline. A retained number without a fresh transcript is history, not current authority.

When a later conflict is detected, the losing application must stop transmitting before selecting again. The draft also permits the host network stack to detect the subtler case: different IPv6 multicast destinations mapping to the same Ethernet address. One application must move, but the specification does not prescribe how hosts coordinate which one.

Five extra bytes create a hierarchy

The veto record resolves collisions reported by network infrastructure, such as a switch table that cannot represent the two uses safely. The component publishes a PTR record under the same owner name. It takes the application’s first PTRDNAME label and appends -veto.

That suffix is not merely descriptive. DNS RDATA comparison encounters the label-length octet first. The longer veto label is therefore lexicographically later and always wins the mDNS conflict rule. The draft even caps the application’s first label at 58 octets to reserve room for the five-byte suffix.

Infrastructure sends this veto without probing. The application loses, stops the stream and chooses another group ID. When the underlying PTR expires or receives a goodbye, the veto holder queries for it; after five seconds without a response, it waits a random 20 to 120 milliseconds and withdraws the veto with its own goodbye.

Zero configuration here is a division of authority, not an absence of it. The application has initiative. Peers have contest rights. Infrastructure has a deterministic override. The receivers still decide whether the replacement stream is useful.

The veto is powerful and unauthenticated

The draft inherits mDNS’s assumption of cooperating participants. A hostile host can answer probes repeatedly, preventing allocation. It can also publish veto records against live assignments and force applications through repeated stop-and-reselect cycles. Filtering mDNS creates the opposite failure: two applications may hear silence and both conclude that the address is free.

The protocol does not authenticate a veto as the report of a real switch-table collision. Nor does a successful announcement authenticate the stream’s sender, authorise its content or prove that a receiver joined. Those are separate controls.

Operators therefore need receipts the wire format does not mandate: the stream identity; selected group ID; source interface identifier; IPv6 and Ethernet destinations; PTR owner and RDATA; probe and announcement times; continuous-query generation; conflict or veto issuer; stop receipt; replacement assignment; receiver migration; and old-record withdrawal. A rate of vetoes without corresponding hardware evidence should be investigated as either a defect or an attack.

A repaired partition can remain ambiguous

Continuous queries help discover duplicate claims after a partition heals. The draft also concedes that low-bandwidth mDNS may take significant time to notice. Where streams may be created throughout a partition, supplemental detection and resolution are left for future work.

That limitation matters more than the probability formula. A 28-bit random space makes accidental simultaneous selection unlikely on one healthy observation domain. It cannot make a filtered packet visible or merge two histories created in isolation. Probability reduces collisions; it does not close the evidence gap.

For multiple subnets, PTR records would have to cross boundaries, perhaps through an mDNS reflector, while the forwarded stream must use a unicast-prefix-based address rather than the link-scoped address created locally. The draft treats that extension cautiously. Its cooperating-host model is not suitable for the global Internet.

What changed after the problem statement

RFC 10019 documented the requirement: an allocator must account for uniqueness at both IPv6 and link layers, survive the absence of a central server and reconcile partitions. It did not provide a finished wire protocol or decide who wins.

Revision 12 supplies a concrete answer. It locates the claim in mDNS, represents the Ethernet resource in a reverse-style name, makes monitoring continuous and grants a visible veto to the component that sees an unresolvable infrastructure collision. That is real progress because it turns an implied power into a protocol event.

It is also the correct place to be precise. A PTR claim is not ownership. A veto is not proof. An announcement is not delivery. Running code deserves primacy over institutional description, but only the code that actually executed at each layer may speak for that layer. The strength of this design is not that it abolishes authority. It is that it makes one important exercise of authority observable enough to govern.

Sources