A new concept with IPv6 multicast is the concept of scoping.
This is difficult to understand for IPv6 novices,
but remember that IPv6 was designed with a global scale in mind.
This means that it falls to administrators to properly
size and restrict their multicast deployments if for no
other reason than best practice.
While it's unlikely that we'll ever have a full IPv6 multicast
shared over the internet, constraining your multicast scope is
still recommended. In IPv6, the multicast groups themselves
determine the scope of reach.
The first three multicast scopes are automatically derived and do not
require configuration. Interface‑level scope is not sent to other
routers and is akin to a loopback or a localhost.
There are almost no interface local addresses reserved or used in practice.
Link‑local multicast addresses are where most
router‑to‑router communication takes place.
IPv6 has no broadcast component.
Everything is multicast, and so many of the functions
originally performed by broadcast live here,
such as neighbor discovery and DHCPv6.
This is also where most routing protocols live, as well as PIMv6.
Link‑local multicast packets are not forwarded beyond the link.
Realm‑local multicast scope is a difficult one to explain, and it's
partly because of the relative newness and unexplored territory of
IPv6 multicast applications.
Tunneling technologies that are not multicast but use
IPv6 could fit into a realm‑local scope.
The main takeaway is that realm local usually refers to some non‑multicast
protocol that is utilizing IPv6 multicast for transport. Applications using
the scope would want to seek registration with the Internet Assigned
Numbers Authority. Interestingly, the realm‑local scope is specifically
zoned within the larger scopes, and this means we need to ensure that a
realm‑local multicast is kept within the same boundaries we defined for
other multicast, which we'll discuss next.
The scopes get a little tricky at this point because there's no real
enforcement of functional scoping from here on. The RFC for IPv6 addressing,
RFC 4291, defines them, and this definition was updated by RFC 7346, but it
can still start to get a little confusing.
The first administratively configured scope is the admin‑local scope.
This is the smallest scope that can be configured, and it's intended for very
small deployments, not to span across even a single site.
The site‑local scope is intended to cover a multicast
boundary within the same organization,
but at a single site. This means it could cross boundaries
of physical location and encompass a more logical site as
defined by administrators.
The organization‑local scope is just what it sounds like.
This scope is intended as a boundary for multicast to ensure it's not
extended beyond an administratively defined organization.
In this case, geographical boundaries would be more secondary to ephemeral ones.
The last scope isn't listed because it has no
boundary, and that's the global scope,
which is FFE. A multicast group that is scoped globally could in theory
span any number of locations across the globe if the underlying
infrastructure and routers allowed it. In fact,
you may be wondering,
what is it that keeps anyone from doing this. With great scope comes great
responsibility. When planning an IPv6 multicast deployment,
it's important to understand the spread your multicast streams need to cover.
While nothing is forcing a particular scope, in fact, scopes are somewhat
arbitrary between the realm local and global scale.
It's important to at least understand the impact scoping can have to control
how far your sources and receivers can be from each other.
BSRs and RPs can accept certain group ranges or offer to serve
only certain scope sizes, and this is an easy way to control what
scope is allowed in your deployments.
We can also configure BSR borders to ensure we don't accept bootstrap messages
on untrusted interfaces, and nor will we propagate them.
Remember that IPv6 uses multicast by default, and this is
another reason that scope should be considered. In IPv4, it was
extremely simple to control the scope.
We simply just didn't run PIM with untrusted neighbors.
IPv6 uses multicast for everything that we once used
broadcast to accomplish, so this is not so easily deactivated
now. I encourage some further reading.
It's difficult to explain all the details of IPv6 address architecture,
even as it pertains to multicast because it's heavily tied into IPv6 as a
solution. These RFCs give a clearer picture of the intention of multicast address scoping and are a great reference.