Summary

  • Source-Specific Multicast identifies a channel by a source and group pair, conventionally written (S,G).
  • Two private senders may choose the same group and remain distinct because their private source addresses differ.
  • A NAT can rewrite both private source addresses to one public outside address while leaving the multicast group unchanged.
  • The two distinct private channels can then appear outside as the same public (S,G), allowing their traffic to intermix.
  • RFC 5135 describes this source-aliasing limit explicitly and leaves a general resolution for future study.
  • Letting an application change its SSM group is an interim escape, not proof that all receivers learned and used the new group.
  • Correct IGMP proxy aggregation protects membership-state semantics; it does not restore a source identity lost in data-plane translation.
  • Endpoint-Independent Mapping stabilizes mapping behavior across destinations, but it does not make two senders uniquely visible behind one outside address.
  • Forwarding counters, an active mapping and packet arrival are separate receipts from receiver demultiplexing and service outcome.
  • Scope controls for 239.0.0.0/8 and 224.0.0.0/24 answer where traffic may travel, not which private source an outside receiver sees.
  • RTP identifiers such as SSRC and CNAME may add application identity, but they must be generated, transported, checked and consumed as a separate layer.
  • Leadership should require an evidence chain from inside source through translation and public advertisement to the receiver's selected, rendered outcome.

The collision hidden inside successful forwarding

Imagine two private encoders, A and B. Each emits a Source-Specific Multicast stream to the same group. Inside the private network, the streams are not ambiguous: A has one source address, B another, so their channels are (A,G) and (B,G). The group is shared, but the ordered pair is not. A receiver or router that knows the private source address can select one without pretending that it selected the other.

Now place both encoders behind one NAT. RFC 5135 requires the device to replace an inside source address with an outside address when multicast moves from inside to outside. If A and B are both represented by the same outside address and the group is not translated, the receiver no longer sees (A,G) and (B,G). It sees two packet streams with one public (N,G), where N is the NAT's outside address. The packets may have crossed the device exactly as configured while the identifying distinction has vanished.

That is not a marginal wording problem. SSM's selection promise rests on the pair. If translation preserves G but coalesces A and B into N, successful transport can coexist with failed meaning. An outside listener requesting (N,G) has no IP-layer fact that says which private sender produced a particular packet. RFC 5135 says the streams are no longer uniquely identifiable and can be intermixed. It does not claim that every implementation or application fails; it identifies the condition under which the public channel ceases to carry the distinction that existed privately.

The most dangerous dashboard is therefore one that shows a green forwarding path and stops. It may prove that a mapping exists, that the proxy has membership state, that packets left the outside interface and that packets arrived at a receiver. None of those receipts proves that the receiver obtained only the intended private source. Reachability is real, but it is not identity.

What RFC 5135 actually asks a multicast NAT to do

RFC 5135 is BCP 135, published in February 2008. It addresses IPv4 NAT and NAPT behavior for multicast, including Any-Source Multicast and Source-Specific Multicast, in a device that provides IGMP proxying. It does not specify PIM-SM behavior, and it does not cover IPv6 translation. Those scope limits matter because a deployment cannot borrow the document's label for mechanisms it never defined.

For traffic moving from the outside to subscribed receivers inside, the NAT must leave the multicast destination address and destination port unchanged. It must forward multicast UDP to the relevant inside receivers, and it should handle non-UDP multicast. These requirements protect the destination semantics of the multicast stream. They do not promise to preserve the source identity of a stream originated behind the device.

For traffic moving from inside to outside, the device must rewrite the source IP address to an outside address. A NAPT may also translate the source UDP port and must maintain a mapping when responses are expected. The document requires Endpoint-Independent Mapping for traffic sent to unicast or multicast destinations. Where several public addresses are available, paired address pooling should keep an inside endpoint on the same outside address. These are useful mapping invariants. They make behavior more predictable; they do not manufacture a unique public source address for every private multicast sender.

The document also requires forwarding of inside-originated multicast UDP and requires a way to disable it. The disable control addresses a distinct risk: in a multihomed arrangement, forwarding through more than one NAT can duplicate public traffic. Duplicate-path control and source-alias control are not the same thing. One asks whether the same stream escaped twice; the other asks whether two different private streams became indistinguishable once they escaped.

Scope gates are another separate layer. The default must not export administratively scoped traffic in 239.0.0.0/8, and Local Network Control Block traffic in 224.0.0.0/24 must not cross the outside boundary. A packet can be correctly blocked by scope, correctly allowed by scope or stopped by a TTL of one. None of those results tells an outside receiver which private source lies behind an allowed public source address.

IGMP proxy success is not source preservation

The proxy control plane deserves precise credit. An IGMP proxy is not a transparent pipe for every private host's reports. It learns downstream membership state, aggregates that state and represents it upstream. RFC 5135 permits IGMPv1 support, requires IGMPv2 support and recommends IGMPv3. If the device supports IGMPv3, it must support SSM and the source-filter behavior associated with IGMPv3 and MLDv2.

Aggregation matters because simply interleaving private reporters' state-change messages can create an invalid sequence for the one upstream reporter. A host can join while another leaves; if their independent messages are forwarded naively, upstream state may temporarily blackhole traffic. The required proxy behavior prevents a private collection of state machines from masquerading as a valid single state machine.

