Summary

  • RFC 3307 gave server allocation and host allocation the same dynamic IPv6 multicast group-ID range, including a slice already used by Solicited-Node multicast. RFC 10028 replaced that overlap with six distinct registry ranges.
  • The new IANA table prevents one allocator from being assigned another allocator’s namespace. It does not prove that legacy MADCAP code changed, that a network supports SSM, or that multicast traffic reached an authorized listener.
  • Mike McBride is one of three RFC 10028 authors, with Nate Karstens and Dino Farinacci. His work illustrates a thin coordination layer whose value depends on implementations and operators preserving the boundary in running systems.

The defect was not hidden in a packet trace. It was printed in the allocation rule.

RFC 3307 described two ways to choose a dynamic IPv6 multicast group identifier. A server could allocate one, using a protocol such as MADCAP. A host could choose one itself, as a future zero-configuration mechanism might require. Both were instructed to use 0x80000000 through 0xFFFFFFFF—the same lower-32-bit space. The top part of that space also belonged to Solicited-Node multicast addresses.

Each rule could be implemented faithfully and still collide with the other. That is a useful category of infrastructure failure: no participant has to violate the specification locally. The common specification has failed to keep their choices disjoint.

RFC 10028, published on the IETF Standards Track in August 2026, repairs that particular defect. The document is collective work by Nate Karstens, Dino Farinacci and Mike McBride. McBride is followed here not as a lone inventor or multicast authority, but as one of the engineers who helped turn a shared interval into an explicit registry.

The IETF Datatracker page captured on 31 August 2026 lists McBride as chair of the Protocols for IP Multicast working group, a delegate to MBONE Deployment and ANIMA, a Routing Area Directorate reviewer and an author of nine RFCs. RFC 10028 gives his affiliation as Futurewei. An older Open Networking Foundation article supplies dated first-person career context. Neither source gives him personal control over the IANA table or over any operator’s network.

The thirty-two bits that two allocators shared

An IPv6 multicast address contains more than a group ID, but RFC 3307 assigns the lower 32 bits that role. Those bits are mapped directly into the link-layer multicast address on Ethernet. A shared group-ID choice can therefore become more than a duplicate label in a database; it can alter what a network interface and switch have to distinguish.

The earlier dynamic rule made no namespace distinction between server and host allocation. Its table was effectively one large sign saying “dynamic use”, even though the mechanisms had different coordination models. MADCAP asks an allocation server. A zero-configuration host protocol is meant to work without that server. If each mechanism believes it owns the same interval, neither can know from the identifier alone which process produced it.

RFC 10019, the related zeroconf problem statement, makes the coexistence problem concrete. It requires future decentralized solutions to work alongside other allocation mechanisms and to detect and resolve collisions at both network and link layers. A host algorithm cannot satisfy that requirement merely by choosing a random value from a range that another allocator also regards as its own.

The Solicited-Node overlap was a second defect. IPv6 Neighbor Discovery derives Solicited-Node multicast addresses from unicast or anycast addresses. Their group IDs occupy 0xFF000000 through 0xFFFFFFFF. RFC 3307’s old dynamic interval included that entire block. An identifier selected for a different dynamic purpose could therefore land in space already carrying a distinct architectural use.

The repair began by naming separate owners for separate slices.

Six lanes replaced one field

RFC 10028 creates the “Dynamic Multicast Group IDs” registry inside IANA’s IPv6 Multicast Address Space registry group. Its initial content is small enough to reproduce without abstraction:

  • 0x80000000-0x8FFFFFFF for MADCAP;
  • 0x90000000-0xEFFFFFFF unassigned;
  • 0xF0000000-0xFCFFFFFF for host allocation of SSM group addresses;
  • 0xFD000000-0xFDFFFFFF for Private Use;
  • 0xFE000000-0xFEFFFFFF for Experimental Use;
  • 0xFF000000-0xFFFFFFFF for Solicited-Node multicast addresses.

The ordinary unassigned range requires Standards Action before a future protocol receives part of it. Private and experimental ranges retain their stated purposes. Each entry has only a range, description and reference. This is coordination in a deliberately thin form: the table distinguishes identifiers; it does not prescribe an application, select a routing design or operate a network.

That narrowness is its strength. A registry does not need to know who will watch a stream or how a receiver is authorized in order to prevent the host-allocation range from being the MADCAP range. It needs a stable, reviewable statement that those identifiers have different intended uses.

