Summary
- SSM replaces a group-only request with a channel request,
(S,G), so the receiver names the sender as well as the multicast group. - That removes shared-tree and rendezvous machinery from the SSM path, but moves source discovery into the application and does not authenticate the named source.
- The RFCs support a strong interdomain recommendation, not a claim that ASM has vanished inside every network or that SSM is universally deployed.
The extra coordinate
Traditional multicast language invites a deceptively simple picture: an application joins group G, and the network works out which sources belong behind that address. Source-Specific Multicast changes the request itself. Under RFC 4607, the service is a channel identified by (S,G). The host asks to receive datagrams sent from source address S to the SSM destination address G; datagrams from a different source do not satisfy that subscription.
That extra coordinate is the architecture. IPv4 reserves 232.0.0.0/8 for SSM semantics, while IPv6 uses FF3x::/32. Routers must treat those ranges consistently. A non-source-specific (*,G) request for an SSM address is not an approximate version of the right request: RFC 4607 says it must not be used or propagated. If one router treats the address as source-specific while another expects ordinary group membership, the meaning of the address fractures along the path.
The important transfer of authority is easy to miss because the packet still looks like multicast. In Any-Source Multicast, source discovery can be a network function. In SSM, the receiver application must learn the source by some other mechanism and pass it to the host. The network is asked to preserve a choice already made at the edge.
A simpler path with a new dependency
RFC 8815 makes the operator case bluntly. For interdomain multicast it recommends deprecating ASM, recommends SSM, and calls for full host and router support. The SSM path does not need a Rendezvous Point, a shared tree, a shortest-path-tree switchover, PIM Register messages, MSDP, or dynamic RP discovery. The receiver's source-qualified join can build state toward the named source using PIM-SSM.
This is real simplification, not merely cleaner notation. It removes components whose only purpose is to help the network discover and coordinate sources. But the source has not become self-discovering. The dependency has moved to the application-layer channel that tells the receiver which S to request.
A stale programme guide, a compromised control service, or an operator mistake can therefore select the wrong source and still be enforced perfectly by the multicast network. That sentence is analysis, not a claim made by the RFCs: the standards establish the out-of-band discovery requirement; the operational consequence follows from where the decision now sits.
RFC 8815 also draws a boundary around its recommendation. It deprecates ASM for interdomain multicast. It does not preclude ASM within one organization or administrative domain. The BCP is an architectural direction at an administrative boundary, not evidence that every existing multicast deployment has already migrated.
The host must preserve the choice
RFC 4604 maps this model into IGMPv3 and MLDv2. A source-specific application request has to survive the host API, the host IP module, first-hop signalling and router state. A non-source-specific request for an address in the SSM range should fail. Older-version compatibility can also prevent the requested (S,G) channel from being delivered, because the legacy report cannot carry the source qualification.
There is a sharper failure on a shared link. In the legacy-compatibility condition described by RFC 4604, an SSM-aware host must not suppress its own source-specific report merely because it heard another host's report. Suppression could keep the first-hop router from learning the required source filter and could deny service to other receivers on the link. What looks like duplicate chatter is carrying admission information that the older report does not contain.
Link-layer delivery does not finish the job either. On Ethernet, the multicast destination at the link layer does not select packets by IP source. RFC 4607 therefore leaves a filtering duty in the host IP module: it must check the source before delivering the datagram to a socket that asked for (S,G). SSM is a path-wide agreement, not one clever router feature.
Selection is not authentication
Naming S narrows admission. It does not prove who controls S. RFC 4607 explicitly warns that forged source addresses can violate the service model and says applications needing strong authentication require a higher-layer mechanism. The distinction is exact: SSM gives the receiver network-layer source selection; it does not supply cryptographic sender identity.
The same RFC rejects another comfortable overstatement. SSM does not eliminate multicast state or denial-of-service risk. Each subscription can create router state, processing and control traffic. Very large sets of subscriptions can become an attack surface, and the specification permits carefully selected rate or state limits. A design that removes rendezvous infrastructure can still be exhausted through the admission interface it exposes.
What the evidence does not show
These three RFCs define semantics, host behaviour and the IETF's interdomain recommendation. They do not measure current SSM share by region or operator class. They do not establish vendor defaults, migration defects, or whether a named service protects its source-discovery channel. They also do not quantify bandwidth, incident, or state reduction after a migration. Any such claim needs evidence outside this fixed source set.
What the sources do establish is sufficient for a narrower conclusion. SSM simplifies the network by refusing to let “join the group” stand as a complete instruction. The receiver must name the sender, the host and routers must preserve that choice, and the application must accept responsibility for discovering it. The network becomes easier to reason about precisely because one of its former questions has been handed back to the edge.
Sources
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