But a correct aggregate remains a membership receipt. It can prove which groups and source filters the proxy intended to represent upstream. It does not reverse the source-address rewrite applied to the data packets. A healthy proxy table beside an aliased public (S,G) is not contradictory. The control plane can be correct while the data plane no longer exposes the private distinction.

This boundary is easy to miss because IGMPv3 is the membership protocol associated with SSM. The association tempts an operator to treat correct source filtering as proof of source identity throughout the path. Yet the filter can only act on the source address visible at its location. Once two private sources have been expressed as the same public source, an outside filter does not possess a hidden memory of their earlier addresses.

The interim escape moves work into the application

RFC 5135's Appendix A does not pretend to solve the general aliasing problem. It advises SSM applications, as an interim measure, to let a user change the multicast group address. If A and B choose different groups, (N,G1) and (N,G2) remain distinct even though both use the same public source N. That can be effective. It is also a transfer of responsibility.

The application now needs a collision signal or an operator who recognizes the condition. Someone must select a replacement group within the applicable allocation and scope rules. Session signaling must advertise the new public (S,G) accurately. Every intended receiver must obtain the update, abandon the old selection and subscribe to the new one. Cached descriptions, stale receiver configuration, authorization policy and monitoring expectations must follow. The change is real only when those local systems adopt it.

That is why group configurability is not a checkbox-shaped solution. A control proves that change is possible. A configuration record proves that somebody requested a change. Neither proves that a receiver stopped consuming the intermixed channel and began consuming the intended one. The portable standard can expose the escape; operational evidence must show the escape was taken successfully.

Application identity can help, but it is another receipt

Some applications carry identifiers above IP. RTP, for example, uses SSRC identifiers and canonical names to reason about participants and collisions. RFC 5135 encourages proper CNAME generation because private address ranges are reused behind many NATs. An application that validates such identity may distinguish packets even when the network-layer source is shared.

That possibility should not be promoted into an automatic repair. The sender must generate a suitable identifier. Signaling and packet transport must convey it. The receiver must inspect it, apply the relevant collision rules and bind it to the intended participant. An SSRC collision is also a different failure from the IP-layer SSM alias described here. A system can have one, both or neither.

For ASM carried with RTP, the document discusses mapping lifetime because an expired and recreated mapping can change a translated transport address and trigger RTP collision behavior. It recommends retaining a mapping for 60 minutes and removing it when the group is left, while allowing resource pressure to shorten the lifetime no lower than the referenced NAT minimum. A long-lived mapping is a continuity receipt for translated transport state. It still does not prove that a decoder rendered the intended source, or that two SSM senders did not share the same public (S,G).

Build the evidence chain the receiver actually needs

An accountable deployment starts on the inside. Record the sender's operational identity, its private source address, the chosen group, the application configuration generation and the time interval in which that combination was active. Observe the inside (S,G) rather than reconstructing it later from a public packet capture.

At the translation boundary, retain the mapping generation, outside address, translated port where relevant, pooling decision and expiry state. Keep IGMP version, downstream membership, source-filter state and the proxy's aggregate separately. A proxy-state change and a data mapping may be causally related, but they are not interchangeable observations.

On the outside, record the (S,G) that session signaling advertised and the one receivers actually requested. Detect whether several inside sources are contributing to the same public pair. Packet captures need provenance and bounded retention; aggregate counters alone cannot answer the identity question. If the application has a second identity layer, retain the SSRC, CNAME or equivalent binding and the receiver's collision decision.

Finally, measure the outcome at the receiving application: which logical source it selected, which packets it accepted, what it discarded, whether content was mixed, whether timing constraints were met and what was rendered or acted upon. This is the point at which “forwarded” can become “delivered as intended.” Until then, it remains a network-layer observation.

A thin standard, a thick local proof

The document's value is sharpened, not diminished, by this limit. A common specification should define the minimum behavior needed for interoperable forwarding, mapping, scope and proxy state. It should not claim omniscience over application identity or business outcome. The mistake is made later, when an organization turns a conformance label into a statement about reality that the label never measured.

Running code imposes a more disciplined sequence. The RFC defines what the boundary should do. An implementation creates a particular mapping and proxy state. A deployment exposes those behaviors through its topology and configuration. An application gives them meaning. A receiver either obtains the intended stream or does not. Each transition needs its own receipt.

That sequence is the practical reading of a thin coordination layer. Preserve the invariant that must be common. Keep local decisions local. Then insist on auditability at every place where one fact is transformed into another. The result is not skepticism about standards. It is respect for the exact work a standard performs—and refusal to assign it work performed elsewhere.

Sources

  1. RFC 5135, HTML
  2. RFC 5135, plain text
  3. RFC Editor record for RFC 5135
  4. IETF Datatracker record for RFC 5135
  5. RFC 5135 document history
  6. RFC 5135 errata search
  7. RFC 4787
  8. RFC 4605
  9. RFC 3376
  10. RFC 4607
  11. RFC 5760
  12. RFC 3550
  13. RFC 2365
  14. RFC 5771
  15. RFC 1918
  16. RFC 8085
  17. IANA multicast address registry
  18. IANA multicast address registry, XML
  19. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  20. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  21. Running-Code Primary