A simple proposition emerged to embed the RP address in the multicast address. This proposal is called Embedded-RP [RFC3956]. This seems impossible as both the RP address and the multicast address are 128 bits long. But making assumptions on the interface identifier of the RP, this solution is applicable.
An embedded-RP address structure is defined above:
Then an embedded-RP IPv6 multicast address for the RP having the address 2001:660:3307:125::3 will be FF7x:340:2001:660:3007:125:aabb:ccdd (aabb:ccdd being the group-ID chosen in this example); "x" can be any hexadecimal value as embedded-RP can be used for any address scope. The embedded-RP solution requires that the RPs have unicast addresses with interface identifiers having all bits, except the 4 low order bits, set to zero.
Required modifications to PIM-SMv2
Embedded-RP requires that the group-to-RP mapping algorithm is changed. When a packet comes into the router with a destination address in FF70::/12 prefix, the RP address is retrieved as explained above.
Embedded-RP must be supported on all the routers of the shared tree, the RP and the DR of the sources and receivers. The support on the source tree is not required because the messages exchanged are PIM (S,G) prune/join. Nevertheless, one has to be aware that support on all routers eases the deployment and management of embedded-RP.
Impacts on the network
The IPv6 inter-domain multicast with embedded-RP is very different from what is done today in IPv4. The biggest change is that the PIM domains disappear with embedded-RP: the IPv6 multicast internet is a unique PIM “domain” where multiples rendezvous points are configured.
• A side benefit of embedded-RP is that the address allocation problem is much easier than with IPv4. It is difficult to say now if this model will be accepted and deployed. Even if tests showed that the technology worked fine, some questions remain about the impacts caused by differences with the model known and deployed today. Also some general problems of the ASM case remain. For example: the third party dependency, multicast packets from domain A to domain B have to go through the domain of the RP;
• there is no source control: any source on the Internet can send into any inter-domain group;
• multicast data packets are encapsulated towards the RP (at least initially).