(to neighboring routers) the current multicast listening state, or
changes in the multicast listening state, of their interfaces.
Reports 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 = 143 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Nr of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each Multicast Address Record has the following internal format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Type | Aux Data Len | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Multicast Address *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Source Address [1] *
| |
* *
| |
+- -+
| |
* *
| |
* Source Address [2] *
| |
* *
| |
+- -+
. . .
. . .
. . .
+- -+
| |
* *
| |
* Source Address [N] *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Auxiliary Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.1. Reserved
The Reserved fields are set to zero on transmission, and ignored on
reception.
5.2.2. Checksum
The standard ICMPv6 checksum; it covers the entire MLDv2 message,
plus a "pseudo-header" of IPv6 header fields [RFC2460, RFC2463]. In
order to compute the checksum, the Checksum field is set to zero.
When a packet is received, the checksum MUST be verified before
processing it.
5.2.3. Nr of Mcast Address Records (M)
The Nr of Mcast Address Records (M) field specifies how many
Multicast Address Records are present in this Report.
5.2.4. Multicast Address Record
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.
5.2.5. Record Type
It specifies the type of the Multicast Address Record. See section
5.2.12 for a detailed description of the different possible Record
Types.
5.2.6. Aux Data Len
The Aux Data Len field contains the length of the Auxiliary Data
Field in this Multicast Address Record, in units of 32-bit words. It
may contain zero, to indicate the absence of any auxiliary data.
5.2.7. Number of Sources (N)
The Number of Sources (N) field specifies how many source addresses
are present in this Multicast Address Record.
5.2.8. Multicast Address
The Multicast Address field contains the multicast address to which
this Multicast Address Record pertains.
5.2.9. Source Address [i]
The Source Address [i] fields are a vector of n unicast addresses,
where n is the value in this record’s Number of Sources (N) field.
5.2.10. Auxiliary Data
The Auxiliary Data field, if present, contains additional information
that pertain to this Multicast Address Record. The protocol
specified in this document, MLDv2, does not define any auxiliary
data. Therefore, implementations of MLDv2 MUST NOT include any
auxiliary data (i.e., MUST set the Aux Data Len field to zero) in any
transmitted Multicast Address Record, and MUST ignore any such data
present in any received Multicast Address Record. The semantics and
the internal encoding of the Auxiliary Data field are to be defined
by any future version or extension of MLD that uses this field.
5.2.11. Additional Data
If the Payload Length field in the IPv6 header of a received Report
indicates that there are additional octets of data present, beyond
the last Multicast Address Record, 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
Report, an MLDv2 implementation MUST NOT include additional octets
beyond the last Multicast Address Record.
5.2.12. Multicast Address Record Types
There are a number of different types of Multicast Address Records
that may be included in a Report message:
o A "Current State Record" is sent by a node in response to a Query
received on an interface. It reports the current listening state
of that interface, with respect to a single multicast address.
The Record Type of a Current State Record may be one of the
following two values:
Value Name and Meaning
----- ----------------
1 MODE_IS_INCLUDE - indicates that the interface has a filter
mode of INCLUDE for the specified multicast address. The
Source Address [i] fields in this Multicast Address Record
contain the interface’s source list for the specified
multicast address. A MODE_IS_INCLUDE Record is never sent
with an empty source list.
2 MODE_IS_EXCLUDE - indicates that the interface has a filter
mode of EXCLUDE for the specified multicast address. The
Source Address [i] fields in this Multicast Address Record
contain the interface’s source list for the specified
multicast address, if it is non-empty.
o A "Filter Mode Change Record" is sent by a node whenever a local
invocation of IPv6MulticastListen causes a change of the filter
mode (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to
INCLUDE) of the interface-level state entry for a particular
multicast address, whether the source list changes at the same
time or not. The Record is included in a Report sent from the
interface on which the change occurred. The Record Type of a
Filter Mode Change Record may be one of the following two values:
3 CHANGE_TO_INCLUDE_MODE - indicates that the interface has
changed to INCLUDE filter mode for the specified multicast
address. The Source Address [i] fields in this Multicast
Address Record contain the interface’s new source list for
the specified multicast address, if it is non-empty.
4 CHANGE_TO_EXCLUDE_MODE - indicates that the interface has
changed to EXCLUDE filter mode for the specified multicast
address. The Source Address [i] fields in this Multicast
Address Record contain the interface’s new source list for
the specified multicast address, if it is non-empty.
o A "Source List Change Record" is sent by a node whenever a local
invocation of IPv6MulticastListen causes a change of source list
that is *not* coincident with a change of filter mode, of the
interface-level state entry for a particular multicast address.
The Record is included in a Report sent from the interface on
which the change occurred. The Record Type of a Source List
Change Record may be one of the following two values:
5 ALLOW_NEW_SOURCES - indicates that the Source Address [i]
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.
6 BLOCK_OLD_SOURCES - indicates that the Source Address [i]
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.
If a change of source list results in both allowing new sources and
blocking old sources, then two Multicast Address Records are sent for
the same multicast address, one of type ALLOW_NEW_SOURCES and one of
type BLOCK_OLD_SOURCES.
We use the term "State Change Record" to refer to either a Filter
Mode Change Record or a Source List Change Record.
Multicast Address Records with an unrecognized Record Type value MUST
be silently ignored, with the rest of the report being processed.
In the rest of this document, we use the following notation to
describe the contents of a Multicast Address Record that pertains to
a particular multicast address:
IS_IN ( x ) - Type MODE_IS_INCLUDE, source addresses x
IS_EX ( x ) - Type MODE_IS_EXCLUDE, source addresses x
TO_IN ( x ) - Type CHANGE_TO_INCLUDE_MODE, source addresses x
TO_EX ( x ) - Type CHANGE_TO_EXCLUDE_MODE, source addresses x
ALLOW ( x ) - Type ALLOW_NEW_SOURCES, source addresses x
BLOCK ( x ) - Type BLOCK_OLD_SOURCES, source addresses x
where x is either:
o a capital letter (e.g., "A") to represent the set of source
addresses,
or
o a set expression (e.g., "A+B"), where "A+B" means the union of
sets A and B, "A*B" means the intersection of sets A and B, and
"A-B" means the removal of all elements of set B from set A.
5.2.13. Source Addresses for Reports
An MLDv2 Report MUST be sent with a valid IPv6 link-local source
address, or the unspecified address (::), if the sending interface
has not acquired a valid link-local address yet. Sending reports
with the unspecified address is allowed to support the use of IP
multicast in the Neighbor Discovery Protocol [RFC2461]. For
stateless autoconfiguration, as defined in [RFC2462], a node is
required to join several IPv6 multicast groups, in order to perform
Duplicate Address Detection (DAD). Prior to DAD, the only address
the reporting node has for the sending interface is a tentative one,
which cannot be used for communication. Thus, the unspecified
address must be used.
On the other hand, routers MUST silently discard a message that is
not sent with a valid link-local address, without taking any action
on the contents of the packet. Thus, a Report is discarded if the
router cannot identify the source address of the packet as belonging
to a link connected to the interface on which the packet was
received. A Report sent with the unspecified address is also
discarded by the router. This enhances security, as unidentified
reporting nodes cannot influence the state of the MLDv2 router(s).
Nevertheless, the reporting node has modified its listening state for
multicast addresses that are contained in the Multicast Address
Records of the Report message. From now on, it will treat packets
sent to those multicast addresses according to this new listening
state. Once a valid link-local address is available, a node SHOULD
generate new MLDv2 Report messages for all multicast addresses joined
on the interface.
5.2.14. Destination Addresses for Reports
Version 2 Multicast Listener Reports are sent with an IP destination
address of FF02:0:0:0:0:0:0:16, to which all MLDv2-capable multicast
routers listen (see section 11 for IANA considerations related to
this special destination address). A node that operates in version 1
compatibility mode (see details in section 8) sends version 1 Reports
to the multicast address specified in the Multicast Address field of
the Report. In addition, a node MUST accept and process any version
1 Report whose IP Destination Address field contains *any* of the
IPv6 addresses (unicast or multicast) assigned to the interface on
which the Report arrives. This might be useful, e.g., for debugging
purposes.
5.2.15. Multicast Listener Report Size
If the set of Multicast Address Records required in a Report does not
fit within the size limit of a single Report message (as determined
by the MTU of the link on which it will be sent), the Multicast
Address Records are sent in as many Report messages as needed to
report the entire set.
If a single Multicast Address Record contains so many source
addresses that it does not fit within the size limit of a single
Report message, then:
o if its Type is not IS_EX or TO_EX, it is split into multiple
Multicast Address Records; each such record contains a different
subset of the source addresses, and is sent in a separate Report.
o if its Type is IS_EX or TO_EX, a single Multicast Address Record
is sent, with as many source addresses as can fit; the remaining
source addresses are not reported. Although the choice of which
sources to report is arbitrary, it is preferable to report the
same set of sources in each subsequent report, rather than