Multicast Listener Discovery Protocol (IPv6 Multicasting)

The Multicast Listener Discovery (MLD) protocol is the multicast group management protocol for IPv6 and is used to exchange group information between multicast hosts and routers. The MLD protocol was designed based on IGMP, the Internet Group Management Protocol for IPv4, and the protocol specification is the same in many points. Unlike IGMP, however, MLD is defined as part of ICMPv6, while IGMP is defined as a separate transport layer protocol.

MLD messages are generally sent with an IPv6 link-local source IP address. The hop limit is always 1, preventing the forwarding of MLD messages by a router.

Currently, two versions of MLD are defined: version 1 of MLD (MLDvl) [RFC2710] is based on version 2 of IGMP (IGMPv2), and version 2 of MLD (MLDv2) [RFC3810] is based on version 3 of IGMP (IGMPv3).

Similar to IGMPv2, MLDv1 consists of three types of messages: Multicast Listener Query, Multicast Listener Report, and Multicast Listener Done. These message types correspond to the IGMPv2 Membership Query, Membership Report, and Leave Group message types, respectively.

This topic mainly focuses on MLDv1, although Section 2.4.5 will provide some more background of MLDv2. In the rest of this topic, the term "MLD" generally means MLDv1 for brevity unless explicitly noted otherwise, even when the corresponding discussion applies to MLDv2 as well. In some cases, it is necessary to distinguish the different versions of MLD, and they are explictly referred to as MLDv1 or MLDv2.


MLD Protocol Message Format

MLD protocol messages have the ICMPv6 message format shown in Figure 2-2. The format is common to all MLD (v1 and v2) message types.

The length of any MLDv1 message must not be larger than 24 bytes. The sender must not transmit any MLDv1 message larger than 24 bytes; the receiver ignores any bytes passing this limit. This behavior of the receiver ensures upper-compatibility with future extensions of the protocol. In fact, MLDv2 uses larger packets with minimum compatibility with MLDv1. MLD messages are identified by the ICMPv6 Type field as given in Table 2-1. The Multicast Listener Query message can be classified into two query types: the general Query for a router to learn multicast addresses that have active listeners, and the (multicast-address) specific Query for membership in a particular multicast address on a given link.

The Code field has the value of 0. The Checksum field contains the ICMPv6 checksum value. The Reserved field must be set to 0 by the sender and is ignored by receivers.

The Maximum Response Delay field is given in units of milliseconds. This field specifies the maximum time a host can delay before sending a report back to the querying router. This field is meaningful only to Query messages, and it is set to 0 by the sender and is ignored by the receivers in the other types of MLD messages. The Maximum Response Delay controls the time between the time the last member of a multicast group stops listening and routers reflect that information in multicast routing. The Maximum Response Delay also controls the burstiness of the MLD traffic on the link.

FIGURE 2-2

FIGURE 2-2

TABLE 2-1

ICMPv6 message type

MLD message type

130

Multicast Listener Query

131

Multicast Listener Report

132

Multicast Listener Done

The Multicast Address field is set to 0 (the IPv6 unspecified address) in a general Query message, or a specific multicast address in an address specific Query message. In a Report message, the Multicast Address field contains the multicast address on which the sender is listening. In a Done message, the Multicast Address field contains the multicast address from which the sender is departing.

Router Alert Option

A node sends the Multicast Listener Report and Done messages to the multicast groups of which the node is already a member. The Router Alert option prompts a receiving router to examine the MLD messages even if these messages may be of no interest to the router at the IP layer, since it may be of interest to upper layer protocols or applications within the router. The sender ensures by including the Router Alert option in a Hop-by-Hop Options header with each MLD message that the MLD message processing is carried out by the receiving router.

The IPv6 Router Alert option, as defined in [RFC2711], reserves the value of 0 to specify an MLD packet.

Source Address Selection

The requirement that the source address of the MLD messages must be an IPv6 link-local address may be problematic during the boot-up time of the transmitting node.

A node configures a link-local address on an interface and begins the Duplicate Address Detection.This link-local address is called tentative while DAD is in progress. The operation of the DAD algorithm relies on the node joining the solicited-node multicast group of the tentative address, resulting in the transmission of a Multicast Listener Report message for that group. Unfortunately, the transmitting interface does not yet have a valid (i.e., nontentative) link-local address, in which case the Report message could not be sent.

A problem arises when an MLD-snooping switching device connects the nodes on the link. Such a switching device snoops for multicast packets on the link, but since no Report message was ever transmitted, the switching device blocks the Neighbor Solicitation and Neighbor Advertisement messages that otherwise would have allowed the configuring node to detect the duplicate address condition if and when it occurred on the link.

[RFC3590] loosens the source address requirement to prevent the above scenario. Nodes are allowed to send both the Report and Done messages with the unspecified address as the source address when no valid link-local address is available on the sending interface.

Destination Address Selection

Table 2-2 summarizes the MLD message types and the associated packet destination addresses.

MLD Querier

