rfc9777v1.txt | rfc9777.txt | |||
---|---|---|---|---|
skipping to change at line 14 ¶ | skipping to change at line 14 ¶ | |||
STD: 101 March 2025 | STD: 101 March 2025 | |||
Obsoletes: 3810 | Obsoletes: 3810 | |||
Updates: 2710 | Updates: 2710 | |||
Category: Standards Track | Category: Standards Track | |||
ISSN: 2070-1721 | ISSN: 2070-1721 | |||
Multicast Listener Discovery Version 2 (MLDv2) for IPv6 | Multicast Listener Discovery Version 2 (MLDv2) for IPv6 | |||
Abstract | Abstract | |||
This document updates RFC 2710, and it specifies the Multicast | This document specifies the Multicast Listener Discovery version 2 | |||
Listener Discovery version 2 (MLDv2) protocol. MLD is used by an | (MLDv2) protocol. MLD is used by an IPv6 router to discover the | |||
IPv6 router to discover the presence of multicast listeners on | presence of multicast listeners on directly attached links and to | |||
directly attached links and to discover which multicast addresses are | discover which multicast addresses are of interest to those | |||
of interest to those neighboring nodes. MLDv2 is designed to be | neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. | |||
interoperable with MLDv1. MLDv2 adds the ability for a node to | MLDv2 adds the ability for a node to report interest in listening to | |||
report interest in listening to packets with a particular multicast | packets with a particular multicast address only from specific source | |||
address only from specific source addresses or from all sources | addresses or from all sources except for specific source addresses. | |||
except for specific source addresses. | ||||
This document obsoletes RFC 3810. | This document updates RFC 2710 and obsoletes RFC 3810. | |||
Status of This Memo | Status of This Memo | |||
This is an Internet Standards Track document. | This is an Internet Standards Track document. | |||
This document is a product of the Internet Engineering Task Force | This document is a product of the Internet Engineering Task Force | |||
(IETF). It represents the consensus of the IETF community. It has | (IETF). It represents the consensus of the IETF community. It has | |||
received public review and has been approved for publication by the | received public review and has been approved for publication by the | |||
Internet Engineering Steering Group (IESG). Further information on | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | Internet Standards is available in Section 2 of RFC 7841. | |||
skipping to change at line 72 ¶ | skipping to change at line 71 ¶ | |||
outside the IETF Standards Process, and derivative works of it may | outside the IETF Standards Process, and derivative works of it may | |||
not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
it for publication as an RFC or to translate it into languages other | it for publication as an RFC or to translate it into languages other | |||
than English. | than English. | |||
Table of Contents | Table of Contents | |||
1. Introduction | 1. Introduction | |||
1.1. Conventions Used in This Document | 1.1. Conventions Used in This Document | |||
2. Protocol Overview | 2. Protocol Overview | |||
2.1. Building Multicast Listening State on Multicast Address | 2.1. Building Multicast Address Listening State on Multicast | |||
Listeners | Address Listeners | |||
2.2. Exchanging Messages between the Querier and the Listening | 2.2. Exchanging Messages between the Querier and the Listening | |||
Nodes | Nodes | |||
2.3. Building Multicast Address Listener State on Multicast | 2.3. Building Multicast Address Listening State on Multicast | |||
Routers | Routers | |||
3. The Service Interface for Requesting IP Multicast Reception | 3. The Service Interface for Requesting IP Multicast Reception | |||
4. Multicast Listening State Maintained by Nodes | 4. Multicast Address Listening State Maintained by Nodes | |||
4.1. Per-Socket State | 4.1. Per-Socket State | |||
4.2. Per-Interface State | 4.2. Per-Interface State | |||
5. Message Formats | 5. Message Formats | |||
5.1. Multicast Listener Query Message | 5.1. Multicast Listener Query Message | |||
5.1.1. Code | 5.1.1. Code | |||
5.1.2. Checksum | 5.1.2. Checksum | |||
5.1.3. Maximum Response Code | 5.1.3. Maximum Response Code | |||
5.1.4. Reserved | 5.1.4. Reserved | |||
5.1.5. Multicast Address | 5.1.5. Multicast Address | |||
5.1.6. Flags | 5.1.6. Flags | |||
skipping to change at line 128 ¶ | skipping to change at line 127 ¶ | |||
6.2. Action on Reception of a Query | 6.2. Action on Reception of a Query | |||
6.3. Action on Timer Expiration | 6.3. Action on Timer Expiration | |||
7. Description of the Protocol for Multicast Routers | 7. Description of the Protocol for Multicast Routers | |||
7.1. Conditions for MLD Queries | 7.1. Conditions for MLD Queries | |||
7.2. MLD State Maintained by Multicast Routers | 7.2. MLD State Maintained by Multicast Routers | |||
7.2.1. Definition of Router Filter Mode | 7.2.1. Definition of Router Filter Mode | |||
7.2.2. Definition of Filter Timers | 7.2.2. Definition of Filter Timers | |||
7.2.3. Definition of Source Timers | 7.2.3. Definition of Source Timers | |||
7.3. MLDv2 Source-Specific Forwarding Rules | 7.3. MLDv2 Source-Specific Forwarding Rules | |||
7.4. Action on Reception of Reports | 7.4. Action on Reception of Reports | |||
7.4.1. Reception of Current State Records | 7.4.1. Reception of Current-State Records | |||
7.4.2. Reception of Filter Mode Change and Source List Change | 7.4.2. Reception of Filter-Mode-Change and Source List Change | |||
Records | Records | |||
7.5. Switching Router Filter Modes | 7.5. Switching Router Filter Modes | |||
7.6. Action on Reception of Queries | 7.6. Action on Reception of Queries | |||
7.6.1. Timer Updates | 7.6.1. Timer Updates | |||
7.6.2. Querier Election | 7.6.2. Querier Election | |||
7.6.3. Building and Sending Specific Queries | 7.6.3. Building and Sending Specific Queries | |||
8. Interoperation with MLDv1 | 8. Interoperation with MLDv1 | |||
8.1. Query Version Distinctions | 8.1. Query Version Distinctions | |||
8.2. Multicast Address Listener Behavior | 8.2. Multicast Address Listener Behavior | |||
8.2.1. In the Presence of MLDv1 Routers | 8.2.1. In the Presence of MLDv1 Routers | |||
8.2.2. In the Presence of MLDv1 Multicast Address Listeners | 8.2.2. In the Presence of MLDv1 Multicast Address Listeners | |||
8.3. Multicast Router Behavior | 8.3. Multicast Router Behavior | |||
8.3.1. In the Presence of MLDv1 Routers | 8.3.1. In the Presence of MLDv1 Routers | |||
8.3.2. In the Presence of MLDv1 Multicast Address Listeners | 8.3.2. In the Presence of MLDv1 Multicast Address Listeners | |||
9. List of Timers, Counters, and Their Default Values | 9. List of Timers, Counters, and Their Default Values | |||
9.1. Robustness Variable | 9.1. Robustness Variable | |||
9.2. Query Interval | 9.2. Query Interval | |||
9.3. Query Response Interval | 9.3. Query Response Interval | |||
9.4. Multicast Address Listening Interval | 9.4. Multicast Address Listening Interval | |||
9.5. Other Querier Present Timeout | 9.5. Other Querier Present Interval | |||
9.6. Startup Query Interval | 9.6. Startup Query Interval | |||
9.7. Startup Query Count | 9.7. Startup Query Count | |||
9.8. Last Listener Query Interval | 9.8. Last Listener Query Interval | |||
9.9. Last Listener Query Count | 9.9. Last Listener Query Count | |||
9.10. Last Listener Query Time | 9.10. Last Listener Query Time | |||
9.11. Unsolicited Report Interval | 9.11. Unsolicited Report Interval | |||
9.12. Older Version Querier Present Timeout | 9.12. Older Version Querier Present Interval | |||
9.13. Older Version Host Present Timeout | 9.13. Older Version Host Present Interval | |||
9.14. Configuring Timers | 9.14. Configuring Timers | |||
9.14.1. Robustness Variable | 9.14.1. Robustness Variable | |||
9.14.2. Query Interval | 9.14.2. Query Interval | |||
9.14.3. Maximum Response Delay | 9.14.3. Maximum Response Delay | |||
10. Security Considerations | 10. Security Considerations | |||
10.1. Query Message | 10.1. Query Message | |||
10.2. Current State Report Messages | 10.2. Current-State Report Messages | |||
10.3. State Change Report Messages | 10.3. State-Change Report Messages | |||
11. IANA Considerations | 11. IANA Considerations | |||
12. References | 12. References | |||
12.1. Normative References | 12.1. Normative References | |||
12.2. Informative References | 12.2. Informative References | |||
Appendix A. Design Rationale | Appendix A. Design Rationale | |||
A.1. The Need for State Change Messages | A.1. The Need for State-Change Messages | |||
A.2. Host Suppression | A.2. Host Suppression | |||
A.3. Switching Router Filter Modes from EXCLUDE to INCLUDE | A.3. Switching Router Filter Modes from EXCLUDE to INCLUDE | |||
Appendix B. Summary of Changes | Appendix B. Summary of Changes | |||
B.1. MLDv1 | B.1. MLDv1 | |||
B.2. Changes since RFC 3810 | B.2. Changes since RFC 3810 | |||
Acknowledgments | Acknowledgments | |||
Contributors | Contributors | |||
Author's Address | Author's Address | |||
1. Introduction | 1. Introduction | |||
The Multicast Listener Discovery (MLD) protocol is used by IPv6 | The Multicast Listener Discovery (MLD) protocol is used by IPv6 | |||
routers to discover the presence of multicast listeners (i.e., nodes | routers to discover the presence of multicast listeners (i.e., nodes | |||
that wish to receive multicast packets) on their directly attached | that wish to receive multicast packets) on their directly attached | |||
links and to discover specifically which multicast addresses are of | links and to discover specifically which multicast addresses are of | |||
interest to those neighboring nodes. Note that a multicast router | interest to those neighboring nodes. Note that a multicast router | |||
may itself be a listener of one or more multicast addresses; in this | may itself be a listener of one or more multicast addresses; in this | |||
case, it performs both the "multicast router part" and the "multicast | case, it performs both the "multicast router part" and the "Multicast | |||
address listener part" of the protocol, to collect the multicast | Address Listener part" of the protocol, to collect the multicast | |||
listener information needed by its multicast routing protocol on the | listener information needed by its multicast routing protocol and to | |||
one hand, and to inform itself and other neighboring multicast | inform itself and other neighboring multicast routers of its | |||
routers of its listening state on the other hand. | listening state, respectively. | |||
This document specifies version 2 of MLD. The previous version of | This document specifies version 2 of MLD. The previous version of | |||
MLD is specified in [RFC2710]; in this document, we will refer to it | MLD is specified in [RFC2710]; in this document, we will refer to it | |||
as "MLDv1". MLDv2 is a translation of IGMPv3 [RFC9776] for IPv6 | as "MLDv1". MLDv2 is a translation of IGMPv3 [RFC9776] for IPv6 | |||
semantics. | semantics. | |||
The MLDv2 protocol, when compared to MLDv1, adds support for "source | The MLDv2 protocol, when compared to MLDv1, adds support for "source | |||
filtering", i.e., the ability for a node to report interest in | filtering", i.e., the ability for a node to report interest in | |||
listening to packets only from specific source addresses, as required | listening to packets only from specific source addresses, as required | |||
to support Source-Specific Multicast (SSM) [RFC3569], or from *all | to support Source-Specific Multicast (SSM) [RFC3569], or from *all | |||
skipping to change at line 227 ¶ | skipping to change at line 226 ¶ | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
2. Protocol Overview | 2. Protocol Overview | |||
This section gives a brief description of the protocol operation. | This section gives a brief description of the protocol operation. | |||
The following sections present the protocol details. | The following sections present the protocol details. | |||
MLD is an asymmetric protocol; it specifies separate behaviors for | MLD is an asymmetric protocol; it specifies separate behaviors for | |||
multicast address listeners (i.e., hosts or routers that listen to | Multicast Address Listeners (i.e., hosts or routers that listen to | |||
multicast packets) and multicast routers. The purpose of MLD is to | multicast packets) and multicast routers. The purpose of MLD is to | |||
enable each multicast router to learn, for each of its directly | enable each multicast router to learn, for each of its directly | |||
attached links, which multicast addresses and which sources have | attached links, which multicast addresses and which sources have | |||
interested listeners on that link. The information gathered by MLD | interested listeners on that link. The information gathered by MLD | |||
is provided to whichever multicast routing protocol is used by the | is provided to whichever multicast routing protocol is used by the | |||
router, in order to ensure that multicast packets are delivered to | router, in order to ensure that multicast packets are delivered to | |||
all links where there are listeners interested in such packets. | all links where there are listeners interested in such packets. | |||
Multicast routers only need to know that at least one node on an | Multicast routers only need to know that at least one node on an | |||
attached link is listening to packets for a particular multicast | attached link is listening to packets for a particular multicast | |||
skipping to change at line 251 ¶ | skipping to change at line 250 ¶ | |||
A multicast router performs the router part of the MLDv2 protocol | A multicast router performs the router part of the MLDv2 protocol | |||
(described in detail in Section 7) on each of its directly attached | (described in detail in Section 7) on each of its directly attached | |||
links. If a multicast router has more than one interface connected | links. If a multicast router has more than one interface connected | |||
to the same link, it only needs to operate the protocol on one of | to the same link, it only needs to operate the protocol on one of | |||
those interfaces. The router behavior depends on whether there are | those interfaces. The router behavior depends on whether there are | |||
several multicast routers on the same subnet, or not. If that is the | several multicast routers on the same subnet, or not. If that is the | |||
case, a querier election mechanism (described in Section 7.6.2) is | case, a querier election mechanism (described in Section 7.6.2) is | |||
used to elect a single multicast router to be in Querier state. This | used to elect a single multicast router to be in Querier state. This | |||
router is called the "Querier". All multicast routers on the subnet | router is called the "Querier". All multicast routers on the subnet | |||
listen to the messages sent by multicast address listeners, and | listen to the messages sent by Multicast Address Listeners, and | |||
maintain the same multicast listening information state, so that they | maintain the same multicast listening information state, so that they | |||
can take over the querier role, should the present Querier fail. | can take over the querier role, should the present Querier fail. | |||
Nevertheless, only the Querier sends periodical or triggered query | Nevertheless, only the Querier sends periodical or triggered query | |||
messages on the subnet, as described in Section 7.1. | messages on the subnet, as described in Section 7.1. | |||
A multicast address listener performs the listener part of the MLDv2 | A Multicast Address Listener performs the listener part of the MLDv2 | |||
protocol (described in detail in Section 6) on all interfaces on | protocol (described in detail in Section 6) on all interfaces on | |||
which multicast reception is supported, even if more than one of | which multicast reception is supported, even if more than one of | |||
those interfaces are connected to the same link. | those interfaces are connected to the same link. | |||
2.1. Building Multicast Listening State on Multicast Address Listeners | 2.1. Building Multicast Address Listening State on Multicast Address | |||
Listeners | ||||
Upper-layer protocols and applications that run on a multicast | Upper-layer protocols and applications that run on a Multicast | |||
address listener node use specific service interface calls (described | Address Listener node use specific service interface calls (described | |||
in Section 3) to ask the IP layer to enable or disable reception of | in Section 3) to ask the IP layer to enable or disable reception of | |||
packets sent to specific multicast addresses. The node keeps | packets sent to specific multicast addresses. The node keeps | |||
Multicast Address Listening state for each socket on which the | Multicast Address Listening state for each socket on which the | |||
service interface calls have been invoked (Section 4.1). In addition | service interface calls have been invoked (Section 4.1). In addition | |||
to this per-socket multicast listening state, a node must also | to this per-socket Multicast Address Listening state, a node must | |||
maintain or compute multicast listening state for each of its | also maintain or compute Multicast Address Listening state for each | |||
interfaces (Section 4.2). Conceptually, that state consists of a set | of its interfaces (Section 4.2). Conceptually, that state consists | |||
of records, with each record containing an IPv6 multicast address, a | of a set of records, with each record containing an IPv6 multicast | |||
filter mode, and a source list. The filter mode may be either | address, a filter mode, and a source list. The filter mode may be | |||
INCLUDE or EXCLUDE. In INCLUDE mode, reception of packets sent to | either INCLUDE or EXCLUDE. In INCLUDE mode, reception of packets | |||
the specified multicast address is enabled only from the source | sent to the specified multicast address is enabled only from the | |||
addresses listed in the source list. In EXCLUDE mode, reception of | source addresses listed in the source list. In EXCLUDE mode, | |||
packets sent to the given multicast address is enabled from all | reception of packets sent to the given multicast address is enabled | |||
source addresses except those listed in the source list. | from all source addresses except those listed in the source list. | |||
At most, one record per multicast address exists for a given | At most, one record per multicast address exists for a given | |||
interface. This per-interface state is derived from the per-socket | interface. This per-interface state is derived from the per-socket | |||
state, but it may differ from the per-socket state when different | state, but it may differ from the per-socket state when different | |||
sockets have differing filter modes and/or source lists for the same | sockets have differing filter modes and/or source lists for the same | |||
multicast address and interface. After a multicast packet has been | multicast address and interface. After a multicast packet has been | |||
accepted from an interface by the IP layer, its subsequent delivery | accepted from an interface by the IP layer, its subsequent delivery | |||
to the application connected to a particular socket depends on the | to the application connected to a particular socket depends on the | |||
multicast listening state of that socket (and possibly also on other | Multicast Address Listening state of that socket (and possibly also | |||
conditions, such as what transport-layer port the socket is bound | on other conditions, such as what transport-layer port the socket is | |||
to). Note that MLDv2 messages are not subject to source filtering | bound to). Note that MLDv2 messages are not subject to source | |||
and must always be processed by hosts and routers. | filtering and must always be processed by hosts and routers. | |||
2.2. Exchanging Messages between the Querier and the Listening Nodes | 2.2. Exchanging Messages between the Querier and the Listening Nodes | |||
There are three types of MLDv2 query messages: General Queries, | There are three types of MLDv2 query messages: General Queries, | |||
Multicast Address Specific Queries, and Multicast Address and Source | Multicast Address Specific Queries, and Multicast Address and Source | |||
Specific Queries. The Querier periodically sends General Queries, to | Specific Queries. The Querier periodically sends General Queries, to | |||
learn multicast address listener information from an attached link. | learn Multicast Address Listener information from an attached link. | |||
These queries are used to build and refresh the Multicast Address | These queries are used to build and refresh the Multicast Address | |||
Listener state inside all multicast routers on the link. | Listening state inside all multicast routers on the link. | |||
Nodes respond to these queries by reporting their per-interface | Nodes respond to these queries by reporting their per-interface | |||
Multicast Address Listening state through Current State Report | Multicast Address Listening state through Current-State Report | |||
messages sent to a specific multicast address that all MLDv2 routers | messages sent to a specific multicast address that all MLDv2 routers | |||
on the link listen to. On the other hand, if the listening state of | on the link listen to. On the other hand, if the listening state of | |||
a node changes, the node immediately reports these changes through a | a node changes, the node immediately reports these changes through a | |||
State Change Report message. The State Change Report contains either | State-Change Report message. The State-Change Report contains either | |||
Filter Mode Change Records, Source List Change Records, or records of | Filter-Mode-Change Records, Source List Change Records, or records of | |||
both types. A detailed description of the report messages is | both types. A detailed description of the report messages is | |||
presented in Section 5.2.13. | presented in Section 5.2.13. | |||
Both router and listener state changes are mainly triggered by the | Both router and listener state changes are mainly triggered by the | |||
expiration of a specific timer or the reception of an MLD message | expiration of a specific timer or the reception of an MLD message | |||
(listener state change can be also triggered by the invocation of a | (listener state change can be also triggered by the invocation of a | |||
service interface call). Therefore, to enhance protocol robustness, | service interface call). Therefore, to enhance protocol robustness, | |||
in spite of the possible unreliability of message exchanges, messages | in spite of the possible unreliability of message exchanges, messages | |||
are retransmitted several times. Furthermore, timers are set so as | are retransmitted several times. Furthermore, timers are set so as | |||
to take into account the possible message losses and to wait for | to take into account the possible message losses and to wait for | |||
retransmissions. | retransmissions. | |||
Periodical General Queries and Current State Reports do not apply | Periodical General Queries and Current-State Reports do not apply | |||
this rule, in order to not overload the link; it is assumed that in | this rule, in order to not overload the link; it is assumed that in | |||
general, these messages do not generate state changes as their main | general, these messages do not generate state changes as their main | |||
purpose is to refresh existing state. Thus, even if one such message | purpose is to refresh existing state. Thus, even if one such message | |||
is lost, the corresponding state will be refreshed during the next | is lost, the corresponding state will be refreshed during the next | |||
reporting period. | reporting period. | |||
As opposed to Current State Reports, State Change Reports are | As opposed to Current-State Reports, State-Change Reports are | |||
retransmitted several times, in order to avoid them being missed by | retransmitted several times, in order to avoid them being missed by | |||
one or more multicast routers. The number of retransmissions depends | one or more multicast routers. The number of retransmissions depends | |||
on the so-called Robustness Variable. This variable allows tuning | on the so-called Robustness Variable. This variable allows tuning | |||
the protocol according to the expected packet loss on a link. If a | the protocol according to the expected packet loss on a link. If a | |||
link is expected to be lossy (e.g., a wireless connection), the value | link is expected to be lossy (e.g., a wireless connection), the value | |||
of the Robustness Variable may be increased. MLD is robust to | of the Robustness Variable may be increased. MLD is robust to | |||
[Robustness Variable]-1 packet losses. This document recommends a | [Robustness Variable]-1 packet losses. This document recommends a | |||
default value of 2 for the Robustness Variable (see Section 9.1). | default value of 2 for the Robustness Variable (see Section 9.1). | |||
If more changes to the same per-interface state entry occur before | If more changes to the same per-interface state entry occur before | |||
all the retransmissions of the State Change Report for the first | all the retransmissions of the State-Change Report for the first | |||
change have been completed, each additional change triggers the | change have been completed, each additional change triggers the | |||
immediate transmission of a new State Change Report. Section 6.1 | immediate transmission of a new State-Change Report. Section 6.1 | |||
shows how the content of this new report is computed. | shows how the content of this new report is computed. | |||
Retransmissions of the new State Change Report will be scheduled as | Retransmissions of the new State-Change Report will be scheduled as | |||
well, in order to ensure that each instance of state change is | well, in order to ensure that each instance of state change is | |||
transmitted at least [Robustness Variable] times. | transmitted at least [Robustness Variable] times. | |||
If a node on a link expresses, through a State Change Report, its | If a node on a link expresses, through a State-Change Report, its | |||
desire to no longer listen to a particular multicast address (or | desire to no longer listen to a particular multicast address (or | |||
source), the Querier must query for other listeners of the multicast | source), the Querier must query for other listeners of the multicast | |||
address (or source) before deleting the multicast address (or source) | address (or source) before deleting the multicast address (or source) | |||
from its Multicast Address Listener state and stopping the | from its Multicast Address Listening state and stopping the | |||
corresponding traffic. Thus, the Querier sends a Multicast Address | corresponding traffic. Thus, the Querier sends a Multicast Address | |||
Specific Query to verify whether there are nodes still listening to a | Specific Query to verify whether there are nodes still listening to a | |||
specified multicast address or not. Similarly, the Querier sends a | specified multicast address or not. Similarly, the Querier sends a | |||
Multicast Address and Source Specific Query to verify whether, for a | Multicast Address and Source Specific Query to verify whether, for a | |||
specified multicast address, there are nodes still listening to a | specified multicast address, there are nodes still listening to a | |||
specific set of sources, or not. Section 5.1.13 describes each query | specific set of sources, or not. Section 5.1.13 describes each query | |||
in more detail. | in more detail. | |||
Both Multicast Address Specific Queries and Multicast Address and | Both Multicast Address Specific Queries and Multicast Address and | |||
Source Specific Queries are only sent in response to State Change | Source Specific Queries are only sent in response to State-Change | |||
Reports, never in response to Current State Reports. This | Reports, never in response to Current-State Reports. This | |||
distinction between the two types of reports is needed to avoid the | distinction between the two types of reports is needed to avoid the | |||
router treating all Multicast Listener Reports as potential changes | router treating all Multicast Listener Reports as potential changes | |||
in state. By doing so, the fast leave mechanism of MLDv2, described | in state. By doing so, the fast leave mechanism of MLDv2, described | |||
in more detail in Section 2.3, might not be effective if a State | in more detail in Section 2.3, might not be effective if a State- | |||
Change Report is lost and only the following Current State Report is | Change Report is lost and only the following Current-State Report is | |||
received by the router. Nevertheless, it avoids an increased | received by the router. Nevertheless, it avoids an increased | |||
processing at the router, and it reduces the MLD traffic on the link. | processing at the router, and it reduces the MLD traffic on the link. | |||
More details on the necessity of distinguishing between the two | More details on the necessity of distinguishing between the two | |||
report types can be found in Appendix A.1. | report types can be found in Appendix A.1. | |||
Nodes respond to the above queries through Current State Reports that | Nodes respond to the above queries through Current-State Reports that | |||
contain their per-interface Multicast Address Listening state only | contain their per-interface Multicast Address Listening state only | |||
for the multicast addresses (or sources) being queried. | for the multicast addresses (or sources) being queried. | |||
As stated earlier, in order to ensure protocol robustness, all the | As stated earlier, in order to ensure protocol robustness, all the | |||
queries, except the periodical General Queries, are retransmitted | queries, except the periodical General Queries, are retransmitted | |||
several times within a given time interval. The number of | several times within a given time interval. The number of | |||
retransmissions depends on the Robustness Variable. If, while | retransmissions depends on the Robustness Variable. If, while | |||
scheduling new queries, there are pending queries to be retransmitted | scheduling new queries, there are pending queries to be retransmitted | |||
for the same multicast address, the new queries and the pending | for the same multicast address, the new queries and the pending | |||
queries have to be merged. In addition, host reports received for a | queries have to be merged. In addition, host reports received for a | |||
skipping to change at line 405 ¶ | skipping to change at line 405 ¶ | |||
similarly, any non-querier multicast router that receives the query | similarly, any non-querier multicast router that receives the query | |||
lowers its timers in the same way. Nevertheless, while waiting for | lowers its timers in the same way. Nevertheless, while waiting for | |||
the next scheduled queries to be sent, the Querier may receive a | the next scheduled queries to be sent, the Querier may receive a | |||
report that updates the timers. The scheduled queries still have to | report that updates the timers. The scheduled queries still have to | |||
be sent, in order to ensure that a non-querier router keeps its state | be sent, in order to ensure that a non-querier router keeps its state | |||
synchronized with the current Querier (the non-querier router might | synchronized with the current Querier (the non-querier router might | |||
have missed the first query). Nevertheless, the timers should not be | have missed the first query). Nevertheless, the timers should not be | |||
lowered again, as a valid answer was already received. Therefore, in | lowered again, as a valid answer was already received. Therefore, in | |||
subsequent queries, the Querier sets the S flag. | subsequent queries, the Querier sets the S flag. | |||
2.3. Building Multicast Address Listener State on Multicast Routers | 2.3. Building Multicast Address Listening State on Multicast Routers | |||
Multicast routers that implement MLDv2 (whether they are in Querier | Multicast routers that implement MLDv2 (whether they are in Querier | |||
state or not) keep state per multicast address per attached link. | state or not) keep state per multicast address per attached link. | |||
This multicast address listener state consists of a Filter Mode, a | This Multicast Address Listening state consists of a filter mode, a | |||
Filter Timer, and a Source List, with a timer associated to each | filter timer, and a source list, with a timer associated to each | |||
source from the list. The Filter Mode is used to summarize the total | source from the list. The filter mode is used to summarize the total | |||
listening state of a multicast address to a minimum set, such that | listening state of a multicast address to a minimum set, such that | |||
all nodes' listening states are respected. The Filter Mode may | all nodes' listening states are respected. The filter mode may | |||
change in response to the reception of particular types of report | change in response to the reception of particular types of report | |||
messages or when certain timer conditions occur. | messages or when certain timer conditions occur. | |||
A router is in INCLUDE mode for a specific multicast address on a | A router is in INCLUDE mode for a specific multicast address on a | |||
given interface if all the listeners on the link interested in that | given interface if all the listeners on the link interested in that | |||
address are in INCLUDE mode. The router state is represented through | address are in INCLUDE mode. The router state is represented through | |||
the notation INCLUDE (A), where A is a list of sources, called the | the notation INCLUDE (A), where A is a list of sources, called the | |||
"Include List". The Include List is the set of sources that one or | "Include List". The Include List is the set of sources that one or | |||
more listeners on the link have requested to receive. All the | more listeners on the link have requested to receive. All the | |||
sources from the Include List will be forwarded by the router. Any | sources from the Include List will be forwarded by the router. Any | |||
other source that is not in the Include List will be blocked by the | other source that is not in the Include List will be blocked by the | |||
router. | router. | |||
A source can be added to the current Include List if a listener in | A source can be added to the current Include List if a listener in | |||
INCLUDE mode sends a Current State or a State Change Report that | INCLUDE mode sends a Current-State or a State-Change Report that | |||
includes that source. Each source from the Include List is | includes that source. Each source from the Include List is | |||
associated with a source timer that is updated whenever a listener in | associated with a Source Timer that is updated whenever a listener in | |||
INCLUDE mode sends a report that confirms its interest in that | INCLUDE mode sends a report that confirms its interest in that | |||
specific source. If the timer of a source from the Include List | specific source. If the timer of a source from the Include List | |||
expires, the source is deleted from the Include List. | expires, the source is deleted from the Include List. | |||
Besides this "soft leave" mechanism, there is also a "fast leave" | Besides this "soft leave" mechanism, there is also a "fast leave" | |||
scheme in MLDv2; it is also based on the use of source timers. When | scheme in MLDv2; it is also based on the use of source timers. When | |||
a node in INCLUDE mode expresses its desire to stop listening to a | a node in INCLUDE mode expresses its desire to stop listening to a | |||
specific source, all the multicast routers on the link lower their | specific source, all the multicast routers on the link lower their | |||
timers for that source to a given value. The Querier then sends a | timers for that source to a given value. The Querier then sends a | |||
Multicast Address and Source Specific Query, to verify whether there | Multicast Address and Source Specific Query, to verify whether there | |||
are other listeners for that source on the link, or not. If a report | are other listeners for that source on the link, or not. If a report | |||
that includes this source is received before the timer expiration, | that includes this source is received before the timer expiration, | |||
all the multicast routers on the link update the source timer. If | all the multicast routers on the link update the source timer. If | |||
not, the source is deleted from the Include List. The handling of | not, the source is deleted from the Include List. The handling of | |||
the Include List, according to the received reports, is detailed in | the Include List, according to the received reports, is detailed in | |||
Sections 7.4.1 and 7.4.2. | Sections 7.4.1 and 7.4.2. | |||
A router is in EXCLUDE mode for a specific multicast address on a | A router is in EXCLUDE mode for a specific multicast address on a | |||
given interface if there is at least one listener in EXCLUDE mode for | given interface if there is at least one listener in EXCLUDE mode for | |||
that address on the link. When the first report is received from | that address on the link. When the first report is received from | |||
such a listener, the router sets the Filter Timer that corresponds to | such a listener, the router sets the filter timer that corresponds to | |||
that address. This timer is reset each time an EXCLUDE mode listener | that address. This timer is reset each time an EXCLUDE mode listener | |||
confirms its listening state through a Current State Report. The | confirms its listening state through a Current-State Report. The | |||
timer is also updated when a listener, formerly in INCLUDE mode, | timer is also updated when a listener, formerly in INCLUDE mode, | |||
announces its filter mode change through a State Change Report | announces its filter mode change through a State-Change Report | |||
message. If the Filter Timer expires, it means that there are no | message. If the filter timer expires, it means that there are no | |||
more listeners in EXCLUDE mode on the link. In this case, the router | more listeners in EXCLUDE mode on the link. In this case, the router | |||
switches back to INCLUDE mode for that multicast address. | switches back to INCLUDE mode for that multicast address. | |||
When the router is in EXCLUDE mode, the router state is represented | When the router is in EXCLUDE mode, the router state is represented | |||
by the notation EXCLUDE (X,Y), where X is called the "Requested List" | by the notation EXCLUDE (X,Y), where X is called the "Requested List" | |||
and Y is called the "Exclude List". All sources, except those from | and Y is called the "Exclude List". All sources, except those from | |||
the Exclude List, will be forwarded by the router. The Requested | the Exclude List, will be forwarded by the router. The Requested | |||
List has no effect on forwarding. Nevertheless, the router has to | List has no effect on forwarding. Nevertheless, the router has to | |||
maintain the Requested List for two reasons: | maintain the Requested List for two reasons: | |||
skipping to change at line 485 ¶ | skipping to change at line 485 ¶ | |||
When the router switches to INCLUDE mode, the sources in the | When the router switches to INCLUDE mode, the sources in the | |||
Requested List are moved to the Include List, and the Exclude | Requested List are moved to the Include List, and the Exclude | |||
List is deleted. Before switching, the Requested List can | List is deleted. Before switching, the Requested List can | |||
contain an inexact guess of the sources listeners in INCLUDE mode | contain an inexact guess of the sources listeners in INCLUDE mode | |||
listen to, which might be too large or too small. These | listen to, which might be too large or too small. These | |||
inexactitudes are due to the fact that the Requested List is also | inexactitudes are due to the fact that the Requested List is also | |||
used for fast blocking purposes, as described below. If such a | used for fast blocking purposes, as described below. If such a | |||
fast blocking is required, some sources may be deleted from the | fast blocking is required, some sources may be deleted from the | |||
Requested List (as shown in Sections 7.4.1 and 7.4.2) in order to | Requested List (as shown in Sections 7.4.1 and 7.4.2) in order to | |||
reduce router state. Nevertheless, in each such case, the Filter | reduce router state. Nevertheless, in each such case, the filter | |||
Timer is updated as well. Therefore, listeners in INCLUDE mode | timer is updated as well. Therefore, listeners in INCLUDE mode | |||
will have enough time, before an eventual switching, to reconfirm | will have enough time, before an eventual switching, to reconfirm | |||
their interest in the eliminated source(s) and rebuild the | their interest in the eliminated source(s) and rebuild the | |||
Requested List accordingly. The protocol ensures that when a | Requested List accordingly. The protocol ensures that when a | |||
switch to INCLUDE mode occurs, the Requested List will be | switch to INCLUDE mode occurs, the Requested List will be | |||
accurate. Details about the transition of the router to INCLUDE | accurate. Details about the transition of the router to INCLUDE | |||
mode are presented in Appendix A.3. | mode are presented in Appendix A.3. | |||
2. To allow the fast blocking of previously unblocked sources. If | 2. To allow the fast blocking of previously unblocked sources. If | |||
the router receives a report that contains such a request, the | the router receives a report that contains such a request, the | |||
concerned sources are added to the Requested List. Their timers | concerned sources are added to the Requested List. Their timers | |||
skipping to change at line 549 ¶ | skipping to change at line 549 ¶ | |||
"primary" or "default" interface of the node (perhaps established | "primary" or "default" interface of the node (perhaps established | |||
by system configuration). If reception of the same multicast | by system configuration). If reception of the same multicast | |||
address is desired on more than one interface, IPv6MulticastListen | address is desired on more than one interface, IPv6MulticastListen | |||
is invoked separately for each desired interface. | is invoked separately for each desired interface. | |||
* "IPv6 multicast address" is the multicast address to which the | * "IPv6 multicast address" is the multicast address to which the | |||
request pertains. If reception of more than one multicast address | request pertains. If reception of more than one multicast address | |||
on a given interface is desired, IPv6MulticastListen is invoked | on a given interface is desired, IPv6MulticastListen is invoked | |||
separately for each desired address. | separately for each desired address. | |||
* "filter mode" may be either INCLUDE or EXCLUDE. In INCLUDE mode, | * "filter-mode" may be either INCLUDE or EXCLUDE. In INCLUDE mode, | |||
reception of packets sent to the specified multicast address is | reception of packets sent to the specified multicast address is | |||
requested only from the source addresses listed in the source list | requested only from the source addresses listed in the source list | |||
parameter. In EXCLUDE mode, reception of packets sent to the | parameter. In EXCLUDE mode, reception of packets sent to the | |||
given multicast address is requested from all source addresses | given multicast address is requested from all source addresses | |||
except those listed in the source list parameter. | except those listed in the source list parameter. | |||
* "source list" is an unordered list of zero or more unicast | * "source list" is an unordered list of zero or more unicast | |||
addresses from which multicast reception is desired or not | addresses from which multicast reception is desired or not | |||
desired, depending on the filter mode. An implementation MAY | desired, depending on the filter mode. An implementation MAY | |||
impose a limit on the size of source lists. When an operation | impose a limit on the size of source lists. When an operation | |||
skipping to change at line 575 ¶ | skipping to change at line 575 ¶ | |||
at any one time. Nevertheless, either the filter mode or the source | at any one time. Nevertheless, either the filter mode or the source | |||
list, or both, may be changed by subsequent IPv6MulticastListen | list, or both, may be changed by subsequent IPv6MulticastListen | |||
requests that specify the same socket, interface, and IPv6 multicast | requests that specify the same socket, interface, and IPv6 multicast | |||
address. Each subsequent request completely replaces any earlier | address. Each subsequent request completely replaces any earlier | |||
request for the given socket, interface, and multicast address. | request for the given socket, interface, and multicast address. | |||
The MLDv1 protocol did not support source filters and had a simpler | The MLDv1 protocol did not support source filters and had a simpler | |||
service interface; it consisted of Start Listening and Stop Listening | service interface; it consisted of Start Listening and Stop Listening | |||
operations to enable and disable listening to a given multicast | operations to enable and disable listening to a given multicast | |||
address (from all sources) on a given interface. The equivalent | address (from all sources) on a given interface. The equivalent | |||
operations in the new service interface are as follows. | operations in the service interface are as follows. | |||
The Start Listening operation is equivalent to: | The Start Listening operation is equivalent to: | |||
IPv6MulticastListen ( socket, interface, IPv6 multicast address, | IPv6MulticastListen ( socket, interface, IPv6 multicast address, | |||
EXCLUDE, {} ) | EXCLUDE, {} ) | |||
and the Stop Listening operation is equivalent to: | and the Stop Listening operation is equivalent to: | |||
IPv6MulticastListen ( socket, interface, IPv6 multicast address, | IPv6MulticastListen ( socket, interface, IPv6 multicast address, | |||
INCLUDE, {} ) | INCLUDE, {} ) | |||
where {} is an empty source list. | where {} is an empty source list. | |||
An example of an API that provides the capabilities outlined in this | An example of an API that provides the capabilities outlined in this | |||
service interface is given in [RFC3678]. | service interface is given in [RFC3678]. | |||
4. Multicast Listening State Maintained by Nodes | 4. Multicast Address Listening State Maintained by Nodes | |||
4.1. Per-Socket State | 4.1. Per-Socket State | |||
For each socket on which IPv6MulticastListen has been invoked, the | For each socket on which IPv6MulticastListen has been invoked, the | |||
node records the desired multicast listening state for that socket. | node records the desired Multicast Address Listening state for that | |||
That state conceptually consists of a set of records of the form: | socket. That state conceptually consists of a set of records of the | |||
form: | ||||
(interface, IPv6 multicast address, filter mode, source list) | (interface, IPv6 multicast address, filter mode, source list) | |||
The per-socket state evolves in response to each invocation of | The per-socket state evolves in response to each invocation of | |||
IPv6MulticastListen on the socket, as follows: | IPv6MulticastListen on the socket, as follows: | |||
* If the requested filter mode is INCLUDE and the requested source | * If the requested filter mode is INCLUDE and the requested source | |||
list is empty, then the entry that corresponds to the requested | list is empty, then the entry that corresponds to the requested | |||
interface and multicast address is deleted, if present. If no | interface and multicast address is deleted, if present. If no | |||
such entry is present, the request has no effect. | such entry is present, the request has no effect. | |||
* If the requested filter mode is EXCLUDE or the requested source | * If the requested filter mode is EXCLUDE or the requested source | |||
list is non-empty, then the entry that corresponds to the | list is non-empty, then the entry that corresponds to the | |||
requested interface and multicast address, if present, is changed | requested interface and multicast address, if present, is changed | |||
to contain the requested filter mode and source list. If no such | to contain the requested filter mode and source list. If no such | |||
entry is present, a new entry is created, using the parameters | entry is present, a new entry is created, using the parameters | |||
specified in the request. | specified in the request. | |||
4.2. Per-Interface State | 4.2. Per-Interface State | |||
In addition to the per-socket multicast listening state, a node must | In addition to the per-socket Multicast Address Listening state, a | |||
also maintain or compute multicast listening state for each of its | node must also maintain or compute Multicast Address Listening state | |||
interfaces. That state conceptually consists of a set of records of | for each of its interfaces. That state conceptually consists of a | |||
the form: | set of records of the form: | |||
(IPv6 multicast address, filter mode, source list) | (IPv6 multicast address, filter mode, source list) | |||
At most, one record per multicast address exists for a given | At most, one record per multicast address exists for a given | |||
interface. This per-interface state is derived from the per-socket | interface. This per-interface state is derived from the per-socket | |||
state, but it may differ from the per-socket state when different | state, but it may differ from the per-socket state when different | |||
sockets have differing filter modes and/or source lists for the same | sockets have differing filter modes and/or source lists for the same | |||
multicast address and interface. For example, suppose one | multicast address and interface. For example, suppose one | |||
application or process invokes the following operation on socket s1: | application or process invokes the following operation on socket s1: | |||
skipping to change at line 652 ¶ | skipping to change at line 653 ¶ | |||
requesting reception on the same interface i of packets sent to the | 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. | 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 | 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 | 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 | 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 | state of interface i for multicast address m has filter mode INCLUDE | |||
and source list {a, b, c, d}. | and source list {a, b, c, d}. | |||
After a multicast packet has been accepted from an interface by the | After a multicast packet has been accepted from an interface by the | |||
IP layer, its subsequent delivery to the application or process that | IP layer, its subsequent delivery to the application or process that | |||
listens on a particular socket depends on the multicast listening | listens on a particular socket depends on the Multicast Address | |||
state of that socket (and possibly also on other conditions, such as | Listening state of that socket (and possibly also on other | |||
what transport-layer port the socket is bound to). So, in the above | conditions, such as what transport-layer port the socket is bound | |||
example, if a packet arrives on interface i, destined to multicast | to). So, in the above example, if a packet arrives on interface i, | |||
address m, with source address a, it may be delivered on socket s1 | destined to multicast address m, with source address a, it may be | |||
but not on socket s2. Note that MLDv2 messages are not subject to | delivered on socket s1 but not on socket s2. Note that MLDv2 | |||
source filtering and must always be processed by hosts and routers. | 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 | Requiring the filtering of packets based upon a socket's multicast | |||
reception state is a new feature of this service interface. The | reception state is a feature of this service interface. The previous | |||
previous service interface described no filtering based upon | service interface described no filtering based upon Multicast Address | |||
multicast listening state; rather, a Start Listening operation on a | Listening state; rather, a Start Listening operation on a socket | |||
socket simply caused the node to start to listen to a multicast | simply caused the node to start to listen to a multicast address on | |||
address on the given interface; packets sent to that multicast | the given interface; packets sent to that multicast address could be | |||
address could be delivered to all sockets, whether they had started | delivered to all sockets, whether they had started to listen or not. | |||
to listen or not. | ||||
The general rules for deriving the per-interface state from the per- | The general rules for deriving the per-interface state from the per- | |||
socket state are as follows: for each distinct (interface, IPv6 | socket state are as follows: for each distinct (interface, IPv6 | |||
multicast address) pair that appears in any per-socket state, a per- | multicast address) pair that appears in any per-socket state, a per- | |||
interface record is created for that multicast address on that | interface record is created for that multicast address on that | |||
interface. Considering all socket records that contain the same | interface. Considering all socket records that contain the same | |||
(interface, IPv6 multicast address) pair, | (interface, IPv6 multicast address) pair, | |||
* if any such record has a filter mode of EXCLUDE, then the filter | * 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 | mode of the interface record is EXCLUDE, and the source list of | |||
skipping to change at line 756 ¶ | skipping to change at line 757 ¶ | |||
* Multicast Listener Query (Type = decimal 130) | * Multicast Listener Query (Type = decimal 130) | |||
* Version 2 Multicast Listener Report (Type = decimal 143). See | * Version 2 Multicast Listener Report (Type = decimal 143). See | |||
Section 11 for IANA considerations. | Section 11 for IANA considerations. | |||
To assure the interoperability with nodes that implement MLDv1 (see | To assure the interoperability with nodes that implement MLDv1 (see | |||
Section 8), an implementation of MLDv2 must also support the | Section 8), an implementation of MLDv2 must also support the | |||
following two message types: | following two message types: | |||
* Version 1 Multicast Listener Report (Type = decimal 131) [RFC2710] | * Multicast Listener Report (Type = decimal 131) [RFC2710] | |||
* Version 1 Multicast Listener Done (Type = decimal 132) [RFC2710] | * Multicast Listener Done (Type = decimal 132) [RFC2710] | |||
Unrecognized message types MUST be silently ignored. Other message | Unrecognized message types MUST be silently ignored. Other message | |||
types may be used by newer versions or extensions of MLD, by | types may be used by newer versions or extensions of MLD, by | |||
multicast routing protocols, or for other uses. | multicast routing protocols, or for other uses. | |||
In this document, unless otherwise qualified, the capitalized words | In this document, unless otherwise qualified, the capitalized words | |||
"Query" and "Report" refer to MLD Multicast Listener Queries and MLD | "Query" and "Report" refer to MLD Multicast Listener Queries and MLD | |||
Version 2 Multicast Listener Reports, respectively. | Version 2 Multicast Listener Reports, respectively. | |||
5.1. Multicast Listener Query Message | 5.1. Multicast Listener Query Message | |||
Multicast Listener Queries are sent by multicast routers in Querier | Multicast Listener Queries are sent by multicast routers in Querier | |||
state to query the multicast listening state of neighboring | state to query the Multicast Address Listening state of neighboring | |||
interfaces. Queries have the following format: | interfaces. Queries have the following format: | |||
0 1 2 3 | 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 | 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 | | | Type = 130 | Code | Checksum | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Maximum Response Code | Reserved | | | Maximum Response Code | Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
skipping to change at line 828 ¶ | skipping to change at line 829 ¶ | |||
5.1.1. Code | 5.1.1. Code | |||
The Code field is initialized to zero by the sender and ignored by | The Code field is initialized to zero by the sender and ignored by | |||
receivers. | receivers. | |||
5.1.2. Checksum | 5.1.2. Checksum | |||
The Checksum field is the standard ICMPv6 checksum; it covers the | The Checksum field is the standard ICMPv6 checksum; it covers the | |||
entire MLDv2 message, plus a "pseudo-header" of IPv6 header fields | entire MLDv2 message, plus a "pseudo-header" of IPv6 header fields | |||
[RFC4443]. For computing the checksum, the Checksum field is set to | [RFC4443] [RFC8200]. For computing the checksum, the Checksum field | |||
zero. When a packet is received, the checksum MUST be verified | is set to zero. When a packet is received, the checksum MUST be | |||
before processing it. | verified before processing it. | |||
5.1.3. Maximum Response Code | 5.1.3. Maximum Response Code | |||
The Maximum Response Code field specifies the maximum time allowed | The Maximum Response Code field specifies the maximum time allowed | |||
before sending a responding Report. The actual time allowed, called | before sending a responding Report. The actual time allowed, called | |||
the "Maximum Response Delay", is represented in units of milliseconds | the "Maximum Response Delay", is represented in units of milliseconds | |||
and is derived from the Maximum Response Code as follows: | and is derived from the Maximum Response Code as follows: | |||
* If Maximum Response Code < 32768, Maximum Response Delay = Maximum | * If Maximum Response Code < 32768, Maximum Response Delay = Maximum | |||
Response Code. | Response Code. | |||
skipping to change at line 853 ¶ | skipping to change at line 854 ¶ | |||
a floating-point value as follows: | a floating-point value as follows: | |||
0 1 2 3 4 5 6 7 8 9 A B C D E F | 0 1 2 3 4 5 6 7 8 9 A B C D E F | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|1| exp | mant | | |1| exp | mant | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Maximum Response Delay = (mant | 0x1000) << (exp+3) | Maximum Response Delay = (mant | 0x1000) << (exp+3) | |||
Small values of Maximum Response Delay allow MLDv2 routers to tune | Small values of Maximum Response Delay allow MLDv2 routers to tune | |||
the "leave latency" (the time between the moment the last node on a | 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 | link ceases to listen to a specific multicast address and the moment | |||
the routing protocol is notified that there are no more listeners for | the routing protocol is notified that there are no more listeners for | |||
that address). Larger values, especially in the exponential range, | that address). Larger values, especially in the exponential range, | |||
allow the tuning of the burstiness of MLD traffic on a link. | allow the tuning of the burstiness of MLD traffic on a link. | |||
5.1.4. Reserved | 5.1.4. Reserved | |||
The Reserved field is set to zero on transmission and ignored on | The Reserved field is set to zero on transmission and ignored on | |||
reception. | reception. | |||
skipping to change at line 881 ¶ | skipping to change at line 882 ¶ | |||
5.1.6. Flags | 5.1.6. Flags | |||
Allocation of individual bits within the Flags field is described in | Allocation of individual bits within the Flags field is described in | |||
Section 2.2 of [RFC9778]. Future specifications will define the | Section 2.2 of [RFC9778]. Future specifications will define the | |||
associated meaning tied to any such allocation. | associated meaning tied to any such allocation. | |||
5.1.7. S Flag (Suppress Router-Side Processing) | 5.1.7. S Flag (Suppress Router-Side Processing) | |||
When set to one, the S flag indicates to any receiving multicast | When set to one, the S flag indicates to any receiving multicast | |||
routers that they have to suppress the normal timer updates they | routers that they have to suppress the normal timer updates they | |||
perform upon hearing a Query. Nevertheless, it does not suppress the | perform upon receiving a Query. Nevertheless, it does not suppress | |||
querier election or the normal "host-side" processing of a Query that | the querier election or the normal "host-side" processing of a Query | |||
a router may be required to perform as a consequence of itself being | that a router may be required to perform as a consequence of itself | |||
a multicast listener. | being a multicast listener. | |||
5.1.8. QRV (Querier's Robustness Variable) | 5.1.8. QRV (Querier's Robustness Variable) | |||
If non-zero, the QRV field contains the [Robustness Variable] value | If non-zero, the QRV field contains the [Robustness Variable] value | |||
used by the Querier. If the Querier's [Robustness Variable] exceeds | 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. | 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 | Routers adopt the QRV value from the most recently received Query as | |||
their own [Robustness Variable] value, unless that most recently | their own [Robustness Variable] value, unless that most recently | |||
received QRV was zero, in which case they use the default [Robustness | received QRV was zero, in which case they use the default [Robustness | |||
skipping to change at line 996 ¶ | skipping to change at line 997 ¶ | |||
Multicast Address and Source Specific Queries are sent with an IP | Multicast Address and Source Specific Queries are sent with an IP | |||
destination address equal to the multicast address of interest. | destination address equal to the multicast address of interest. | |||
However, a node MUST accept and process any Query whose IP | However, a node MUST accept and process any Query whose IP | |||
Destination Address field contains any of the addresses (unicast or | Destination Address field contains any of the addresses (unicast or | |||
multicast) assigned to the interface on which the Query arrives. | multicast) assigned to the interface on which the Query arrives. | |||
This might be useful, e.g., for debugging purposes. | This might be useful, e.g., for debugging purposes. | |||
5.2. Version 2 Multicast Listener Report Message | 5.2. Version 2 Multicast Listener Report Message | |||
Version 2 Multicast Listener Reports are sent by IP nodes to report | Version 2 Multicast Listener Reports are sent by IP nodes to report | |||
(to neighboring routers) the current multicast listening state, or | (to neighboring routers) the current Multicast Address Listening | |||
changes in the multicast listening state, of their interfaces. | state, or changes in the Multicast Address Listening state, of their | |||
Reports have the following format: | interfaces. Reports have the following format: | |||
0 1 2 3 | 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 | 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 | | | Type = 143 | Reserved | Checksum | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Flags |Nr of Mcast Address Records (M)| | | Flags |Nr of Mcast Address Records (M)| | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
. . | . . | |||
skipping to change at line 1087 ¶ | skipping to change at line 1088 ¶ | |||
5.2.1. Reserved | 5.2.1. Reserved | |||
The Reserved field is set to zero on transmission and ignored on | The Reserved field is set to zero on transmission and ignored on | |||
reception. | reception. | |||
5.2.2. Checksum | 5.2.2. Checksum | |||
The Checksum Field is the standard ICMPv6 checksum; it covers the | The Checksum Field is the standard ICMPv6 checksum; it covers the | |||
entire MLDv2 message, plus a "pseudo-header" of IPv6 header fields | entire MLDv2 message, plus a "pseudo-header" of IPv6 header fields | |||
[RFC8200] [RFC4443]. In order to compute the checksum, the Checksum | [RFC4443] [RFC8200]. In order to compute the checksum, the Checksum | |||
field is set to zero. When a packet is received, the checksum MUST | field is set to zero. When a packet is received, the checksum MUST | |||
be verified before processing it. | be verified before processing it. | |||
5.2.3. Flags | 5.2.3. Flags | |||
Allocation of individual bits within the Flags field is described in | Allocation of individual bits within the Flags field is described in | |||
Section 2.3 of [RFC9778]. Future specifications will define the | Section 2.3 of [RFC9778]. Future specifications will define the | |||
associated meaning tied to any such allocation. | associated meaning tied to any such allocation. | |||
5.2.4. Nr of Mcast Address Records (M) | 5.2.4. Nr of Mcast Address Records (M) | |||
skipping to change at line 1162 ¶ | skipping to change at line 1163 ¶ | |||
those octets in the computation to verify the received MLD Checksum, | those octets in the computation to verify the received MLD Checksum, | |||
but MUST otherwise ignore those additional octets. When sending a | but MUST otherwise ignore those additional octets. When sending a | |||
Report, an MLDv2 implementation MUST NOT include additional octets | Report, an MLDv2 implementation MUST NOT include additional octets | |||
beyond the last Multicast Address Record. | beyond the last Multicast Address Record. | |||
5.2.13. Multicast Address Record Types | 5.2.13. Multicast Address Record Types | |||
There are a number of different types of Multicast Address Records | There are a number of different types of Multicast Address Records | |||
that may be included in a Report message: | that may be included in a Report message: | |||
* A "Current State Record" is sent by a node in response to a Query | * A "Current-State Record" is sent by a node in response to a Query | |||
received on an interface. It reports the current listening state | received on an interface. It reports the current listening state | |||
of that interface, with respect to a single multicast address. | of that interface, with respect to a single multicast address. | |||
The Record Type of a Current State Record may be one of the | The Record Type of a Current-State Record may be one of the | |||
following two values: | following two values: | |||
1. MODE_IS_INCLUDE - indicates that the interface has a filter | 1. MODE_IS_INCLUDE - indicates that the interface has a filter | |||
mode of INCLUDE for the specified multicast address. The | mode of INCLUDE for the specified multicast address. The | |||
Source Address [i] fields in this Multicast Address Record | Source Address [i] fields in this Multicast Address Record | |||
contain the interface's source list for the specified | contain the interface's source list for the specified | |||
multicast address. A MODE_IS_INCLUDE Record is never sent | multicast address. A MODE_IS_INCLUDE Record is never sent | |||
with an empty source list. | with an empty source list. | |||
2. MODE_IS_EXCLUDE - indicates that the interface has a filter | 2. MODE_IS_EXCLUDE - indicates that the interface has a filter | |||
mode of EXCLUDE for the specified multicast address. The | mode of EXCLUDE for the specified multicast address. The | |||
Source Address [i] fields in this Multicast Address Record | Source Address [i] fields in this Multicast Address Record | |||
contain the interface's source list for the specified | contain the interface's source list for the specified | |||
multicast address, if it is non-empty. An SSM-aware host | multicast address, if it is non-empty. An SSM-aware host | |||
SHOULD NOT send a MODE_IS_EXCLUDE record type for multicast | SHOULD NOT send a MODE_IS_EXCLUDE record type for multicast | |||
addresses that fall within the SSM address range as they will | addresses that fall within the SSM address range as they will | |||
be ignored by SSM-aware routers [RFC4604]. | be ignored by SSM-aware routers [RFC4604]. | |||
* A "Filter Mode Change Record" is sent by a node whenever a local | * A "Filter-Mode-Change Record" is sent by a node whenever a local | |||
invocation of IPv6MulticastListen causes a change of the filter | invocation of IPv6MulticastListen causes a change of the filter | |||
mode (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to | mode (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to | |||
INCLUDE) of the interface-level state entry for a particular | INCLUDE) of the interface-level state entry for a particular | |||
multicast address, whether the source list changes at the same | multicast address, whether the source list changes at the same | |||
time or not. The Record is included in a Report sent from the | time or not. The Record is included in a Report sent from the | |||
interface on which the change occurred. The Record Type of a | interface on which the change occurred. The Record Type of a | |||
Filter Mode Change Record may be one of the following two values: | Filter-Mode-Change Record may be one of the following two values: | |||
3. CHANGE_TO_INCLUDE_MODE - indicates that the interface has | 3. CHANGE_TO_INCLUDE_MODE - indicates that the interface has | |||
changed to INCLUDE filter mode for the specified multicast | changed to INCLUDE filter mode for the specified multicast | |||
address. The Source Address [i] fields in this Multicast | address. The Source Address [i] fields in this Multicast | |||
Address Record contain the interface's new source list for the | Address Record contain the interface's new source list for the | |||
specified multicast address, if it is non-empty. | specified multicast address, if it is non-empty. | |||
4. CHANGE_TO_EXCLUDE_MODE - indicates that the interface has | 4. CHANGE_TO_EXCLUDE_MODE - indicates that the interface has | |||
changed to EXCLUDE filter mode for the specified multicast | changed to EXCLUDE filter mode for the specified multicast | |||
address. The Source Address [i] fields in this Multicast | address. The Source Address [i] fields in this Multicast | |||
skipping to change at line 1238 ¶ | skipping to change at line 1239 ¶ | |||
change was to an INCLUDE source list, these are the addresses | change was to an INCLUDE source list, these are the addresses | |||
that were deleted from the list; if the change was to an | that were deleted from the list; if the change was to an | |||
EXCLUDE source list, these are the addresses that were added | EXCLUDE source list, these are the addresses that were added | |||
to the list. | to the list. | |||
If a change of source list results in both allowing new sources and | If a change of source list results in both allowing new sources and | |||
blocking old sources, then two Multicast Address Records are sent for | blocking old sources, then two Multicast Address Records are sent for | |||
the same multicast address, one of type ALLOW_NEW_SOURCES and one of | the same multicast address, one of type ALLOW_NEW_SOURCES and one of | |||
type BLOCK_OLD_SOURCES. | type BLOCK_OLD_SOURCES. | |||
We use the term "State Change Record" to refer to either a Filter | We use the term "State-Change Record" to refer to either a Filter | |||
Mode Change Record or a Source List Change Record. | Mode Change Record or a Source List Change Record. | |||
Multicast Address Records with an unrecognized Record Type value MUST | Multicast Address Records with an unrecognized Record Type value MUST | |||
be silently ignored, with the rest of the report being processed. | be silently ignored, with the rest of the report being processed. | |||
In the rest of this document, we use the following notation to | In the rest of this document, we use the following notation to | |||
describe the contents of a Multicast Address Record that pertains to | describe the contents of a Multicast Address Record that pertains to | |||
a particular multicast address: | a particular multicast address: | |||
IS_IN ( x ) - Type MODE_IS_INCLUDE, source addresses x | * IS_IN ( x ) - Type MODE_IS_INCLUDE, source addresses x | |||
IS_EX ( x ) - Type MODE_IS_EXCLUDE, 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_IN ( x ) - Type CHANGE_TO_INCLUDE_MODE, source addresses x | |||
TO_EX ( x ) - Type CHANGE_TO_EXCLUDE_MODE, source addresses x | * TO_EX ( x ) - Type CHANGE_TO_EXCLUDE_MODE, source addresses x | |||
ALLOW ( x ) - Type ALLOW_NEW_SOURCES, source addresses x | * ALLOW ( x ) - Type ALLOW_NEW_SOURCES, source addresses x | |||
BLOCK ( x ) - Type BLOCK_OLD_SOURCES, source addresses x | * BLOCK ( x ) - Type BLOCK_OLD_SOURCES, source addresses x | |||
where x is either: | where x is either: | |||
* a capital letter (e.g., "A") to represent the set of source | * a capital letter (e.g., "A") to represent the set of source | |||
addresses or | addresses or | |||
* a set expression (e.g., "A+B"), where "A+B" means the union of | * 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 | 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. | "A-B" means the removal of all elements of set B from set A. | |||
skipping to change at line 1334 ¶ | skipping to change at line 1335 ¶ | |||
* if its Type is IS_EX or TO_EX, a single Multicast Address Record | * 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 | is sent, with as many source addresses as can fit; the remaining | |||
source addresses are not reported. Although the choice of which | source addresses are not reported. Although the choice of which | |||
sources to report is arbitrary, it is preferable to report the | sources to report is arbitrary, it is preferable to report the | |||
same set of sources in each subsequent report, rather than | same set of sources in each subsequent report, rather than | |||
reporting different sources each time. | reporting different sources each time. | |||
6. Protocol Description for Multicast Address Listeners | 6. Protocol Description for Multicast Address Listeners | |||
MLD is an asymmetric protocol, as it specifies separate behaviors for | MLD is an asymmetric protocol, as it specifies separate behaviors for | |||
multicast address listeners -- that is, hosts or routers that listen | Multicast Address Listeners -- that is, hosts or routers that listen | |||
to multicast packets -- and multicast routers. This section | to multicast packets -- and multicast routers. This section | |||
describes the part of MLDv2 that applies to all multicast address | describes the part of MLDv2 that applies to all Multicast Address | |||
listeners. (Note that a multicast router that is also a multicast | Listeners. (Note that a multicast router that is also a Multicast | |||
address listener performs both parts of MLDv2; it receives and it | Address Listener performs both parts of MLDv2; it receives and it | |||
responds to its own MLD messages as well as to those of its | responds to its own MLD messages as well as to those of its | |||
neighbors.) The multicast router part of MLDv2 is described in | neighbors.) The multicast router part of MLDv2 is described in | |||
Section 7. | Section 7. | |||
A node performs the protocol described in this section over all | A node performs the protocol described in this section over all | |||
interfaces on which multicast reception is supported, even if more | interfaces on which multicast reception is supported, even if more | |||
than one of those interfaces are connected to the same link. | than one of those interfaces are connected to the same link. | |||
For interoperability with multicast routers that run the MLDv1 | For interoperability with multicast routers that run the MLDv1 | |||
protocol, nodes maintain a Host Compatibility Mode variable for each | protocol, nodes maintain a Host Compatibility Mode variable for each | |||
interface on which multicast reception is supported. This section | interface on which multicast reception is supported. This section | |||
describes the behavior of multicast address listener nodes on | describes the behavior of Multicast Address Listener nodes on | |||
interfaces for which Host Compatibility Mode = MLDv2. The algorithm | interfaces for which Host Compatibility Mode = MLDv2. The algorithm | |||
for determining Host Compatibility Mode and the behavior if its value | for determining Host Compatibility Mode and the behavior if its value | |||
is set to MLDv1 are described in Section 8. | is set to MLDv1 are described in Section 8. | |||
The link-scope all-nodes multicast address, (ff02::1), is handled as | The link-scope all-nodes multicast address, (ff02::1), is handled as | |||
a special case. On all nodes -- that is, all hosts and routers | a special case. On all nodes -- that is, all hosts and routers | |||
including multicast routers -- listening to packets destined to the | including multicast routers -- listening to packets destined to the | |||
all-nodes multicast address, from all sources, is permanently enabled | all-nodes multicast address, from all sources, is permanently enabled | |||
on all interfaces on which multicast listening is supported. No MLD | on all interfaces on which multicast listening is supported. No MLD | |||
messages are ever sent regarding neither the link-scope all-nodes | messages are ever sent regarding neither the link-scope all-nodes | |||
skipping to change at line 1386 ¶ | skipping to change at line 1387 ¶ | |||
(Received MLD messages of types other than Query are silently | (Received MLD messages of types other than Query are silently | |||
ignored, except as required for interoperation with nodes that | ignored, except as required for interoperation with nodes that | |||
implement MLDv1.) | implement MLDv1.) | |||
The following subsections describe the actions to be taken for each | The following subsections describe the actions to be taken for each | |||
case. Timer and counter names appear in square brackets. Default | case. Timer and counter names appear in square brackets. Default | |||
values for those timers and counters are specified in Section 9. | values for those timers and counters are specified in Section 9. | |||
6.1. Action on Change of Per-Interface State | 6.1. Action on Change of Per-Interface State | |||
An invocation of IPv6MulticastListen may cause the multicast | An invocation of IPv6MulticastListen may cause the Multicast Address | |||
listening state of an interface to change, according to the rules in | Listening state of an interface to change, according to the rules in | |||
Section 4.2. Each such change affects the per-interface entry for a | Section 4.2. Each such change affects the per-interface entry for a | |||
single multicast address. | single multicast address. | |||
A change of per-interface state causes the node to immediately | A change of per-interface state causes the node to immediately | |||
transmit a State Change Report from that interface. The type and | transmit a State-Change Report from that interface. The type and | |||
contents of the Multicast Address Record(s) in that Report are | contents of the Multicast Address Record(s) in that Report are | |||
determined by comparing the filter mode and source list for the | determined by comparing the filter mode and source list for the | |||
affected multicast address before and after the change, according to | affected multicast address before and after the change, according to | |||
Table 1. If no per-interface state existed for that multicast | Table 1. If no per-interface state existed for that multicast | |||
address before the change (i.e., the change consisted of creating a | address before the change (i.e., the change consisted of creating a | |||
new per-interface record), or if no state exists after the change | new per-interface record), or if no state exists after the change | |||
(i.e., the change consisted of deleting a per-interface record), then | (i.e., the change consisted of deleting a per-interface record), then | |||
the "non-existent" state is considered to have an INCLUDE filter mode | the "non-existent" state is considered to have an INCLUDE filter mode | |||
and an empty source list. | and an empty source list. | |||
+=============+=============+==========================+ | +=============+=============+==========================+ | |||
| Old State | New State | State Change Record Sent | | | Old State | New State | State-Change Record Sent | | |||
+=============+=============+==========================+ | +=============+=============+==========================+ | |||
| INCLUDE (A) | INCLUDE (B) | ALLOW (B-A), BLOCK (A-B) | | | INCLUDE (A) | INCLUDE (B) | ALLOW (B-A), BLOCK (A-B) | | |||
+-------------+-------------+--------------------------+ | +-------------+-------------+--------------------------+ | |||
| EXCLUDE (A) | EXCLUDE (B) | ALLOW (A-B), BLOCK (B-A) | | | EXCLUDE (A) | EXCLUDE (B) | ALLOW (A-B), BLOCK (B-A) | | |||
+-------------+-------------+--------------------------+ | +-------------+-------------+--------------------------+ | |||
| INCLUDE (A) | EXCLUDE (B) | TO_EX (B) | | | INCLUDE (A) | EXCLUDE (B) | TO_EX (B) | | |||
+-------------+-------------+--------------------------+ | +-------------+-------------+--------------------------+ | |||
| EXCLUDE (A) | INCLUDE (B) | TO_IN (B) | | | EXCLUDE (A) | INCLUDE (B) | TO_IN (B) | | |||
+-------------+-------------+--------------------------+ | +-------------+-------------+--------------------------+ | |||
Table 1: State Change Record Transmission Logic | Table 1: State-Change Record Transmission Logic | |||
If the computed source list for either an ALLOW or a BLOCK State | If the computed source list for either an ALLOW or a BLOCK State- | |||
Change Record is empty, that record is omitted from the Report. | Change Record is empty, that record is omitted from the Report. | |||
To cover the possibility of the State Change Report being missed by | To cover the possibility of the State-Change Report being missed by | |||
one or more multicast routers, [Robustness Variable] - 1 | one or more multicast routers, [Robustness Variable] - 1 | |||
retransmissions are scheduled, through a Retransmission Timer, at | retransmissions are scheduled, through a Retransmission Timer, at | |||
intervals chosen at random from the range (0, [Unsolicited Report | intervals chosen at random from the range (0, [Unsolicited Report | |||
Interval]). | Interval]). | |||
If more changes to the same per-interface state entry occur before | If more changes to the same per-interface state entry occur before | |||
all the retransmissions of the State Change Report for the first | all the retransmissions of the State-Change Report for the first | |||
change have been completed, each such additional change triggers the | change have been completed, each such additional change triggers the | |||
immediate transmission of a new State Change Report. | immediate transmission of a new State-Change Report. | |||
The contents of the new Report are calculated as follows: | The contents of the new Report are calculated as follows: | |||
* As for the first Report, the per-interface state for the affected | * As for the first Report, the per-interface state for the affected | |||
multicast address before and after the latest change is compared. | multicast address before and after the latest change is compared. | |||
* The records that express the difference are built according to the | * The records that express the difference are built according to the | |||
table above. Nevertheless, these records are not transmitted in a | table above. Nevertheless, these records are not transmitted in a | |||
separate message, but they are instead merged with the contents of | separate message, but they are instead merged with the contents of | |||
the pending report, to create the new State Change Report. The | the pending report, to create the new State-Change Report. The | |||
rules for calculating this merged report are described below. | rules for calculating this merged report are described below. | |||
The transmission of the merged State Change Report terminates | The transmission of the merged State-Change Report terminates | |||
retransmissions of the earlier State Change Reports for the same | retransmissions of the earlier State-Change Reports for the same | |||
multicast address and becomes the first of [Robustness Variable] | multicast address and becomes the first of [Robustness Variable] | |||
transmissions of the new State Change Reports. These transmissions | transmissions of the new State-Change Reports. These transmissions | |||
are necessary in order to ensure that each instance of state change | are necessary in order to ensure that each instance of state change | |||
is transmitted at least [Robustness Variable] times. | is transmitted at least [Robustness Variable] times. | |||
Each time a source is included in the difference report calculated | Each time a source is included in the difference report calculated | |||
above, retransmission state for that source needs to be maintained | above, retransmission state for that source needs to be maintained | |||
until [Robustness Variable] State Change Reports have been sent by | until [Robustness Variable] State-Change Reports have been sent by | |||
the node. This is done in order to ensure that a series of | the node. This is done in order to ensure that a series of | |||
successive state changes do not break the protocol robustness. | successive state changes do not break the protocol robustness. | |||
Sources in retransmission state can be kept in a per-multicast- | Sources in retransmission state can be kept in a per-multicast- | |||
address Retransmission List, with a Source Retransmission Counter | address Retransmission List, with a Source Retransmission Counter | |||
associated to each source in the list. When a source is included in | associated to each source in the list. When a source is included in | |||
the list, its counter is set to [Robustness Variable]. Each time a | the list, its counter is set to [Robustness Variable]. Each time a | |||
State Change Report is sent, the counter is decreased by one unit. | State-Change Report is sent, the counter is decreased by one unit. | |||
When the counter reaches zero, the source is deleted from the | When the counter reaches zero, the source is deleted from the | |||
Retransmission List for that multicast address. | Retransmission List for that multicast address. | |||
If the per-interface listening change that triggers the new report is | If the per-interface listening change that triggers the new report is | |||
a filter mode change, then the next [Robustness Variable] State | a filter mode change, then the next [Robustness Variable] State- | |||
Change Reports will include a Filter Mode Change Record. This | Change Reports will include a Filter-Mode-Change Record. This | |||
applies even if any number of source list changes occur in that | applies even if any number of source list changes occur in that | |||
period. The node has to maintain retransmission state for the | period. The node has to maintain retransmission state for the | |||
multicast address until the [Robustness Variable] State Change | multicast address until the [Robustness Variable] State-Change | |||
Reports have been sent. This can be done through a per-multicast- | Reports have been sent. This can be done through a per-multicast- | |||
address Filter Mode Retransmission Counter. When the filter mode | address Filter Mode Retransmission Counter. When the filter mode | |||
changes, the counter is set to [Robustness Variable]. Each time a | changes, the counter is set to [Robustness Variable]. Each time a | |||
State Change Report is sent the counter is decreased by one unit. | State-Change Report is sent the counter is decreased by one unit. | |||
When the counter reaches zero, i.e., [Robustness Variable] State | When the counter reaches zero, i.e., [Robustness Variable] State- | |||
Change Reports with Filter Mode Change Records have been transmitted | Change Reports with Filter-Mode-Change Records have been transmitted | |||
after the last filter mode change, and if source list changes have | after the last filter mode change, and if source list changes have | |||
resulted in additional reports being scheduled, then the next State | resulted in additional reports being scheduled, then the next State- | |||
Change Report will include Source List Change Records. | Change Report will include Source List Change Records. | |||
Each time a per-interface listening state change triggers the | Each time a per-interface listening state change triggers the | |||
immediate transmission of a new State Change Report, its contents are | immediate transmission of a new State-Change Report, its contents are | |||
determined as follows. If the report should contain a Filter Mode | determined as follows. If the report should contain a Filter-Mode- | |||
Change Record, i.e., the Filter Mode Retransmission Counter for that | Change Record, i.e., the Filter Mode Retransmission Counter for that | |||
multicast address has a value higher than zero, then, if the current | multicast address has a value higher than zero, then, if the current | |||
filter mode of the interface is INCLUDE, a TO_IN record is included | filter mode of the interface is INCLUDE, a TO_IN record is included | |||
in the report; otherwise, a TO_EX record is included. If instead the | in the report; otherwise, a TO_EX record is included. If instead the | |||
report should contain Source List Change Records, i.e., the Filter | report should contain Source List Change Records, i.e., the Filter | |||
Mode Retransmission Counter for that multicast address is zero, an | Mode Retransmission Counter for that multicast address is zero, an | |||
ALLOW and a BLOCK record is included. The contents of these records | ALLOW and a BLOCK record is included. The contents of these records | |||
are built according Table 2. | are built according Table 2. | |||
+========+=======================================================+ | +========+=======================================================+ | |||
skipping to change at line 1505 ¶ | skipping to change at line 1506 ¶ | |||
+--------+-------------------------------------------------------+ | +--------+-------------------------------------------------------+ | |||
| TO_EX | All in the current per-interface state that must be | | | TO_EX | All in the current per-interface state that must be | | |||
| | blocked. | | | | blocked. | | |||
+--------+-------------------------------------------------------+ | +--------+-------------------------------------------------------+ | |||
| ALLOW | All with retransmission state (i.e., all sources from | | | ALLOW | All with retransmission state (i.e., all sources from | | |||
| | the Retransmission List) that must be forwarded. | | | | the Retransmission List) that must be forwarded. | | |||
+--------+-------------------------------------------------------+ | +--------+-------------------------------------------------------+ | |||
| BLOCK | All with retransmission state that must be blocked. | | | BLOCK | All with retransmission state that must be blocked. | | |||
+--------+-------------------------------------------------------+ | +--------+-------------------------------------------------------+ | |||
Table 2: Per-Interface State Change Report Contents | Table 2: Per-Interface State-Change Report Contents | |||
If the computed source list for either an ALLOW or a BLOCK record is | If the computed source list for either an ALLOW or a BLOCK record is | |||
empty, that record is omitted from the State Change Report. | empty, that record is omitted from the State-Change Report. | |||
Note: When the first State Change Report is sent, the non-existent | | Note: When the first State-Change Report is sent, the non- | |||
pending report to merge with can be treated as a Source Change Report | | existent pending report to merge with can be treated as a | |||
with empty ALLOW and BLOCK records (no sources have retransmission | | Source-Change Report with empty ALLOW and BLOCK records (no | |||
state). | | sources have retransmission state). | |||
The building of a scheduled State Change Report, triggered by the | The building of a scheduled State-Change Report, triggered by the | |||
firing of a Retransmission Timer, instead of a per-interface | firing of a Retransmission Timer, instead of a per-interface | |||
listening state change, is described in Section 6.3. | listening state change, is described in Section 6.3. | |||
6.2. Action on Reception of a Query | 6.2. Action on Reception of a Query | |||
Upon reception of an MLD message that contains a Query, the node | Upon reception of an MLD message that contains a Query, the node | |||
checks if the source address of the message is a valid link-local | checks if the source address of the message is a valid link-local | |||
address, if the Hop Limit is set to 1, and if the Router Alert option | address, if the Hop Limit is set to 1, and if the Router Alert option | |||
is present in the Hop-by-Hop Options header of the IPv6 packet. If | is present in the Hop-by-Hop Options header of the IPv6 packet. If | |||
any of these checks fail, the packet is dropped. | any of these checks fail, the packet is dropped. | |||
skipping to change at line 1552 ¶ | skipping to change at line 1553 ¶ | |||
* an Interface Timer for scheduling responses to General Queries; | * an Interface Timer for scheduling responses to General Queries; | |||
* a Multicast Address Timer for scheduling responses to Multicast | * a Multicast Address Timer for scheduling responses to Multicast | |||
Address (and Source) Specific Queries, for each multicast address | Address (and Source) Specific Queries, for each multicast address | |||
the node has to report on; and | the node has to report on; and | |||
* a per-multicast-address list of sources to be reported in response | * a per-multicast-address list of sources to be reported in response | |||
to a Multicast Address and Source Specific Query. | to a Multicast Address and Source Specific Query. | |||
When a new valid General Query arrives on an interface, the node | When a valid General Query arrives on an interface, the node checks | |||
checks whether it has any per-interface listening state record to | whether it has any per-interface listening state record to report on, | |||
report on, or not. Similarly, when a new valid Multicast Address | or not. Similarly, when a valid Multicast Address (and Source) | |||
(and Source) Specific Query arrives on an interface, the node checks | Specific Query arrives on an interface, the node checks whether it | |||
whether it has a per-interface listening state record that | has a per-interface listening state record that corresponds to the | |||
corresponds to the queried multicast address (and source), or not. | queried multicast address (and source), or not. If it does, a delay | |||
If it does, a delay for a response is randomly selected in the range | for a response is randomly selected in the range (0, [Maximum | |||
(0, [Maximum Response Delay]), where Maximum Response Delay is | Response Delay]), where Maximum Response Delay is derived from the | |||
derived from the Maximum Response Code inserted in the received Query | Maximum Response Code inserted in the received Query message. The | |||
message. The following rules are then used to determine if a Report | following rules are then used to determine if a Report needs to be | |||
needs to be scheduled or not and the type of Report to schedule. | scheduled or not and the type of Report to schedule. (The rules are | |||
(The rules are considered in order and only the first matching rule | considered in order and only the first matching rule is applied.) | |||
is applied.) | ||||
1. If there is a pending response to a previous General Query | 1. If there is a pending response to a previous General Query | |||
scheduled sooner than the selected delay, no additional response | scheduled sooner than the selected delay, no additional response | |||
needs to be scheduled. | needs to be scheduled. | |||
2. If the received Query is a General Query, the Interface Timer is | 2. If the received Query is a General Query, the Interface Timer is | |||
used to schedule a response to the General Query after the | used to schedule a response to the General Query after the | |||
selected delay. Any previously pending response to a General | selected delay. Any previously pending response to a General | |||
Query is canceled. | Query is canceled. | |||
skipping to change at line 1608 ¶ | skipping to change at line 1608 ¶ | |||
earliest of the remaining time for the pending report and the | earliest of the remaining time for the pending report and the | |||
selected delay. | selected delay. | |||
6.3. Action on Timer Expiration | 6.3. Action on Timer Expiration | |||
There are several timers that, upon expiration, trigger protocol | There are several timers that, upon expiration, trigger protocol | |||
actions on an MLDv2 Multicast Address Listener node. All these | actions on an MLDv2 Multicast Address Listener node. All these | |||
actions are related to pending reports scheduled by the node. | actions are related to pending reports scheduled by the node. | |||
1. If the expired timer is the Interface Timer (i.e., there is a | 1. If the expired timer is the Interface Timer (i.e., there is a | |||
pending response to a General Query), then one Current State | pending response to a General Query), then one Current-State | |||
Record is sent for each multicast address for which the specified | Record is sent for each multicast address for which the specified | |||
interface has listening state, as described in Section 4.2. The | interface has listening state, as described in Section 4.2. The | |||
Current State Record carries the multicast address and its | Current-State Record carries the multicast address and its | |||
associated filter mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and | associated filter mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and | |||
source list. Multiple Current State Records are packed into | source list. Multiple Current-State Records are packed into | |||
individual Report messages, to the extent possible. | individual Report messages, to the extent possible. | |||
This naive algorithm may result in bursts of packets when a node | This naive algorithm may result in bursts of packets when a node | |||
listens to a large number of multicast addresses. Instead of | listens to a large number of multicast addresses. Instead of | |||
using a single Interface Timer, implementations are recommended | using a single Interface Timer, implementations are recommended | |||
to spread transmission of such Report messages over the interval | to spread transmission of such Report messages over the interval | |||
(0, [Maximum Response Delay]). Note that any such implementation | (0, [Maximum Response Delay]). Note that any such implementation | |||
MUST avoid the "ack-implosion" problem, i.e., MUST NOT send a | MUST avoid the "ack-implosion" problem, i.e., MUST NOT send a | |||
Report immediately upon reception of a General Query. | Report immediately upon reception of a General Query. | |||
2. If the expired timer is a Multicast Address Timer and the list of | 2. If the expired timer is a Multicast Address Timer and the list of | |||
recorded sources for that multicast address is empty (i.e., there | recorded sources for that multicast address is empty (i.e., there | |||
is a pending response to a Multicast Address Specific Query), | is a pending response to a Multicast Address Specific Query), | |||
then if, and only if, the interface has listening state for that | then if, and only if, the interface has listening state for that | |||
multicast address, a single Current State Record is sent for that | multicast address, a single Current-State Record is sent for that | |||
address. The Current State Record carries the multicast address | address. The Current-State Record carries the multicast address | |||
and its associated filter mode (MODE_IS_INCLUDE or | and its associated filter mode (MODE_IS_INCLUDE or | |||
MODE_IS_EXCLUDE) and source list, if any. | MODE_IS_EXCLUDE) and source list, if any. | |||
3. If the expired timer is a Multicast Address Timer and the list of | 3. If the expired timer is a Multicast Address Timer and the list of | |||
recorded sources for that multicast address is non-empty (i.e., | recorded sources for that multicast address is non-empty (i.e., | |||
there is a pending response to a Multicast Address and Source | there is a pending response to a Multicast Address and Source | |||
Specific Query), then if, and only if, the interface has | Specific Query), then if, and only if, the interface has | |||
listening state for that multicast address, the contents of the | listening state for that multicast address, the contents of the | |||
corresponding Current State Record are determined from the per- | corresponding Current-State Record are determined from the per- | |||
interface state and the pending response record, as specified in | interface state and the pending response record, as specified in | |||
Table 3. | Table 3. | |||
+=====================+=========================+==============+ | +=====================+=========================+===============+ | |||
| Per-Interface State | Set of Sources in the | Current | | | Per-Interface | Set of Sources in the | Current-State | | |||
| | Pending Response Record | State Record | | | State | Pending Response Record | Record | | |||
+=====================+=========================+==============+ | +=====================+=========================+===============+ | |||
| INCLUDE (A) | B | IS_IN (A*B) | | | INCLUDE (A) | B | IS_IN (A*B) | | |||
+---------------------+-------------------------+--------------+ | +---------------------+-------------------------+---------------+ | |||
| EXCLUDE (A) | B | IS_IN (B-A) | | | EXCLUDE (A) | B | IS_IN (B-A) | | |||
+---------------------+-------------------------+--------------+ | +---------------------+-------------------------+---------------+ | |||
Table 3: Determining Contents of Current State Record | Table 3: Determining Contents of Current-State Record | |||
If the resulting Current State Record has an empty set of source | If the resulting Current-State Record has an empty set of source | |||
addresses, then no response is sent. After the required Report | addresses, then no response is sent. After the required Report | |||
messages have been generated, the source lists associated with | messages have been generated, the source lists associated with | |||
any reported multicast addresses are cleared. | any reported multicast addresses are cleared. | |||
4. If the expired timer is a Retransmission Timer for a multicast | 4. If the expired timer is a Retransmission Timer for a multicast | |||
address (i.e., there is a pending State Change Report for that | address (i.e., there is a pending State-Change Report for that | |||
multicast address), the contents of the report are determined as | multicast address), the contents of the report are determined as | |||
follows. If the report should contain a Filter Mode Change | follows. If the report should contain a Filter-Mode-Change | |||
Record, i.e., the Filter Mode Retransmission Counter for that | Record, i.e., the Filter Mode Retransmission Counter for that | |||
multicast address has a value higher than zero, then, if the | multicast address has a value higher than zero, then, if the | |||
current filter mode of the interface is INCLUDE, a TO_IN record | current filter mode of the interface is INCLUDE, a TO_IN record | |||
is included in the report; otherwise a TO_EX record is included. | is included in the report; otherwise a TO_EX record is included. | |||
In both cases, the Filter Mode Retransmission Counter for that | In both cases, the Filter Mode Retransmission Counter for that | |||
multicast address is decremented by one unit after the | multicast address is decremented by one unit after the | |||
transmission of the report. | transmission of the report. | |||
If instead the report should contain Source List Change Records, | If instead the report should contain Source List Change Records, | |||
i.e., the Filter Mode Retransmission Counter for that multicast | i.e., the Filter Mode Retransmission Counter for that multicast | |||
skipping to change at line 1704 ¶ | skipping to change at line 1704 ¶ | |||
| | For each included source, its Source Retransmission | | | | For each included source, its Source Retransmission | | |||
| | Counter is decreased with one unit after the | | | | Counter is decreased with one unit after the | | |||
| | transmission of the report. If the counter reaches | | | | transmission of the report. If the counter reaches | | |||
| | zero, the source is deleted from the Retransmission | | | | zero, the source is deleted from the Retransmission | | |||
| | List for that multicast address. | | | | List for that multicast address. | | |||
+--------+-----------------------------------------------------+ | +--------+-----------------------------------------------------+ | |||
Table 4: Determining Contents of Source List Change Records | Table 4: Determining Contents of Source List Change Records | |||
If the computed source list for either an ALLOW or a BLOCK record | If the computed source list for either an ALLOW or a BLOCK record | |||
is empty, that record is omitted from the State Change Report. | is empty, that record is omitted from the State-Change Report. | |||
7. Description of the Protocol for Multicast Routers | 7. Description of the Protocol for Multicast Routers | |||
The purpose of MLD is to enable each multicast router to learn, for | The purpose of MLD is to enable each multicast router to learn, for | |||
each of its directly attached links, which multicast addresses have | each of its directly attached links, which multicast addresses have | |||
listeners on that link. MLD version 2 adds the capability for a | listeners on that link. MLD version 2 adds the capability for a | |||
multicast router to also learn which sources have listeners among the | multicast router to also learn which sources have listeners among the | |||
neighboring nodes, for packets sent to any particular multicast | neighboring nodes, for packets sent to any particular multicast | |||
address. The information gathered by MLD is provided to whichever | address. The information gathered by MLD is provided to whichever | |||
multicast routing protocol is used by the router, in order to ensure | multicast routing protocol is used by the router, in order to ensure | |||
that multicast packets are delivered to all links where there are | that multicast packets are delivered to all links where there are | |||
interested listeners. | interested listeners. | |||
This section describes the part of MLDv2 that is performed by | This section describes the part of MLDv2 that is performed by | |||
multicast routers. Multicast routers may themselves become multicast | multicast routers. Multicast routers may themselves become Multicast | |||
address listeners and therefore also perform the multicast listener | Address Listeners and therefore also perform the multicast listener | |||
part of MLDv2, as described in Section 6. | part of MLDv2, as described in Section 6. | |||
A multicast router performs the protocol described in this section | A multicast router performs the protocol described in this section | |||
over each of its directly attached links. If a multicast router has | over each of its directly attached links. If a multicast router has | |||
more than one interface to the same link, it only needs to operate | more than one interface to the same link, it only needs to operate | |||
this protocol over one of those interfaces. | this protocol over one of those interfaces. | |||
For each interface over which the router operates the MLD protocol, | For each interface over which the router operates the MLD protocol, | |||
the router must configure that interface to listen to all link-layer | the router must configure that interface to listen to all link-layer | |||
multicast addresses that can be generated by IPv6 multicasts. For | multicast addresses that can be generated by IPv6 multicasts. For | |||
example, an Ethernet-attached router must set its Ethernet address | example, an Ethernet-attached router must set its Ethernet address | |||
reception filter to accept all Ethernet multicast addresses that | reception filter to accept all Ethernet multicast addresses that | |||
start with the hexadecimal value 3333 [RFC2464]; in the case of an | start with the hexadecimal value 3333 [RFC2464]; in the case of an | |||
Ethernet interface that does not support the filtering of such a | Ethernet interface that does not support the filtering of such a | |||
multicast address range, it must be configured to accept ALL Ethernet | multicast address range, it must be configured to accept ALL Ethernet | |||
multicast addresses, in order to meet the requirements of MLD. | multicast addresses, in order to meet the requirements of MLD. | |||
On each interface over which this protocol is being run, the router | On each interface over which this protocol is being run, the router | |||
MUST enable reception of the link-scope "all MLDv2-capable routers" | MUST enable reception of the link-scope "all MLDv2-capable routers" | |||
multicast address from all sources and MUST perform the multicast | multicast address from all sources and MUST perform the Multicast | |||
address listener part of MLDv2 for that address on that interface. | Address Listener part of MLDv2 for that address on that interface. | |||
Multicast routers only need to know that at least one node on an | Multicast routers only need to know that at least one node on an | |||
attached link listens to packets for a particular multicast address | attached link listens to packets for a particular multicast address | |||
from a particular source; a multicast router is not required to | from a particular source; a multicast router is not required to | |||
individually keep track of the interests of each neighboring node. | individually keep track of the interests of each neighboring node. | |||
(Nevertheless, see Appendix A.2, item 1 for discussion.) | (Nevertheless, see Appendix A.2, item 1 for discussion.) | |||
MLDv2 is backward compatible with the MLDv1 protocol. For a detailed | MLDv2 is backward compatible with the MLDv1 protocol. For a detailed | |||
description of compatibility issues, see Section 8. | description of compatibility issues, see Section 8. | |||
7.1. Conditions for MLD Queries | 7.1. Conditions for MLD Queries | |||
The behavior of a router that implements the MLDv2 protocol depends | The behavior of a router that implements the MLDv2 protocol depends | |||
on whether there are several multicast routers on the same subnet, or | on whether there are several multicast routers on the same subnet, or | |||
not. If it is the case, a querier election mechanism (described in | not. If it is the case, a querier election mechanism (described in | |||
Section 7.6.2) is used to elect a single multicast router to be in | Section 7.6.2) is used to elect a single multicast router to be in | |||
Querier state. All the multicast routers on the subnet listen to the | Querier state. All the multicast routers on the subnet listen to the | |||
messages sent by multicast address listeners, and maintain the same | messages sent by Multicast Address Listeners, and maintain the same | |||
multicast listening information state, so that they can quickly and | multicast listening information state, so that they can quickly and | |||
correctly take over the querier functionality, should the present | correctly take over the querier functionality, should the present | |||
Querier fail. Nevertheless, it is only the Querier that sends | Querier fail. Nevertheless, it is only the Querier that sends | |||
periodical or triggered query messages on the subnet. | periodical or triggered query messages on the subnet. | |||
The Querier periodically sends General Queries to request Multicast | The Querier periodically sends General Queries to request Multicast | |||
Address Listener information from an attached link. These queries | Address Listener information from an attached link. These queries | |||
are used to build and refresh the Multicast Address Listener state of | are used to build and refresh the Multicast Address Listening state | |||
routers on attached links. | of routers on attached links. | |||
Nodes respond to these queries by reporting their Multicast Address | Nodes respond to these queries by reporting their Multicast Address | |||
Listening state (and set of sources they listen to) with Current | Listening state (and set of sources they listen to) with Current | |||
State Multicast Address Records in MLDv2 Multicast Listener Reports. | State Multicast Address Records in MLD Version 2 Multicast Listener | |||
Reports. | ||||
As a listener of a multicast address, a node may express interest in | As a listener of a multicast address, a node may express interest in | |||
listening or not listening to traffic from particular sources. As | listening or not listening to traffic from particular sources. As | |||
the desired listening state of a node changes, it reports these | the desired listening state of a node changes, it reports these | |||
changes using Filter Mode Change Records or Source List Change | changes using Filter-Mode-Change Records or Source List Change | |||
Records. These records indicate an explicit state change in a | Records. These records indicate an explicit state change in a | |||
multicast address at a node in either the Multicast Address Record's | multicast address at a node in either the Multicast Address Record's | |||
source list or its filter mode. When Multicast Address Listening is | source list or its filter mode. When Multicast Address Listening is | |||
terminated at a node or traffic from a particular source is no longer | terminated at a node or traffic from a particular source is no longer | |||
desired, the Querier must query for other listeners of the multicast | desired, the Querier must query for other listeners of the multicast | |||
address or of the source before deleting the multicast address (or | address or of the source before deleting the multicast address (or | |||
source) from its Multicast Address Listener state and pruning its | source) from its Multicast Address Listening state and pruning its | |||
traffic. | traffic. | |||
To enable all nodes on a link to respond to changes in multicast | To enable all nodes on a link to respond to changes in multicast | |||
address listening, the Querier sends specific queries. A Multicast | address listening, the Querier sends specific queries. A Multicast | |||
Address Specific Query is sent to verify that there are no nodes that | Address Specific Query is sent to verify that there are no nodes that | |||
listen to the specified multicast address or to "rebuild" the | listen to the specified multicast address or to "rebuild" the | |||
listening state for a particular multicast address. Multicast | listening state for a particular multicast address. Multicast | |||
Address Specific Queries are sent when the Querier receives a State | Address Specific Queries are sent when the Querier receives a State- | |||
Change Record indicating that a node ceases to listen to a multicast | Change Record indicating that a node ceases to listen to a multicast | |||
address. They are also sent in order to enable a fast transition of | address. They are also sent in order to enable a fast transition of | |||
a router from EXCLUDE to INCLUDE mode, in case a received State | a router from EXCLUDE to INCLUDE mode, in case a received State- | |||
Change Record motivates this action. | Change Record motivates this action. | |||
A Multicast Address and Source Specific Query is used to verify that | A Multicast Address and Source Specific Query is used to verify that | |||
there are no nodes on a link that listen to traffic from a specific | there are no nodes on a link that listen to traffic from a specific | |||
set of sources. Multicast Address and Source Specific Queries list | set of sources. Multicast Address and Source Specific Queries list | |||
sources for a particular multicast address that have been requested | sources for a particular multicast address that have been requested | |||
to no longer be forwarded. This query is sent by the Querier in | to no longer be forwarded. This query is sent by the Querier in | |||
order to learn if any node listens to packets sent to the specified | order to learn if any node listens to packets sent to the specified | |||
multicast address, from the specified source addresses. Multicast | multicast address, from the specified source addresses. Multicast | |||
Address and Source Specific Queries are only sent in response to | Address and Source Specific Queries are only sent in response to | |||
State Change Records and never in response to Current State Records. | State-Change Records and never in response to Current-State Records. | |||
Section 5.1.13 describes each query in more detail. | Section 5.1.13 describes each query in more detail. | |||
7.2. MLD State Maintained by Multicast Routers | 7.2. MLD State Maintained by Multicast Routers | |||
Multicast routers that implement the MLDv2 protocol keep state per | Multicast routers that implement the MLDv2 protocol keep state per | |||
multicast address per attached link. This multicast address state | multicast address per attached link. This multicast address state | |||
consists of a filter mode, a list of sources, and various timers. | consists of a filter mode, a list of sources, and various timers. | |||
For each attached link on which MLD runs, a multicast router records | For each attached link on which MLD runs, a multicast router records | |||
the listening state for that link. That state conceptually consists | the listening state for that link. That state conceptually consists | |||
of a set of records of the form: | of a set of records of the form: | |||
skipping to change at line 1861 ¶ | skipping to change at line 1862 ¶ | |||
in the Include List will be blocked by the router. | in the Include List will be blocked by the router. | |||
A router is in EXCLUDE mode for a specific multicast address on a | A router is in EXCLUDE mode for a specific multicast address on a | |||
given interface if there is at least one listener in EXCLUDE mode | given interface if there is at least one listener in EXCLUDE mode | |||
interested in that address on the link. Conceptually, when a | interested in that address on the link. Conceptually, when a | |||
Multicast Address Record is received, the Router Filter Mode for that | Multicast Address Record is received, the Router Filter Mode for that | |||
multicast address is updated to cover all the requested sources using | multicast address is updated to cover all the requested sources using | |||
the least amount of state. As a rule, once a Multicast Address | the least amount of state. As a rule, once a Multicast Address | |||
Record with a filter mode of EXCLUDE is received, the Router Filter | Record with a filter mode of EXCLUDE is received, the Router Filter | |||
Mode for that multicast address will be set to EXCLUDE. | Mode for that multicast address will be set to EXCLUDE. | |||
Nevertheless, if all nodes with a multicast address record having | Nevertheless, if all nodes with a Multicast Address Record having | |||
filter mode set to EXCLUDE cease reporting, it is desirable for the | filter mode set to EXCLUDE cease reporting, it is desirable for the | |||
Router Filter Mode for that multicast address to transition back to | Router Filter Mode for that multicast address to transition back to | |||
INCLUDE mode. This transition occurs when the Filter Timer expires; | INCLUDE mode. This transition occurs when the filter timer expires; | |||
see Section 7.5 for more details. | see Section 7.5 for more details. | |||
When the router is in EXCLUDE mode, the router state is represented | When the router is in EXCLUDE mode, the router state is represented | |||
through the notation EXCLUDE (X,Y), where X is called the "Requested | through the notation EXCLUDE (X,Y), where X is called the "Requested | |||
List" and Y is called the "Exclude List". All sources, except those | List" and Y is called the "Exclude List". All sources, except those | |||
from the Exclude List, will be forwarded by the router. The | from the Exclude List, will be forwarded by the router. The | |||
Requested List has no effect on forwarding. Nevertheless, it has to | Requested List has no effect on forwarding. Nevertheless, it has to | |||
be maintained for several reasons, as explained in Section 7.2.3. | be maintained for several reasons, as explained in Section 7.2.3. | |||
The exact handling of both the INCLUDE and EXCLUDE mode router state, | The exact handling of both the INCLUDE and EXCLUDE mode router state, | |||
according to the received reports, is presented in detail in Sections | according to the received reports, is presented in detail in Sections | |||
7.4.1 and 7.4.2. | 7.4.1 and 7.4.2. | |||
7.2.2. Definition of Filter Timers | 7.2.2. Definition of Filter Timers | |||
The Filter Timer is only used when the router is in EXCLUDE mode for | The filter timer is only used when the router is in EXCLUDE mode for | |||
a specific multicast address, and it represents the time for the | a specific multicast address, and it represents the time for the | |||
Router Filter Mode of the multicast address to expire and switch to | Router Filter Mode of the multicast address to expire and switch to | |||
INCLUDE mode. A Filter Timer is a decrementing timer with a lower | INCLUDE mode. A filter timer is a decrementing timer with a lower | |||
bound of zero. One Filter Timer exists per multicast address record. | bound of zero. One filter timer exists per Multicast Address Record. | |||
Filter Timers are updated according to the types of Multicast Address | Filter timers are updated according to the types of Multicast Address | |||
Records received. | Records received. | |||
If a Filter Timer expires, with the Router Filter Mode for that | If a filter timer expires, with the Router Filter Mode for that | |||
multicast address being EXCLUDE, it means that there are no more | multicast address being EXCLUDE, it means that there are no more | |||
listeners in EXCLUDE mode on the attached link. At this point, the | listeners in EXCLUDE mode on the attached link. At this point, the | |||
router transitions to INCLUDE filter mode. Section 7.5 describes the | router transitions to INCLUDE filter mode. Section 7.5 describes the | |||
actions taken when a Filter Timer expires while in EXCLUDE mode. | actions taken when a filter timer expires while in EXCLUDE mode. | |||
Table 5 summarizes the role of the Filter Timer. Section 7.4 | Table 5 summarizes the role of the filter timer. Section 7.4 | |||
describes the details of setting the Filter Timer per type of | describes the details of setting the filter timer per type of | |||
Multicast Address Record received. | Multicast Address Record received. | |||
+=========+========+================================================+ | +=========+========+================================================+ | |||
| Router | Filter | Actions/Comments | | | Router | Filter | Actions/Comments | | |||
| Filter | Timer | | | | Filter | Timer | | | |||
| Mode | Value | | | | Mode | Value | | | |||
+=========+========+================================================+ | +=========+========+================================================+ | |||
| INCLUDE | Not | All listeners in INCLUDE mode. | | | INCLUDE | Not | All listeners in INCLUDE mode. | | |||
| | Used | | | | | Used | | | |||
+---------+--------+------------------------------------------------+ | +---------+--------+------------------------------------------------+ | |||
skipping to change at line 1936 ¶ | skipping to change at line 1937 ¶ | |||
timers per type of Multicast Address Records received. | timers per type of Multicast Address Records received. | |||
In the following, abbreviations are used for several variables (all | In the following, abbreviations are used for several variables (all | |||
of which are described in detail in Section 9). The variable MALI | of which are described in detail in Section 9). The variable MALI | |||
stands for the Multicast Address Listening Interval, which is the | stands for the Multicast Address Listening Interval, which is the | |||
time in which multicast address listening state will time out. The | time in which multicast address listening state will time out. The | |||
variable LLQT is the Last Listener Query Time, which is the total | variable LLQT is the Last Listener Query Time, which is the total | |||
time the router should wait for a report, after the Querier has sent | time the router should wait for a report, after the Querier has sent | |||
the first query. During this time, the Querier should send [Last | the first query. During this time, the Querier should send [Last | |||
Member Query Count]-1 retransmissions of the query. LLQT represents | Member Query Count]-1 retransmissions of the query. LLQT represents | |||
the "leave latency" or the difference between the transmission of a | the leave latency or the difference between the transmission of a | |||
listener state change and the modification of the information passed | listener state change and the modification of the information passed | |||
to the routing protocol. | to the routing protocol. | |||
If the router is in INCLUDE filter mode, a source can be added to the | If the router is in INCLUDE filter mode, a source can be added to the | |||
current Include List if a listener in INCLUDE mode sends a Current | current Include List if a listener in INCLUDE mode sends a Current- | |||
State or a State Change Report that includes that source. Each | State or a State-Change Report that includes that source. Each | |||
source from the Include List is associated with a source timer that | source from the Include List is associated with a Source Timer that | |||
is updated whenever a listener in INCLUDE mode sends a report that | is updated whenever a listener in INCLUDE mode sends a report that | |||
confirms its interest in that specific source. If the timer of a | confirms its interest in that specific source. If the timer of a | |||
source from the Include List expires, the source is deleted from the | source from the Include List expires, the source is deleted from the | |||
Include List. If there are no more source records left, the | Include List. If there are no more source records left, the | |||
multicast address record is deleted from the router. | Multicast Address Record is deleted from the router. | |||
Besides this "soft leave" mechanism, there is also a "fast leave" | Besides this "soft leave" mechanism, there is also a "fast leave" | |||
scheme in MLDv2; it is also based on the use of source timers. When | scheme in MLDv2; it is also based on the use of source timers. When | |||
a node in INCLUDE mode expresses its desire to stop listening to a | a node in INCLUDE mode expresses its desire to stop listening to a | |||
specific source, all the multicast routers on the link lower their | specific source, all the multicast routers on the link lower their | |||
timer for that source to a small interval of LLQT milliseconds. The | timer for that source to a small interval of LLQT milliseconds. The | |||
Querier then sends then a Multicast Address and Source Specific | Querier then sends then a Multicast Address and Source Specific | |||
Query, to verify whether there are other listeners for that source on | Query, to verify whether there are other listeners for that source on | |||
the link, or not. If a corresponding report is received before the | the link, or not. If a corresponding report is received before the | |||
timer expires, all the multicast routers on the link update their | timer expires, all the multicast routers on the link update their | |||
skipping to change at line 1993 ¶ | skipping to change at line 1994 ¶ | |||
When the router switches to INCLUDE mode, the sources in the | When the router switches to INCLUDE mode, the sources in the | |||
Requested List are moved to the Include List, and the Exclude | Requested List are moved to the Include List, and the Exclude | |||
List is deleted. Before the switch, the Requested List can | List is deleted. Before the switch, the Requested List can | |||
contain an inexact guess at the sources that listeners in INCLUDE | contain an inexact guess at the sources that listeners in INCLUDE | |||
mode listen to, which might be too large or too small. These | mode listen to, which might be too large or too small. These | |||
inexactitudes are due to the fact that the Requested List is also | inexactitudes are due to the fact that the Requested List is also | |||
used for fast blocking purposes, as described below. If such a | used for fast blocking purposes, as described below. If such a | |||
fast blocking is required, some sources may be deleted from the | fast blocking is required, some sources may be deleted from the | |||
Requested List (as shown in Sections 7.4.1 and 7.4.2) in order to | Requested List (as shown in Sections 7.4.1 and 7.4.2) in order to | |||
reduce router state. Nevertheless, in each such case the Filter | reduce router state. Nevertheless, in each such case the filter | |||
Timer is updated as well. Therefore, listeners in INCLUDE mode | timer is updated as well. Therefore, listeners in INCLUDE mode | |||
will have enough time, before an eventual switching, to reconfirm | will have enough time, before an eventual switching, to reconfirm | |||
their interest in the eliminated source(s), and rebuild the | their interest in the eliminated source(s), and rebuild the | |||
Requested List accordingly. The protocol ensures that when a | Requested List accordingly. The protocol ensures that when a | |||
switch to INCLUDE mode occurs, the Requested List will be | switch to INCLUDE mode occurs, the Requested List will be | |||
accurate. Details about the transition of the router to INCLUDE | accurate. Details about the transition of the router to INCLUDE | |||
mode are presented in Appendix A.3. | mode are presented in Appendix A.3. | |||
2. To allow a fast blocking of previously unblocked sources. If the | 2. To allow a fast blocking of previously unblocked sources. If the | |||
router receives a report that contains such a request, the | router receives a report that contains such a request, the | |||
concerned sources are added to the Requested List. Their timers | concerned sources are added to the Requested List. Their timers | |||
skipping to change at line 2017 ¶ | skipping to change at line 2018 ¶ | |||
check whether there are nodes on the link still interested in | check whether there are nodes on the link still interested in | |||
those sources, or not. If no node confirms its interest in | those sources, or not. If no node confirms its interest in | |||
receiving a specific source, the timer of that source expires. | receiving a specific source, the timer of that source expires. | |||
Then, the source is moved from the Requested List to the Exclude | Then, the source is moved from the Requested List to the Exclude | |||
List. From then on, the source will be blocked by the router. | List. From then on, the source will be blocked by the router. | |||
The handling of the EXCLUDE mode router state, according to the | The handling of the EXCLUDE mode router state, according to the | |||
received reports, is detailed in Sections 7.4.1 and 7.4.2. | received reports, is detailed in Sections 7.4.1 and 7.4.2. | |||
When the Router Filter Mode for a multicast address is EXCLUDE, | When the Router Filter Mode for a multicast address is EXCLUDE, | |||
source records are only deleted when the Filter Timer expires or when | source records are only deleted when the filter timer expires or when | |||
newly received Multicast Address Records modify the source record | newly received Multicast Address Records modify the source record | |||
list of the router. | list of the router. | |||
7.3. MLDv2 Source-Specific Forwarding Rules | 7.3. MLDv2 Source-Specific Forwarding Rules | |||
When a multicast router receives a datagram from a source destined to | When a multicast router receives a datagram from a source destined to | |||
a particular multicast address, a decision has to be made whether to | a particular multicast address, a decision has to be made whether to | |||
forward the datagram on an attached link or not. The multicast | forward the datagram on an attached link or not. The multicast | |||
routing protocol in use is in charge of this decision and should use | routing protocol in use is in charge of this decision and should use | |||
the MLDv2 information to ensure that all sources/multicast addresses | the MLDv2 information to ensure that all sources/multicast addresses | |||
that have listeners on a link are forwarded to that link. MLDv2 | that have listeners on a link are forwarded to that link. MLDv2 | |||
information does not override multicast routing information; for | information does not override multicast routing information; for | |||
example, if the MLDv2 filter mode for a multicast address is EXCLUDE, | example, if the MLDv2 filter mode for a multicast address is EXCLUDE, | |||
a router may still forward packets for excluded sources to a transit | a router may still forward packets for excluded sources to a transit | |||
link. | link. | |||
To summarize, Table 6 below describes the forwarding suggestions made | To summarize, Table 6 below describes the forwarding suggestions made | |||
by MLDv2 to the routing protocol for traffic originating from a | by MLDv2 to the routing protocol for traffic originating from a | |||
source destined to a multicast address. It also summarizes the | source destined to a multicast address. It also summarizes the | |||
actions taken upon the expiration of a source timer based on the | actions taken upon the expiration of a Source Timer based on the | |||
Router Filter Mode of the multicast address. | Router Filter Mode of the multicast address. | |||
+=========+=========+=========================================+ | +=========+=========+=========================================+ | |||
| Router | Source | Action | | | Router | Source | Action | | |||
| Filter | Timer | | | | Filter | Timer | | | |||
| Mode | Value | | | | Mode | Value | | | |||
+=========+=========+=========================================+ | +=========+=========+=========================================+ | |||
| INCLUDE | TIMER > | Suggest to forward traffic from source. | | | INCLUDE | TIMER > | Suggest to forward traffic from source. | | |||
| | 0 | | | | | 0 | | | |||
+---------+---------+-----------------------------------------+ | +---------+---------+-----------------------------------------+ | |||
| INCLUDE | TIMER | Suggest to stop forwarding traffic from | | | INCLUDE | TIMER | Suggest to stop forwarding traffic from | | |||
| | == 0 | source and remove the source record. | | | | == 0 | source and remove the source record. | | |||
| | | If there are no more source records, | | | | | If there are no more source records, | | |||
| | | delete the multicast address record. | | | | | delete the Multicast Address Record. | | |||
+---------+---------+-----------------------------------------+ | ||||
| INCLUDE | No | Suggest to not forward traffic from | | ||||
| | Source | source. | | ||||
| | Element | | | ||||
+---------+---------+-----------------------------------------+ | +---------+---------+-----------------------------------------+ | |||
| EXCLUDE | TIMER > | Suggest to forward traffic from source. | | | EXCLUDE | TIMER > | Suggest to forward traffic from source. | | |||
| | 0 | | | | | 0 | | | |||
+---------+---------+-----------------------------------------+ | +---------+---------+-----------------------------------------+ | |||
| EXCLUDE | TIMER | Suggest to not forward traffic from | | | EXCLUDE | TIMER | Suggest to not forward traffic from | | |||
| | == 0 | source. Move the source from the | | | | == 0 | source. Move the source from the | | |||
| | | Requested List to the Exclude List (DO | | | | | Requested List to the Exclude List (DO | | |||
| | | NOT remove the source record). | | | | | NOT remove the source record). | | |||
+---------+---------+-----------------------------------------+ | +---------+---------+-----------------------------------------+ | |||
| EXCLUDE | No | Suggest to forward traffic from all | | | EXCLUDE | No | Suggest to forward traffic from all | | |||
| | Source | sources. | | | | Source | sources. | | |||
| | Element | | | | | Element | | | |||
+---------+---------+-----------------------------------------+ | +---------+---------+-----------------------------------------+ | |||
Table 6 | Table 6: MLD Forwarding Recommendations | |||
7.4. Action on Reception of Reports | 7.4. Action on Reception of Reports | |||
Upon reception of an MLD message that contains a Report, the router | Upon reception of an MLD message that contains a Report, the router | |||
checks if the source address of the message is a valid link-local | checks if the source address of the message is a valid link-local | |||
address, if the Hop Limit is set to 1, and if the Router Alert option | address, if the Hop Limit is set to 1, and if the Router Alert option | |||
is present in the Hop-by-Hop Options header of the IPv6 packet. If | is present in the Hop-by-Hop Options header of the IPv6 packet. If | |||
any of these checks fail, the packet is dropped. If the validity of | any of these checks fail, the packet is dropped. If the validity of | |||
the MLD message is verified, the router starts to process the Report. | the MLD message is verified, the router starts to process the Report. | |||
SSM-aware routers SHOULD ignore records that contain multicast | SSM-aware routers SHOULD ignore records that contain multicast | |||
addresses in the SSM address range if the record type is | addresses in the SSM address range if the record type is | |||
MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE. SSM-aware routers SHOULD | MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE. SSM-aware routers SHOULD | |||
ignore MLDv1 Report and DONE messages that contain multicast | ignore MLDv1 Report and DONE messages that contain multicast | |||
addresses in the SSM address range, SHOULD NOT use such Reports to | addresses in the SSM address range, SHOULD NOT use such Reports to | |||
establish IP forwarding state, and MAY log an error if it receives | establish IP forwarding state, and MAY log an error if it receives | |||
such a message. | such a message. | |||
7.4.1. Reception of Current State Records | 7.4.1. Reception of Current-State Records | |||
When receiving Current State Records, a router updates both its | When receiving Current-State Records, a router updates both its | |||
Filter Timer and its source timers. In some circumstances, the | filter timer and its source timers. In some circumstances, the | |||
reception of a type of multicast address record will cause the Router | reception of a type of Multicast Address Record will cause the Router | |||
Filter Mode for that multicast address to change. Table 7 describes | Filter Mode for that multicast address to change. Table 7 describes | |||
the actions, with respect to state and timers, that occur to a | the actions, with respect to state and timers, that occur to a | |||
router's state upon reception of Current State Records. | router's state upon reception of Current-State Records. | |||
If the router is in INCLUDE filter mode for a multicast address, we | If the router is in INCLUDE filter mode for a multicast address, we | |||
will use the notation INCLUDE (A), where A denotes the associated | will use the notation INCLUDE (A), where A denotes the associated | |||
Include List. If the router is in EXCLUDE filter mode for a | Include List. If the router is in EXCLUDE filter mode for a | |||
multicast address, we will use the notation EXCLUDE (X,Y), where X | multicast address, we will use the notation EXCLUDE (X,Y), where X | |||
and Y denote the associated Requested List and Exclude List, | and Y denote the associated Requested List and Exclude List, | |||
respectively. | respectively. | |||
Within the "Actions" section of the router state tables, we use the | Within the "Actions" section of the router state tables, we use the | |||
notation '(A)=J', which means that set A of the source records should | notation '(A)=J', which means that set A of the source records should | |||
have their source timers set to value J. 'Delete (A)' means that set | have their source timers set to value J. 'Delete (A)' means that set | |||
A of the source records should be deleted. 'Filter Timer = J' means | A of the source records should be deleted. 'filter timer = J' means | |||
that the Filter Timer for the multicast address should be set to | that the filter timer for the multicast address should be set to | |||
value J. | value J. | |||
+=========+==========+=========+======================+ | +=========+==========+=========+======================+ | |||
| Router | Report | New | Actions | | | Router | Report | New | Actions | | |||
| State | Received | Router | | | | State | Received | Router | | | |||
| | | State | | | | | | State | | | |||
+=========+==========+=========+======================+ | +=========+==========+=========+======================+ | |||
| INCLUDE | IS_IN | INCLUDE | (B)=MALI | | | INCLUDE | IS_IN | INCLUDE | (B)=MALI | | |||
| (A) | (B) | (A+B) | | | | (A) | (B) | (A+B) | | | |||
+---------+----------+---------+----------------------+ | +---------+----------+---------+----------------------+ | |||
skipping to change at line 2135 ¶ | skipping to change at line 2140 ¶ | |||
+---------+----------+---------+----------------------+ | +---------+----------+---------+----------------------+ | |||
| EXCLUDE | IS_EX | EXCLUDE | (A-X-Y)=MALI | | | EXCLUDE | IS_EX | EXCLUDE | (A-X-Y)=MALI | | |||
| (X,Y) | (A) | (A-Y, | | | | (X,Y) | (A) | (A-Y, | | | |||
| | | Y*A) | Delete (X-A) | | | | | Y*A) | Delete (X-A) | | |||
| | | | | | | | | | | | |||
| | | | Delete (Y-A) | | | | | | Delete (Y-A) | | |||
| | | | | | | | | | | | |||
| | | | Filter Timer=MALI | | | | | | Filter Timer=MALI | | |||
+---------+----------+---------+----------------------+ | +---------+----------+---------+----------------------+ | |||
Table 7: Actions for Received Current State Records | Table 7: Actions for Received Current-State Records | |||
7.4.2. Reception of Filter Mode Change and Source List Change Records | 7.4.2. Reception of Filter-Mode-Change and Source List Change Records | |||
When a change in the global state of a multicast address occurs in a | When a change in the global state of a multicast address occurs in a | |||
node, the node sends either a Source List Change Record or a Filter | node, the node sends either a Source List Change Record or a Filter | |||
Mode Change Record for that multicast address. As with Current State | Mode Change Record for that multicast address. As with Current-State | |||
Records, routers must act upon these records and possibly change | Records, routers must act upon these records and possibly change | |||
their own state to reflect the new listening state of the link. | their own state to reflect the new listening state of the link. | |||
The Querier must query sources or multicast addresses that are | The Querier must query sources or multicast addresses that are | |||
requested to be no longer forwarded. When a router queries or | requested to be no longer forwarded. When a router queries or | |||
receives a query for a specific set of sources, it lowers its source | receives a query for a specific set of sources, it lowers its source | |||
timers for those sources to a small interval of Last Listener Query | timers for those sources to a small interval of Last Listener Query | |||
Time milliseconds. If multicast address records are received in | Time milliseconds. If Multicast Address Records are received in | |||
response to the queries that express interest in listening to the | response to the queries that express interest in listening to the | |||
queried sources, the corresponding timers are updated. | queried sources, the corresponding timers are updated. | |||
Multicast Address Specific queries can also be used in order to | Multicast Address Specific queries can also be used in order to | |||
enable a fast transition of a router from EXCLUDE to INCLUDE mode, in | enable a fast transition of a router from EXCLUDE to INCLUDE mode, in | |||
case a received Multicast Address Record motivates this action. The | case a received Multicast Address Record motivates this action. The | |||
Filter Timer for that multicast address is lowered to a small | filter timer for that multicast address is lowered to a small | |||
interval of Last Listener Query Time milliseconds. If any multicast | interval of Last Listener Query Time milliseconds. If any Multicast | |||
address records that express EXCLUDE mode interest in the multicast | Address Records that express EXCLUDE mode interest in the multicast | |||
address are received within this interval, the Filter Timer is | address are received within this interval, the filter timer is | |||
updated and the suggestion to the routing protocol to forward the | updated and the suggestion to the routing protocol to forward the | |||
multicast address stands without any interruption. If not, the | multicast address stands without any interruption. If not, the | |||
router will switch to INCLUDE filter mode for that multicast address. | router will switch to INCLUDE filter mode for that multicast address. | |||
During the query period (i.e., Last Listener Query Time | During the query period (i.e., Last Listener Query Time | |||
milliseconds), the MLD component in the router continues to suggest | milliseconds), the MLD component in the router continues to suggest | |||
to the routing protocol to forward traffic from the multicast | to the routing protocol to forward traffic from the multicast | |||
addresses or sources that are queried. It is not until after Last | addresses or sources that are queried. It is not until after Last | |||
Listener Query Time milliseconds without receiving a record that | Listener Query Time milliseconds, and without receiving a record that | |||
expresses interest in the queried multicast address or sources that | expresses interest in the queried multicast address or sources, that | |||
the router may prune the multicast address or sources from the link. | the router may prune the multicast address or sources from the link. | |||
Table 8 describes the changes in multicast address state and the | Table 8 describes the changes in multicast address state and the | |||
action(s) taken when receiving either Filter Mode Change or Source | action(s) taken when receiving either Filter-Mode-Change or Source | |||
List Change Records. Table 8 also describes the queries that are | List Change Records. Table 8 also describes the queries that are | |||
sent by the Querier when a particular report is received. | sent by the Querier when a particular report is received. | |||
We use the following notation to describe the queries that are sent. | We use the following notation to describe the queries that are sent. | |||
We use the notation 'Q(MA)' to describe a Multicast Address Specific | We use the notation 'Q(MA)' to describe a Multicast Address Specific | |||
Query to the MA multicast address. We use the notation 'Q(MA,A)' to | Query to the MA multicast address. We use the notation 'Q(MA,A)' to | |||
describe a Multicast Address and Source Specific Query to the MA | describe a Multicast Address and Source Specific Query to the MA | |||
multicast address with source list A. If source list A is null as a | multicast address with source list A. If source list A is null as a | |||
result of the action (e.g. A*B), then no query is sent as a result of | result of the action (e.g. A*B), then no query is sent as a result of | |||
the operation. | the operation. | |||
skipping to change at line 2232 ¶ | skipping to change at line 2237 ¶ | |||
| | | | Filter Timer=MALI | | | | | | Filter Timer=MALI | | |||
+---------+----------+--------------------+------------------------+ | +---------+----------+--------------------+------------------------+ | |||
| EXCLUDE | TO_IN | EXCLUDE(X+A,Y-A) | (A)=MALI, Send | | | EXCLUDE | TO_IN | EXCLUDE(X+A,Y-A) | (A)=MALI, Send | | |||
| (X,Y) | (A) | | Q(MA,X-A), Send Q(MA) | | | (X,Y) | (A) | | Q(MA,X-A), Send Q(MA) | | |||
+---------+----------+--------------------+------------------------+ | +---------+----------+--------------------+------------------------+ | |||
Table 8: Multicast Router State Transitions | Table 8: Multicast Router State Transitions | |||
7.5. Switching Router Filter Modes | 7.5. Switching Router Filter Modes | |||
The Filter Timer is used as a mechanism for transitioning the Router | The filter timer is used as a mechanism for transitioning the Router | |||
Filter Mode from EXCLUDE to INCLUDE. | Filter Mode from EXCLUDE to INCLUDE. | |||
When a Filter Timer expires with a Router Filter Mode of EXCLUDE, a | When a filter timer expires with a Router Filter Mode of EXCLUDE, a | |||
router assumes that there are no nodes with a filter mode of EXCLUDE | router assumes that there are no nodes with a filter mode of EXCLUDE | |||
present on the attached link. Thus, the router transitions to | present on the attached link. Thus, the router transitions to | |||
INCLUDE filter mode for the multicast address. | INCLUDE filter mode for the multicast address. | |||
A router uses the sources from the Requested List as its state for | A router uses the sources from the Requested List as its state for | |||
the switch to a filter mode of INCLUDE. Sources from the Requested | the switch to a filter mode of INCLUDE. Sources from the Requested | |||
List are moved in the Include List, while sources from the Exclude | List are moved in the Include List, while sources from the Exclude | |||
List are deleted. For example, if a router's state for a multicast | List are deleted. For example, if a router's state for a multicast | |||
address is EXCLUDE(X,Y) and the Filter Timer expires for that | address is EXCLUDE(X,Y) and the filter timer expires for that | |||
multicast address, the router switches to filter mode of INCLUDE with | multicast address, the router switches to filter mode of INCLUDE with | |||
state INCLUDE(X). If at the moment of the switch the Requested List | state INCLUDE(X). If at the moment of the switch the Requested List | |||
(X) is empty, the multicast address record is deleted from the | (X) is empty, the Multicast Address Record is deleted from the | |||
router. | router. | |||
7.6. Action on Reception of Queries | 7.6. Action on Reception of Queries | |||
Upon reception of an MLD message that contains a Query, the router | Upon reception of an MLD message that contains a Query, the router | |||
checks if the source address of the message is a valid link-local | checks if the source address of the message is a valid link-local | |||
address, if the Hop Limit is set to 1, and if the Router Alert option | address, if the Hop Limit is set to 1, and if the Router Alert option | |||
is present in the Hop-by-Hop Options header of the IPv6 packet. If | is present in the Hop-by-Hop Options header of the IPv6 packet. If | |||
any of these checks fail, the packet is dropped. | any of these checks fail, the packet is dropped. | |||
skipping to change at line 2279 ¶ | skipping to change at line 2284 ¶ | |||
Query with the S flag not set. | Query with the S flag not set. | |||
+=========+=====================================================+ | +=========+=====================================================+ | |||
| Query | Action | | | Query | Action | | |||
+=========+=====================================================+ | +=========+=====================================================+ | |||
| Q(MA,A) | Source Timers for sources in A are lowered to LLQT. | | | Q(MA,A) | Source Timers for sources in A are lowered to LLQT. | | |||
+---------+-----------------------------------------------------+ | +---------+-----------------------------------------------------+ | |||
| Q(MA) | The Filter Timer is lowered to LLQT. | | | Q(MA) | The Filter Timer is lowered to LLQT. | | |||
+---------+-----------------------------------------------------+ | +---------+-----------------------------------------------------+ | |||
Table 9 | Table 9: Timer Actions for Query Message Transmission | |||
When a router sends or receives a query with the S flag set, it will | When a router sends or receives a query with the S flag set, it will | |||
not update its timers. | not update its timers. | |||
7.6.2. Querier Election | 7.6.2. Querier Election | |||
MLDv2 elects a single router per subnet to be in Querier state; all | MLDv2 elects a single router per subnet to be in Querier state; all | |||
the other routers on the subnet should be in Non-Querier state. | the other routers on the subnet should be in Non-Querier state. | |||
MLDv2 uses the same querier election mechanism as MLDv1, namely the | MLDv2 uses the same querier election mechanism as MLDv1, namely the | |||
IPv6 address. When a router starts operating on a subnet, by default | IPv6 address. When a router starts operating on a subnet, by default | |||
it considers itself as being the Querier. Thus, it sends several | it considers itself as being the Querier. Thus, it sends several | |||
General Queries separated by a small time interval (see Sections 9.6 | General Queries separated by a small time interval (see Sections 9.6 | |||
and 9.7 for details). | and 9.7 for details). | |||
When a router receives a query with a lower IPv6 address than its | When a router receives a query with a lower IPv6 address than its | |||
own, it sets the Other Querier Present timer to Other Querier Present | own, it sets the Other-Querier-Present Timer to [Other Querier | |||
Timeout; if it was previously in Querier state, it switches to Non- | Present Interval]; if it was previously in Querier state, it switches | |||
Querier state and ceases to send queries on the link. After the | to Non- Querier state and ceases to send queries on the link. After | |||
Other Querier Present timer expires, it should re-enter the Querier | the Other-Querier-Present Timer expires, it should re-enter the | |||
state and begin sending General Queries. | Querier state and begin sending General Queries. | |||
All MLDv2 queries MUST be sent with the fe80::/64 link-local source | All MLDv2 queries MUST be sent with the fe80::/64 link-local source | |||
address prefix. Therefore, for the purpose of MLDv2 querier | address prefix. Therefore, for the purpose of MLDv2 querier | |||
election, an IPv6 address A is considered to be lower than an IPv6 | election, an IPv6 address A is considered to be lower than an IPv6 | |||
address B if the interface ID represented by the last 64 bits of | address B if the interface ID represented by the last 64 bits of | |||
address A, in big-endian bit order, is lower than the interface ID | address A, in big-endian bit order, is lower than the interface ID | |||
represented by the last 64 bits of address B. | represented by the last 64 bits of address B. | |||
7.6.3. Building and Sending Specific Queries | 7.6.3. Building and Sending Specific Queries | |||
7.6.3.1. Building and Sending Multicast Address Specific Queries | 7.6.3.1. Building and Sending Multicast Address Specific Queries | |||
When a table action "Send Q(MA)" is encountered, the Filter Timer | When a table action "Send Q(MA)" is encountered, the filter timer | |||
must be lowered to LLQT. The Querier must then immediately send a | must be lowered to LLQT. The Querier must then immediately send a | |||
Multicast Address Specific Query as well as schedule [Last Listener | Multicast Address Specific Query as well as schedule [Last Listener | |||
Query Count - 1] query retransmissions to be sent every [Last | Query Count - 1] query retransmissions to be sent every [Last | |||
Listener Query Interval], over [Last Listener Query Time]. | Listener Query Interval], over [Last Listener Query Time]. | |||
When transmitting a Multicast Address Specific Query, if the Filter | When transmitting a Multicast Address Specific Query, if the filter | |||
Timer is larger than LLQT, the "Suppress Router-Side Processing" bit | timer is larger than LLQT, the "Suppress Router-Side Processing" bit | |||
is set in the query message. | is set in the query message. | |||
7.6.3.2. Building and Sending Multicast Address and Source Specific | 7.6.3.2. Building and Sending Multicast Address and Source Specific | |||
Queries | Queries | |||
When a table action "Send Q(MA,X)" is encountered by the Querier in | When a table action "Send Q(MA,X)" is encountered by the Querier in | |||
Table 8 (Section 7.4.2), the following actions must be performed for | Table 8 (Section 7.4.2), the following actions must be performed for | |||
each of the sources in X that send to multicast address MA, with the | each of the sources in X that send to multicast address MA, with the | |||
source timer larger than LLQT: | Source Timer larger than LLQT: | |||
* lower source timer to LLQT; | * lower Source Timer to LLQT; | |||
* add the sources to the Retransmission List; and | * add the sources to the Retransmission List; and | |||
* set the Source Retransmission Counter for each source to [Last | * set the Source Retransmission Counter for each source to [Last | |||
Listener Query Count]. | Listener Query Count]. | |||
The Querier must then immediately send a Multicast Address and Source | The Querier must then immediately send a Multicast Address and Source | |||
Specific Query as well as schedule [Last Listener Query Count -1] | Specific Query as well as schedule [Last Listener Query Count -1] | |||
query retransmissions to be sent every [Last Listener Query | query retransmissions to be sent every [Last Listener Query | |||
Interval], over [Last Listener Query Time]. The contents of these | Interval], over [Last Listener Query Time]. The contents of these | |||
skipping to change at line 2354 ¶ | skipping to change at line 2359 ¶ | |||
multicast address MA, two separate query messages are sent for the | multicast address MA, two separate query messages are sent for the | |||
multicast address. The first one has the "Suppress Router-Side | multicast address. The first one has the "Suppress Router-Side | |||
Processing" bit set and contains all the sources with retransmission | Processing" bit set and contains all the sources with retransmission | |||
state (i.e., sources from the Retransmission List of that multicast | state (i.e., sources from the Retransmission List of that multicast | |||
address) and timers greater than LLQT. The second has the "Suppress | address) and timers greater than LLQT. The second has the "Suppress | |||
Router-Side Processing" bit clear and contains all the sources with | Router-Side Processing" bit clear and contains all the sources with | |||
retransmission state and timers lower or equal to LLQT. If either of | retransmission state and timers lower or equal to LLQT. If either of | |||
the two calculated messages does not contain any sources, then its | the two calculated messages does not contain any sources, then its | |||
transmission is suppressed. | transmission is suppressed. | |||
Note: If a Multicast Address Specific Query is scheduled to be | | Note: If a Multicast Address Specific Query is scheduled to be | |||
transmitted at the same time as a Multicast Address and Source | | transmitted at the same time as a Multicast Address and Source | |||
Specific Query for the same multicast address, then transmission of | | Specific Query for the same multicast address, then | |||
the Multicast Address and Source Specific message with the "Suppress | | transmission of the Multicast Address and Source Specific | |||
Router-Side Processing" bit set may be suppressed. | | message with the "Suppress Router-Side Processing" bit set may | |||
| be suppressed. | ||||
8. Interoperation with MLDv1 | 8. Interoperation with MLDv1 | |||
MLD version 2 hosts and routers interoperate with hosts and routers | MLD version 2 hosts and routers interoperate with hosts and routers | |||
that have not yet been upgraded to MLDv2. This compatibility is | that have not yet been upgraded to MLDv2. This compatibility is | |||
maintained by hosts and routers taking appropriate actions depending | maintained by hosts and routers taking appropriate actions depending | |||
on the versions of MLD operating on hosts and routers within a | on the versions of MLD operating on hosts and routers within a | |||
network. | network. | |||
8.1. Query Version Distinctions | 8.1. Query Version Distinctions | |||
skipping to change at line 2393 ¶ | skipping to change at line 2399 ¶ | |||
In order to be compatible with MLDv1 routers, MLDv2 hosts MUST | In order to be compatible with MLDv1 routers, MLDv2 hosts MUST | |||
operate in version 1 compatibility mode. MLDv2 hosts MUST keep state | operate in version 1 compatibility mode. MLDv2 hosts MUST keep state | |||
per local interface regarding the compatibility mode of each attached | per local interface regarding the compatibility mode of each attached | |||
link. A host's compatibility mode is determined from the Host | link. A host's compatibility mode is determined from the Host | |||
Compatibility Mode variable that can be in one of the two states: | Compatibility Mode variable that can be in one of the two states: | |||
MLDv1 or MLDv2. | MLDv1 or MLDv2. | |||
The Host Compatibility Mode of an interface is set to MLDv1 whenever | The Host Compatibility Mode of an interface is set to MLDv1 whenever | |||
an MLDv1 Multicast Address Listener General Query is received on that | an MLDv1 Multicast Address Listener General Query is received on that | |||
interface. At the same time, the Older Version Querier Present timer | interface. At the same time, the Older-Version-Querier-Present Timer | |||
for the interface is set to Older Version Querier Present Timeout | for the interface is set to [Older Version Querier Present Interval] | |||
seconds. The timer is reset whenever a new MLDv1 General Query is | seconds. The timer is reset whenever a new MLDv1 General Query is | |||
received on that interface. If the Older Version Querier Present | received on that interface. If the Older-Version-Querier-Present | |||
timer expires, the host switches back to Host Compatibility Mode of | Timer expires, the host switches back to Host Compatibility Mode of | |||
MLDv2. | MLDv2. | |||
When Host Compatibility Mode is MLDv2, a host acts using the MLDv2 | When Host Compatibility Mode is MLDv2, a host acts using the MLDv2 | |||
protocol on that interface. When Host Compatibility Mode is MLDv1, a | protocol on that interface. When Host Compatibility Mode is MLDv1, a | |||
host acts in MLDv1 compatibility mode, using only the MLDv1 protocol, | host acts in MLDv1 compatibility mode, using only the MLDv1 protocol, | |||
on that interface. | on that interface. | |||
An MLDv1 Querier will send General Queries with the Maximum Response | An MLDv1 Querier will send General Queries with the Maximum Response | |||
Code set to the desired Maximum Response Delay, i.e., the full range | Code set to the desired Maximum Response Delay, i.e., the full range | |||
of this field is linear and the exponential algorithm described in | of this field is linear and the exponential algorithm described in | |||
skipping to change at line 2423 ¶ | skipping to change at line 2429 ¶ | |||
An SSM-aware host that receives an MLDv1 General Query or MLDv1 Group | An SSM-aware host that receives an MLDv1 General Query or MLDv1 Group | |||
Specific Query for a multicast address in the SSM address range | Specific Query for a multicast address in the SSM address range | |||
SHOULD log an error. It is RECOMMENDED that implementations provide | SHOULD log an error. It is RECOMMENDED that implementations provide | |||
a configuration option to disable the use of Host Compatibility Mode | a configuration option to disable the use of Host Compatibility Mode | |||
to allow networks to operate only in SSM mode. This configuration | to allow networks to operate only in SSM mode. This configuration | |||
option SHOULD be disabled by default. | option SHOULD be disabled by default. | |||
8.2.2. In the Presence of MLDv1 Multicast Address Listeners | 8.2.2. In the Presence of MLDv1 Multicast Address Listeners | |||
An MLDv2 host may be placed on a link where there are MLDv1 hosts. A | An MLDv2 host may be placed on a link where there are MLDv1 hosts. A | |||
host MAY allow its MLDv2 Multicast Listener Report to be suppressed | host MAY allow its MLD Version 2 Multicast Listener Report to be | |||
by a Version 1 Multicast Listener Report. | suppressed by an MLDv1 Multicast Listener Report (Type = decimal | |||
131). | ||||
8.3. Multicast Router Behavior | 8.3. Multicast Router Behavior | |||
8.3.1. In the Presence of MLDv1 Routers | 8.3.1. In the Presence of MLDv1 Routers | |||
MLDv2 routers may be placed on a network where there is at least one | MLDv2 routers may be placed on a network where there is at least one | |||
MLDv1 router. The following requirements apply: | MLDv1 router. The following requirements apply: | |||
* If an MLDv1 router is present on the link, the Querier MUST use | * If an MLDv1 router is present on the link, the Querier MUST use | |||
the lowest version of MLD present on the network. This must be | the lowest version of MLD present on the network. This must be | |||
skipping to change at line 2461 ¶ | skipping to change at line 2468 ¶ | |||
* It is RECOMMENDED that implementations provide a configuration | * It is RECOMMENDED that implementations provide a configuration | |||
option to disable use of compatibility mode to allow networks to | option to disable use of compatibility mode to allow networks to | |||
operate only in SSM mode. This configuration option SHOULD be | operate only in SSM mode. This configuration option SHOULD be | |||
disabled by default. | disabled by default. | |||
8.3.2. In the Presence of MLDv1 Multicast Address Listeners | 8.3.2. In the Presence of MLDv1 Multicast Address Listeners | |||
MLDv2 routers may be placed on a network where there are hosts that | MLDv2 routers may be placed on a network where there are hosts that | |||
have not yet been upgraded to MLDv2. In order to be compatible with | have not yet been upgraded to MLDv2. In order to be compatible with | |||
MLDv1 hosts, MLDv2 routers MUST operate in version 1 compatibility | MLDv1 hosts, MLDv2 routers MUST operate in version 1 compatibility | |||
mode. MLDv2 routers keep a compatibility mode per multicast address | mode. MLDv2 routers keep a compatibility mode per Multicast Address | |||
record. The compatibility mode of a multicast address is determined | Record. The compatibility mode of a multicast address is determined | |||
from the Multicast Address Compatibility Mode variable, which can be | from the Multicast Address Compatibility Mode variable, which can be | |||
in one of the two following states: MLDv1 or MLDv2. | in one of the two following states: MLDv1 or MLDv2. | |||
The Multicast Address Compatibility Mode of a multicast address | The Multicast Address Compatibility Mode of a Multicast Address | |||
record is set to MLDv1 whenever an MLDv1 Multicast Listener Report is | Record is set to MLDv1 whenever an MLDv1 Multicast Listener Report | |||
received for that multicast address. At the same time, the Older | (Type = decimal 131) is received for that multicast address. At the | |||
Version Host Present timer for the multicast address is set to Older | same time, the Older-Version-Host-Present Timer for the multicast | |||
Version Host Present Timeout seconds. The timer is reset whenever a | address is set to [Older Version Host Present Interval] seconds. The | |||
new MLDv1 Report is received for that multicast address. If the | timer is reset whenever a new MLDv1 Report is received for that | |||
Older Version Host Present timer expires, the router switches back to | multicast address. If the Older-Version-Host-Present Timer expires, | |||
the Multicast Address Compatibility Mode of MLDv2 for that multicast | the router switches back to the Multicast Address Compatibility Mode | |||
address. | of MLDv2 for that multicast address. | |||
Note that when a router switches back to MLDv2 Multicast Address | Note that when a router switches back to MLDv2 Multicast Address | |||
Compatibility Mode for a multicast address, it takes some time to | Compatibility Mode for a multicast address, it takes some time to | |||
regain source-specific state information. Source-specific | regain source-specific state information. Source-specific | |||
information will be learned during the next General Query, but | information will be learned during the next General Query, but | |||
sources that should be blocked will not be blocked until [Multicast | sources that should be blocked will not be blocked until [Multicast | |||
Address Listening Interval] after that. | Address Listening Interval] after that. | |||
When Multicast Address Compatibility Mode is MLDv2, a router acts | When Multicast Address Compatibility Mode is MLDv2, a router acts | |||
using the MLDv2 protocol for that multicast address. When Multicast | using the MLDv2 protocol for that multicast address. When Multicast | |||
skipping to change at line 2524 ¶ | skipping to change at line 2531 ¶ | |||
a link. If a link is expected to be lossy, the value of the | a link. If a link is expected to be lossy, the value of the | |||
Robustness Variable may be increased. MLD is robust to [Robustness | Robustness Variable may be increased. MLD is robust to [Robustness | |||
Variable] - 1 packet losses. The value of the Robustness Variable | Variable] - 1 packet losses. The value of the Robustness Variable | |||
MUST NOT be zero and SHOULD NOT be one. Default value: 2. | MUST NOT be zero and SHOULD NOT be one. Default value: 2. | |||
9.2. Query Interval | 9.2. Query Interval | |||
The Query Interval variable denotes the interval between General | The Query Interval variable denotes the interval between General | |||
Queries sent by the Querier. Default value: 125 seconds. | Queries sent by the Querier. Default value: 125 seconds. | |||
By varying the [Query Interval], an administrator may tune the number | By varying the Query Interval, an administrator may tune the number | |||
of MLD messages on the link; larger values cause MLD Queries to be | of MLD messages on the link; larger values cause MLD Queries to be | |||
sent less often. | sent less often. | |||
9.3. Query Response Interval | 9.3. Query Response Interval | |||
The Query Response Interval is the Maximum Response Delay used to | The Query Response Interval is the Maximum Response Delay used to | |||
calculate the Maximum Response Code that is inserted into the | calculate the Maximum Response Code that is inserted into the | |||
periodic General Queries. Default value: 10000 (10 seconds) | periodic General Queries. Default value: 10000 (10 seconds) | |||
By varying the [Query Response Interval], an administrator may tune | By varying the Query Response Interval, an administrator may tune the | |||
the burstiness of MLD messages on the link; larger values make the | burstiness of MLD messages on the link; larger values make the | |||
traffic less bursty, as host responses are spread out over a larger | traffic less bursty, as host responses are spread out over a larger | |||
interval. The number of seconds represented by the [Query Response | interval. The number of seconds represented by [Query Response | |||
Interval] must be less than the [Query Interval]. | Interval] must be less than the [Query Interval]. | |||
9.4. Multicast Address Listening Interval | 9.4. Multicast Address Listening Interval | |||
The Multicast Address Listening Interval (MALI) is the amount of time | The Multicast Address Listening Interval (MALI) is the amount of time | |||
that must pass before a multicast router decides there are no more | that must pass before a multicast router decides there are no more | |||
listeners of a multicast address or a particular source on a link. | listeners of a multicast address or a particular source on a link. | |||
This value MUST be ([Robustness Variable] times [Query Interval]) | This value MUST be ([Robustness Variable] times [Query Interval]) | |||
plus 2 times [Query Response Interval]. | plus 2 times [Query Response Interval]. | |||
9.5. Other Querier Present Timeout | 9.5. Other Querier Present Interval | |||
The Other Querier Present Timeout is the length of time that must | The Other Querier Present Interval is the length of time that must | |||
pass before a multicast router decides that there is no longer | pass before a multicast router decides that there is no longer | |||
another multicast router that should be the Querier. This value MUST | another multicast router that should be the Querier. This value MUST | |||
be ([Robustness Variable] times ([Query Interval]) plus (one half of | be ([Robustness Variable] times ([Query Interval]) plus (0.5 times | |||
[Query Response Interval]). | [Query Response Interval]). | |||
9.6. Startup Query Interval | 9.6. Startup Query Interval | |||
The Startup Query Interval is the interval between General Queries | The Startup Query Interval is the interval between General Queries | |||
sent by a Querier on startup. Default value: 1/4 the [Query | sent by a Querier on startup. Default value: 1/4 the [Query | |||
Interval]. | Interval]. | |||
9.7. Startup Query Count | 9.7. Startup Query Count | |||
The Startup Query Count is the number of Queries sent out on startup, | The Startup Query Count is the number of Queries sent out on startup, | |||
separated by the Startup Query Interval. Default value: [Robustness | separated by the Startup Query Interval. Default value: [Robustness | |||
Variable]. | Variable]. | |||
9.8. Last Listener Query Interval | 9.8. Last Listener Query Interval | |||
The Last Listener Query Interval (LLQI) is the Maximum Response Delay | The Last Listener Query Interval (LLQI) is the Maximum Response Delay | |||
used to calculate the Maximum Response Code inserted into Multicast | used to calculate the Maximum Response Code inserted into Multicast | |||
Address Specific Queries sent in response to Version 1 Multicast | Address Specific Queries sent in response to MLDv1 Multicast Listener | |||
Listener Done messages. It is also the Maximum Response Delay used | Done (Type = decimal 132) messages. It is also the Maximum Response | |||
to calculate the Maximum Response Code inserted into Multicast | Delay used to calculate the Maximum Response Code inserted into | |||
Address and Source Specific Query messages. Default value: 1000 (1 | Multicast Address and Source Specific Query messages. Default value: | |||
second). | 1000 (1 second). | |||
Note that for values of LLQI greater than 32.768 seconds, a limited | Note that for values of LLQI greater than 32.768 seconds, a limited | |||
set of values can be represented, corresponding to sequential values | set of values can be represented, corresponding to sequential values | |||
of Maximum Response Code. When converting a configured time to a | of Maximum Response Code. When converting a configured time to a | |||
Maximum Response Code value, it is recommended to use the exact value | Maximum Response Code value, it is recommended to use the exact value | |||
if possible, or the next lower value if the requested value is not | if possible, or the next lower value if the requested value is not | |||
exactly representable. | exactly representable. | |||
This value may be tuned to modify the "leave latency" of the link. A | This value may be tuned to modify the leave latency of the link. A | |||
reduced value results in reduced time to detect the departure of the | reduced value results in reduced time to detect the departure of the | |||
last listener for a multicast address or source. | last listener for a multicast address or source. | |||
9.9. Last Listener Query Count | 9.9. Last Listener Query Count | |||
The Last Listener Query Count is the number of Multicast Address | The Last Listener Query Count is the number of Multicast Address | |||
Specific Queries sent before the router assumes there are no local | Specific Queries sent before the router assumes there are no local | |||
listeners. The Last Listener Query Count is also the number of | listeners. The Last Listener Query Count is also the number of | |||
Multicast Address and Source Specific Queries sent before the router | Multicast Address and Source Specific Queries sent before the router | |||
assumes there are no listeners for a particular source. Default | assumes there are no listeners for a particular source. Default | |||
value: [Robustness Variable]. | value: [Robustness Variable]. | |||
9.10. Last Listener Query Time | 9.10. Last Listener Query Time | |||
The Last Listener Query Time is the time value represented by the | The Last Listener Query Time is the time value represented by the | |||
Last Listener Query Interval, multiplied by [Last Listener Query | [Last Listener Query Interval] times [Last Listener Query Count]. It | |||
Count]. It is not a tunable value, but it may be tuned by changing | is not a tunable value, but it may be tuned by changing its | |||
its components. | components. | |||
9.11. Unsolicited Report Interval | 9.11. Unsolicited Report Interval | |||
The Unsolicited Report Interval is the time between repetitions of a | The Unsolicited Report Interval is the time between repetitions of a | |||
node's initial report of interest in a multicast address. Default | node's initial report of interest in a multicast address. Default | |||
value: 1 second. | value: 1 second. | |||
9.12. Older Version Querier Present Timeout | 9.12. Older Version Querier Present Interval | |||
The Older Version Querier Present Timeout is the timeout for | The Older Version Querier Present Interval is the timeout for | |||
transitioning a host back to MLDv2 Host Compatibility Mode. When an | transitioning a host back to MLDv2 Host Compatibility Mode. When an | |||
MLDv1 query is received, MLDv2 hosts set their Older Version Querier | MLDv1 query is received, MLDv2 hosts set their Older-Version-Querier- | |||
Present Timer to [Older Version Querier Present Timeout]. | Present Timer to [Older Version Querier Present Interval]. | |||
This value MUST be ([Robustness Variable] times (the [Query Interval] | This value MUST be ([Robustness Variable] times [Query Interval] in | |||
in the last Query received)) plus ([Query Response Interval]). | the last Query received) plus ([Query Response Interval]). | |||
9.13. Older Version Host Present Timeout | 9.13. Older Version Host Present Interval | |||
The Older Version Host Present Timeout is the timeout for | The Older Version Host Present Interval is the timeout for | |||
transitioning a router back to MLDv2 Multicast Address Compatibility | transitioning a router back to MLDv2 Multicast Address Compatibility | |||
Mode for a specific multicast address. When an MLDv1 report is | Mode for a specific multicast address. When an MLDv1 report is | |||
received for that multicast address, routers set their Older Version | received for that multicast address, routers set their Older-Version- | |||
Host Present Timer to [Older Version Host Present Timeout]. | Host-Present Timer to [Older Version Host Present Interval]. | |||
This value MUST be ([Robustness Variable] times [Query Interval]) | This value MUST be ([Robustness Variable] times [Query Interval]) | |||
plus ([Query Response Interval]). | plus ([Query Response Interval]). | |||
9.14. Configuring Timers | 9.14. Configuring Timers | |||
This section is meant to provide advice to network administrators on | This section is meant to provide advice to network administrators on | |||
how to tune these settings to their network. Ambitious router | how to tune these settings to their network. Ambitious router | |||
implementations might tune these settings dynamically based upon | implementations might tune these settings dynamically based upon | |||
changing characteristics of the network. | changing characteristics of the network. | |||
skipping to change at line 2724 ¶ | skipping to change at line 2731 ¶ | |||
of the IPv6 packet. If any of these checks fails, the packet is | of the IPv6 packet. If any of these checks fails, the packet is | |||
dropped. This defends the MLDv2 nodes from acting on forged MLD | dropped. This defends the MLDv2 nodes from acting on forged MLD | |||
messages originated off-link. Therefore, we discuss only the effects | messages originated off-link. Therefore, we discuss only the effects | |||
of on-link forgery in the following section. | of on-link forgery in the following section. | |||
10.1. Query Message | 10.1. Query Message | |||
A forged Query message from a machine with a lower IPv6 address than | A forged Query message from a machine with a lower IPv6 address than | |||
the current Querier will cause Querier duties to be assigned to the | the current Querier will cause Querier duties to be assigned to the | |||
forger. If the forger then sends no more Query messages, other | forger. If the forger then sends no more Query messages, other | |||
routers' Other Querier Present timer will time out and one will | routers' Other Querier Present Timer will time out and one will | |||
resume the role of Querier. During this time, if the forger ignores | resume the role of Querier. During this time, if the forger ignores | |||
Multicast Listener Done messages, traffic might flow to multicast | Multicast Listener Done messages, traffic might flow to multicast | |||
addresses with no listeners for up to [Multicast Address Listener | addresses with no listeners for up to [Multicast Address Listener | |||
Interval]. | Interval]. | |||
A forged Version 1 Query message will put MLDv2 listeners on that | A forged Version 1 Query message will put MLDv2 listeners on that | |||
link in MLDv1 Host Compatibility Mode. This scenario can be avoided | link in MLDv1 Host Compatibility Mode. This scenario can be avoided | |||
by providing MLDv2 hosts with a configuration option to ignore | by providing MLDv2 hosts with a configuration option to ignore | |||
Version 1 messages completely. | Version 1 messages completely. | |||
A DoS attack on a node could be staged through forged Multicast | A DoS attack on a node could be staged through forged Multicast | |||
Address and Source Specific Queries. The attacker can find out about | Address and Source Specific Queries. The attacker can find out about | |||
the listening state of a specific node with a general query. After | the listening state of a specific node with a General Query. After | |||
that, it could send a large number of Multicast Address and Source | that, it could send a large number of Multicast Address and Source | |||
Specific Queries, each with a large source list and/or long Maximum | Specific Queries, each with a large source list and/or long Maximum | |||
Response Delay. The node will have to store and maintain the sources | Response Delay. The node will have to store and maintain the sources | |||
specified in all of those queries for as long as it takes to send the | specified in all of those queries for as long as it takes to send the | |||
delayed response. This would consume both memory and CPU cycles in | delayed response. This would consume both memory and CPU cycles in | |||
order to augment the recorded sources with the source lists included | order to augment the recorded sources with the source lists included | |||
in the successive queries. | in the successive queries. | |||
To protect against such a DoS attack, a node stack implementation | To protect against such a DoS attack, a node stack implementation | |||
could restrict the number of Multicast Address and Source Specific | could restrict the number of Multicast Address and Source Specific | |||
Queries per multicast address within this interval and/or record only | Queries per multicast address within this interval and/or record only | |||
a limited number of sources. | a limited number of sources. | |||
10.2. Current State Report Messages | 10.2. Current-State Report Messages | |||
A forged Report message may cause multicast routers to think there | A forged Report message may cause multicast routers to think there | |||
are listeners of a multicast address on a link when there are not. | are listeners of a multicast address on a link when there are not. | |||
Nevertheless, since listening to a multicast address on a host is | Nevertheless, since listening to a multicast address on a host is | |||
generally an unprivileged operation, a local user may trivially gain | generally an unprivileged operation, a local user may trivially gain | |||
the same result without forging any messages. If a large number of | the same result without forging any messages. If a large number of | |||
forged Report messages are generated, a multicast router may consume | forged Report messages are generated, a multicast router may consume | |||
significant resources maintaining multicast forwarding state. | significant resources maintaining multicast forwarding state. | |||
A forged Version 1 Report Message may put a router into MLDv1 | A forged Version 1 Report Message may put a router into MLDv1 | |||
Multicast Address Compatibility Mode for a particular multicast | Multicast Address Compatibility Mode for a particular multicast | |||
address, meaning that the router will ignore MLDv2 source-specific | address, meaning that the router will ignore MLDv2 source-specific | |||
state messages. This can cause traffic to flow from unwanted sources | state messages. This can cause traffic to flow from unwanted sources | |||
for up to [Multicast Address Listener Interval]. This can be solved | for up to [Multicast Address Listener Interval]. This can be solved | |||
by providing routers with a configuration switch to ignore Version 1 | by providing routers with a configuration switch to ignore Version 1 | |||
messages completely. This breaks automatic compatibility with | messages completely. This breaks automatic compatibility with | |||
Version 1 hosts, so it should only be used in situations where source | Version 1 hosts, so it should only be used in situations where source | |||
filtering is critical. | filtering is critical. | |||
10.3. State Change Report Messages | 10.3. State-Change Report Messages | |||
A forged State Change Report message will cause the Querier to send | A forged State-Change Report message will cause the Querier to send | |||
out Multicast Address Specific or Multicast Address and Source | out Multicast Address Specific or Multicast Address and Source | |||
Specific Queries for the multicast address in question. This causes | Specific Queries for the multicast address in question. This causes | |||
extra processing on each router and on each listener of the multicast | extra processing on each router and on each listener of the multicast | |||
address, but it cannot cause loss of desired traffic. | address, but it cannot cause loss of desired traffic. | |||
11. IANA Considerations | 11. IANA Considerations | |||
IANA has assigned the IPv6 link-local multicast address ff02::16, | IANA has assigned the IPv6 link-local multicast address ff02::16, | |||
called "all MLDv2-capable routers", as described in Section 5.2.15. | called "all MLDv2-capable routers", as described in Section 5.2.15. | |||
Version 2 Multicast Listener Reports will be sent to this special | Version 2 Multicast Listener Reports will be sent to this special | |||
skipping to change at line 2878 ¶ | skipping to change at line 2885 ¶ | |||
Address Autoconfiguration", RFC 4862, | Address Autoconfiguration", RFC 4862, | |||
DOI 10.17487/RFC4862, September 2007, | DOI 10.17487/RFC4862, September 2007, | |||
<https://www.rfc-editor.org/info/rfc4862>. | <https://www.rfc-editor.org/info/rfc4862>. | |||
[RFC9776] Haberman, B., "Internet Group Management Protocol, Version | [RFC9776] Haberman, B., "Internet Group Management Protocol, Version | |||
3", STD 100, RFC 9776, DOI 10.17487/RFC9776, March 2025, | 3", STD 100, RFC 9776, DOI 10.17487/RFC9776, March 2025, | |||
<https://www.rfc-editor.org/info/rfc9776>. | <https://www.rfc-editor.org/info/rfc9776>. | |||
Appendix A. Design Rationale | Appendix A. Design Rationale | |||
A.1. The Need for State Change Messages | A.1. The Need for State-Change Messages | |||
MLDv2 specifies two types of Multicast Listener Reports: Current | MLDv2 specifies two types of Multicast Listener Reports: Current | |||
State and State Change. This section describes the rationale for the | State and State Change. This section describes the rationale for the | |||
need for both these types of Reports. | need for both these types of Reports. | |||
Routers need to distinguish Multicast Listener Reports that were sent | Routers need to distinguish Multicast Listener Reports that were sent | |||
in response to Queries from those that were sent as a result of a | in response to Queries from those that were sent as a result of a | |||
change in the per-interface state. Multicast Listener Reports that | change in the per-interface state. Multicast Listener Reports that | |||
are sent in response to Multicast Address Listener Queries are used | are sent in response to Multicast Address Listener Queries are used | |||
mainly to refresh the existing state at the router; they typically do | mainly to refresh the existing state at the router; they typically do | |||
skipping to change at line 2901 ¶ | skipping to change at line 2908 ¶ | |||
state require the router to take some action in response to the | state require the router to take some action in response to the | |||
received report (see Section 7.4). | received report (see Section 7.4). | |||
The inability to distinguish between the two types of reports would | The inability to distinguish between the two types of reports would | |||
force a router to treat all Multicast Listener Reports as potential | force a router to treat all Multicast Listener Reports as potential | |||
changes in state and could result in increased processing at the | changes in state and could result in increased processing at the | |||
router as well as an increase in MLD traffic on the link. | router as well as an increase in MLD traffic on the link. | |||
A.2. Host Suppression | A.2. Host Suppression | |||
In MLDv1, a host would not send a pending multicast listener report | In MLDv1, a host would not send a pending Multicast Listener Report | |||
if a similar report was sent by another listener on the link. In | if a similar report was sent by another listener on the link. In | |||
MLDv2, the suppression of multicast listener reports has been | MLDv2, the suppression of Multicast Listener Reports has been | |||
removed. The following points explain this decision. | removed. The following points explain this decision. | |||
1. Routers may want to track per-host multicast listener status on | 1. Routers may want to track per-host Multicast Listener status on | |||
an interface. This would allow routers to implement fast leaves | an interface. This would allow routers to implement fast leaves | |||
(e.g., for layered multicast congestion control schemes) as well | (e.g., for layered multicast congestion control schemes) as well | |||
as track listener status for possible security or accounting | as track listener status for possible security or accounting | |||
purposes. The present specification does not require routers to | purposes. The present specification does not require routers to | |||
implement per-host tracking. Nevertheless, the lack of host | implement per-host tracking. Nevertheless, the lack of host | |||
suppression in MLDv2 makes it possible to implement either | suppression in MLDv2 makes it possible to implement either | |||
proprietary or future standard behavior of multicast routers that | proprietary or future standard behavior of multicast routers that | |||
would support per-host tracking, while being fully interoperable | would support per-host tracking, while being fully interoperable | |||
with MLDv2 listeners and routers that implement the exact | with MLDv2 listeners and routers that implement the exact | |||
behavior described in this specification. | behavior described in this specification. | |||
2. Multicast Listener Report suppression does not work well on | 2. Multicast Listener Report suppression does not work well on | |||
bridged LANs. Many bridges and Layer 2 / Layer 3 switches that | bridged LANs. Many bridges and Layer 2 / Layer 3 switches that | |||
implement MLD snooping do not forward MLD messages across LAN | implement MLD snooping do not forward MLD messages across LAN | |||
segments in order to prevent multicast listener report | segments in order to prevent Multicast Listener Report | |||
suppression. | suppression. | |||
3. By eliminating multicast listener report suppression, hosts have | 3. By eliminating Multicast Listener Report suppression, hosts have | |||
fewer messages to process; this leads to a simpler state machine | fewer messages to process; this leads to a simpler state machine | |||
implementation. | implementation. | |||
4. In MLDv2, a single multicast listener report now bundles multiple | 4. In MLDv2, a single Multicast Listener Report now bundles multiple | |||
multicast address records to decrease the number of packets sent. | Multicast Address Records to decrease the number of packets sent. | |||
In comparison, the previous version of MLD required that each | In comparison, the previous version of MLD required that each | |||
multicast address be reported in a separate message. | multicast address be reported in a separate message. | |||
A.3. Switching Router Filter Modes from EXCLUDE to INCLUDE | A.3. Switching Router Filter Modes from EXCLUDE to INCLUDE | |||
If on a link there are nodes in both EXCLUDE and INCLUDE modes for a | If on a link there are nodes in both EXCLUDE and INCLUDE modes for a | |||
single multicast address, the router must be in EXCLUDE mode as well | single multicast address, the router must be in EXCLUDE mode as well | |||
(see Section 7.2.1). In EXCLUDE mode, a router forwards traffic from | (see Section 7.2.1). In EXCLUDE mode, a router forwards traffic from | |||
all sources except those in the Exclude List. If all nodes in | all sources except those in the Exclude List. If all nodes in | |||
EXCLUDE mode cease to exist or to listen, it would be desirable for | EXCLUDE mode cease to exist or to listen, it would be desirable for | |||
the router to switch back to INCLUDE mode seamlessly, without | the router to switch back to INCLUDE mode seamlessly, without | |||
interrupting the flow of traffic to existing listeners. | interrupting the flow of traffic to existing listeners. | |||
One of the ways to accomplish this is for routers to keep track of | One of the ways to accomplish this is for routers to keep track of | |||
all sources that nodes that are in INCLUDE mode listen to, even | all sources that nodes that are in INCLUDE mode listen to, even | |||
though the router itself is in EXCLUDE mode. If the Filter Timer for | though the router itself is in EXCLUDE mode. If the filter timer for | |||
a multicast address expires, it implies that there are no nodes in | a multicast address expires, it implies that there are no nodes in | |||
EXCLUDE mode on the link (otherwise, a multicast listener report from | EXCLUDE mode on the link (otherwise, a Multicast Listener Report from | |||
that node would have refreshed the Filter Timer). The router can | that node would have refreshed the filter timer). The router can | |||
then switch to INCLUDE mode seamlessly; sources from the Requested | then switch to INCLUDE mode seamlessly; sources from the Requested | |||
List are moved to the Include List, while sources from the Exclude | List are moved to the Include List, while sources from the Exclude | |||
List are deleted. | List are deleted. | |||
Appendix B. Summary of Changes | Appendix B. Summary of Changes | |||
B.1. MLDv1 | B.1. MLDv1 | |||
The following is a summary of changes from MLDv1, specified in | The following is a summary of changes from MLDv1, specified in | |||
[RFC2710]. | [RFC2710]. | |||
* MLDv2 introduces source filtering. | * MLDv2 introduces source filtering. | |||
* The IP service interface of MLDv2 nodes is modified accordingly. | * The IP service interface of MLDv2 nodes is modified accordingly. | |||
It enables the specification of a filter mode and a source list. | It enables the specification of a filter mode and a source list. | |||
* An MLDv2 node keeps per-socket and per-interface multicast | * An MLDv2 node keeps per-socket and per-interface Multicast Address | |||
listening states that include a filter mode and a source list for | Listening states that include a filter mode and a source list for | |||
each multicast address. This enables packet filtering based on a | each multicast address. This enables packet filtering based on a | |||
socket's multicast reception state. | socket's multicast reception state. | |||
* MLDv2 state kept on routers includes a filter mode and a list of | * MLDv2 state kept on routers includes a filter mode and a list of | |||
sources and source timers for each multicast address that has | sources and source timers for each multicast address that has | |||
listeners on the link. MLDv1 routers kept only the list of | listeners on the link. MLDv1 routers kept only the list of | |||
multicast addresses. | multicast addresses. | |||
* Queries include additional fields (Section 5.1). | * Queries include additional fields (Section 5.1). | |||
skipping to change at line 3015 ¶ | skipping to change at line 3022 ¶ | |||
* Unsolicited Reports, announcing changes in receiver listening | * Unsolicited Reports, announcing changes in receiver listening | |||
state, are sent [Robustness Variable] times. [RFC2710] is less | state, are sent [Robustness Variable] times. [RFC2710] is less | |||
explicit. | explicit. | |||
* There are no Done messages. | * There are no Done messages. | |||
* Interoperability with MLDv1 systems is achieved by MLDv2 state | * Interoperability with MLDv1 systems is achieved by MLDv2 state | |||
operations. | operations. | |||
* In order to ensure interoperability, hosts maintain a Host | * In order to ensure interoperability, hosts maintain a Host | |||
Compatibility Mode variable and an Older Version Querier Present | Compatibility Mode variable and an Older-Version-Querier-Present | |||
timer per interface. Routers maintain a Multicast Address | Timer per interface. Routers maintain a Multicast Address | |||
Compatibility Mode variable and an Older Version Host Present | Compatibility Mode variable and an Older-Version-Host-Present | |||
timer per multicast address. | Timer per multicast address. | |||
B.2. Changes since RFC 3810 | B.2. Changes since RFC 3810 | |||
The following summarizes the changes made since [RFC3810]. | The following summarizes the changes made since [RFC3810]. | |||
* Added definition of Resv to address Erratum 4773. | * Added definition of Resv to address Erratum 4773. | |||
* Added clarifying text on which multicast addresses require the | * Added clarifying text on which multicast addresses require the | |||
sending of MLD messages to address Erratum 5977. | sending of MLD messages to address Erratum 5977. | |||
* Added text to clarify the Group Membership Interval timer changes | * Added text to clarify the Group Membership Interval Timer changes | |||
per Erratum 6725. | per Erratum 6725. | |||
* Changed "Reserved field" to "Flags field" in messages to | * Changed "Reserved field" to "Flags field" in messages to | |||
facilitate use of an IANA-managed registry for future bit | facilitate use of an IANA-managed registry for future bit | |||
allocations. | allocations. | |||
Acknowledgments | Acknowledgments | |||
We would like to thank Hitoshi Asaeda, Randy Bush, Francis Dupont, | We would like to thank Hitoshi Asaeda, Randy Bush, Francis Dupont, | |||
Ted Hardie, Russ Housley, Konstantin Kabassanov, Erik Nordmark, | Ted Hardie, Russ Housley, Konstantin Kabassanov, Erik Nordmark, | |||
End of changes. 184 change blocks. | ||||
332 lines changed or deleted | 339 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |