impose a limit on the size of source lists. When an operation
causes the source list size limit to be exceeded, the service
interface SHOULD return an error.
For a given combination of socket, interface, and IPv6 multicast
address, only a single filter mode and source list can be in effect
at any one time. Nevertheless, either the filter mode or the source
list, or both, may be changed by subsequent IPv6MulticastListen
requests that specify the same socket, interface, and IPv6 multicast
address. Each subsequent request completely replaces any earlier
request for the given socket, interface, and multicast address.
The MLDv1 protocol did not support source filters, and had a simpler
service interface; it consisted of Start Listening and Stop Listening
operations to enable and disable listening to a given multicast
address (from *all* sources) on a given interface. The equivalent
operations in the new service interface are as follows:
The Start Listening operation is equivalent to:
IPv6MulticastListen ( socket, interface, IPv6 multicast address,
EXCLUDE, {} )
and the Stop Listening operation is equivalent to:
IPv6MulticastListen ( socket, interface, IPv6 multicast address,
INCLUDE, {} )
where {} is an empty source list.
An example of an API that provides the capabilities outlined in this
service interface is given in [RFC3678].
4. Multicast Listening State Maintained by Nodes
4.1. Per-Socket State
For each socket on which IPv6MulticastListen has been invoked, the
node records the desired multicast listening state for that socket.
That state conceptually consists of a set of records of the form:
(interface, IPv6 multicast address, filter mode, source list)
The per-socket state evolves in response to each invocation of
IPv6MulticastListen on the socket, as follows:
o If the requested filter mode is INCLUDE *and* the requested source
list is empty, then the entry that corresponds to the requested
interface and multicast address is deleted, if present. If no
such entry is present, the request has no effect.
o If the requested filter mode is EXCLUDE *or* the requested source
list is non-empty, then the entry that corresponds to the
requested interface and multicast address, if present, is changed
to contain the requested filter mode and source list. If no such
entry is present, a new entry is created, using the parameters
specified in the request.
4.2. Per-Interface State
In addition to the per-socket multicast listening state, a node must
also maintain or compute multicast listening state for each of its
interfaces. That state conceptually consists of a set of records of
the form:
(IPv6 multicast address, filter mode, source list)
At most one record per multicast address exists for a given
interface. This per-interface state is derived from the per-socket
state, but may differ from it when different sockets have differing
filter modes and/or source lists for the same multicast address and
interface. For example, suppose one application or process invokes
the following operation on socket s1:
IPv6MulticastListen ( s1, i, m, INCLUDE, {a, b, c} )
requesting reception on interface i of packets sent to multicast
address m, *only* if they come from the sources a, b, or c. Suppose
another application or process invokes the following operation on
socket s2:
IPv6MulticastListen ( s2, i, m, INCLUDE, {b, c, d} )
requesting reception on the same interface i of packets sent to the
same multicast address m, *only* if they come from sources b, c, or
d. In order to satisfy the reception requirements of both sockets,
it is necessary for interface i to receive packets sent to m from any
one of the sources a, b, c, or d. Thus, in this example, the
listening state of interface i for multicast address m has filter
mode INCLUDE and source list {a, b, c, d}.
After a multicast packet has been accepted from an interface by the
IP layer, its subsequent delivery to the application or process that
listens on a particular socket depends on the multicast listening
state of that socket (and possibly also on other conditions, such as
what transport-layer port the socket is bound to). So, in the above
example, if a packet arrives on interface i, destined to multicast
address m, with source address a, it may be delivered on socket s1
but not on socket s2. Note that MLDv2 messages are not subject to
source filtering and must always be processed by hosts and routers.
Requiring the filtering of packets based upon a socket’s multicast
reception state is a new feature of this service interface. The
previous service interface described no filtering based upon
multicast listening state; rather, a Start Listening operation on a
socket simply caused the node to start to listen to a multicast
address on the given interface; packets sent to that multicast
address could be delivered to all sockets, whether they had started
to listen or not.
The general rules for deriving the per-interface state from the per-
socket state are as follows: for each distinct (interface, IPv6
multicast address) pair that appears in any per-socket state, a per-
interface record is created for that multicast address on that
interface. Considering all socket records that contain the same
(interface, IPv6 multicast address) pair,
o if *any* such record has a filter mode of EXCLUDE, then the filter
mode of the interface record is EXCLUDE, and the source list of
the interface record is the intersection of the source lists of
all socket records in EXCLUDE mode, minus those source addresses
that appear in any socket record in INCLUDE mode. For example, if
the socket records for multicast address m on interface i are:
from socket s1: ( i, m, EXCLUDE, {a, b, c, d} )
from socket s2: ( i, m, EXCLUDE, {b, c, d, e} )
from socket s3: ( i, m, INCLUDE, {d, e, f} )
then the corresponding interface record on interface i is:
( m, EXCLUDE, {b, c} )
If a fourth socket is added, such as:
From socket s4: ( i, m, EXCLUDE, {} )
then the interface record becomes:
( m, EXCLUDE, {} )
o if *all* such records have a filter mode of INCLUDE, then the
filter mode of the interface record is INCLUDE, and the source
list of the interface record is the union of the source lists of
all the socket records. For example, if the socket records for
multicast address m on interface i are:
from socket s1: ( i, m, INCLUDE, {a, b, c} )
from socket s2: ( i, m, INCLUDE, {b, c, d} )
from socket s3: ( i, m, INCLUDE, {e, f} )
then the corresponding interface record on interface i is:
( m, INCLUDE, {a, b, c, d, e, f} )
An implementation MUST NOT use an EXCLUDE interface record for a
multicast address if all sockets for this multicast address are in
INCLUDE state. If system resource limits are reached when a per-
interface state source list is calculated, an error MUST be returned
to the application which requested the operation.
The above rules for deriving the per-interface state are
(re)evaluated whenever an IPv6MulticastListen invocation modifies the
per-socket state by adding, deleting, or modifying a per-socket state
record. Note that a change of the per-socket state does not
necessarily result in a change of the per-interface state.
5. Message Formats
MLDv2 is a sub-protocol of ICMPv6, that is, MLDv2 message types are a
subset of ICMPv6 messages, and MLDv2 messages are identified in IPv6
packets by a preceding Next Header value of 58. All MLDv2 messages
described in this document MUST be sent with a link-local IPv6 Source
Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option
[RFC2711] in a Hop-by-Hop Options header. (The Router Alert option
is necessary to cause routers to examine MLDv2 messages sent to IPv6
multicast addresses in which the routers themselves have no
interest.) MLDv2 Reports can be sent with the source address set to
the unspecified address [RFC3513], if a valid link-local IPv6 source
address has not been acquired yet for the sending interface. (See
section 5.2.13. for details.)
There are two MLD message types of concern to the MLDv2 protocol
described in this document:
o Multicast Listener Query (Type = decimal 130)
o Version 2 Multicast Listener Report (Type = decimal 143). See
section 11 for IANA considerations.
To assure the interoperability with nodes that implement MLDv1 (see
section 8), an implementation of MLDv2 must also support the
following two message types:
o Version 1 Multicast Listener Report (Type = decimal 131) [RFC2710]
o Version 1 Multicast Listener Done (Type = decimal 132) [RFC2710]
Unrecognized message types MUST be silently ignored. Other message
types may be used by newer versions or extensions of MLD, by
multicast routing protocols, or for other uses.
In this document, unless otherwise qualified, the capitalized words
"Query" and "Report" refer to MLD Multicast Listener Queries and MLD
Version 2 Multicast Listener Reports, respectively.
5.1. Multicast Listener Query Message
Multicast Listener Queries are sent by multicast routers in Querier
State to query the multicast listening state of neighboring
interfaces. Queries have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 130 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Response Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Multicast Address *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv |S| QRV | QQIC | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Source Address [1] *
| |
* *
| |
+- -+
| |
* *
| |
* Source Address [2] *
| |
* *
| |
+- . -+
. . .
. . .
+- -+
| |
* *
| |
* Source Address [N] *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.1. Code
Initialized to zero by the sender; ignored by receivers.
5.1.2. Checksum
The standard ICMPv6 checksum; it covers the entire MLDv2 message,
plus a "pseudo-header" of IPv6 header fields [RFC2463]. For
computing the checksum, the Checksum field is set to zero. When a
packet is received, the checksum MUST be verified before processing
it.
5.1.3. Maximum Response Code
The Maximum Response Code field specifies the maximum time allowed
before sending a responding Report. The actual time allowed, called
the Maximum Response Delay, is represented in units of milliseconds,
and is derived from the Maximum Response Code as follows:
If Maximum Response Code < 32768,
Maximum Response Delay = Maximum Response Code
If Maximum Response Code >=32768, Maximum Response Code represents a
floating-point value as follows:
0 1 2 3 4 5 6 7 8 9 A B C D E F
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| exp | mant |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Maximum Response Delay = (mant | 0x1000) << (exp+3)
Small values of Maximum Response Delay allow MLDv2 routers to tune
the "leave latency" (the time between the moment the last node on a
link ceases to listen to a specific multicast address and the moment
the routing protocol is notified that there are no more listeners for
that address). Larger values, especially in the exponential range,
allow the tuning of the burstiness of MLD traffic on a link.
5.1.4. Reserved
Initialized to zero by the sender; ignored by receivers.
5.1.5. Multicast Address
For a General Query, the Multicast Address field is set to zero. For
a Multicast Address Specific Query or Multicast Address and Source
Specific Query, it is set to the multicast address being queried (see
section 5.1.10, below).
5.1.7. S Flag (Suppress Router-Side Processing)
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. Nevertheless, it does not suppress the
querier election or the normal "host-side" processing of a Query that
a router may be required to perform as a consequence of itself being
a multicast listener.
5.1.8. QRV (Querier’s Robustness Variable)
If non-zero, the QRV field contains the [Robustness Variable] value
used by the Querier. If the Querier’s [Robustness Variable] exceeds
7 (the maximum value of the QRV field), the QRV field is set to zero.
Routers adopt the QRV value from the most recently received Query as
their own [Robustness Variable] value, unless that most recently
received QRV was zero, in which case they use the default [Robustness
Variable] value specified in section 9.1, or a statically configured
value.
5.1.9. QQIC (Querier’s Query Interval Code)
The Querier’s Query Interval Code field specifies the [Query
Interval] used by the Querier. The actual interval, called the
Querier’s Query Interval (QQI), is represented in units of seconds,
and is derived from the Querier’s Query Interval Code as follows:
If QQIC < 128, QQI = QQIC
If QQIC >= 128, QQIC represents a floating-point value as follows:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1| exp | mant |
+-+-+-+-+-+-+-+-+
QQI = (mant | 0x10) << (exp + 3)
Multicast routers that are not the current Querier adopt the QQI
value from the most recently received Query as their own [Query
Interval] value, unless that most recently received QQI was zero, in
which case the receiving routers use the default [Query Interval]
value specified in section 9.2.
5.1.10. Number of Sources (N)
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 non-zero in a Multicast
Address and Source Specific Query. This number is limited by the MTU
of the link over which the Query is transmitted. For example, on an
Ethernet link with an MTU of 1500 octets, the IPv6 header (40 octets)
together with the Hop-By-Hop Extension Header (8 octets) that
includes the Router Alert option consume 48 octets; the MLD fields up
to the Number of Sources (N) field consume 28 octets; thus, there are
1424 octets left for source addresses, which limits the number of
source addresses to 89 (1424/16).
5.1.11. Source Address [i]
The Source Address [i] fields are a vector of n unicast addresses,
where n is the value in the Number of Sources (N) field.
5.1.12. Additional Data
If the Payload Length field in the IPv6 header of a received Query
indicates that there are additional octets of data present, beyond
the fields described here, MLDv2 implementations MUST include those
octets in the computation to verify the received MLD Checksum, but
MUST otherwise ignore those additional octets. When sending a Query,
an MLDv2 implementation MUST NOT include additional octets beyond the
fields described above.
5.1.13. Query Variants
There are three variants of the Query message:
o A "General Query" is sent by the Querier to learn which multicast
addresses have listeners on an attached link. In a General Query,
both the Multicast Address field and the Number of Sources (N)
field are zero.
o A "Multicast Address Specific Query" is sent by the Querier to
learn if a particular multicast address has any listeners on an
attached link. In a Multicast Address Specific Query, the
Multicast Address field contains the multicast address of
interest, while the Number of Sources (N) field is set to zero.
o A "Multicast Address and Source Specific Query" is sent by the
Querier to learn if any of the sources from the specified list for
the particular multicast address has any listeners on an attached
link or not. In a Multicast Address and Source Specific Query the
Multicast Address field contains the multicast address of
interest, while the Source Address [i] field(s) contain(s) the
source address(es) of interest.
5.1.14. Source Addresses for Queries
All MLDv2 Queries MUST be sent with a valid IPv6 link-local source
address. If a node (router or host) receives a Query message with
the IPv6 Source Address set to the unspecified address (::), or any
other address that is not a valid IPv6 link-local address, it MUST
silently discard the message and SHOULD log a warning.
5.1.15. Destination Addresses for Queries
In MLDv2, General Queries are sent to the link-scope all-nodes
multicast address (FF02::1). Multicast Address Specific and
Multicast Address and Source Specific Queries are sent with an IP
destination address equal to the multicast address of interest.
*However*, a node MUST accept and process any Query whose IP
Destination Address field contains *any* of the addresses (unicast or
multicast) assigned to the interface on which the Query arrives. This
might be useful, e.g., for debugging purposes.
5.2. Version 2 Multicast Listener Report Message
Version 2 Multicast Listener Reports are sent by IP nodes to report