Summary

  • RFC 2375 let a permanent multicast service meaning appear at several legal IPv6 scopes, but said that addresses differing only by scope represented different groups and had to be joined individually.
  • A reserved or assigned group ID was therefore a coordination record, not proof that a listener existed, a router retained membership state, a source was admitted or an application received a packet.

A registry crossed the protocol boundary

In July 1998, IPv6 needed more than a multicast address format. Implementers needed a shared list: which destinations meant all nodes, all routers, routing protocols, time service, conference channels and the other group names already circulating through the IPv4 world.

RFC 2375 supplied an initial answer. It selectively adapted IPv4 multicast assignments that appeared relevant to IPv6, declined to convert those that did not, invited comments on the conversion and reserved everything else. That was not a claim of finality. It was a controlled opening of a namespace.

The list carried history with it. Beside basic control groups were names from experimental protocols, vendor systems and the multicast conferencing culture of the 1990s. A registry could preserve a service meaning even while the implementations, media and communities behind that name changed.

The X concealed a boundary

Some addresses in RFC 2375 had a fixed scope. Others used X in the scope position: the same permanent group number could be expressed at any legal scope. At first glance this looked like one group stretched from a machine to the Internet.

The document said otherwise. Addresses that differed only in scope represented different groups. Nodes had to join each group individually. The semantic label might survive—NTP servers, for example—but the actual multicast destination was rebuilt when the scope nibble changed.

RFC 2373 made the topology concrete. The scope value bounded the group. A permanent group ID could retain its meaning at node-local, link-local, site-local or global scope, yet each full address described a different reach. Routers were not to forward multicast traffic beyond the encoded scope.

The identifier travelled. Membership did not.

Assignment was the first receipt

RFC 2375 separated fixed-scope addresses from variable-scope ones and left unlisted addresses reserved. This was valuable coordination. Without it, two protocols might claim the same value, or an implementation might give a familiar number a different meaning.

But an assignment established only a namespace fact. It did not say that an application had requested reception, that a host had joined on a particular interface, that a neighboring router had learned of a listener, that multicast forwarding state existed, or that an admissible source was sending useful packets.

That missing chain became explicit in RFC 2710. Multicast Listener Discovery let routers discover which multicast addresses had listeners on directly attached links. Hosts moved through non-listener, delaying-listener and idle-listener states. Queries and reports applied to an address on an interface. A name in the table and a live listener were deliberately different things.

Scope changed the question

The difference was not merely how far a packet might travel. Scope changed the population being addressed. “All routers” on one interface was not “all routers” on one link, and neither was “all routers” at one site. Even when the low-order group ID was identical, the full address asked a different operational question.

Transient groups were stricter still. RFC 2373 said that a non-permanent address at one site had no necessary relationship to the same address at another site, to the same group ID under another scope, or to a permanent group carrying that ID. Visual similarity was not continuity.

This distinction prevented a compact identifier from being mistaken for a universal audience. The address encoded a bounded destination. The audience had to materialise through local state.

Later rules separated three kinds of permanence

RFC 3307 later distinguished permanent multicast addresses, permanent group identifiers and dynamic addresses. IANA could allocate a permanent address through Expert Review. A permanent group ID could act as a global identifier for a service offered by many servers and across multiple scopes. Dynamic allocation used a different range and flag.

Those were three different promises. A permanent address reserved a full form. A permanent group ID preserved service identity across forms. A dynamic address created a temporary operational choice. None guaranteed that listeners or forwarding state existed at any particular place or time.

RFC 3306 added unicast-prefix-based multicast and made the context even more visible. The multicast scope could not exceed the embedded unicast prefix's scope, and the multicast address should not outlive that prefix. Reusable identity remained constrained by allocation and time.

The table kept changing

RFC 4291 retained the scoped-group model in the successor IPv6 addressing architecture. RFC 7346 later assigned value 3 to realm-local scope and regularised the scope vocabulary. The current IANA registry divides the space into scope values, fixed-scope addresses, variable-scope addresses, unicast-based group IDs and dynamic group IDs.

That continuing structure is evidence of a living coordination system, not evidence that the 1998 table describes current traffic. An entry may remain reserved while no contemporary service uses it. A newer service may acquire an assignment long after RFC 2375. A scope name may be refined without altering the fundamental need for listener state.

The durable object is a governed namespace. The running object is a changing set of hosts, interfaces, reports, routes, sources and packets.

The history was a lesson in modest authority

Lu Heng's minimum-initial-specification lens fits RFC 2375 unusually well. The document called itself initial, converted selectively, invited correction and reserved the unused space. It established enough common vocabulary for independent systems to interoperate without claiming that the first list exhausted the future.

Running-code primacy then tells us where the next authority lives. An IANA entry can settle what a group identifier means. Only listener state, router state, source policy and observed delivery can show whether that meaning became an operational service at a given scope.

Reality layers keep the receipts from collapsing: registered service, group ID, scope, full address, interface membership, learned listener state, multicast route, accepted source, received packet and application outcome. RFC 2375 named the early groups. Its most useful warning was that the same name did not make them one group.