Summary

  • RFC 10028 replaces the overlapping dynamic IPv6 multicast ranges in RFC 3307 with separate space for MADCAP, host-allocated SSM, Private Use, Experimental Use and Solicited-Node addresses. The separation works only when deployed allocators use the current rule set.
  • A registry row cannot prove which allocator selected a live group ID, whether another allocator chose the same value, whether the IPv6-to-Ethernet mapping collided, or whether membership and forwarding delivered the intended (S,G) stream. Those claims require an end-to-end rule-epoch ledger.

A host starts a new Source-Specific Multicast channel on a vessel, factory floor or production campus. Its current allocator selects group ID 0xF0000001, inside the range that RFC 10028 reserves for host allocation of SSM addresses. The address passes the new range check.

On the same link, an older MADCAP server still believes that every value from 0x80000000 through 0xFFFFFFFF belongs to its dynamic pool. It leases 0xF0000001 to another application. That decision also passes the validation compiled into the old server.

Two green checks have now described one collision.

The new host is not violating the new registry. The legacy server may be behaving exactly as its superseded implementation was designed. The fault lies between rule epochs: a coordination document changed, but one running allocator did not. Because the lower 32 bits feed the Ethernet multicast destination, the disagreement is not confined to a standards table. It can reach interface filters, snooping tables, low-bandwidth receivers and the streams applications actually consume.

RFC 10028, published on the IETF Standards Track in August 2026, repairs the namespace that made this conflict possible. Its operational significance is precise. It does not make the registry sovereign over a local link, and it does not make the registry irrelevant. It gives implementers a necessary boundary and leaves leaders with the harder task of proving adoption.

The old range assigned two methods to the same territory

RFC 3307 treated the low-order 32 bits of an IPv6 multicast address as its group ID. It described both server allocation and host allocation, but assigned both to the same dynamic space: 0x80000000 through 0xFFFFFFFF. The top segment also covered group IDs used by Solicited-Node multicast.

That structure could not tell a MADCAP allocation from a host allocation by looking at the number. Two independent mechanisms could legitimately search the same space and select the same result. The overlap with Solicited-Node addresses added a second class of conflict.

RFC 10028 replaces that arrangement with the “Dynamic Multicast Group IDs” registry now visible in the IANA IPv6 Multicast Address Space. The current partition is:

Group-ID range Purpose
0x800000000x8FFFFFFF MADCAP
0x900000000xEFFFFFFF Unassigned
0xF00000000xFCFFFFFF Host allocation of SSM group addresses
0xFD0000000xFDFFFFFF Private Use
0xFE0000000xFEFFFFFF Experimental Use
0xFF0000000xFFFFFFFF Solicited-Node multicast

Future assignments in the unassigned block require Standards Action. RFC 8126 provides the registry-policy vocabulary and emphasizes explicit change control. This is good minimum specification: the shared system records which allocation class owns which numeric territory, while lower-level choices can remain distributed.

But the table is not a live allocation service. IANA does not choose 0xF0000001 for a host, inspect a switch or revoke a stale lease. Range membership answers “which class may use this part of the namespace?” It does not answer “who selected this value here, under which code and with what result?”

The migration instruction is the real news

RFC 10028 cuts MADCAP down to 0x800000000x8FFFFFFF. It says MADCAP implementations should be updated. Existing deployments should either use an updated implementation or run where no other IPv6 multicast address allocation protocols coexist.

That sentence creates a practical fork. Upgrade, or isolate.

At the time of writing, the RFC reported one known MADCAP implementation and no known large-scale deployments. That is a bounded statement from the standards process, not a 2026 product census. An operator cannot turn the absence of known large deployments into proof that no old server exists inside a marine bridge, industrial cell, AV estate or lab network.

MADCAP is a client-server mechanism. A client can discover servers, request addresses and receive an offer, acknowledgement or rejection. Administrators can impose local allocation policy. A successful lease therefore proves a server decision under its configuration. It does not prove that its pool was narrowed after RFC 10028 or that a host allocator did not independently select the same ID.

The migration inventory must identify the server build, configured pool, lease records and coexisting allocation methods. “MADCAP active” is not enough. “RFC 10028 compliant” is not enough unless the claim binds to the exact executable and configuration that issued the lease.

An IPv6 address is not just an entry in a spreadsheet

