Mar
28

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:

IPV6 Multicasting

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.

Happy studies.

 

FF7e:0640:2002:6666::1

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

(shown in hex)

2002:6666:0:0

32 bits group ID

To extract the RP, take x number of bits from

the network prefix field, and that will be the

the beginning of our RP address.In this case

our prefix length field of (0×40, or decimal 64)

means that x = 64 bits.

At the tail end of those 64 bits, we append the

value of the 4 bits that make up the RIID, in our

example that is a value of 6.

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


You can leave a response, or trackback from your own site.

10 Responses to “Embedded RP- IPv6 multicast tips and tricks (Part 3)”

 
  1. Yasir Ashfaque says:

    Oh Man Excellent, i was waiting for this Thanks again :)

  2. Marcel Lammerse says:

    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?

    Thanks again, please keep posting those great articles!

    • 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.

  3. Marcel Lammerse says:

    Makes sense to me now :) Thanks.

  4. mihai says:

    Thank you – nice series.
    Would be able to share with us the IOS ver u used for all these?

  5. Ole Troan says:

    I would recommend against using 2002::/16 (6to4) addresses in examples. Especially without the encoded IPv4 address. That may have unexpected consequences.

    • 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.

      Good eye!

  6. Johan says:

    Hey

    Just a question, what if it is required for R3 to be able to ping the multicast group it joined, would it work ?

    Thanks !

  7. diablo says:

    bsr and this post were really good… thanks!

 

Leave a Reply

Categories

CCIE Bloggers