Embedded RP- IPv6 multicast tips and tricks (Part 3)

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).
You may want to visit the 2 previous posts on IPv6 multicast using static RPs using this link, or BSR mapped RPs using this link.
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).

R3#show ipv6 pim group-map ff7e:640:2002:6666::1
IP PIM Group Mapping Table
(* indicates group mappings being used) 

FF00::/8*
    SM
    Info source: Default
    Uptime: 00:00:17, Groups: 0

R3(config)#int lo 0
R3(config-if)#ipv6 mld join-group ff7e:640:2002:6666::1
R3#show ipv6 pim group-map ff7e:640:2002:6666::1
IP PIM Group Mapping Table
(* indicates group mappings being used) 

FF7E:640:2002:6666::/96*
    SM, RP: 2002:6666::6
    RPF: Fa0/0,FE80::244:44FF:FE44:4444
    Info source: Embedded
    Uptime: 00:00:02, Groups: 1

Let’s take a look at R6,  who is the RP

R6#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
       C - Connected, L - Local, I - Received Source Specific Host Report,
       P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
       J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State

(*, FF7E:640:2002:6666::1), 00:05:57/00:02:33, RP 2002:6666::6, flags: S
  Incoming interface: Tunnel2
  RPF nbr: 2002:6666::6
  Immediate Outgoing interface list:
    FastEthernet0/0, Forward, 00:05:57/00:02:33

Now we will generate some multicast traffic, destined for that group, from R5.

R5#   ping ff7e:640:2002:6666::1
Output Interface: fastethernet0/1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF7E:640:2002:6666::1, timeout is 2 seconds:
Packet sent with a source address of 2002:45::5

Reply to request 0 received from 2002:3333::3, 272 ms
Reply to request 1 received from 2002:3333::3, 64 ms
Reply to request 2 received from 2002:3333::3, 104 ms
Reply to request 3 received from 2002:3333::3, 80 ms
Reply to request 4 received from 2002:3333::3, 84 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/120/272 ms
5 multicast replies and 0 errors.
R5#

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.

R4#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
       C - Connected, L - Local, I - Received Source Specific Host Report,
       P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
       J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State

(*, FF7E:640:2002:6666::1), 00:05:35/00:02:56, RP 2002:6666::6, flags: S
  Incoming interface: FastEthernet0/1
  RPF nbr: FE80::255:55FF:FE55:5555
  Immediate Outgoing interface list:
    FastEthernet0/0, Forward, 00:05:35/00:02:56

(2002:45::5, FF7E:640:2002:6666::1), 00:02:32/00:00:56, flags: ST
  Incoming interface: FastEthernet0/1
  RPF nbr: FE80::255:55FF:FE55:5555
  Immediate Outgoing interface list:
    FastEthernet0/0, Forward, 00:02:32/00:02:56

 

R4#show ipv6 pim group-map
IP PIM Group Mapping Table
(* indicates group mappings being used) 

FF7E:640:2002:6666::/96*
    SM, RP: 2002:6666::6
    RPF: Fa0/1,FE80::255:55FF:FE55:5555
    Info source: Embedded
    Uptime: 00:17:31, Groups: 1

For more information on embedded RP with IPv6 multicast, check out our workbooks as well as RFC3956.