RFC 4291 gives IPv6 multicast addresses their FF prefix, flags, scope and group ID. Scope matters: a transient group is meaningful inside a defined topological region, not as an abstract global object. The same 32-bit value can be harmless in separated scopes and damaging when two formerly separated networks reconnect.

On Ethernet, RFC 2464 maps an IPv6 multicast destination to a 33:33 address followed by the last four octets of the IPv6 address. That makes the group ID part of the link-layer forwarding surface. It does not make the mapping a certificate of uniqueness.

RFC 10019 explains the consequences in zeroconf networks. Two IPv6 groups that reach the same link-layer destination can force a host to filter unwanted traffic in software. They can defeat the benefit of multicast snooping, burden a low-bandwidth link or collide inside constrained switch tables. The document uses marine systems as a vivid case—sensors, controls, displays, radar, sonar and video on one subnet—but its requirements extend to industrial, AV and ad hoc environments.

It also exposes a time dimension. Two partitions can allocate independently and look collision-free until the link reconnects. A future decentralized allocator must detect and resolve the conflict by migrating streams. RFC 10028 creates disjoint protocol ranges; it does not implement those probes or perform the renumbering.

SSM narrows coordination, not evidence

RFC 4607 defines an SSM channel as (S,G). A receiver requests traffic sent by source S to destination group G, so different sources can reuse the same G without representing the same channel. RFC 8815 identifies this as a major address-management advantage: G need not be globally unique inside the reserved SSM space.

That does not make G meaningless. A host still has to choose an address from the correct range. An application has to preserve S. A receiver needs source-qualified membership support. Routers and switches must process the relevant state. RFC 10028 expressly notes that SSM is not universally supported.

In constrained links, the distinction may narrow further. RFC 10019 notes that some cost-effective switches maintain destination-MAC state and cannot express source-specific filtering. RFC 4541 documents how snooping behavior can mis-prune or over-forward traffic when protocol versions and switch capabilities disagree. A correct (S,G) in an application is not proof that every forwarding element enforced S.

SSM therefore changes the uniqueness claim. It does not eliminate the evidence chain. Record the source tuple, membership report, snooping entry, routing state and packet canary separately.

Private and experimental ranges are boundaries, not absolution

RFC 10028 gives Private Use its own block and suggests isolated deployments such as manual allocation. Private use means that local parties can select values without a central assignment. It also means two independent parties can select the same value. Interconnecting their networks converts a local convenience into a migration event.

Experimental Use is similarly easy to over-read. RFC 10028 permits experiments without restricting them to a private link. The label does not prove that an experiment is safe, authorized, collision-free or suitable for production dependency. It needs an owner, scope, expiry and cleanup record.

Unassigned space is not “free for now.” It is reserved for a future Standards Action. Solicited-Node space is an architectural function, not a spare dynamic pool. The registry creates clearer categories precisely so operators do not turn absence of an immediate assignment into local authority.

Build a rule-epoch ledger

For every allocation, preserve the standards revision and allocator class, software version and configuration hash. Record the request or local selection event, complete IPv6 address, scope, group ID, Ethernet mapping, application, stream identity, and lease start, expiry and renewal. For SSM, retain the source address as part of the channel identity.

Then move beyond allocation. Record all allocation systems present in the scope, conflict probes, MLD or IGMP membership, snooping and forwarding entries, first and last packet times, packet-count and content canaries, unexpected-source traffic, renumbering triggers and withdrawal of the old group. A migration completes only after stale host and switch state has drained.

The states must remain separate:

  • the value is in a current registered range;
  • an identified allocator selected it under an identified rule epoch;
  • no competing allocator selected a conflicting value in the scope;
  • the intended receiver joined the channel;
  • the path forwarded the intended source and group;
  • the application received the intended stream.

This follows Heng Lu's running-code primacy. A record is necessary evidence about coordination, but the executed allocator and packet path decide operational truth. His minimum initial specification and localized decision describes why the range split should remain narrow: common rules prevent cross-protocol collision, while adoption and deployment choices remain local. His distinction between formal and practical data control explains the authority boundary. The IETF and IANA can define and record the namespace without controlling the software, switch or receiver that gives one number practical effect.

RFC 10028 improves the map. Leadership begins by refusing to confuse the map with the migrated territory.