Summary

  • The IETF Datatracker records draft-ietf-pim-gaap-23 on 3 September 2026 and moves the document to AD Followup; it remains an Experimental Internet-Draft, not an approved RFC.
  • Revision 23 fixes the application-use ranges at 239.0.0.0/10 for IPv4 and the RFC 10028 Experimental Use Group ID range for IPv6 so independently written implementations share the same derivation space.
  • The revision also says partition repair will not detect a same-name split when one side selects the +1 candidate and the other selects +2: the addresses differ, so nothing collides and the group can remain split after healing.
  • Collision absence is therefore not proof of group-name convergence. The experiment needs evidence that intended participants ended up on the same address and could communicate after a partition.
  • A local group-name convergence receipt would preserve that evidence without pretending to be a new IETF requirement.

Revision 23 solves a configuration disagreement

The IETF history record dates revision 23 of the Group Address Allocation Protocol to 3 September. The same event moved the document substate from Revised I-D Needed to AD Followup and returned its IANA review to Version Changed - Review Needed. Those labels describe work in progress. They do not mean the IESG has approved the protocol.

The change log in revision 23 says it addressed Éric Vyncke’s IESG DISCUSS and COMMENT ballot. The useful news is not the workflow label by itself. It is a new contrast inside the design.

GAAP is an experimental way for multicast participants to derive group addresses without a central allocation service. An application supplies a group name. The protocol hashes four permitted strings: the name itself, then the name followed by +1, +2 or +3. A node claims the first resulting address and waits about one periodic Claim interval—roughly one minute. If no claim reports the same network-layer address for a different group name, the application may begin using it. If there is a collision, the node tries the next candidate.

The design intentionally carries little shared state. Nodes need not cache other nodes’ claims. Each node tracks its own allocations and periodic timers; a restart rebuilds that soft state through new claims. That simplicity is the point, but it also makes common inputs decisive. Two implementations cannot coordinate through the same hash rule if they begin from different address ranges.

The official comparison of revisions 22 and 23 shows the repair. The draft no longer leaves the application-use ranges to operator configuration. It says a configurable range would be reliably compatible only with itself, because an operator cannot control which independently written GAAP implementation an application might use.

The new text sets one IPv4 range, 239.0.0.0/10. It points to RFC 2365 for the unassigned blocks available for expansion of the Organization-Local scope and to RFC 5771 for the surrounding assignment guidance. For IPv6, it selects 0xFE000000–0xFEFFFFFF, the Experimental Use part of the Dynamic Multicast Group ID space created by RFC 10028. That IPv6 space is not exclusive to GAAP. Other experiments may use it too.

This is a real interoperability decision. It replaces nine possible local understandings of “the configured range” with one protocol input per address family. It does not, however, establish that nodes later agree on the address attached to a particular group name.

A healed link can preserve two valid answers

Revision 23 now says so directly. Its partition-repair procedure handles the case in which both sides end up using the same address for a group name. When the partition closes, the claims meet; the procedure can compare them and resolve the condition.

The unresolved case looks less alarming precisely because it produces no collision. Suppose unrelated local traffic on one side forces the shared group name away from its base address to the +1 candidate. A different local collision on the other side moves the same name to +2. Both choices obey the candidate list. Both can be locally clean. When connectivity returns, one side announces one address and the other announces another. The protocol’s collision predicate—same address, different names—does not fire. The draft says the group remains split and calls resolution an open question for the experiment.

Vyncke had asked this in his ballot comment: what happens when partitioned networks use +1 and +2, and will everyone converge? Revision 23 turns that question into an explicit boundary. It does not supply a convergence mechanism.

That distinction matters because the two states can look equally successful in an ordinary collision counter:

  • one group name, one address, no collision;
  • one group name, two addresses, still no collision.

Only the first is rendezvous. In the second, the intended application population has become two populations. A monitoring system that records rejected collisions but not the group-name-to-address mapping can declare a quiet recovery while participants remain unable to meet.

RFC 10019, the problem statement GAAP cites, requires a decentralized allocation solution to detect and resolve address collisions that arise after a temporary partition. That remains important. Revision 23 exposes an adjacent condition that is not a collision at all: divergent answers for the same name. The solution’s success vocabulary therefore needs both objects. “Collision resolved” and “name converged” cannot be aliases.

An experiment needs positive evidence of rendezvous

The draft is careful about its maturity. It says decentralized hash-based multicast allocation has not been deployed. The experiment is meant to learn whether collision detection and resolution are sufficient in practical networks, what collision rates arise at different scales, and how periodic Claim traffic scales. It is complete only when operational experience supports a later Standards Track case or reveals a fundamental limitation requiring revision.

The newly documented split belongs inside that experiment definition. Counting collisions can measure how often two names meet at one address and how often the repair procedure moves one of them. It cannot measure how often one name remains attached to two addresses after a partition, because the protocol does not classify that state as a collision.

The missing evidence can be kept locally without turning the experiment into a centralized allocator. A group-name convergence receipt could bind a privacy-conscious name identifier, the observed partition cohorts, the candidate index on each side, the selected addresses, partition and heal times, the detection path, post-heal membership reachability, and the repair result. A reviewer could then distinguish three outcomes: convergence observed, divergence observed, or insufficient observation.

That receipt is my editorial proposal, not text in GAAP and not a requirement from the IETF, IANA or the PIM working group. Its purpose is narrower: prevent an experiment from treating the absence of a negative event as evidence of the positive property it set out to test.

Lu Heng’s Minimum Initial Specification, Localized Future Decision offers a useful division of labour. The fixed ranges are a small shared rule needed for independently built implementations to meet. The method for observing, storing and repairing a rare split can remain local during the experiment, provided its result is comparable and does not disappear.

Running Code Primary supplies the proof standard. A revised document, an IANA allocation or a cleared ballot can change the formal surface. None can demonstrate that two implementations exposed to different local collisions reunite on one mapping. That claim belongs to a test that creates the partition, produces the +1/+2 divergence, heals the path and preserves what every node actually used.

Revision 23 improves the experiment by naming the boundary. The next governance step is not to hide it behind the newly fixed ranges. It is to make convergence an observable result in its own right.

Sources

  1. GAAP Datatracker record
  2. GAAP document history
  3. GAAP revision 23
  4. GAAP revision 22
  5. Official revision 22–23 comparison
  6. IESG ballot for GAAP
  7. RFC 10019: Zeroconf Multicast Address Allocation Problem Statement
  8. RFC 10028: IPv6 Dynamic Multicast Group IDs
  9. RFC 2365: Administratively Scoped IP Multicast
  10. RFC 5771: IANA Guidelines for IPv4 Multicast Address Assignments
  11. Lu Heng — Minimum Initial Specification, Localized Future Decision
  12. Lu Heng — Running Code Primary