IPv6 Essentials

Multicast Group Management

In Chapter 3, we discussed the use and format of multicast addresses. Multicast group addresses are used as an identifier for a group of nodes. They are identified by a high-order byte of FF. A protocol is required to manage the efficient routing of packets with multicast group addresses as a destination.

Multicast group management in IPv4 is done through Internet Group Management Protocol (IGMP). Version 2 of IGMP is defined in RFC 2236. IPv6 uses ICMPv6 messages for the same functionality; development was based on IGMPv2 specifications. It is now called Multicast Listener Discovery (MLD), and is defined in RFC 2710.

All MLD messages are sent with a link-local IPv6 source address and a hop limit of one to make sure they remain in the local network. If the packet has a Hop-by-Hop Options header, it has the Router Alert flag set. Thus, routers will not ignore the packet, even if they are not listening to the multicast group address in question.

All three message types have the same format, which is shown in Figure 4-21.

Figure 4-21. MLD message format

The Type field is 130 for Multicast Listener Queries, 131 for Multicast Listener Reports, or 132 for Multicast Listener Done messages. There are two types of query messages. One is a general query that is used to determine which multicast group addresses have listeners on a link. The other is an address-specific query that is used to determine whether there are listeners for a specific address on a link. The Maximum Response Delay field is used only in query messages. This is the maximum allowed delay (in milliseconds) in which a node has to send a report if it has a listener. In all other messages, this field is set to 0. The Multicast Address field is set to 0 in a general query. In an address-specific query, it contains the multicast group address to be queried. In report and done messages, this field contains the multicast group to which a member listens or the group it is leaving.

Routers use MLD to discover which multicast addresses have listeners on each of their links. For each attached link, the router keeps a list of listener addresses.

General queries are sent to the link-local scope all-nodes multicast address FF02::1. Any station that wants to send a report in answer to a query starts a timer when it receives the query and is supposed to wait some random delay before sending the report. The maximum delay is the one specified in the Maximum Response Delay field in the query. If within that delay, the station sees another station sending a report, it stops the process. Thus, multiple reports for the same address can be avoided. Group membership join reports and terminations are sent to the address in question.

The link-local scope all-nodes address (FF02::1) is a special address. It never sends a membership report or a done message. If an address has a scope of 1 (node-local), MLD messages are never sent. Table 4-7 summarizes the message types and their destination address.

Table 4-7. Message types and their destination

Message type	IPv6 destination address
General Query	link-local scope all-nodes (FF02::1)
Multicast-Address-Specific Query	The multicast address being queried
Report	The multicast address being reported
Done	link-local scope all-routers (FF02::2)

RFC 2710 contains a lot of interesting and detailed information. It discusses various states that nodes can go through and includes state transition diagrams. There is also much detailed information on timers: how they are used, their default values, and how they can be configured.

MLD Version 2 is already in the works as a draft and is based on IGMPv3. There are already implementations available based on the drafts. The current draft is http://www.ietf.org/internet-drafts/draft-vida-mld-v2-03.txt. For more information about the implementations, go to http://mldv2.lip6.fr.