10.4 IPv6 Multicast and related Multicast protocols
This section goes into IPv6 multicast in more detail, starting with the equivalent to IGMP for IPv4: Multicast Listener Discovery.
10.4.1 Multicast Listener Discovery (MLD)
Multicast receivers must inform their local subnet multicast router that they want to receive multicast traffic. Hosts perform this signaling using a protocol known as Multicast Listener Discovery, or MLD, which is based on IGMP and performs the same tasks as IGMP does in IPv4 networks. MLD also uses ICMPv6 messages in its operation.
In IPv6 networks, routers act as MLD queriers to determine which hosts want to receive traffic for a particular multicast group. Hosts are receivers, including routers, that want to receive that multicast traffic.
MLD hosts send report messages to MLD queriers to inform them of their desire to receive that multicast traffic.
MLDv1 is based on IGMPv2; MLDv2 is based on IGMPv3. Like IGMP, MLDv2 is backward-compatible to MLDv1 hosts and allows for MLDv1-only, MLDv2-only, and networks with mixed MLDv1 and MLDv2 hosts.
In Cisco switches, MLD snooping provides the same functionality as IGMP snooping for IPv4. That is, it provides information to the switch about which connected hosts are members of a particular multicast group so that the switch can make decisions about whether, and on which interfaces, to allow traffic for that group to flow through the switch.
Configure a router interface to statically join a specific multicast group (in this case FF04::EE), regardless of whether any other group members are present on this interface, as follows:
TK1(config-if)# ipv6 mid join-group ff04::ee
10.4.2 Explicit Tracking
Explicit tracking allows a multicast router to track the behavior of hosts within the IPv6 network. This feature also supports the fast-leave mechanism in MLDv2, which is based on the same feature in IGMPv3. Explicit tracking is disabled by default; you can enable it on an interface by using the command ipv6 mld explicit-tracking access-list-name.
10.4.3 IPv6 PIM
IPv6 PIM supports two modes of operation: sparse mode (SM) and source-specific multicast (SSM). PIM for IPv6 does not support dense mode. As is true in IPv4 PIM sparse mode, IPv6 PIM requires a Rendezvous Point (RP) to be statically defined at the RP router. However, other PIM-SM routers can learn about the RP using embedded RP support. This feature works by embedding information about RPs in MLD report messages and PIM messages. Routers then watch for the RP for each multicast group and use that RP for all PIM-SM activities. You can statically override embedded PIM information by specifying RPs on a per-group basis.
10.4.3.1 PIM DR Election
On broadcast interfaces, the PIM designated router (DR) is responsible for sending PIM Register, Join, and Prune messages toward the RP. In IPv6 PIM, DR election works exactly as in IPv4. That is, by default, the PIM router with the highest unicast IPv6 address becomes the DR. You can also statically configure the PIM DR by assigning priority values. (The highest priority wins the election.) If the DR fails, the PIM router with the highest remaining priority becomes the DR. The IPv6 address is again the tie-breaker.
10.4.3.2 Source-Specific Multicast
Source-specific PIM is derived from PIM sparse mode. It is more efficient than sparse mode. In sparse mode, a PIM Join message from a host results in sending traffic from all multicast sources toward that receiver. SSM instead uses the (S,G) model from the start to deliver multicast traffic to a particular group member from only one source, which the joining host specifies, rather than from all multicast senders for that group. SSM requires MLDv2 to operate, because MLDv1 messages do not contain the required information to support SSM. However, SSM mapping supports MLDv1 hosts by either DNS or static hostname-to-IPv6 address mappings. This allows routers to look up the source of a multicast stream when they receive an MLDv1 Join message. This feature permits extending SSM to MLDv1 hosts, in keeping with SSM's concept of maximizing multicasting efficiency.
SSM mapping must be enabled globally on a router by using the ipv6 mid ssm-map enable command. SSM mapping uses DNS by default. Disable DNS lookup for SSM mapping by using the no ipv6 mid ssm-map query dns command. Specify static mappings by using the ipv6 mid ssm-map static access-list-name source-address command.
10.4.3.3 PIM BSR
As in IPv4 PIM, every sparse-mode multicast group must be associated with the IPv6 address of an RP. PIM BSR performs this association automatically and adapts to changes in RP mappings to provide resiliency in the event of RP failures.
10.4.3.4 Additional PIM Concepts and Options
All the IPv6 concepts of shared trees, shortest-path trees (SPT), switching between shared trees and SPTs, bidirectional PIM, and the RP behavior of tracking multicast groups and senders are identical to IPv4 PIM. The command structure for configuring PIM is also nearly identical to IPv4. In IPv6, the ipv6 keyword precedes specific interface commands, instead of IP. Also, some additional command-line arguments exist for the IPv6 commands.
10.4.4 IPv6 Multicast Static Routes
Just as in IPv4, multicast routing fundamentally builds its routing table based on the unicast routing table. Before any multicast traffic can be routed, that traffic must pass the router's RPF check. That is, it must have arrived on the interface that the router's unicast routing table indicates is the correct path back toward the traffic source.
For tunnels, in particular, the RPF check can cause problems. If multicast traffic arrives over a tunnel instead of the physical interface over which the unicast routing table indicates that traffic should have arrived, then the router will discard that traffic. To prevent this behavior, you can configure static multicast routes to instruct the router as to which interface the traffic should arrive on. This will allow the RPF check to pass. In IPv6, unicast and multicast static routes use the same command, ipv6 route, but with different options.
For example, if you expect all multicast traffic on a router to arrive over the tunnel0 interface, configure the static multicast route as follows:
TK2(config)# ipv6 route ::/0 tunnel 0 multicast
Configuring Multicast Routing for IPv6
The first step in configuring multicast on a Cisco IOS router or switch is to enable multicast routing:
TK3(config)# ipv6 multicast-routing
Once multicast routing is enabled, you can configure PIM on the desired interfaces, adjust MLD configuration, and enable any other necessary features such as BSR, MLD, and so forth.