Summary
- RFC 3956 encoded a prefix length, unicast prefix and small interface identifier into an IPv6 multicast group address so routers could derive one PIM-SM Rendezvous Point without a separate mapping service.
- The group address could be supplied by any user, so implementations still had to reject invalid derived addresses; a valid derivation proved neither that the RP existed nor that joins, registrations, forwarding or receiver delivery succeeded.
Configuration became part of the destination
Multicast receivers ordinarily begin with a group address. They may learn it from configuration, a directory, a web page or another application. RFC 3956 made that address do more work: for a designated range of IPv6 multicast groups, it also contained the information needed to reconstruct the Rendezvous Point used by Protocol Independent Multicast Sparse Mode.
The attraction was inter-domain coordination. IPv6 did not receive the same MSDP source-discovery arrangement used by earlier IPv4 Any-Source Multicast deployments, while Source-Specific Multicast was not treated as a complete near-term substitute. If every router could calculate the group-to-RP mapping from the destination itself, operators needed less distributed configuration and no separate mapping exchange for that choice.
The calculation was deterministic. It was not omniscient.
A whole address would not fit
An IPv6 address has 128 bits. The group address still needed to identify the multicast group, so it could not simply contain another complete 128-bit RP address. RFC 3956 built on the unicast-prefix-based format of RFC 3306. A flag selected the embedded-RP form. A prefix-length field and a portion of a unicast network prefix supplied most of the location; a four-bit RP interface identifier supplied the remaining choice under a constrained address construction.
RIID zero was reserved. Different non-zero identifiers could select different RPs under one prefix, while each complete multicast address still mapped to one RP candidate. Group-ID uniqueness remained outside the specification. Deriving the same RP everywhere therefore did not guarantee that two administrators had coordinated the group itself.
For the embedded range, the mapping received the longest possible match and priority over other group-to-RP mechanisms. That rule prevented two discovery systems from producing competing answers for the same address. It proved selection consistency, not service availability.
The user indirectly chose control-plane traffic
A receiver learned the group, issued an MLD report, and its designated router began a PIM-SM Join toward the derived RP. A sender learned the same kind of group address and its designated router could send initial traffic inside PIM Register messages to that RP. The group address thus influenced where routers sent control traffic and where they tried to assemble source and receiver state.
This made input provenance important. RFC 3956 says the embedded information comes from an untrusted source: any Internet user may supply such a group address. Implementations had to apply at least the validity checks used for RPs learned by other means. The document specifically excludes results in link-local fe80::/10, ::/16 and multicast ff00::/8 ranges.
Passing those checks established that the derived address was permissible as a candidate. It did not authenticate the person who supplied the group, the operator of the prefix, a multicast sender or a receiver. Nor did it grant permission to create a group, send to it or join it. Address syntax had become a routing input, not an access-control credential.
The RFC said the existence claim could not be made
PIM-SM specifications expect a configured or learned RP address to be reachable across the domain. RFC 3956 confronted the limit directly: reachability cannot generally be proven, and with foreign embedded RPs one cannot even guarantee that the RP exists.
That sentence separates several observations that network dashboards often compress. A route to the derived address means a forwarding table has a candidate next hop. It does not prove that the endpoint runs PIM-SM, accepts Registers, maintains the correct source state, has sufficient resources or returns useful control messages. A successful Join creates state along some path; it does not prove that a source has registered or that data reached the receiver. A mapping cache proves only that a router once performed or stored the derivation.
The address also makes the RP more visible as a single point of failure. Visibility can improve troubleshooting and concentrate attacks at the same time. It is not a health check. Hiding a group from MSDP advertisements was already obscurity rather than access control; the embedded form did not transform discoverability into protection. Boundary scoping and explicit policy remained separate tools.
The surrounding protocols kept their own authority
RFC 4601 later specified PIM-SM's Join, Register and shared-tree behavior in detail. RFC 3810 defined MLDv2 host membership reports. Those records occupy different positions in the chain. A local membership report asks the first-hop network to receive traffic; it does not attest to a remote RP. A PIM state entry records a control decision; it does not certify packet delivery.
RFC 4607 described Source-Specific Multicast, which avoids an RP by using a source-and-group channel. RFC 3956 discussed SSM as an important alternative without treating it as an immediate universal replacement. The comparison matters historically, but it does not change the evidence boundary: naming more of the intended path still does not prove its current operation.
RFC 7371 later updated the IPv6 multicast addressing architecture. The RFC Editor record and errata page preserve RFC 3956's own publication state. None of these records prove adoption by a particular network or current vendor behavior.
Embedded-RP worked by making one result reproducible. Reproducibility is valuable: it reduces inconsistent configuration and makes failures easier to localize. But a reproducible candidate is still a candidate. The group address named where the control plane should try. Routes, PIM exchanges, RP source state, forwarding counters and receiver observation had to establish every stronger claim.
Sources
- RFC 3956 — Embedding the RP Address in an IPv6 Multicast Address
- RFC 3956 metadata
- RFC 3956 errata
- RFC 3306 — Unicast-Prefix-based IPv6 Multicast Addresses
- RFC 4601 — PIM Sparse Mode
- RFC 3810 — MLDv2
- RFC 4607 — Source-Specific Multicast for IP
- RFC 7371 — IPv6 Multicast Addressing Architecture Update
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
