Section 4.10. Multicast Listener Discovery (MLD)

4.10. Multicast Listener Discovery (MLD)

Multicast has been available in IPv4 since 1988 and is used to address a certain group of hosts at the same time. Instead of sending out a broadcast, which is not routable and has to be processed by every node on the subnet, the multicast packet is addressed to a multicast group address out of the Class D address range. Only the hosts that are members of that multicast group will process the packet. Multicast messages can be forwarded over routers. In order to make this routing efficient, a multicast group management protocol ensures that routers only forward multicast packets over interfaces to links with members of the multicast group.

In IPv6, multicast is an integral part of the protocol and is available on all IPv6 nodes. A new multicast address format has been defined with a prefix of FF and with added functionality by using scopes in addition to the group address. For example, a multicast group address can be in a link-local scope (FF02), a site-local scope (FF05), or a global scope (FF0E). For an explanation of the multicast address format and a list of scope identifiers, refer to Chapter 3.

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; initial development was based on the IGMPv2 specification. It is now called Multicast Listener Discovery (MLD). Version 1 of MLD is defined in RFC 2710. In 2004, MLD Version 2 was defined. It extends MLD Version 1 to support the use of Source Specific Multicast (SSM). It is based on IGMPv3 (RFC 3376) and is specified in RFC 3810. MLDv2 is compatible with MLD Version 1.

MLD is the protocol that allows multicast listeners to register for multicast addresses they want to use, to ensure efficient routing. Therefore, a routing mechanism is needed to manage the forwarding of multicast messages. PIM (Protocol Independent Multicast, RFC 2362) can be used with IPv6 with minimal changes. To find information about the status of PIM, go to the IETF working group at http://www.ietf.org/html.charters/pim-charter.html.

MLD is an asymmetric protocol. The behavior of listeners , i.e., nodes that want to receive messages destined for a specific multicast group, differs from the behavior of routers. For multicast addresses where a router is a listener, it uses both parts of the protocol. 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. It does not keep track of how many members are listening to an address. A multicast address is listed as long as there is at least one member on the link. A listener sends member reports for its multicast addresses. With these messages, it registers with routers on the link to receive the messages addressed to the respective multicast group. If the multicast address is not in the routers list for this link, the router adds the address to its list of multicast addresses to be forwarded over this interface. With a Done message, a listener deregisters for a multicast address. When the last member of a group deregisters for a multicast address, the router removes the address from its list for this link.

All MLD messages are sent with a link-local IPv6 Source address and a hop limit of one to make sure they remain on the local link. The packet has a Hop-by-Hop Options header with 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. Refer to Chapter 2 for more information on Extension headers.

4.10.1. MLDv1

The following message types have been specified for MLDv1 (RFC 2710):

Multicast Listener Querytype 130

Used by an IPv6 router to query the multicast addresses on a link. There are two types of queries: the general query used to determine the multicast addresses that have listeners on the link (in the general query, the multicast address field is set to zero) and the address specific query used to find out whether there are members for a specific multicast address on a link (the multicast address field is set to the multicast address for which the query is done).

Multicast Listener Reporttype 131

Used by a listener to register for a multicast group. This can be an unsolicited registration or the answer to a multicast listener query from the router.

Multicast Listener Donetype 132

Sent by a listener to deregister for a multicast address. When a router receives a Multicast Listener Done message from the last member of the multicast address on a link, it will delete the multicast address from its list of multicast addresses to be forwarded over this interface.

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

Figure 4-19. MLD message format

The Type field is 130 for Multicast Listener Queries, 131 for Multicast Listener Reports, or 132 for Multicast Listener Done messages. The Code field is set to 0 by the sender and ignored by the receiver. 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 either the multicast group to which a member listens (report message) or the group it is leaving (done message).

Routers send general queries 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 the station sees another station sending a report within that delay, 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 (interface-local), MLD messages are never sent. Table 4-9 summarizes the message types and their Destination address.

Table 4-9. Message types and their destinations

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.

4.10.2. MLDv2

MLD Version 2 has been specified in RFC 3810. It is based on IGMPv3 (RFC 3376). MLDv2 adds the ability for a node to do source filtering , which means to report interest in listening to packets with a particular multicast address from only specific Source addresses or from all sources except for specific Source addresses. This is also referred to as Source Specific Multicast (SSM) as opposed to Any Source Multicast (ASM), which is the name for the previous version, based on IGMPv2 (MLDv1).

