PIM-SM IPv6 using Embedded RP
Load multicast.init.cfg
Configure R9 and XR4 with addresses 2001:db8:1:1::X/128 where X is the router number.
Using embedded RP, join R2 to two groups, one per RP. R4 should be able to send traffic to these groups and get a response from R2.
Answer
Explanation
IPv6 multicast addresses are so large that we can easily embed information into the group address itself.
One way that information is embedded is by setting the scope in the multicast address. The scope is set as the fourth hex character. The following scopes are defined:
Prefix
Scope
FF01
Interface Local
FF02
Link Local
FF04
Admin Local
FF05
Site Local
FF08
Organization Local
FF0E
Global
Additionally, the thrid hex character is made up of four flags:
The flags are composed as follows:
Reserved
Always set to 0
R (RP embedded)
When set to 1, indicates that RP information is embedded. The P and T bits must also be set to 1.
P (Prefix embedded)
When set to 1, indicates that address prefix information is embeddd in the multicast group address. When set to 1, the T bit must also be set.
T (Transient/Temporary)
When set to 1, it indicates a transient/temp address. When set to 0, it indicates a well-known/IANA-allocated address.
Embedding prefix information is done for two puroses - one is embedding the RP, and the other is to produce organizationally-unique address blocks.
For IPv4, we had the GLOP space, in which the organization’s 16bit AS could be embedded into the group address to produce a unique group address block. However, this was problematic because many organizations have 32 bit ASNs, not 16 bit.
The IPv6 equivalent of this is using a unicast-prefix embedded group block. The P and T bits are set to 1, and the prefix length and network prefix are embedded into the group address itself. This produces a unique group address block that cannot overlap with any other organization’s group addresses. For example, if an organization owns 2001:db8:1::/48, this maps to FF3X:0030:2001:db8:1::/96. The X is the scope, the next 00 is because the RIID is not used. The 30 is the prefix length in hex (48), then the actual prefix follows. The organization is left with 32 bits for group IDs to use in this block.
This embedding technique is also used by the embedded RP feature. Instead of encoding a global unicast prefix block however, we embed the RP’s loopback address by encoding the prefix and then encoding the RIID (RP’s Interface ID). We only have 4 bits for the RIID (one hex character), and it cannot be 0, so it must be in the range 1-F. The maximum prefix length is 64.
For example, the addres FF75:0140:2001:db8:100:200::1234 means the following:
FF7 means that this is a multicast address and the R, P and T flag are all set. This means that this is an embedded RP address.
The next 5 means that the scope is site local.
The next 0 is reserved
The next 1 means that the RP’s Interface ID is 1.
The next 40 means the following prefix is 64 bits long (0x40 in hex)
Next is the prefix itself - 2001:db8:100:200::/64
Finally, we have the group ID which is 0:1234
So the RP address for the multicast group above is 2001:db8:100:200::1.
Note that you can also use prefix lengths less than 64, for example a /32. The prefix length just tells the router where the RP’s prefix ends and the multicast group begins.
By using this technique, senders and receivers can signal the RP within the data plane itself (the multicast address) and we don’t need to statically or dynamically (BSR) define the RP in the network. Note that this can only support RP redundancy by using an Anycast IP as the embedded RP address. Also note that embedded RP is not supported for PIM Bidir (I believe because there is no way to signal that the RP is bidir-capable by using this method).
As an aside, the SSM range also uses the P and T bits set to one. SSM ranges begin with FF3X, where X is the scope. However, SSM always sets the prefix length and prefix to all zeros. So you can think of the SSM ranges as using this embedded address format but with all zeros as the “host/prefix.” (This works because the host is signaled as a separate field in MLDv2 - it never needs to be signaled within the embedded group address. So SSM can use this same range but always with zeros as the host/prefix).
Let’s now test the embedded RP feature. To start, all routers simply support basic IPv6 PIM and form IPv6 PIM adjancencies. All we need to do is define the loopbacks on the RPs, advertise them into the IGP, and then send/receive traffic to the correctly-calculated group addresses.
Additionally, we also need to tell the RPs that they are acting as RP at those addresses. Otherwise, these routers will reject Registers destined to them and reject PIM Joins destined for them as RP. When you define the RP as a local address, the router automatically creates the PIM tunnels which are used for decapsulating PIM Registers.
Without doing this step, the router rejects PIM Registers. For example:
So we must define the local loopback address as an RP address. On IOS-XE this is done by simply defining the router as an RP. On IOS-XR, this is accomplished by defining the router to act as an embedded RP for a given group range. On IOS-XR, defining the router as an RP does not work, because IOS-XR has a default ff70::/12 range for embedded RP which points to a null RP. Even if you define the router as an RP statically, the group ranges in ff70::/12 will always be rejected because the RP is null (::) for that range. You must manually populate the IOS-XR IPv6 group mappings with embedded ranges.
On R2, we’ll enable IPv6 multicast and join two groups:
FF75:940:2001:db8:1:1::1234
The RIID is 9 and the prefix is 2001:db8:1:1::/64
FF75:e40:2001:db8:1:1::1234
The RIID is E and the prefix is 2001:db8:1:1::/64
On R5, we see two (*, G) entries are created, and the RP address has been extracted from the group address:
This can also be seen in show ipv6 pim group-map
The (*, G) joins make their way to both RPs:
If we send traffic from R4, we should see a reply from R2.
XR3, acting as FHR, finds the RP information embedded in the group address, and registers the traffic with the RP. This is normal PIM-SM behavior except the RP is learned via the group address itself. Note that this is buggy on the CSR1000v - it will successfully decode the RP address but will not register the packets. For this reason we can only use XRv as the FHR.
Summary
Embedded RP is a neat feature for IPv6 PIM which allows you to embed the RP address directly in the IPv6 group address. The RP’s interface ID, prefix, and prefix length are encoded in the address. Routers will extract this from the group addresses in the ff70::/12 range automatically. This means that you do not need to set the RP anywhere. All you need to do is define the local RP as an RP so that it creates the decap Register tunnels and accepts PIM Joins. On IOS-XE this is defined simply by setting ipv6 pim rp-address <loopback>. On IOS-XR this is defined by setting embedded-rp <loopback> <ACL referencing ::/96 range>.
The slight problem with this is that the application must have a way to learn the RP address to be able to encode the address into the group address anyways. In my opinion, it seems to be a similar level of difficulty for the application to learn the source address instead, and SSM could be used instead of SM. However, for applications in which there are many sources, this could be a good use case.
Also note that embedded RP could be considered a security risk, as the hosts are the ones who dictate which router is the RP. If you don’t want to allow hosts to be able to do this, you can disable the embedded RP feature on a router using no ipv6 pim rp embedded on IOS-XE and router pim add ipv6 embedded-rp disable on IOS-XR.
Last updated
