Skip to main content

3. IPv6 Considerations

In order to avoid confusion, the previous discussions have been based exclusively on IPv4. The equivalent protocol for IPv6 is Multicast Listener Discovery [MLD]. As MLD is based on IGMP, the complete description and recommendations are not repeated here; instead, only the cases where MLD differs from IGMP are pointed out.

The control and data forwarding rules described for IGMP in Section 2 can be applied to MLD with few considerations; that is, the basic functionality of intercepting MLD messages and building membership and multicast router lists is the same as for IGMP.

IPv6 data forwarding is simpler than IPv4 in one respect: MLD is mandatory for addresses in the scope 2 (link-local) and greater ranges. The only exception is the all-hosts link-local address FF02::1, which never sends MLD messages; packets destined to the all-hosts link-local address should be forwarded on all ports.

Groups with addresses in FF00::/15 (which covers the reserved FF00::/16 and the node-local FF01::/16) do not send MLD messages, and these addresses should therefore never appear in packets on the link.

The following differences between IPv4 and IPv6 are relevant to snooping:

  1. The protocol for IPv6 multicast group maintenance is called Multicast Listener Discovery Version 2 [MLDv2]. MLDv2 uses ICMPv6 message types instead of IGMP message types.

  2. [IPV6-ETHER] and [IPV6-FDDI] describe how the 32 bits of the 128-bit Destination IP (DIP) address are used to form the 48-bit Destination MAC (DMAC) address; [IPV6-TOKEN] describes the mapping for Token Ring DMAC addresses using the three low-order bits; and [IPV6-1394] uses a 6-bit channel number.

  3. Multicast router discovery is performed by the MRDISC protocol as defined in [MRDISC].

Equivalent to the IPv4 behaviors regarding the null IP Source address, MLD membership reports must not be rejected by an MLD snooping switch because of an unspecified IP source address (::). Additionally, if a non-Querier switch spoofs any General Queries (as addressed in Section 2.1 above, for Spanning Tree topology changes), the switch should use the unspecified IP source address (::) when sending said queries. When such proxy queries are received, they must not be included in the Querier election process.

The IPv6 header does not include a checksum field. However, a switch should, to the extent possible, detect other packet integrity issues, such as consistency between the address version and the payload length. If such errors are detected, the information in the packet must not be incorporated into the MLD forwarding table, and the forwarding code should discard the packet and take such reasonable follow-up actions as discussed earlier.

Since MLDv2 uses ICMPv6, and ICMPv6 has several other uses besides MLD, relying solely on the next-header field in the IP header being ICMPv6 to determine whether a packet is related to MLD snooping is no longer sufficient. A software implementation that treats all ICMPv6 packets as candidates for MLD snooping can easily fill receive queues and stall the CPU, defeating the purpose of the snooping function, and will lose non-MLD packets destined for other hosts.

There are two possible approaches to deal with this:

  1. Require the snooping switch to look more deeply into the packet content. This approach is preferable when a configuration option is provided that allows the administrator to specify which ICMPv6 packet types should trigger a CPU redirect; hard-coding packet types lacks flexibility for the introduction of new types in the future.

  2. Combine the ICMPv6 detection with the multicast DMAC address. This approach risks misclassifying new protocols that use ICMPv6 with a multicast DMAC address as MLD.

The first approach is recommended. If such a configuration option cannot be provided, implementers should seriously consider adding it, since Neighbor Discovery messages fall into the category that would be misclassified, and they are critical to the operational integrity of IPv6 networks.

The initial allocation of IPv6 multicast addresses, as described in [RFC3307], covers only the lower 32 bits of the group ID. The mapping of IP multicast addresses to multicast DMAC addresses therefore has a large amount of overlap. The structure of an IPv6 multicast address is:

   |   8    |  4 |  4 |             112 bits                  |
   +--------+----+----+---------------------------------------+
   |11111111|flgs|scop|             group ID                  |
   +--------+----+----+---------------------------------------+

Thus, in Ethernet and FDDI, 2 ** (112 - 32), i.e., more than 1.2e24 unique DIP addresses, map to the same DMAC address, compared with 2**5 for IPv4. However, per [RFC3307], the initial allocation of IPv6 multicast addresses covers only the lower 32 bits of the group ID; this temporarily reduces the ambiguity problem to group IDs with different flag and scope values, but the allocation policy may change in the future. Given this potential overlap, forwarding based on IPv6 addresses rather than MAC addresses is recommended.