Hosts report multicast group memberships to routers by responding to both general and specific Query messages. The identity of the router that sent the Query messages is not important to the hosts; what is important to the hosts is to receive the Query messages. As such, just a single router per link generating the Query messages suffices.

TABLE 2-2

MLD message type

Packet destination address

General Query message

ff02::1 (link-local All-Nodes multicast address)

Multicast-Address-Specific Query

Same as the address specified by Multicast Address field

Report message

Same as the address specified by Multicast Address field

Done message

ff02::2 (link-local All-Routers multicast address)

TABLE 2-3

Variable

Robustness variable

Default value 2

Query Interval

125s

Query Response Interval

10000 (10 s)

Multicast Listener Interval

(Robustness-var * Query Interval)

+ Query Response Interval

Other Querier Present Interval

(Robustness-var * Query Interval)

+ (0.5 * Query Response Interval)

Startup Query Interval

0.25 * Query Interval

Startup Query Count

Robustness variable

Last Listener Query Interval

1000 (1 s)

Last Listener Query Count

Robustness variable

Unsolicited Report Interval

10s

This router is called the (MLD) Querier. A Querier generates periodic general Query messages on the link to solicit and learn the multicast addresses that have memberships.

A router can assume the role of either a Querier or a non-Querier. Each router on startup assumes the Querier role but participates in a Querier election process. The process converges to elect the router having the smallest IPv6 address. For brevity, we assume a router is the Querier in the succeeding MLD discussions.

Operational Variables

Table 2-3 lists configurable variables that affect the MLD operation.

The Robustness variable should be set with a value that reflects the expected packet loss characteristics of the link. This variable must not be 0 and should not be 1.

The Query Interval is the inter packet gap between consecutive general Query messages sent by the Querier.

The Query Response Interval is the value inserted into the Maximum Delay Response field of the MLD message. The smaller the value is the faster the hosts will send the reports, possibly resulting in a burst of MLD packets.

The Multicast Listener Interval specifies the amount of time that must elapse before a router decides that there are no more listeners in a particular group.

The Other Querier Present Interval specifies the amount of time that a router must wait before determining whether it should be the Querier.

The Startup Query Interval is the inter packet gap between consecutive general Query messages sent by a router that assumes the Querier role on startup.

The Startup Query Count specifies the number of queries separated by the Startup Query Interval, which may be transmitted by a router assuming the Querier role on startup.

The Last Listener Query Interval is the value inserted into the Maximum Response Delay field of multicast address specific Query messages sent in response to Done messages. The interval value also specifies the inter packet gap for the specific Query messages.

The Last Listener Query Count is the number of specific Query messages sent by a router before it assumes there are no more listeners in the multicast group queried.

The Unsolicited Report Interval specifies the inter packet gap between consecutive initial Report messages sent by a node expressing its interest in a multicast group.

MLD Join Process

An IPv6 host joins a multicast group by sending a Multicast Listener Report message destined to the multicast address of interest. A multicast router is configured to accept all multicast packets from the link. The router recognizes the MLD packets through the Hop-by-Hop Router Alert option and passes these MLD messages to the upper layer. The multicast routing process within the router accepts and starts forwarding these multicast packets to the reported group according to the routing protocol it deploys.

A host that is a member of a group also receives Report messages sent to the group by other hosts joining the group. The receiving host then remembers that there is another host joining the group. The existence of the other group members affects the leave process described in Section 2.3.8.

Figure 2-3 gives an example of the join process. In this example, host H2 has already joined the multicast group ff05::1:3. Host H1 is starting up and joins the same group by sending out the Report message indicating its interest in the ff05::1:3 group. Both the router and H2 receive the Report message, and H2 remembers there is another group member.

FIGURE 2-3

FIGURE 2-3

MLD Leave Process

When a host is going to leave a multicast group and is the last node that sent a Multicast Listener Report message for the group (this can be detected by whether or not the host has heard a Report from another node for the group), it notifies the router of the departure by sending a Multicast Listener Done message to the All-Routers multicast group address (ff02::2).

Assume in the previous example that H1 did not receive any Report message from other nodes. Then H1 is the last member that sent a Report for ff05::1:3. Since H2 is aware of the presence of another listener (H1) being a member in that group, it will not generate a Done message if it leaves the group first. On the other hand, if H1 leaves the group before H2, it will notify the router with a Done message sent to the All-Routers multicast address (ff02::2).

The router responds to the Done message from H1 with a multicast-address specific Query. H2 responds to the Query with a Report message, indicating there is still a listener present. The router thus continues the multicast packet forwarding for this group. Figure 2-4 illustrates this scenario.

The router responds to the Done message by sending out Last Listener Query Count number of multicast-address specific Query messages, each separated by the Last Listener Query Interval seconds. If the departing node is the last member of the group, the router will not receive any Report. The router will cease forwarding multicast packets for the group once the transmissions complete without receiving any Report message. Continuing with the previous example, this progression takes place when H2 leaves the group as depicted in Figure 2-5.

FIGURE 2-4

FIGURE 2-4

FIGURE 2-5

FIGURE 2-5

Next post:

Previous post: