Summary

  • draft-ietf-pim-ipv6-zeroconf-assignment-12 lets an application assume a multicast address is available when mDNS produces no indication of use; that negative evidence is only as complete as the host, link and reflector path that could have carried a contradiction.
  • A saved group ID reduces churn but does not authorize skipping probe, announcement, continuous query or defence. After a partition heals, the losing sender must stop, choose another ID and persist it—possibly only after low-bandwidth mDNS has taken significant time to expose the collision.

Revision 12 arrived on 22 September 2026 with a stronger warning than its predecessor. It is an active PIM Working Group Internet-Draft, submitted to the IESG and in Last Call through 6 October in the frozen Datatracker record. Its requested status is Proposed Standard. It is not yet an RFC, a completed IANA allocation, an interoperability report or a deployment result.

The proposal addresses a real coordination problem. An application that wants to originate an IPv6 multicast stream selects a random group ID from the proposed dynamic range 0x90000000–0x9FFFFFFF. It combines that value with the source interface identifier to create a link-scoped source-specific IPv6 multicast address, then derives the corresponding Ethernet multicast address. A worked example turns group ID 9abc:def0 into 33:33:9A:BC:DE:F0 on Ethernet.

The address then becomes a local DNS name. The application reverses the Ethernet nibbles beneath .eth-addr.arpa; the example produces 0.f.e.d.c.b.a.9.3.3.3.eth-addr.arpa. It publishes a PTR record through Multicast DNS, probes before claiming it, announces it, responds to queries, keeps querying for a contradiction and defends the record. The design deliberately reuses mDNS machinery rather than creating a new allocation protocol.

Its crucial sentence is not about the size of the random space. It says the protocol uses implicit availability: if an application receives no indication that an address is already used, it assumes the address is free. Revision 12 immediately states the consequence. Filtering mDNS at the host or network can prevent applications from coordinating and may create address collisions.

That distinction turns “no answer” from a fact into a scoped observation. A probe can show that no conflicting PTR was visible on the interfaces and paths reached during the probing interval. It cannot show that no peer existed behind a blocked multicast boundary, a misconfigured reflector, a quiet interface or a temporary partition. The protocol's probability estimate—n / 2^28 for another application choosing the same group ID—describes random selection. It does not turn a particular silence into positive uniqueness proof.

Network partition is the cleanest demonstration. Imagine a production floor split by a failed switch. On one side, an application restores a previously saved group ID. On the other, a new stream independently selects the same value and finds no objection. Each half is internally coherent because the contradictory PTR cannot cross the cut. When the switch returns, both claims become mutually visible.

The draft requires a continuous query precisely for this case. Once the partition is repaired, conflict handling follows mDNS rules. The loser must stop transmitting that multicast stream, return to group-ID selection, choose another value and overwrite the old persisted value. That is a sound recovery direction, but it is not an instantaneous one. The draft says mDNS is designed for low bandwidth and can take a significant amount of time to detect a resource-record collision after repair. It gives no universal upper bound.

For operators, that interval is the material event. Both senders may look healthy while frames sharing the same Ethernet multicast destination carry different IPv6 multicast destinations. Receivers, switches and monitoring systems may observe effects that a simple “PTR registered” dashboard cannot explain. The coordination record remains calm until the delayed query surfaces the contradiction.

Revision 12 adds an optional second sensor. A host network stack may watch for traffic addressed to the same destination Ethernet multicast address but to a different destination IPv6 multicast address. If that mismatch appears, the application must stop the stream and choose a new group ID. Only one side must move, although both may. The draft intentionally provides no method for the hosts to coordinate which one yields.

Infrastructure gets a separate override. If a switch or other component detects a collision it cannot resolve, it can publish a veto PTR. The target label is extended with -veto, making the record lexicographically later than the application's record and therefore the winner under the mDNS conflict rule. Infrastructure publishes it without probing; the application is forced to abandon the ID.

The veto is powerful but temporary. Once the offending PTR disappears or expires, the veto publisher queries for it for five seconds. If it receives no matching response, it waits a random 20–120 milliseconds and sends a goodbye that invalidates the veto. Storing vetoes permanently is unnecessary because the displaced application stores its replacement ID.

This mechanism reveals a control surface, not an infallible arbiter. The security section says a hostile participant can forge conflict responses during probing or create vetoes for allocated addresses, repeatedly preventing a sender from finding or retaining an address. Filtering mDNS can neutralise collision prevention altogether. Cooperation is an assumption; it is not produced by the protocol.

Persistence has similarly narrow authority. A returning application must use the group ID saved for that stream. This lets a stable network settle and reduces future collision probability. Revision 12 also says, explicitly, that retention does not allow the application to skip any preceding step. The stored ID must be probed and announced again, the continuous query must run, and the record must be defended. Storage is a continuity hint, not a certificate that the observation domain stayed unchanged while the sender was offline.

That is a useful Running-Code Primacy test. The operator should trust the executable sequence—select, derive, probe, announce, query, defend, stop and replace—not a database cell that merely says “allocated”. A stable identifier and a stable service are different things. The identifier can survive exactly when the topology that made it safe has disappeared.

The protocol is also narrower than service discovery. It coordinates one PTR record for an address. It does not prescribe how a receiver learns the stream address. DNS-SD with a _udp service and a TXT record is mentioned as a natural option, not as part of the allocation proof. Even successful discovery would not prove receiver membership, multicast forwarding, packet delivery or application consumption.

The multi-subnet case widens the evidence problem. PTR records must be distributed between subnets, perhaps by an mDNS reflector, and the draft calls such distribution an area of continuing research. Forwarded streams must use a unicast-prefix-based multicast address rather than the generated link-scoped address. The design assumes cooperating hosts and is described as unsuitable for the global Internet.

The proposed common layer should therefore stay thin. It can coordinate local address uniqueness when participants can hear one another. It should not be inflated into proof that a stream is discoverable, joined, forwarded, received or useful. Each later claim needs its own receipt.

The leadership ledger starts with the group ID, source interface, derived IPv6 and Ethernet addresses, stream identity and storage epoch. It then records the interfaces and subnets covered by probe and continuous query, every relevant filter and reflector, the partition epoch, conflict or veto evidence, which sender stopped, the replacement ID and successful re-probe. Receiver membership, forwarding entries, packet counters and application outcomes follow as separate stages.

Without that scope, “no conflict observed” is dangerously incomplete. The operational question is not simply whether mDNS was running. It is: who could have answered, across which links, during which interval, and what evidence will force the stream to stop when yesterday's silence becomes today's collision?

Sources