Embedded RP, with IPv6 multicast, is a very cool trick. It simply embeds the RP IPv6 address as part of the multicast group address. This way, when a multicast router sees the group address, it can extract the RP and begin to use it for the shared tree immediately. The only thing that has to be hard coded on a router is to tell the RP that he is the RP, and that’s it. All the other routers in the network dynamically learn the RP address from the group address. So here is the problem: A 128 bit RP address can’t be embedded into a 128 bit group address and still leave space for the group identity, (at least not without compression).

Here is the topology we are using, which matches the one from the previous posts:

To facilitate the embedding of an RP address int the multicast group address, there are some rules to follow. These are listed in RFC 3956.
First of all, to indicate that a multicast group contains an embedded RP in it, bits 9, 10, 11 and 12, from the left, need to be 0111. Because the first 8 bits are all 1s, an embedded RP multicast address would always begin with FF70::/12 or 1111 1111 0111

To determine an embedded RP from a multicast group address, we include an example from RFC 3956.“The network administrator of 2001:DB8::/32 wants to set up an RP for the network and all the customers, by placing it on an existing subnet, e.g., 2001:DB8:BEEF:FEED::/64.

In that case, the group addresses would be something like “FF7x:y40:2001:DB8:BEEF:FEED::/96″, and then their RP address would be “2001:DB8:BEEF:FEED::y”. There are still 32 bits of multicast group-ids to assign to customers and self (“y” could be anything from 1 to F, as 0 must not be used).”

In our lab example, if we wanted R6 to be an RP, using 2002:6666::6 as the RP address, we could reverse engineer a multicast group to be FF7x:y40:2002:6666::1 (x=scope), or FF7e:640:2002:6666::1. The only configuration that would need to be done is to hard code R6 locally, to tell it that it is a RP, and then all the other routers would extract the RP from the multicast group address.

Here is the breakdown to determine the RP address from the group FF7e:0640:2002:6666::1
This example includes the roles of all 128 bits in the IPv6 embedded RP address, which will assist in understanding it.

8 bits = Multicast (0xFF)
1111 1111

4 bits = Flags (0×7)
0111

4 bits = Scope (0xE)
1110

4 bits Reserved (0)
0000

4 bits RIID (RP Interface Identifier) (0×6)
0110

8 bits Prefix Length (0×40) decimal 64
0100 0000

64 bits Network Prefix (0×2002:6666:0:0)

32 bits group ID (0×0:1)

To determine the RP, is simple.
It is the value of the Network Prefix, with the RIID (4bits) tagged on at the end. Thats it.

Since the prefix length says it is 64 (0×40), we take those 64 bits as the high
order bits of the RP, and add the RIID (4bits) to the low order position, and we are done!

Our final RP address would then be 2002:6666:0:0::6, or 2002:6666::6

Let’s configure R6 locally first.

R6(config)#ipv6 pim rp-address 2002:6666::6
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up

Next we will have R3 join that group, but before we do, let’s see if R3 knows of a RP for the group. After we join the group, R3 will automagically know who the RP is. (Not really magic, it just extracted the RP from the group address).

Looks like it worked. While the ping requests are being sent via multicast to the group, the replies from R3 are unicast. Let’s take a peek at R4 who is in the transit path between R5 (the server) and the listener R3.

Thanks for this excellent article! I think this is a really cool feature of IPv6. I have been going over the RFC and I just don’t quite get why it doesn’t matter what the right-most digit in the address is (as long as it between 1 and F). I.e. ,
in “FF7e:640:2002:666::1″, why a ’1′ here?

Hello Marcel- Thanks for your comments. I updated the post with a breakdown of all 128 bits and what they do. This should shed some additional light on the subject.

Regarding your direct question, the multicast group we choose to use is based on our choice, that is why the last 4 bits of the multicast group can be anything we want, (except for a 0). The group FF7e:640:2002:666::1 could be used for multicasting video, and group FF7e:640:2002:666::2 could be used for multicasting audio, and the RP would be the same one for these 2 groups.

Ole- I am with you! I work on several different racks, and agree. I will make sure to mix up the topology for future IPv6 posts. Without a tunnel interface, and without the tunnel being set to a type 6to4, the use of the 2002 initial 16 bits shouldn’t cause any strange behavior.

Leave a Reply

Currently you have JavaScript disabled. In order to post comments, please make sure JavaScript and Cookies are enabled, and reload the page.Click here for instructions on how to enable JavaScript in your browser.