There are two message types for MLDv2:

• Multicast Listener QueryType 130

• Version 2 Multicast Listener ReportType 143 (RFC 3810)

To be interoperable with MLDv1, MLDv2 implementations also need to support Version 1 Multicast Listener Report (Type 131) and Version 1 Multicast Listener Done (Type 132) messages.

For MLDv2 query messages, the MLD header shown in Figure 4-19 is extended with the following fields, which are appended after the Multicast Address field shown in Figure 4-19:

Reserved4 bits

Must be set to zero.

S-Flag (Suppress Router-Side Processing)1 bit

When set to one, the S-Flag indicates to any receiving multicast routers that they have to suppress the normal timer updates they perform upon hearing a Query.

QRV (Querier's Robustness Variable)3 bits

If non-zero, the QRV field contains the Robustness Variable value used by the Querier. This value affects timers and the number of retries. Included in queries in order to synchronize all MLDv2 routers connected to the same link.

QQIC (Querier's Query Interval Code)8 bits

The Querier's Query Interval Code field specifies the Query Interval used by the Querier. Included in queries in order to synchronize all MLDv2 routers connected to the same link.

Number of Sources16 bits

The Number of Sources (N) field specifies how many Source addresses are present in the Query. This number is zero in a General Query or a Multicast Address Specific Query, and nonzero in a Multicast Address and Source Specific Query.

Source Addressvariable length

Contains the Source addresses. Length is defined by the number of addresses specified in the N-Field.

MLDv2 Listener Done messages have the following format:

• Type Field1 byte, set to 143

• Reserved1 byte

• Checksum2 bytes

• Reserved2 bytes

• M-Field (Number of Multicast Address Records)2 bytes

• Multicast Address Recordsvariable length

Each Multicast Address Record is a block of fields that contain information on the sender listening to a single multicast address on the interface from which the Report is sent. It includes a field specifying the number of sources and the list of sources for a particular multicast address.

There are different types of multicast address records that can be included in a Report message (RFC 3810; description follows).

A node that receives a Query on an interface responds with a Current State Record to report the state of the interface regarding the multicast address in question. The Current State Record can have one of two values:

Value 1MODE_IS_INCLUDE

Indicates that the interface has a filter mode of INCLUDE for the specified multicast address

Value 2MODE_IS_EXCLUDE

Indicates that the interface has a filter mode of EXCLUDE for the specified multicast address

If there is a change of the filter mode, a node sends a Filter Mode Change Record. This record is included in a report sent from the interface where the change occurred. The Filter Mode Change Record can have one of two values:

Value 3CHANGE_TO_INCLUDE_MODE

Indicates that the interface has changed to INCLUDE filter mode for the specified multicast address. The Source Address fields in this Multicast Address Record contain the interface's new source list for the specified multicast address, if it is nonempty.

Value 4CHANGE_TO_EXCLUDE_MODE

Indicates that the interface has changed to EXCLUDE filter mode for the specified multicast address. The Source Address fields in this Multicast Address Record contain the interface's new source list for the specified multicast address, if it is nonempty.

If there is a change of source list, a node includes a Source List Change Record in a report sent from the interface where the change occurred. The Source List Change Record can have one of two values:

Value 5ALLOW_NEW_SOURCES

Indicates that the Source Address fields in this Multicast Address Record contain a list of the additional sources that the node wishes to listen to, for packets sent to the specified multicast address. If the change was to an INCLUDE source list, these are the addresses that were added to the list; if the change was to an EXCLUDE source list, these are the addresses that were deleted from the list.

Value 6BLOCK_OLD_SOURCES

Indicates that the Source Address fields in this Multicast Address Record contain a list of the sources that the node no longer wishes to listen to for packets sent to the specified multicast address. If the change was to an INCLUDE source list, these are the addresses that were deleted from the list; if the change was to an EXCLUDE source list, these are the addresses that were added to the list.

Version 2 Multicast Listener Reports are sent with an IP Destination address of FF02:0:0:0:0:0:0:16. All MLDv2-capable multicast routers listen to this address.

For more information about Multicast and Anycast Group Membership, refer to the IETF Magma Group at http://www.ietf.org/html.charters/magma-charter.html.