Bidirectional multicast is not different in IPv6.
Rather than explain the entirety of BiDir PIM again,
I'll focus on a high‑level recap and then show you how it works in IPv6.
In this module, we'll recap bidirectional PIM and its basic operation.
We'll demonstrate BiDir PIM for IPv6 to see what multicast
state looks like at the command line.
We'll finish off with packet capture analysis including a PIM Hello,
a join, and a few DF election packets.
Globomantics plans to finish its IPv6 lab testing with an
implementation of bidirectional PIM.
The same considerations for IPv4 exists in IPv6,
including tracking many‑to‑many flows and ensuring the router
resources aren't eaten up by excessive state tracking between
multiple sources and receivers.
As a refresher,
bidirectional PIM is intended to solve a very specific multicast use case,
that of many sources and receivers.
Normally,
each S,G flow is tracked separately to ensure optimal flow
between the source and its receivers.
The state is tracked by the router and it consumes
precious resources to keep them in memory.
For tens of flows, this may not be an issue,
but what if it were hundreds, thousands?
The scale quickly gets out of hand when we have a network full of
sources who can also be receivers and vice versa.
BiDir PIM achieves scale by ceasing to track the sources altogether,
and instead, establishes suboptimal,
but scalable traffic flow through a rendezvous point.
Because the rendezvous point is always in the data plane
and at the root of the shared tree,
the traffic will never switch to a source tree.
This is expected as if we don't track sources,
we can't send PIM joins toward them either.
Because the rendezvous point no longer handles source registration,
it instead acts as an arbitrary point from which the
bidirectional shared tree is built.
Just like IPv4,
the main workhorse of BiDir‑PIM in IPv6 is the designated forwarder election.
We talked about the designated forwarder in the IPv4 BiDir PIM,
but it bears repeating and works the same in IPv6.
The designated forwarder is elected based on the shortest
path to the RP for each segment and link.
It is the sole router on a segment that can forward multicast
downward to receivers or upward towards the RP.
The DF is also the one that forwards the PIM joins upstream to the
RP to help build the outgoing interface list.
It is the oil that ultimately determines where
multicast flows downward from the RP.
All source traffic flows upstream to the RP regardless of PIM joins.
The DF is also the only router which will deliver multicast to
any local segment where there are receivers.
There is no PIM assert in bidirectional PIM.
One more time,
let's walk through the DF election and what that
means for building the shared tree.
Starting with the RP, which is the root of the shared tree,
each segment outward must have a designated forwarder.
Remember that the router elected the designated forwarder will be the one
delivering downstream multicast and forwarding PIM joins upstream.
Importantly,
the field in a PIM Join's upstream neighbor field will always be
the DF of the upstream link when forwarding.
Moving to the next routers outward from the RP link,
we start seeing specific pathings starting to take place.
Each router attached to a link compares its unicast best path
metric to the RP address and announces it.
The best metric wins the DF election.
If there is a tie of metric, the highest PIM neighbor IP wins.
The process is very similar to the spanning tree root bridge
election with an RP acting as the root.
Much like spanning tree and VLANs,
different multicast groups can use different RP addresses for this process,
resulting in a different shared tree.
We talked about phantom RP in IPv4 bidirectional PIM,
but the concept still applies in IPv6 and works exactly the same.
Unlike any source multicast, the rendezvous point,
as in BiDir PIM, doesn't need to register sources,
in fact, it doesn't need to do anything.
There is no source registration so there is no need for the RP
to send a join towards an upstream source.
The RP becomes just an arbitrary point in the network from
which we plan to build a shared tree.
All routers have to agree on the RP,
but only so we can determine what's upstream and
downstream and elect the designated forwarders.
The RP address doesn't need to be tied to an actual device.
Just to cover all the bases,
we'll walk through phantom RP one more time and
reemphasize the caveats which still apply.
First, in order to use a phantom RP,
we need to advertise some arbitrary link into the network.
There are a lot of ways to accomplish this,
but we usually see it as a loopback address.
We also need a way for everyone to agree on the RP address,
but only static configuration for phantom RP is supported in IPv6.
Next, we need to ensure that the RP address is not local to any router.
The reason why we don't want any router to process the PIM
join is because the PIM joins are only being used to create
an outgoing interface list.
There'll be no need for an RP to send a source tree join.
Providing redundancy for a phantom RP means making sure there are
multiple arbitrary places within the network that can serve as the
RP in case of a router or link failure.
In our example, MCAST2 has a loopback configured that's also advertising,
but notice that the subnet mask is a shorter match than MCAST1.
This means if MCAST 1 fails,
the rest of the PIM routers will still have an RP address to use,
though such a failure would necessitate a DF
reelection and recalculation of best path.
MCAST2 is the backup phantom RP because,
even though the prefix is the same,
the subnet mask is less preferred by the unicast routing table.
If you remember from IPv4,
there is a very good reason we don't want local routers to have the
IP configured for an RP in bidirectional PIM.
If a receiver sends an MLD report and the PIM joint needs to be
forwarded to the RP and the best path to the RP happens to be through
another router with a phantom RP link configured,
even though it should be forwarded to the correct RP,
if the PIM Join were to reach a router serving as the backup phantom RP
and that interface IP was the same as the RP address,
the PIM Join would stop there and the local router
would try to process the PIM Join.
It wouldn't be forwarded upstream.
If the RPs within the subnet of the link,
but not the IP itself,
every PIM router will correctly forward it to the
current best phantom RP address.
The most important thing to remember is that for phantom RP to work,
the RP address must fall within the subnet of the advertised links,
but not be assigned to a router.
Redundancy is achieved by advertising backup phantom
RP links with shorter matches,
though the RP address still needs to fall within that subnet.
To wrap up the recap,
very little changes between IPv4 and IPv6 bidirectional PIM.
The RP has to be configured for bidirectional groups, but that's it.
The DF election and avoidance of multicast loops depends on every router having
the same RP address and agreeing on where the RP link is at.
That's because every PIM router will send multicast source
traffic towards the RP via the BiDir upstream interface
without waiting for an OIL to be built.
PIM joins for the shared tree will also be forwarded to the RP link and
it's that that builds the outgoing interface list downward to the
receivers so it's vital that every router agree on the forwarding
shared tree to get traffic from the source down to a receiver without tracking sources themselves.