PIM SSM works the same in IPv6 as in IPv4 with a few small differences,
mainly around the SSM range.
In this module, we'll discuss the following,
we'll recap the operation of PIM SSM; then we'll see a demonstration
of IPv6 source‑specific multicast in action; last,
we'll look at packets that matter for source‑specific,
multicast MLDv2 and the PIM PIM/Prune.
Globomantics is pushing forward with their IPv6 lab testing,
now incorporating source‑specific multicast into the mix.
The goal is to determine what differences exist and account for
them in an eventual production deployment.
Just like IPv4,
IPv6 PIM SSM gives control of the multicast traffic to the receivers.
There is no need for complex rendezvous point systems if a
method exists for receivers to know what sources are available
and send those requests directly.
The receiver issues an MLDv2 report requesting the SSM group and
source from which it wants to receive the stream.
Using the IP of the requested source,
PIM joins are forwarded according to the incoming interface as
determined by the Unicast routing table.
The outgoing interface list is built downward based on the interfaces
on which upstream routers receive the PIM joins,
as always.
Once the first‑hop router adds the interface to its oil,
the traffic flows down according to the outgoing
interface list built by this PIM joins.
Just like in IPV4, because we're dealing exclusively with S,
G pairs and the receiver only subscribes to the source of the request,
we can reuse multicast groups and not have to worry about blending traffic.
Though stricter requirements for IPv6 SSM are still in place,
the network must support it.
The IPv6 PIM SSM RFC reserves ff3x::/16 as a
special range for groups to run SSM.
The reason routers have to know what range is acting as the SSM group ranges
simple, a multicast group in the SSM range must be requested with a source for
the RFC. Sending an any‑source PIM join to a multicast group in the SSM range
is not supported and will be ignored.
Your receiver must support MLDv3.
The protocol is 20 years old now,
so there's not much excuse for it not to be supported.
But having said that, the protocol does still see low adoption rates.
Your receiver just needs to be able to know what to ask for.
In the case of IPTV as an example,
a channel browser is supplied to a set‑top box so that the
remote can browse through the feeds.
The set‑top box has the list of all the sources, and the remote
chooses what source to request by flipping channels.
Of course, every rule has exceptions. And just like in
IPv4, IPv6 PIM SSM mapping is supported.
The specifics are a bit beyond the scope of the course,
but at a high level,
a router can use DNS or a static access list to take an
any‑source MLD report for an SSM group and automatically resolve
the source then forward the PIM join as if the source had been
requested directly by the receiver.
It's intended as migration strategy and not as a full implementation,
but it can help to implement SSM in a network where older receivers that don't support MLDv2 still need multicast.