One of the more interesting features in IPv6 multicast is the embedded RP.
We know that to pair sources and receivers with PIM
ASM we need a rendezvous point.
We also know that for the solution to work,
every PIM router needs to agree on the RP address.
What if I told you we could use some of the 128 bits of a
multicast address to communicate the RP it will use,
thus obviating the need for local configuration or dynamic election of one.
Introducing RFC 3956, or the embedded RP.
We can't understand the embedded RP feature without first
understanding the modified multicast packet format.
The format we use today for embedded RP began its life in RFC 2373
as a single format for all multicast packets.
At that time, there was only a single flag for use, which was the T bit.
T indicated whether the multicast group was a well‑known
group registered with the Internet Assigned Numbers
Authority or if it was a transient group.
If the bit was set to 0, this indicated it was well known,
and if it was set to 1, it was a nonpermanent transient address.
For example,
the all‑nodes multicast group has its T bit set to 0 as it is well known.
If it were transient, the address would be FF12::2.
In RFC 3306,
we gain the ability to add unicast prefix information in a multicast address.
The main goal of this was to allow engineers to identify
from where a group might be coming and to support an IPv6
source‑specific multicast range.
The addition of the P flag, or prefix bit,
signals that a unicast prefix is embedded in the group address.
Since this setup would not involve well‑known addresses,
the T bit must also be set to 1.
Setting the T and P bits both to 1, or 0011, is binary 3.
It's no coincidence that the IPv6 PIM‑SSM range begins with FF3.
The prefix length field was also added to indicate how many bits
were in the embedded network prefix, and of course the network
field was for the prefix itself.
This left only 32 bits for the group ID, but was still
plenty considering the constraints. It should be noted
that if the P bit was set to 0,
this packet format would not be used and instead it would use the
packet format as defined in the previous RFC. RFC 3956 initially
introduced the idea of embedded RP.
Specifically,
it used 4 bits of the reserved field to use as an RP interface identifier,
and it added a new flag called R to the flags field.
The R flag indicates that an embedded RP is present if it's set to 1.
The use of an embedded RP implies an embedded unicast
prefix, so the P bit must also be set to 1. And since
there's no well‑known group like that,
the transient bit must also be set to 1. 0111 is binary 7, so the
embedded RP multicast groups had to start with FF7.
The current RFC is RFC 7371 and includes some minor
updates, mostly to address scalability.
The reserved field is now a second flag field with 4 R bits set to 0
for future use. The 0 flag in the first flag field is now an X that
can optionally be set to 1 or 0 for some use. This flag is
independent of the other bits in the first flag field, so an embedded
RP group can now start with FF7 as before or FFF if all the bits are
set to binary 1.
For those who may still need some practice converting
binary to hex, 1111 is binary 16 or hex F.
Here, I've just illustrated the resulting embedded RP
group that we're going to use in the lab.
The prefix of our RP is 2003:1:1:1::1 and is a loopback on MCAST1. In the demo
coming up, we'll see the PIM routers automatically extract that without having
the RP set or learned locally, and both the PIM Join and multicast stream will be correctly forwarded to that RP.