Summary

  • RFC 2908 separated multicast address allocation into client-to-server, within-domain, and inter-domain layers. Experimental RFC 2909 used MASC to let domains claim temporary address prefixes from a hierarchy, then subdivide or delegate them.
  • RFC 2909 warned that IPsec could protect two peering nodes without making a relayed UPDATE's origin trustworthy: a non-trustworthy MASC node elsewhere in the store-and-forward topology could inject malicious updates. The proposed boundary was administrative trust in peers—not proof that MASC was deployed, exploited, or carried traffic.

In September 2000, the Internet multicast-address architecture had to answer a question that was easy to blur: who could hand a group address to an application, and who could reserve the larger range from which that address came? RFC 2908's answer was to stop treating “allocation” as one transaction. It split the work into three layers. A client asked an allocation server for a group address; allocation servers coordinated inside a domain; and inter-domain mechanisms supplied address ranges to those domains. MADCAP could serve the first layer. AAP or manual configuration could serve the second.

MASC was one proposed mechanism for the third.

That division made multicast allocation less like a single global counter. A MASC node—typically expected to run on a border router—acted for a domain that often corresponded to an Autonomous System. It selected a prefix from a larger range, sent a claim to its configured peers, and waited for colliding claims. The parent-child hierarchy let a domain split a received prefix for its own allocation servers or delegate sub-prefixes to child domains. A surviving claim could also be injected into multicast route information, where a separate routing protocol might use it.

Those were connected control surfaces, not synonyms: a MASC allocation did not itself create a multicast route, a receiver membership, or delivered packets.

Claims had clocks. A prefix came with a lifetime; to keep using it, a domain had to renew before expiry. If renewal failed, the specification said the domain should stop using the prefix and remove the corresponding route state. The timing made delegated space revocable by protocol rather than permanent by default. It also meant that allocation state, route state, and application use could diverge if an operator observed only one of them. A registry-like claim was not a packet trace.

The architecture's design bargain was equally explicit. In scarce address space, a strict partition can guarantee that two domains never choose the same range, but the spare capacity needed for partitions and failover fragments the pool. RFC 2908 judged efficient packing and continuing availability more important than an absolute no-collision guarantee in that case. Its goal was a very high probability of avoiding a clash, while accepting a finite probability.

MASC's claims, collision comparison, waiting period, and ability to choose another prefix implemented that probabilistic posture; they did not turn it into mathematical certainty.

Then RFC 2909 drew attention to a different kind of boundary. An UPDATE did not necessarily stop at the peer that first received it. MASC nodes stored and forwarded updates across parents, siblings, children, and internal peers. RFC 2909 said IPsec could address security between two peering nodes. But if a non-trustworthy MASC node connected anywhere in the topology, it could inject malicious UPDATEs that other nodes might not detect as malicious. The security section therefore recommended that each MASC node peer only with trustworthy nodes.

It also described recovery choices: state from a parent or internal peer was typically treated as trustworthy, while a node could discard its own updates arriving through a sibling or child.

This is not the same as saying “IPsec does not work.” Link protection can protect a particular adjacency. The gap described by RFC 2909 appears after information travels beyond that adjacency: the next hop can know which peer sent it without independently establishing who originated the claim or whether every relay was entitled to repeat it. Claim timestamps and origin-node identifiers help compare competing claims; the document does not present those fields as cryptographic origin authentication. Nor does it report an actual exploit. It describes a threat model and assigns an operational choice to the people configuring the peer graph.

The distinction matters because a range claim can influence more than one allocation server. If it is accepted and propagated, it can constrain neighboring claims and feed multicast route state. A malicious or compromised trusted node could therefore disturb other parts of the allocation topology before an application ever asks for an address. The remedy RFC 2909 names is not a universal global authority that certifies each claim; it is to limit peering to nodes an operator trusts, and to use path-sensitive rules when accepting forwarded updates. That places real control in topology design and trust administration.

The standards labels also set a boundary on the historical claim. RFC 2908 is Informational and describes a proposed architecture; RFC 2909 is an Experimental Protocol, not an Internet Standard. Their publication shows that designers articulated a layered allocation model and its risks. It does not show how many networks implemented it, whether MASC became operationally common, or whether any malicious update disrupted service. RFC 3180's static GLOP mapping and RFC 3171's IANA registration process are different allocation choices; neither establishes MASC adoption.

The surviving lesson is narrower and more useful: a delegated prefix, a protected connection, a trusted origin, a route, and a delivered multicast stream are separate facts. A safe control plane must say which evidence authorizes each transition.

Sources