It is also the limit of the repair. Two IPv6 multicast addresses that differ outside the mapped bits can still arrive at the same Ethernet multicast address. Switch hardware can still compress entries into finite tables or hash buckets. Temporary network partitions can let decentralized participants make conflicting choices before reconnecting. Malicious or accidental senders can still use identifiers badly. RFC 10028 removes the collision caused by overlapping allocation ranges; RFC 10019 still requires detection and resolution for the rest.

The title of this Article therefore matters literally. The registry prevented one kind of collision, not collision itself.

SSM reduces coordination only when SSM exists

The new host-allocation block is specifically for Source-Specific Multicast. That qualifier prevents another easy overclaim.

In Any-Source Multicast, a receiver asks for traffic sent to a group. In SSM, the channel is identified by both source and group, (S,G). RFC 4607 explains why the added coordinate reduces address-management pressure: two different sources can use the same group value while remaining different channels. Hosts no longer need global coordination merely to make every G unique across all sources.

But the source coordinate is not conjured by the address range. Applications must know which source to request. Hosts need the appropriate interfaces and IGMPv3 or MLDv2 behaviour. Designated routers and the multicast routing domain must preserve source-specific semantics. RFC 8815 identifies application support as a persistent deployment issue and recommends SSM for interdomain multicast precisely because the transition still requires these pieces.

RFC 10028 states the boundary plainly: SSM is not universally supported. Its host-allocation range is for environments that support SSM. Selecting an identifier from 0xF0000000-0xFCFFFFFF does not upgrade a legacy receiver, enable MLDv2, configure PIM or authenticate a sender. A correct registry entry can coexist with an unusable channel.

This is where Heng Lu’s Minimum Initial Specification and Running-Code Primacy are useful without turning an IANA protocol table into an argument about regional number registries. The common layer should specify the minimum distinction that interoperability requires. Later operational truth belongs to the implementations and networks that adopt it. The registry records a permissible coordinate; running code supplies the evidence that the coordinate has meaning in a particular deployment.

MADCAP’s smaller address estate

The partition imposes a real compatibility obligation on the older server mechanism. MADCAP was defined in RFC 2730 as a client-server protocol through which hosts request multicast-address leases. Under RFC 3307 it could use the large dynamic interval. RFC 10028 confines it to the first one-sixteenth of that former space, 0x80000000-0x8FFFFFFF.

The operational section reports that the authors knew of one MADCAP implementation and no large-scale deployments at the time of writing. That is not a proof that MADCAP was absent everywhere. “No known” describes the authors’ evidence horizon. It is strong enough to explain why a range reduction looked manageable, but not strong enough to authorize an operator to skip an inventory.

Any existing implementation must either adopt the new range or operate where other IPv6 multicast allocation protocols cannot conflict. A legacy binary that still chooses from the old interval does not become compliant because IANA’s website changed. Nor will a monitoring system discover the problem if it records only the full IPv6 address and omits allocation mechanism, implementation version and effective registry rule.

The migration receipt must join the declaration to the code: which allocator produced the ID, which version enforced the range, what configuration was active, and whether observations found any out-of-range selections. Without that join, the registry has separated the lanes on paper while traffic continues to enter from an old map.

A registry row is not a forwarding result

The cleanest way to use RFC 10028 is to keep several claims separate.

The IETF standards record proves that a reviewed specification established the partition. The IANA record proves what ranges its current public registry shows. An implementation test can prove that one allocator stayed inside its assigned slice. A host and router test can prove the required SSM control behaviour. A packet observation can prove that traffic travelled from a named source to a listener at a particular time and vantage. Authorization records can show whether that listener was meant to receive it.

None of those receipts can replace all the others.

A registry row cannot show that every vendor shipped the change. An SSM group ID cannot show that all routers treat the address source-specifically. Successful forwarding cannot show that the source was legitimate. A listener report cannot show that a different network path works. Absence of a collision during one test cannot show that two allocators will never choose the same link-layer result under another scope, partition or hardware limit.

The useful operating ledger is modest. Record the allocator and version; the mechanism; group ID and complete address; RFC and IANA snapshot; application, host and router prerequisites; collision-detection result; forwarding observation; source-validation result; listener authorization; and rollback owner. It resembles the registry in one respect: every field should say only what it can prove.

Mike McBride’s contribution, shared with Karstens and Farinacci, is a reminder that some important standards work consists of subtracting ambiguity. Six explicit lanes are less grand than a new forwarding architecture. They are also what lets future mechanisms arrive without inheriting a collision from the rulebook.

The registry made coexistence possible. Running networks must still make it true.

Sources