idnits 2.17.00 (12 Aug 2021) /tmp/idnits22970/draft-ietf-pim-3810bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The abstract seems to indicate that this document updates RFC2710, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 2022) is 29 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1025 -- Looks like a reference, but probably isn't: '2' on line 1033 == Missing Reference: 'N' is mentioned on line 1045, but not defined == Missing Reference: 'M' is mentioned on line 1004, but not defined == Unused Reference: 'RFC2434' is defined on line 2730, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Haberman, Ed. 3 Internet-Draft JHU APL 4 Obsoletes: 3810 (if approved) April 2022 5 Intended status: Standards Track 6 Expires: 14 October 2022 8 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 9 draft-ietf-pim-3810bis-02 11 Abstract 13 This document updates RFC 2710, and it specifies Version 2 of the 14 Multicast Listener Discovery Protocol (MLDv2). MLD is used by an 15 IPv6 router to discover the presence of multicast listeners on 16 directly attached links, and to discover which multicast addresses 17 are of interest to those neighboring nodes. MLDv2 is designed to be 18 interoperable with MLDv1. MLDv2 adds the ability for a node to 19 report interest in listening to packets with a particular multicast 20 address only from specific source addresses or from all sources 21 except for specific source addresses. 23 This document obsoletes RFC 3810. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 3 October 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Building Multicast Listening State on Multicast Address 61 Listeners . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.2. Exchanging Messages between the Querier and the Listening 63 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.3. Building Multicast Address Listener State on Multicast 65 Routers . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3. The Service Interface for Requesting IP Multicast 67 Reception . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4. Multicast Listening State Maintained by Nodes . . . . . . . . 13 69 4.1. Per-Socket State . . . . . . . . . . . . . . . . . . . . 13 70 4.2. Per-Interface State . . . . . . . . . . . . . . . . . . . 14 71 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16 72 5.1. Multicast Listener Query Message . . . . . . . . . . . . 17 73 5.1.1. Code . . . . . . . . . . . . . . . . . . . . . . . . 19 74 5.1.2. Checksum . . . . . . . . . . . . . . . . . . . . . . 19 75 5.1.3. Maximum Response Code . . . . . . . . . . . . . . . . 19 76 5.1.4. Reserved . . . . . . . . . . . . . . . . . . . . . . 19 77 5.1.5. Multicast Address . . . . . . . . . . . . . . . . . . 20 78 5.1.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . 20 79 5.1.7. S Flag (Suppress Router-Side Processing) . . . . . . 20 80 5.1.8. QRV (Querier's Robustness Variable) . . . . . . . . . 20 81 5.1.9. QQIC (Querier's Query Interval Code) . . . . . . . . 20 82 5.1.10. Number of Sources (N) . . . . . . . . . . . . . . . . 21 83 5.1.11. Source Address [i] . . . . . . . . . . . . . . . . . 21 84 5.1.12. Additional Data . . . . . . . . . . . . . . . . . . . 21 85 5.1.13. Query Variants . . . . . . . . . . . . . . . . . . . 21 86 5.1.14. Source Addresses for Queries . . . . . . . . . . . . 22 87 5.1.15. Destination Addresses for Queries . . . . . . . . . . 22 88 5.2. Version 2 Multicast Listener Report Message . . . . . . . 22 89 5.2.1. Reserved . . . . . . . . . . . . . . . . . . . . . . 25 90 5.2.2. Checksum . . . . . . . . . . . . . . . . . . . . . . 25 91 5.2.3. Flags . . . . . . . . . . . . . . . . . . . . . . . . 25 92 5.2.4. Nr of Mcast Address Records (M) . . . . . . . . . . . 25 93 5.2.5. Multicast Address Record . . . . . . . . . . . . . . 25 94 5.2.6. Record Type . . . . . . . . . . . . . . . . . . . . . 25 95 5.2.7. Aux Data Len . . . . . . . . . . . . . . . . . . . . 25 96 5.2.8. Number of Sources (N) . . . . . . . . . . . . . . . . 25 97 5.2.9. Multicast Address . . . . . . . . . . . . . . . . . . 26 98 5.2.10. Source Address [i] . . . . . . . . . . . . . . . . . 26 99 5.2.11. Auxiliary Data . . . . . . . . . . . . . . . . . . . 26 100 5.2.12. Additional Data . . . . . . . . . . . . . . . . . . . 26 101 5.2.13. Multicast Address Record Types . . . . . . . . . . . 26 102 5.2.14. Source Addresses for Reports . . . . . . . . . . . . 29 103 5.2.15. Destination Addresses for Reports . . . . . . . . . . 29 104 5.2.16. Multicast Listener Report Size . . . . . . . . . . . 30 105 6. Protocol Description for Multicast Address Listeners . . . . 30 106 6.1. Action on Change of Per-Interface State . . . . . . . . . 31 107 6.2. Action on Reception of a Query . . . . . . . . . . . . . 34 108 6.3. Action on Timer Expiration . . . . . . . . . . . . . . . 36 109 7. Description of the Protocol for Multicast Routers . . . . . . 38 110 7.1. Conditions for MLD Queries . . . . . . . . . . . . . . . 39 111 7.2. MLD State Maintained by Multicast Routers . . . . . . . . 41 112 7.2.1. Definition of Router Filter Mode . . . . . . . . . . 41 113 7.2.2. Definition of Filter Timers . . . . . . . . . . . . . 42 114 7.2.3. Definition of Source Timers . . . . . . . . . . . . . 43 115 7.3. MLDv2 Source Specific Forwarding Rules . . . . . . . . . 45 116 7.4. Action on Reception of Reports . . . . . . . . . . . . . 46 117 7.4.1. Reception of Current State Records . . . . . . . . . 46 118 7.4.2. Reception of Filter Mode Change and Source List Change 119 Records . . . . . . . . . . . . . . . . . . . . . . . 47 120 7.5. Switching Router Filter Modes . . . . . . . . . . . . . . 49 121 7.6. Action on Reception of Queries . . . . . . . . . . . . . 50 122 7.6.1. Timer Updates . . . . . . . . . . . . . . . . . . . . 50 123 7.6.2. Querier Election . . . . . . . . . . . . . . . . . . 50 124 7.6.3. Building and Sending Specific Queries . . . . . . . . 51 125 8. Interoperation with MLDv1 . . . . . . . . . . . . . . . . . . 52 126 8.1. Query Version Distinctions . . . . . . . . . . . . . . . 52 127 8.2. Multicast Address Listener Behavior . . . . . . . . . . . 52 128 8.2.1. In the Presence of MLDv1 Routers . . . . . . . . . . 52 129 8.2.2. In the Presence of MLDv1 Multicast Address 130 Listeners . . . . . . . . . . . . . . . . . . . . . . 53 131 8.3. Multicast Router Behavior . . . . . . . . . . . . . . . . 53 132 8.3.1. In the Presence of MLDv1 Routers . . . . . . . . . . 53 133 8.3.2. In the Presence of MLDv1 Multicast Address 134 Listeners . . . . . . . . . . . . . . . . . . . . . . 54 135 9. List of Timers, Counters, and their Default Values . . . . . 55 136 9.1. Robustness Variable . . . . . . . . . . . . . . . . . . . 55 137 9.2. Query Interval . . . . . . . . . . . . . . . . . . . . . 55 138 9.3. Query Response Interval . . . . . . . . . . . . . . . . . 55 139 9.4. Multicast Address Listening Interval . . . . . . . . . . 55 140 9.5. Other Querier Present Timeout . . . . . . . . . . . . . . 56 141 9.6. Startup Query Interval . . . . . . . . . . . . . . . . . 56 142 9.7. Startup Query Count . . . . . . . . . . . . . . . . . . . 56 143 9.8. Last Listener Query Interval . . . . . . . . . . . . . . 56 144 9.9. Last Listener Query Count . . . . . . . . . . . . . . . . 57 145 9.10. Last Listener Query Time . . . . . . . . . . . . . . . . 57 146 9.11. Unsolicited Report Interval . . . . . . . . . . . . . . . 57 147 9.12. Older Version Querier Present Timeout . . . . . . . . . . 57 148 9.13. Older Version Host Present Timeout . . . . . . . . . . . 57 149 9.14. Configuring timers . . . . . . . . . . . . . . . . . . . 58 150 9.14.1. Robustness Variable . . . . . . . . . . . . . . . . 58 151 9.14.2. Query Interval . . . . . . . . . . . . . . . . . . . 58 152 9.14.3. Maximum Response Delay . . . . . . . . . . . . . . . 58 153 10. Security Considerations . . . . . . . . . . . . . . . . . . . 59 154 10.1. Query Message . . . . . . . . . . . . . . . . . . . . . 59 155 10.2. Current State Report messages . . . . . . . . . . . . . 60 156 10.3. State Change Report messages . . . . . . . . . . . . . . 60 157 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 158 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 61 159 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 61 160 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 61 161 14.1. Normative References . . . . . . . . . . . . . . . . . . 61 162 14.2. Informative References . . . . . . . . . . . . . . . . . 62 163 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 63 164 A.1. The Need for State Change Messages . . . . . . . . . . . 63 165 A.2. Host Suppression . . . . . . . . . . . . . . . . . . . . 63 166 A.3. Switching router filter modes from EXCLUDE to INCLUDE . . 64 167 Appendix B. Summary of Changes . . . . . . . . . . . . . . . . . 64 168 B.1. MLDv1 . . . . . . . . . . . . . . . . . . . . . . . . . . 64 169 B.2. MLDv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 66 170 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 66 172 1. Introduction 174 The Multicast Listener Discovery Protocol (MLD) is used by IPv6 175 routers to discover the presence of multicast listeners (i.e., nodes 176 that wish to receive multicast packets) on their directly attached 177 links, and to discover specifically which multicast addresses are of 178 interest to those neighboring nodes. Note that a multicast router 179 may itself be a listener of one or more multicast addresses; in this 180 case it performs both the "multicast router part" and the "multicast 181 address listener part" of the protocol, to collect the multicast 182 listener information needed by its multicast routing protocol on the 183 one hand, and to inform itself and other neighboring multicast 184 routers of its listening state on the other hand. 186 This document specifies Version 2 of MLD. The previous version of 187 MLD is specified in [RFC2710]. In this document we will refer to it 188 as MLDv1. MLDv2 is a translation of the IGMPv3 protocol [RFC3376] 189 for IPv6 semantics. 191 The MLDv2 protocol, when compared to MLDv1, adds support for "source 192 filtering", i.e., the ability for a node to report interest in 193 listening to packets only from specific source addresses, as required 194 to support Source-Specific Multicast [RFC3569], or from *all but* 195 specific source addresses, sent to a particular multicast address. 196 MLDv2 is designed to be interoperable with MLDv1. 198 This document obsoletes [RFC3810]. 200 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 201 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 202 "OPTIONAL" in this document are to be interpreted as described in 203 [RFC2119]. 205 2. Protocol Overview 207 This section gives a brief description of the protocol operation. 208 The following sections present the protocol details. 210 MLD is an asymmetric protocol; it specifies separate behaviors for 211 multicast address listeners (i.e., hosts or routers that listen to 212 multicast packets) and multicast routers. The purpose of MLD is to 213 enable each multicast router to learn, for each of its directly 214 attached links, which multicast addresses and which sources have 215 interested listeners on that link. The information gathered by MLD 216 is provided to whichever multicast routing protocol is used by the 217 router, in order to ensure that multicast packets are delivered to 218 all links where there are listeners interested in such packets. 220 Multicast routers only need to know that at least one node on an 221 attached link is listening to packets for a particular multicast 222 address, from a particular source; a multicast router is not required 223 to individually keep track of the interests of each neighboring node. 224 (Nevertheless, see Appendix A.2 item 1 for discussion.) 225 A multicast router performs the router part of the MLDv2 protocol 226 (described in details in Section 7) on each of its directly attached 227 links. If a multicast router has more than one interface connected 228 to the same link, it only needs to operate the protocol on one of 229 those interfaces. The router behavior depends on whether there are 230 several multicast routers on the same subnet, or not. If that is the 231 case, a querier election mechanism (described in Section 7.6.2) is 232 used to elect a single multicast router to be in Querier state. This 233 router is called the Querier. All multicast routers on the subnet 234 listen to the messages sent by multicast address listeners, and 235 maintain the same multicast listening information state, so that they 236 can take over the querier role, should the present Querier fail. 237 Nevertheless, only the Querier sends periodical or triggered query 238 messages on the subnet, as described in Section 7.1. 240 A multicast address listener performs the listener part of the MLDv2 241 protocol (described in details in Section 6) on all interfaces on 242 which multicast reception is supported, even if more than one of 243 those interfaces are connected to the same link. 245 2.1. Building Multicast Listening State on Multicast Address Listeners 247 Upper-layer protocols and applications that run on a multicast 248 address listener node use specific service interface calls (described 249 in Section 3) to ask the IP layer to enable or disable reception of 250 packets sent to specific multicast addresses. The node keeps 251 Multicast Address Listening state for each socket on which the 252 service interface calls have been invoked (Section 4.1). In addition 253 to this per-socket multicast listening state, a node must also 254 maintain or compute multicast listening state for each of its 255 interfaces (Section 4.2). Conceptually, that state consists of a set 256 of records, with each record containing an IPv6 multicast address, a 257 filter mode, and a source list. The filter mode may be either 258 INCLUDE or EXCLUDE. In INCLUDE mode, reception of packets sent to 259 the specified multicast address is enabled only from the source 260 addresses listed in the source list. In EXCLUDE mode, reception of 261 packets sent to the given multicast address is enabled from all 262 source addresses except those listed in the source list. 264 At most one record per multicast address exists for a given 265 interface. This per-interface state is derived from the per-socket 266 state, but may differ from it when different sockets have differing 267 filter modes and/or source lists for the same multicast address and 268 interface. After a multicast packet has been accepted from an 269 interface by the IP layer, its subsequent delivery to the application 270 connected to a particular socket depends on the multicast listening 271 state of that socket (and possibly also on other conditions, such as 272 what transport-layer port the socket is bound to). Note that MLDv2 273 messages are not subject to source filtering and must always be 274 processed by hosts and routers. 276 2.2. Exchanging Messages between the Querier and the Listening Nodes 278 There are three types of MLDv2 query messages: General Queries, 279 Multicast Address Specific Queries, and Multicast Address and Source 280 Specific Queries. The Querier periodically sends General Queries, to 281 learn multicast address listener information from an attached link. 282 These queries are used to build and refresh the Multicast Address 283 Listener state inside all multicast routers on the link. 285 Nodes respond to these queries by reporting their per-interface 286 Multicast Address Listening state, through Current State Report 287 messages sent to a specific multicast address all MLDv2 routers on 288 the link listen to. On the other hand, if the listening state of a 289 node changes, the node immediately reports these changes through a 290 State Change Report message. The State Change Report contains either 291 Filter Mode Change records, Source List Change records, or records of 292 both types. A detailed description of the report messages is 293 presented in Section 5.2.13. 295 Both router and listener state changes are mainly triggered by the 296 expiration of a specific timer, or the reception of an MLD message 297 (listener state change can be also triggered by the invocation of a 298 service interface call). Therefore, to enhance protocol robustness, 299 in spite of the possible unreliability of message exchanges, messages 300 are retransmitted several times. Furthermore, timers are set so as 301 to take into account the possible message losses, and to wait for 302 retransmissions. 304 Periodical General Queries and Current State Reports do not apply 305 this rule, in order not to overload the link; it is assumed that in 306 general these messages do not generate state changes, their main 307 purpose being to refresh existing state. Thus, even if one such 308 message is lost, the corresponding state will be refreshed during the 309 next reporting period. 311 As opposed to Current State Reports, State Change Reports are 312 retransmitted several times, in order to avoid them being missed by 313 one or more multicast routers. The number of retransmissions depends 314 on the so-called Robustness Variable. This variable allows tuning 315 the protocol according to the expected packet loss on a link. If a 316 link is expected to be lossy (e.g., a wireless connection), the value 317 of the Robustness Variable may be increased. MLD is robust to 318 [Robustness Variable]-1 packet losses. This document recommends a 319 default value of 2 for the Robustness Variable (see Section 9.1). 321 If more changes to the same per-interface state entry occur before 322 all the retransmissions of the State Change Report for the first 323 change have been completed, each additional change triggers the 324 immediate transmission of a new State Change Report. Section 6.1 325 shows how the content of this new report is computed. 326 Retransmissions of the new State Change Report will be scheduled as 327 well, in order to ensure that each instance of state change is 328 transmitted at least [Robustness Variable] times. 330 If a node on a link expresses, through a State Change Report, its 331 desire to no longer listen to a particular multicast address (or 332 source), the Querier must query for other listeners of the multicast 333 address (or source) before deleting the multicast address (or source) 334 from its Multicast Address Listener state and stopping the 335 corresponding traffic. Thus, the Querier sends a Multicast Address 336 Specific Query to verify whether there are nodes still listening to a 337 specified multicast address or not. Similarly, the Querier sends a 338 Multicast Address and Source Specific Query to verify whether, for a 339 specified multicast address, there are nodes still listening to a 340 specific set of sources, or not. Section 5.1.13 describes each query 341 in more detail. 343 Both Multicast Address Specific Queries and Multicast Address and 344 Source Specific Queries are only sent in response to State Change 345 Reports, never in response to Current State Reports. This 346 distinction between the two types of reports is needed to avoid the 347 router treating all Multicast Listener Reports as potential changes 348 in state. By doing so, the fast leave mechanism of MLDv2, described 349 in more detail in Section 2.2, might not be effective if a State 350 Change Report is lost, and only the following Current State Report is 351 received by the router. Nevertheless, it avoids an increased 352 processing at the router and it reduces the MLD traffic on the link. 353 More details on the necessity of distinguishing between the two 354 report types can be found in Appendix A.1. 356 Nodes respond to the above queries through Current State Reports, 357 that contain their per-interface Multicast Address Listening state 358 only for the multicast addresses (or sources) being queried. 360 As stated earlier, in order to ensure protocol robustness, all the 361 queries, except the periodical General Queries, are retransmitted 362 several times within a given time interval. The number of 363 retransmissions depends on the Robustness Variable. If, while 364 scheduling new queries, there are pending queries to be retransmitted 365 for the same multicast address, the new queries and the pending 366 queries have to be merged. In addition, host reports received for a 367 multicast address with pending queries may affect the contents of 368 those queries. The process of building and maintaining the state of 369 pending queries is presented in Section 7.6.3. 371 Protocol robustness is also enhanced through the use of the S flag 372 (Suppress Router-Side Processing). As described above, when a 373 Multicast Address Specific or a Multicast Address and Source Specific 374 Query is sent by the Querier, a number of retransmissions of the 375 query are scheduled. In the original (first) query the S flag is 376 clear. When the Querier sends this query, it lowers the timers for 377 the concerned multicast address (or source) to a given value; 378 similarly, any non-querier multicast router that receives the query 379 lowers its timers in the same way. Nevertheless, while waiting for 380 the next scheduled queries to be sent, the Querier may receive a 381 report that updates the timers. The scheduled queries still have to 382 be sent, in order to ensure that a non-querier router keeps its state 383 synchronized with the current Querier (the non-querier router might 384 have missed the first query). Nevertheless, the timers should not be 385 lowered again, as a valid answer was already received. Therefore, in 386 subsequent queries the Querier sets the S flag. 388 2.3. Building Multicast Address Listener State on Multicast Routers 390 Multicast routers that implement MLDv2 (whether they are in Querier 391 state or not) keep state per multicast address per attached link. 392 This multicast address listener state consists of a Filter Mode, a 393 Filter Timer, and a Source List, with a timer associated to each 394 source from the list. The Filter Mode is used to summarize the total 395 listening state of a multicast address to a minimum set, such that 396 all nodes' listening states are respected. The Filter Mode may 397 change in response to the reception of particular types of report 398 messages, or when certain timer conditions occur. 400 A router is in INCLUDE mode for a specific multicast address on a 401 given interface if all the listeners on the link interested in that 402 address are in INCLUDE mode. The router state is represented through 403 the notation INCLUDE (A), where A is a list of sources, called the 404 "Include List". The Include List is the set of sources that one or 405 more listeners on the link have requested to receive. All the 406 sources from the Include List will be forwarded by the router. Any 407 other source that is not in the Include List will be blocked by the 408 router. 410 A source can be added to the current Include List if a listener in 411 INCLUDE mode sends a Current State or a State Change Report that 412 includes that source. Each source from the Include List is 413 associated with a source timer that is updated whenever a listener in 414 INCLUDE mode sends a report that confirms its interest in that 415 specific source. If the timer of a source from the Include List 416 expires, the source is deleted from the Include List. 418 Besides this "soft leave" mechanism, there is also a "fast leave" 419 scheme in MLDv2; it is also based on the use of source timers. When 420 a node in INCLUDE mode expresses its desire to stop listening to a 421 specific source, all the multicast routers on the link lower their 422 timers for that source to a given value. The Querier then sends a 423 Multicast Address and Source Specific Query, to verify whether there 424 are other listeners for that source on the link, or not. If a report 425 that includes this source is received before the timer expiration, 426 all the multicast routers on the link update the source timer. If 427 not, the source is deleted from the Include List. The handling of 428 the Include List, according to the received reports, is detailed in 429 Section 7.4.1 and Section 7.4.2. 431 A router is in EXCLUDE mode for a specific multicast address on a 432 given interface if there is at least one listener in EXCLUDE mode for 433 that address on the link. When the first report is received from 434 such a listener, the router sets the Filter Timer that corresponds to 435 that address. This timer is reset each time an EXCLUDE mode listener 436 confirms its listening state through a Current State Report. The 437 timer is also updated when a listener, formerly in INCLUDE mode, 438 announces its filter mode change through a State Change Report 439 message. If the Filter Timer expires, it means that there are no 440 more listeners in EXCLUDE mode on the link. In this case, the router 441 switches back to INCLUDE mode for that multicast address. 443 When the router is in EXCLUDE mode, the router state is represented 444 by the notation EXCLUDE (X,Y), where X is called the "Requested List" 445 and Y is called the "Exclude List". All sources, except those from 446 the Exclude List, will be forwarded by the router. The Requested 447 List has no effect on forwarding. Nevertheless, the router has to 448 maintain the Requested List for two reasons: 450 * To keep track of sources that listeners in INCLUDE mode listen to. 451 This is necessary to assure a seamless transition of the router to 452 INCLUDE mode, when there is no listener in EXCLUDE mode left. 453 This transition should not interrupt the flow of traffic to 454 listeners in INCLUDE mode for that multicast address. Therefore, 455 at the time of the transition, the Requested List should contain 456 the set of sources that nodes in INCLUDE mode have explicitly 457 requested. 459 When the router switches to INCLUDE mode, the sources in the 460 Requested List are moved to the Include List, and the Exclude List 461 is deleted. Before switching, the Requested List can contain an 462 inexact guess of the sources listeners in INCLUDE mode listen to - 463 might be too large or too small. These inexactitudes are due to 464 the fact that the Requested List is also used for fast blocking 465 purposes, as described below. If such a fast blocking is 466 required, some sources may be deleted from the Requested List (as 467 shown in Section 7.4.1 and Section 7.4.2) in order to reduce 468 router state. Nevertheless, in each such case the Filter Timer is 469 updated as well. Therefore, listeners in INCLUDE mode will have 470 enough time, before an eventual switching, to reconfirm their 471 interest in the eliminated source(s), and rebuild the Requested 472 List accordingly. The protocol ensures that when a switch to 473 INCLUDE mode occurs, the Requested List will be accurate. Details 474 about the transition of the router to INCLUDE mode are presented 475 in Appendix A.3. 477 * To allow the fast blocking of previously unblocked sources. If 478 the router receives a report that contains such a request, the 479 concerned sources are added to the Requested List. Their timers 480 are set to a given small value, and a Multicast Address and Source 481 Specific Query is sent by the Querier, to check whether there are 482 nodes on the link still interested in those sources, or not. If 483 no node announces its interest in receiving those specific source, 484 the timers of those sources expire. Then, the sources are moved 485 from the Requested List to the Exclude List. From then on, the 486 sources will be blocked by the router. 488 The handling of the EXCLUDE mode router state, according to the 489 received reports, is detailed in Section 7.4.1 and Section 7.4.2. 491 Both the MLDv2 router and listener behaviors described in this 492 document were defined to ensure backward interoperability with MLDv1 493 hosts and routers. Interoperability issues are detailed in 494 Section 8. 496 3. The Service Interface for Requesting IP Multicast Reception 498 Within an IP system, there is (at least conceptually) a service 499 interface used by upper-layer protocols or application programs to 500 ask the IP layer to enable or disable reception of packets sent to 501 specific IP multicast addresses. In order to take full advantage of 502 the capabilities of MLDv2, a node's IP service interface must support 503 the following operation: 505 IPv6MulticastListen ( socket, interface, IPv6 multicast-address, 506 filter-mode, source-list ) 508 where: 510 * "socket" is an implementation-specific parameter used to 511 distinguish among different requesting entities (e.g., programs, 512 processes) within the node; the socket parameter of BSD Unix 513 system calls is a specific example. 515 * "interface" is a local identifier of the network interface on 516 which reception of the specified multicast address is to be 517 enabled or disabled. Interfaces may be physical (e.g., an 518 Ethernet interface) or virtual (e.g., the endpoint of a Frame 519 Relay virtual circuit or an IP-in-IP "tunnel"). An implementation 520 may allow a special "unspecified" value to be passed as the 521 interface parameter, in which case the request would apply to the 522 "primary" or "default" interface of the node (perhaps established 523 by system configuration). If reception of the same multicast 524 address is desired on more than one interface, IPv6MulticastListen 525 is invoked separately for each desired interface. 527 * "IPv6 multicast address" is the multicast address to which the 528 request pertains. If reception of more than one multicast address 529 on a given interface is desired, IPv6MulticastListen is invoked 530 separately for each desired address. 532 * "filter mode" may be either INCLUDE or EXCLUDE. In INCLUDE mode, 533 reception of packets sent to the specified multicast address is 534 requested only from the source addresses listed in the source list 535 parameter. In EXCLUDE mode, reception of packets sent to the 536 given multicast address is requested from all source addresses 537 except those listed in the source list parameter. 539 * "source list" is an unordered list of zero or more unicast 540 addresses from which multicast reception is desired or not 541 desired, depending on the filter mode. An implementation MAY 542 impose a limit on the size of source lists. When an operation 543 causes the source list size limit to be exceeded, the service 544 interface SHOULD return an error. 546 For a given combination of socket, interface, and IPv6 multicast 547 address, only a single filter mode and source list can be in effect 548 at any one time. Nevertheless, either the filter mode or the source 549 list, or both, may be changed by subsequent IPv6MulticastListen 550 requests that specify the same socket, interface, and IPv6 multicast 551 address. Each subsequent request completely replaces any earlier 552 request for the given socket, interface, and multicast address. 554 The MLDv1 protocol did not support source filters, and had a simpler 555 service interface; it consisted of Start Listening and Stop Listening 556 operations to enable and disable listening to a given multicast 557 address (from all sources) on a given interface. The equivalent 558 operations in the new service interface are as follows: 560 The Start Listening operation is equivalent to: 562 IPv6MulticastListen ( socket, interface, IPv6 multicast address, 563 EXCLUDE, {} ) 565 and the Stop Listening operation is equivalent to: 567 IPv6MulticastListen ( socket, interface, IPv6 multicast address, 568 INCLUDE, {} ) 570 where {} is an empty source list. 572 An example of an API that provides the capabilities outlined in this 573 service interface is given in [RFC3678]. 575 4. Multicast Listening State Maintained by Nodes 577 4.1. Per-Socket State 579 For each socket on which IPv6MulticastListen has been invoked, the 580 node records the desired multicast listening state for that socket. 581 That state conceptually consists of a set of records of the form: 583 (interface, IPv6 multicast address, filter mode, source list) 585 The per-socket state evolves in response to each invocation of 586 IPv6MulticastListen on the socket, as follows: 588 * If the requested filter mode is INCLUDE and the requested source 589 list is empty, then the entry that corresponds to the requested 590 interface and multicast address is deleted, if present. If no 591 such entry is present, the request has no effect. 593 * If the requested filter mode is EXCLUDE or the requested source 594 list is non-empty, then the entry that corresponds to the 595 requested interface and multicast address, if present, is changed 596 to contain the requested filter mode and source list. If no such 597 entry is present, a new entry is created, using the parameters 598 specified in the request. 600 4.2. Per-Interface State 602 In addition to the per-socket multicast listening state, a node must 603 also maintain or compute multicast listening state for each of its 604 interfaces. That state conceptually consists of a set of records of 605 the form: 607 (IPv6 multicast address, filter mode, source list) 609 At most one record per multicast address exists for a given 610 interface. This per-interface state is derived from the per-socket 611 state, but may differ from it when different sockets have differing 612 filter modes and/or source lists for the same multicast address and 613 interface. For example, suppose one application or process invokes 614 the following operation on socket s1: 616 IPv6MulticastListen ( s1, i, m, INCLUDE, {a, b, c} ) 618 requesting reception on interface i of packets sent to multicast 619 address m, only if they come from the sources a, b, or c. Suppose 620 another application or process invokes the following operation on 621 socket s2: 623 IPv6MulticastListen ( s2, i, m, INCLUDE, {b, c, d} ) 625 requesting reception on the same interface i of packets sent to the 626 same multicast address m, only if they come from sources b, c, or d. 627 In order to satisfy the reception requirements of both sockets, it is 628 necessary for interface i to receive packets sent to m from any one 629 of the sources a, b, c, or d. Thus, in this example, the listening 630 state of interface i for multicast address m has filter mode INCLUDE 631 and source list {a, b, c, d}. 633 After a multicast packet has been accepted from an interface by the 634 IP layer, its subsequent delivery to the application or process that 635 listens on a particular socket depends on the multicast listening 636 state of that socket (and possibly also on other conditions, such as 637 what transport-layer port the socket is bound to). So, in the above 638 example, if a packet arrives on interface i, destined to multicast 639 address m, with source address a, it may be delivered on socket s1 640 but not on socket s2. Note that MLDv2 messages are not subject to 641 source filtering and must always be processed by hosts and routers. 643 Requiring the filtering of packets based upon a socket's multicast 644 reception state is a new feature of this service interface. The 645 previous service interface described no filtering based upon 646 multicast listening state; rather, a Start Listening operation on a 647 socket simply caused the node to start to listen to a multicast 648 address on the given interface; packets sent to that multicast 649 address could be delivered to all sockets, whether they had started 650 to listen or not. 652 The general rules for deriving the per-interface state from the per- 653 socket state are as follows: for each distinct (interface, IPv6 654 multicast address) pair that appears in any per-socket state, a per- 655 interface record is created for that multicast address on that 656 interface. Considering all socket records that contain the same 657 (interface, IPv6 multicast address) pair, 659 * if any such record has a filter mode of EXCLUDE, then the filter 660 mode of the interface record is EXCLUDE, and the source list of 661 the interface record is the intersection of the source lists of 662 all socket records in EXCLUDE mode, minus those source addresses 663 that appear in any socket record in INCLUDE mode. For example, if 664 the socket records for multicast address m on interface i are: 666 from socket s1: ( i, m, EXCLUDE, {a, b, c, d} ) 668 from socket s2: ( i, m, EXCLUDE, {b, c, d, e} ) 670 from socket s3: ( i, m, INCLUDE, {d, e, f} ) 672 then the corresponding interface record on interface i is: 674 ( m, EXCLUDE, {b, c} ) 676 If a fourth socket is added, such as: 678 From socket s4: ( i, m, EXCLUDE, {} ) 680 then the interface record becomes: 682 ( m, EXCLUDE, {} ) 684 * if all such records have a filter mode of INCLUDE, then the filter 685 mode of the interface record is INCLUDE, and the source list of 686 the interface record is the union of the source lists of all the 687 socket records. For example, if the socket records for multicast 688 address m on interface i are: 690 from socket s1: ( i, m, INCLUDE, {a, b, c} ) 692 from socket s2: ( i, m, INCLUDE, {b, c, d} ) 694 from socket s3: ( i, m, INCLUDE, {e, f} ) 696 then the corresponding interface record on interface i is: 698 ( m, INCLUDE, {a, b, c, d, e, f} ) 700 An implementation MUST NOT use an EXCLUDE interface record for a 701 multicast address if all sockets for this multicast address are in 702 INCLUDE state. If system resource limits are reached when a per- 703 interface state source list is calculated, an error MUST be 704 returned to the application which requested the operation. 706 The above rules for deriving the per-interface state are 707 (re)evaluated whenever an IPv6MulticastListen invocation modifies the 708 per-socket state by adding, deleting, or modifying a per-socket state 709 record. Note that a change of the per-socket state does not 710 necessarily result in a change of the per-interface state. 712 5. Message Formats 714 MLDv2 is a sub-protocol of ICMPv6, that is, MLDv2 message types are a 715 subset of ICMPv6 messages, and MLDv2 messages are identified in IPv6 716 packets by a preceding Next Header value of 58. All MLDv2 messages 717 described in this document MUST be sent with a link-local IPv6 Source 718 Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option 719 [RFC2711] in a Hop-by-Hop Options header. (The Router Alert option 720 is necessary to cause routers to examine MLDv2 messages sent to IPv6 721 multicast addresses in which the routers themselves have no 722 interest.) MLDv2 Reports can be sent with the source address set to 723 the unspecified address [RFC3513], if a valid link-local IPv6 source 724 address has not been acquired yet for the sending interface. (See 725 Section 5.2.14. for details.) 727 There are two MLD message types of concern to the MLDv2 protocol 728 described in this document: 730 * Multicast Listener Query (Type = decimal 130) 731 * Version 2 Multicast Listener Report (Type = decimal 143). See 732 Section 11 for IANA considerations. 734 To assure the interoperability with nodes that implement MLDv1 (see 735 Section 8), an implementation of MLDv2 must also support the 736 following two message types: 738 * Version 1 Multicast Listener Report (Type = decimal 131) [RFC2710] 740 * Version 1 Multicast Listener Done (Type = decimal 132) [RFC2710] 742 Unrecognized message types MUST be silently ignored. Other message 743 types may be used by newer versions or extensions of MLD, by 744 multicast routing protocols, or for other uses. 746 In this document, unless otherwise qualified, the capitalized words 747 "Query" and "Report" refer to MLD Multicast Listener Queries and MLD 748 Version 2 Multicast Listener Reports, respectively. 750 5.1. Multicast Listener Query Message 752 Multicast Listener Queries are sent by multicast routers in Querier 753 State to query the multicast listening state of neighboring 754 interfaces. Queries have the following format: 756 0 1 2 3 757 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 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Type = 130 | Code | Checksum | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Maximum Response Code | Reserved | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | | 764 * * 765 | | 766 * Multicast Address * 767 | | 768 * * 769 | | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Flags |S| QRV | QQIC | Number of Sources (N) | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | | 774 * * 775 | | 776 * Source Address [1] * 777 | | 778 * * 779 | | 780 +- -+ 781 | | 782 * * 783 | | 784 * Source Address [2] * 785 | | 786 * * 787 | | 788 +- . -+ 789 . . . 790 . . . 791 +- -+ 792 | | 793 * * 794 | | 795 * Source Address [N] * 796 | | 797 * * 798 | | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 5.1.1. Code 803 Initialized to zero by the sender; ignored by receivers. 805 5.1.2. Checksum 807 The standard ICMPv6 checksum; it covers the entire MLDv2 message, 808 plus a "pseudo-header" of IPv6 header fields [RFC2463]. For 809 computing the checksum, the Checksum field is set to zero. When a 810 packet is received, the checksum MUST be verified before processing 811 it. 813 5.1.3. Maximum Response Code 815 The Maximum Response Code field specifies the maximum time allowed 816 before sending a responding Report. The actual time allowed, called 817 the Maximum Response Delay, is represented in units of milliseconds, 818 and is derived from the Maximum Response Code as follows: 820 If Maximum Response Code < 32768, Maximum Response Delay = Maximum 821 Response Code 823 If Maximum Response Code >=32768, Maximum Response Code represents a 824 floating-point value as follows: 826 0 1 2 3 4 5 6 7 8 9 A B C D E F 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 |1| exp | mant | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 Maximum Response Delay = (mant | 0x1000) << (exp+3) 833 Small values of Maximum Response Delay allow MLDv2 routers to tune 834 the "leave latency" (the time between the moment the last node on a 835 link ceases to listen to a specific multicast address and the moment 836 the routing protocol is notified that there are no more listeners for 837 that address). Larger values, especially in the exponential range, 838 allow the tuning of the burstiness of MLD traffic on a link. 840 5.1.4. Reserved 842 Initialized to zero by the sender; ignored by receivers. 844 5.1.5. Multicast Address 846 For a General Query, the Multicast Address field is set to zero. For 847 a Multicast Address Specific Query or Multicast Address and Source 848 Specific Query, it is set to the multicast address being queried (see 849 Section 5.1.10, below). 851 5.1.6. Flags 853 Allocation of individual bits within the Flags field is described in 854 [I-D.haberman-pim-3228bis]. 856 5.1.7. S Flag (Suppress Router-Side Processing) 858 When set to one, the S Flag indicates to any receiving multicast 859 routers that they have to suppress the normal timer updates they 860 perform upon hearing a Query. Nevertheless, it does not suppress the 861 querier election or the normal "host-side" processing of a Query that 862 a router may be required to perform as a consequence of itself being 863 a multicast listener. 865 5.1.8. QRV (Querier's Robustness Variable) 867 If non-zero, the QRV field contains the [Robustness Variable] value 868 used by the Querier. If the Querier's [Robustness Variable] exceeds 869 7 (the maximum value of the QRV field), the QRV field is set to zero. 871 Routers adopt the QRV value from the most recently received Query as 872 their own [Robustness Variable] value, unless that most recently 873 received QRV was zero, in which case they use the default [Robustness 874 Variable] value specified in Section 9.1, or a statically configured 875 value. 877 5.1.9. QQIC (Querier's Query Interval Code) 879 The Querier's Query Interval Code field specifies the [Query 880 Interval] used by the Querier. The actual interval, called the 881 Querier's Query Interval (QQI), is represented in units of seconds, 882 and is derived from the Querier's Query Interval Code as follows: 884 If QQIC < 128, QQI = QQIC 886 If QQIC >= 128, QQIC represents a floating-point value as follows: 888 0 1 2 3 4 5 6 7 889 +-+-+-+-+-+-+-+-+ 890 |1| exp | mant | 891 +-+-+-+-+-+-+-+-+ 893 QQI = (mant | 0x10) << (exp + 3) 895 Multicast routers that are not the current Querier adopt the QQI 896 value from the most recently received Query as their own [Query 897 Interval] value, unless that most recently received QQI was zero, in 898 which case the receiving routers use the default [Query Interval] 899 value specified in Section 9.2. 901 5.1.10. Number of Sources (N) 903 The Number of Sources (N) field specifies how many source addresses 904 are present in the Query. This number is zero in a General Query or 905 a Multicast Address Specific Query, and non-zero in a Multicast 906 Address and Source Specific Query. This number is limited by the MTU 907 of the link over which the Query is transmitted. For example, on an 908 Ethernet link with an MTU of 1500 octets, the IPv6 header (40 octets) 909 together with the Hop-By-Hop Extension Header (8 octets) that 910 includes the Router Alert option consume 48 octets; the MLD fields up 911 to the Number of Sources (N) field consume 28 octets; thus, there are 912 1424 octets left for source addresses, which limits the number of 913 source addresses to 89 (1424/16). 915 5.1.11. Source Address [i] 917 The Source Address [i] fields are a vector of n unicast addresses, 918 where n is the value in the Number of Sources (N) field. 920 5.1.12. Additional Data 922 If the Payload Length field in the IPv6 header of a received Query 923 indicates that there are additional octets of data present, beyond 924 the fields described here, MLDv2 implementations MUST include those 925 octets in the computation to verify the received MLD Checksum, but 926 MUST otherwise ignore those additional octets. When sending a Query, 927 an MLDv2 implementation MUST NOT include additional octets beyond the 928 fields described above. 930 5.1.13. Query Variants 932 There are three variants of the Query message: 934 * A "General Query" is sent by the Querier to learn which multicast 935 addresses have listeners on an attached link. In a General Query, 936 both the Multicast Address field and the Number of Sources (N) 937 field are zero. 939 * A "Multicast Address Specific Query" is sent by the Querier to 940 learn if a particular multicast address has any listeners on an 941 attached link. In a Multicast Address Specific Query, the 942 Multicast Address field contains the multicast address of 943 interest, while the Number of Sources (N) field is set to zero. 945 * A "Multicast Address and Source Specific Query" is sent by the 946 Querier to learn if any of the sources from the specified list for 947 the particular multicast address has any listeners on an attached 948 link or not. In a Multicast Address and Source Specific Query the 949 Multicast Address field contains the multicast address of 950 interest, while the Source Address [i] field(s) contain(s) the 951 source address(es) of interest. 953 5.1.14. Source Addresses for Queries 955 All MLDv2 Queries MUST be sent with a valid IPv6 link-local source 956 address. If a node (router or host) receives a Query message with 957 the IPv6 Source Address set to the unspecified address (::), or any 958 other address that is not a valid IPv6 link-local address, it MUST 959 silently discard the message and SHOULD log a warning. 961 5.1.15. Destination Addresses for Queries 963 In MLDv2, General Queries are sent to the link-scope all-nodes 964 multicast address (FF02::1). Multicast Address Specific and 965 Multicast Address and Source Specific Queries are sent with an IP 966 destination address equal to the multicast address of interest. 967 However, a node MUST accept and process any Query whose IP 968 Destination Address field contains any of the addresses (unicast or 969 multicast) assigned to the interface on which the Query arrives. 970 This might be useful, e.g., for debugging purposes. 972 5.2. Version 2 Multicast Listener Report Message 974 Version 2 Multicast Listener Reports are sent by IP nodes to report 975 (to neighboring routers) the current multicast listening state, or 976 changes in the multicast listening state, of their interfaces. 977 Reports have the following format: 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Type = 143 | Reserved | Checksum | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Flags |Nr of Mcast Address Records (M)| 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | | 987 . . 988 . Multicast Address Record [1] . 989 . . 990 | | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | | 993 . . 994 . Multicast Address Record [2] . 995 . . 996 | | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | . | 999 . . . 1000 | . | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | | 1003 . . 1004 . Multicast Address Record [M] . 1005 . . 1006 | | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 Each Multicast Address Record has the following internal format: 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | Record Type | Aux Data Len | Number of Sources (N) | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | | 1015 * * 1016 | | 1017 * Multicast Address * 1018 | | 1019 * * 1020 | | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | | 1023 * * 1024 | | 1025 * Source Address [1] * 1026 | | 1027 * * 1028 | | 1029 +- -+ 1030 | | 1031 * * 1032 | | 1033 * Source Address [2] * 1034 | | 1035 * * 1036 | | 1037 +- -+ 1038 . . . 1039 . . . 1040 . . . 1041 +- -+ 1042 | | 1043 * * 1044 | | 1045 * Source Address [N] * 1046 | | 1047 * * 1048 | | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | | 1051 . . 1052 . Auxiliary Data . 1053 . . 1054 | | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 5.2.1. Reserved 1059 The Reserved field are set to zero on transmission, and ignored on 1060 reception. 1062 5.2.2. Checksum 1064 The standard ICMPv6 checksum; it covers the entire MLDv2 message, 1065 plus a "pseudo-header" of IPv6 header fields [RFC2460][RFC2463]. In 1066 order to compute the checksum, the Checksum field is set to zero. 1067 When a packet is received, the checksum MUST be verified before 1068 processing it. 1070 5.2.3. Flags 1072 Allocation of individual bits within the Flags field is described in 1073 [I-D.haberman-pim-3228bis]. 1075 5.2.4. Nr of Mcast Address Records (M) 1077 The Nr of Mcast Address Records (M) field specifies how many 1078 Multicast Address Records are present in this Report. 1080 5.2.5. Multicast Address Record 1082 Each Multicast Address Record is a block of fields that contain 1083 information on the sender listening to a single multicast address on 1084 the interface from which the Report is sent. 1086 5.2.6. Record Type 1088 It specifies the type of the Multicast Address Record. See 1089 Section 5.2.13 for a detailed description of the different possible 1090 Record Types. 1092 5.2.7. Aux Data Len 1094 The Aux Data Len field contains the length of the Auxiliary Data 1095 Field in this Multicast Address Record, in units of 32-bit words. It 1096 may contain zero, to indicate the absence of any auxiliary data. 1098 5.2.8. Number of Sources (N) 1100 The Number of Sources (N) field specifies how many source addresses 1101 are present in this Multicast Address Record. 1103 5.2.9. Multicast Address 1105 The Multicast Address field contains the multicast address to which 1106 this Multicast Address Record pertains. 1108 5.2.10. Source Address [i] 1110 The Source Address [i] fields are a vector of n unicast addresses, 1111 where n is the value in this record's Number of Sources (N) field. 1113 5.2.11. Auxiliary Data 1115 The Auxiliary Data field, if present, contains additional information 1116 that pertain to this Multicast Address Record. The protocol 1117 specified in this document, MLDv2, does not define any auxiliary 1118 data. Therefore, implementations of MLDv2 MUST NOT include any 1119 auxiliary data (i.e., MUST set the Aux Data Len field to zero) in any 1120 transmitted Multicast Address Record, and MUST ignore any such data 1121 present in any received Multicast Address Record. The semantics and 1122 the internal encoding of the Auxiliary Data field are to be defined 1123 by any future version or extension of MLD that uses this field. 1125 5.2.12. Additional Data 1127 If the Payload Length field in the IPv6 header of a received Report 1128 indicates that there are additional octets of data present, beyond 1129 the last Multicast Address Record, MLDv2 implementations MUST include 1130 those octets in the computation to verify the received MLD Checksum, 1131 but MUST otherwise ignore those additional octets. When sending a 1132 Report, an MLDv2 implementation MUST NOT include additional octets 1133 beyond the last Multicast Address Record. 1135 5.2.13. Multicast Address Record Types 1137 There are a number of different types of Multicast Address Records 1138 that may be included in a Report message: 1140 * A "Current State Record" is sent by a node in response to a Query 1141 received on an interface. It reports the current listening state 1142 of that interface, with respect to a single multicast address. 1143 The Record Type of a Current State Record may be one of the 1144 following two values: 1146 1 - MODE_IS_INCLUDE - indicates that the interface has a filter 1147 mode of INCLUDE for the specified multicast address. The 1148 Source Address [i] fields in this Multicast Address Record 1149 contain the interface's source list for the specified 1150 multicast address. A MODE_IS_INCLUDE Record is never sent 1151 with an empty source list. 1153 2 - MODE_IS_EXCLUDE - indicates that the interface has a filter 1154 mode of EXCLUDE for the specified multicast address. The 1155 Source Address [i] fields in this Multicast Address Record 1156 contain the interface's source list for the specified 1157 multicast address, if it is non-empty. 1159 * A "Filter Mode Change Record" is sent by a node whenever a local 1160 invocation of IPv6MulticastListen causes a change of the filter 1161 mode (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to 1162 INCLUDE) of the interface-level state entry for a particular 1163 multicast address, whether the source list changes at the same 1164 time or not. The Record is included in a Report sent from the 1165 interface on which the change occurred. The Record Type of a 1166 Filter Mode Change Record may be one of the following two values: 1168 3 - CHANGE_TO_INCLUDE_MODE - indicates that the interface has 1169 changed to INCLUDE filter mode for the specified multicast 1170 address. The Source Address [i] fields in this Multicast 1171 Address Record contain the interface's new source list for 1172 the specified multicast address, if it is non-empty. 1174 4 - CHANGE_TO_EXCLUDE_MODE - indicates that the interface has 1175 changed to EXCLUDE filter mode for the specified multicast 1176 address. The Source Address [i] fields in this Multicast 1177 Address Record contain the interface's new source list for 1178 the specified multicast address, if it is non-empty. 1180 * A "Source List Change Record" is sent by a node whenever a local 1181 invocation of IPv6MulticastListen causes a change of source list 1182 that is not coincident with a change of filter mode, of the 1183 interface-level state entry for a particular multicast address. 1184 The Record is included in a Report sent from the interface on 1185 which the change occurred. The Record Type of a Source List 1186 Change Record may be one of the following two values: 1188 5 - ALLOW_NEW_SOURCES - indicates that the Source Address [i] 1189 fields in this Multicast Address Record contain a list of the 1190 additional sources that the node wishes to listen to, for 1191 packets sent to the specified multicast address. If the 1192 change was to an INCLUDE source list, these are the addresses 1193 that were added to the list; if the change was to an EXCLUDE 1194 source list, these are the addresses that were deleted from 1195 the list. 1197 6 - BLOCK_OLD_SOURCES - indicates that the Source Address [i] 1198 fields in this Multicast Address Record contain a list of the 1199 sources that the node no longer wishes to listen to, for 1200 packets sent to the specified multicast address. If the 1201 change was to an INCLUDE source list, these are the addresses 1202 that were deleted from the list; if the change was to an 1203 EXCLUDE source list, these are the addresses that were added 1204 to the list. 1206 If a change of source list results in both allowing new sources and 1207 blocking old sources, then two Multicast Address Records are sent for 1208 the same multicast address, one of type ALLOW_NEW_SOURCES and one of 1209 type BLOCK_OLD_SOURCES. 1211 We use the term "State Change Record" to refer to either a Filter 1212 Mode Change Record or a Source List Change Record. 1214 Multicast Address Records with an unrecognized Record Type value MUST 1215 be silently ignored, with the rest of the report being processed. 1217 In the rest of this document, we use the following notation to 1218 describe the contents of a Multicast Address Record that pertains to 1219 a particular multicast address: 1221 IS_IN ( x ) - Type MODE_IS_INCLUDE, source addresses x 1222 IS_EX ( x ) - Type MODE_IS_EXCLUDE, source addresses x 1223 TO_IN ( x ) - Type CHANGE_TO_INCLUDE_MODE, source addresses x 1224 TO_EX ( x ) - Type CHANGE_TO_EXCLUDE_MODE, source addresses x 1225 ALLOW ( x ) - Type ALLOW_NEW_SOURCES, source addresses x 1226 BLOCK ( x ) - Type BLOCK_OLD_SOURCES, source addresses x 1228 where x is either: 1230 * a capital letter (e.g., "A") to represent the set of source 1231 addresses, or 1233 * a set expression (e.g., "A+B"), where "A+B" means the union of 1234 sets A and B, "A*B" means the intersection of sets A and B, and 1235 "A-B" means the removal of all elements of set B from set A. 1237 5.2.14. Source Addresses for Reports 1239 An MLDv2 Report MUST be sent with a valid IPv6 link-local source 1240 address, or the unspecified address (::), if the sending interface 1241 has not acquired a valid link-local address yet. Sending reports 1242 with the unspecified address is allowed to support the use of IP 1243 multicast in the Neighbor Discovery Protocol [RFC2461]. For 1244 stateless autoconfiguration, as defined in [RFC2462], a node is 1245 required to join several IPv6 multicast groups, in order to perform 1246 Duplicate Address Detection (DAD). Prior to DAD, the only address 1247 the reporting node has for the sending interface is a tentative one, 1248 which cannot be used for communication. Thus, the unspecified 1249 address must be used. 1251 On the other hand, routers MUST silently discard a message that is 1252 not sent with a valid link-local address, without taking any action 1253 on the contents of the packet. Thus, a Report is discarded if the 1254 router cannot identify the source address of the packet as belonging 1255 to a link connected to the interface on which the packet was 1256 received. A Report sent with the unspecified address is also 1257 discarded by the router. This enhances security, as unidentified 1258 reporting nodes cannot influence the state of the MLDv2 router(s). 1259 Nevertheless, the reporting node has modified its listening state for 1260 multicast addresses that are contained in the Multicast Address 1261 Records of the Report message. From now on, it will treat packets 1262 sent to those multicast addresses according to this new listening 1263 state. Once a valid link-local address is available, a node SHOULD 1264 generate new MLDv2 Report messages for all multicast addresses joined 1265 on the interface. 1267 5.2.15. Destination Addresses for Reports 1269 Version 2 Multicast Listener Reports are sent with an IP destination 1270 address of FF02:0:0:0:0:0:0:16, to which all MLDv2-capable multicast 1271 routers listen (see Section 11 for IANA considerations related to 1272 this special destination address). A node that operates in version 1 1273 compatibility mode (see details in Section 8) sends version 1 Reports 1274 to the multicast address specified in the Multicast Address field of 1275 the Report. In addition, a node MUST accept and process any version 1276 1 Report whose IP Destination Address field contains any of the IPv6 1277 addresses (unicast or multicast) assigned to the interface on which 1278 the Report arrives. This might be useful, e.g., for debugging 1279 purposes. 1281 5.2.16. Multicast Listener Report Size 1283 If the set of Multicast Address Records required in a Report does not 1284 fit within the size limit of a single Report message (as determined 1285 by the MTU of the link on which it will be sent), the Multicast 1286 Address Records are sent in as many Report messages as needed to 1287 report the entire set. 1289 If a single Multicast Address Record contains so many source 1290 addresses that it does not fit within the size limit of a single 1291 Report message, then: 1293 * if its Type is not IS_EX or TO_EX, it is split into multiple 1294 Multicast Address Records; each such record contains a different 1295 subset of the source addresses, and is sent in a separate Report. 1297 * if its Type is IS_EX or TO_EX, a single Multicast Address Record 1298 is sent, with as many source addresses as can fit; the remaining 1299 source addresses are not reported. Although the choice of which 1300 sources to report is arbitrary, it is preferable to report the 1301 same set of sources in each subsequent report, rather than 1302 reporting different sources each time. 1304 6. Protocol Description for Multicast Address Listeners 1306 MLD is an asymmetric protocol, as it specifies separate behaviors for 1307 multicast address listeners -- that is, hosts or routers that listen 1308 to multicast packets -- and multicast routers. This section 1309 describes the part of MLDv2 that applies to all multicast address 1310 listeners. (Note that a multicast router that is also a multicast 1311 address listener performs both parts of MLDv2; it receives and it 1312 responds to its own MLD messages, as well as to those of its 1313 neighbors.) The multicast router part of MLDv2 is described in 1314 Section 7. 1316 A node performs the protocol described in this section over all 1317 interfaces on which multicast reception is supported, even if more 1318 than one of those interfaces are connected to the same link. 1320 For interoperability with multicast routers that run the MLDv1 1321 protocol, nodes maintain a Host Compatibility Mode variable for each 1322 interface on which multicast reception is supported. This section 1323 describes the behavior of multicast address listener nodes on 1324 interfaces for which Host Compatibility Mode = MLDv2. The algorithm 1325 for determining Host Compatibility Mode, and the behavior if its 1326 value is set to MLDv1, are described in Section 8. 1328 The link-scope all-nodes multicast address, (FF02::1), is handled as 1329 a special case. On all nodes -- that is all hosts and routers, 1330 including multicast routers -- listening to packets destined to the 1331 all-nodes multicast address, from all sources, is permanently enabled 1332 on all interfaces on which multicast listening is supported. No MLD 1333 messages are ever sent regarding neither the link-scope all-nodes 1334 multicast address, nor any multicast address of scope 0 (reserved) or 1335 1 (node-local). Multicast listeners MUST send MLD messages for all 1336 multicast addresses except for the link-scope all-nodes multicast 1337 address and any multicast addresses of scope less than 2. 1339 There are three types of events that trigger MLDv2 protocol actions 1340 on an interface: 1342 * a change of the per-interface listening state, caused by a local 1343 invocation of IPv6MulticastListen; 1345 * the firing of a specific timer; 1347 * the reception of a Query. 1349 (Received MLD messages of types other than Query are silently 1350 ignored, except as required for interoperation with nodes that 1351 implement MLDv1.) 1353 The following subsections describe the actions to be taken for each 1354 case. Timer and counter names appear in square brackets. Default 1355 values for those timers and counters are specified in Section 9. 1357 6.1. Action on Change of Per-Interface State 1359 An invocation of IPv6MulticastListen may cause the multicast 1360 listening state of an interface to change, according to the rules in 1361 Section 4.2. Each such change affects the per-interface entry for a 1362 single multicast address. 1364 A change of per-interface state causes the node to immediately 1365 transmit a State Change Report from that interface. The type and 1366 contents of the Multicast Address Record(s) in that Report are 1367 determined by comparing the filter mode and source list for the 1368 affected multicast address before and after the change, according to 1369 the table below. If no per-interface state existed for that 1370 multicast address before the change (i.e., the change consisted of 1371 creating a new per-interface record), or if no state exists after the 1372 change (i.e., the change consisted of deleting a per-interface 1373 record), then the "non-existent" state is considered to have an 1374 INCLUDE filter mode and an empty source list. 1376 +=============+=============+==========================+ 1377 | Old State | New State | State Change Record Sent | 1378 +=============+=============+==========================+ 1379 | INCLUDE (A) | INCLUDE (B) | ALLOW (B-A), BLOCK (A-B) | 1380 +-------------+-------------+--------------------------+ 1381 | EXCLUDE (A) | EXCLUDE (B) | ALLOW (A-B), BLOCK (B-A) | 1382 +-------------+-------------+--------------------------+ 1383 | INCLUDE (A) | EXCLUDE (B) | TO_EX (B) | 1384 +-------------+-------------+--------------------------+ 1385 | EXCLUDE (A) | INCLUDE (B) | TO_IN (B) | 1386 +-------------+-------------+--------------------------+ 1388 Table 1 1390 If the computed source list for either an ALLOW or a BLOCK State 1391 Change Record is empty, that record is omitted from the Report. 1393 To cover the possibility of the State Change Report being missed by 1394 one or more multicast routers, [Robustness Variable] - 1 1395 retransmissions are scheduled, through a Retransmission Timer, at 1396 intervals chosen at random from the range (0, [Unsolicited Report 1397 Interval]). 1399 If more changes to the same per-interface state entry occur before 1400 all the retransmissions of the State Change Report for the first 1401 change have been completed, each such additional change triggers the 1402 immediate transmission of a new State Change Report. 1404 The contents of the new Report are calculated as follows: 1406 * As for the first Report, the per-interface state for the affected 1407 multicast address before and after the latest change is compared. 1409 * The records that express the difference are built according to the 1410 table above. Nevertheless, these records are not transmitted in a 1411 separate message, but they are instead merged with the contents of 1412 the pending report, to create the new State Change Report. The 1413 rules for calculating this merged report are described below. 1415 The transmission of the merged State Change Report terminates 1416 retransmissions of the earlier State Change Reports for the same 1417 multicast address, and becomes the first of [Robustness Variable] 1418 transmissions of the new State Change Reports. These transmissions 1419 are necessary in order to ensure that each instance of state change 1420 is transmitted at least [Robustness Variable] times. 1422 Each time a source is included in the difference report calculated 1423 above, retransmission state for that source needs to be maintained 1424 until [Robustness Variable] State Change Reports have been sent by 1425 the node. This is done in order to ensure that a series of 1426 successive state changes do not break the protocol robustness. 1427 Sources in retransmission state can be kept in a per multicast 1428 address Retransmission List, with a Source Retransmission Counter 1429 associated to each source in the list. When a source is included in 1430 the list, its counter is set to [Robustness Variable]. Each time a 1431 State Change Report is sent the counter is decreased by one unit. 1432 When the counter reaches zero, the source is deleted from the 1433 Retransmission List for that multicast address. 1435 If the per-interface listening change that triggers the new report is 1436 a filter mode change, then the next [Robustness Variable] State 1437 Change Reports will include a Filter Mode Change Record. This 1438 applies even if any number of source list changes occur in that 1439 period. The node has to maintain retransmission state for the 1440 multicast address until the [Robustness Variable] State Change 1441 Reports have been sent. This can be done through a per multicast 1442 address Filter Mode Retransmission Counter. When the filter mode 1443 changes, the counter is set to [Robustness Variable]. Each time a 1444 State Change Report is sent the counter is decreased by one unit. 1445 When the counter reaches zero, i.e., [Robustness Variable] State 1446 Change Reports with Filter Mode Change Records have been transmitted 1447 after the last filter mode change, and if source list changes have 1448 resulted in additional reports being scheduled, then the next State 1449 Change Report will include Source List Change Records. 1451 Each time a per-interface listening state change triggers the 1452 Immediate transmission of a new State Change Report, its contents are 1453 determined as follows. If the report should contain a Filter Mode 1454 Change Record, i.e., the Filter Mode Retransmission Counter for that 1455 multicast address has a value higher than zero, then, if the current 1456 filter mode of the interface is INCLUDE, a TO_IN record is included 1457 in the report; otherwise a TO_EX record is included. If instead the 1458 report should contain Source List Change Records, i.e., the Filter 1459 Mode Retransmission Counter for that multicast address is zero, an 1460 ALLOW and a BLOCK record is included. The contents of these records 1461 are built according to the table below. 1463 +========+======================================================+ 1464 | Record | Sources Included | 1465 +========+======================================================+ 1466 | TO_IN | All in the current per-interface state that must be | 1467 | | forwarded | 1468 +--------+------------------------------------------------------+ 1469 | TO_EX | All in the current per-interface state that must be | 1470 | | blocked | 1471 +--------+------------------------------------------------------+ 1472 | ALLOW | All with retransmission state (i.e., all sources | 1473 | | from the Retransmission List) that must be forwarded | 1474 +--------+------------------------------------------------------+ 1475 | BLOCK | All with retransmission state that must be blocked | 1476 +--------+------------------------------------------------------+ 1478 Table 2 1480 If the computed source list for either an ALLOW or a BLOCK record is 1481 empty, that record is omitted from the State Change Report. 1483 Note: When the first State Change Report is sent, the non-existent 1484 pending report to merge with can be treated as a Source Change Report 1485 with empty ALLOW and BLOCK records (no sources have retransmission 1486 state). 1488 The building of a scheduled State Change Report, triggered by the 1489 firing of a Retransmission Timer, instead of a per-interface 1490 listening state change, is described in Section 6.3. 1492 6.2. Action on Reception of a Query 1494 Upon reception of an MLD message that contains a Query, the node 1495 checks if the source address of the message is a valid link-local 1496 address, if the Hop Limit is set to 1, and if the Router Alert option 1497 is present in the Hop-By-Hop Options header of the IPv6 packet. If 1498 any of these checks fails, the packet is dropped. 1500 If the validity of the MLD message is verified, the node starts to 1501 process the Query. Instead of responding immediately, the node 1502 delays its response by a random amount of time, bounded by the 1503 Maximum Response Delay value derived from the Maximum Response Code 1504 in the received Query message. A node may receive a variety of 1505 Queries on different interfaces and of different kinds (e.g., General 1506 Queries, Multicast Address Specific Queries, and Multicast Address 1507 and Source Specific Queries), each of which may require its own 1508 delayed response. 1510 Before scheduling a response to a Query, the node must first consider 1511 previously scheduled pending responses and, in many cases, schedule a 1512 combined response. Therefore, for each of its interfaces on which it 1513 operates the listener part of the MLDv2 protocol, the node must be 1514 able to maintain the following state: 1516 * an Interface Timer for scheduling responses to General Queries; 1518 * a Multicast Address Timer for scheduling responses to Multicast 1519 Address (and Source) Specific Queries, for each multicast address 1520 the node has to report on; 1522 * a per-multicast-address list of sources to be reported in response 1523 to a Multicast Address and Source Specific Query. 1525 When a new valid General Query arrives on an interface, the node 1526 checks whether it has any per-interface listening state record to 1527 report on, or not. Similarly, when a new valid Multicast Address 1528 (and Source) Specific Query arrives on an interface, the node checks 1529 whether it has a per-interface listening state record that 1530 corresponds to the queried multicast address (and source), or not. 1531 If it does, a delay for a response is randomly selected in the range 1532 (0, [Maximum Response Delay]), where Maximum Response Delay is 1533 derived from the Maximum Response Code inserted in the received Query 1534 message. The following rules are then used to determine if a Report 1535 needs to be scheduled or not, and the type of Report to schedule. 1536 (The rules are considered in order and only the first matching rule 1537 is applied.) 1539 1. If there is a pending response to a previous General Query 1540 scheduled sooner than the selected delay, no additional response 1541 needs to be scheduled. 1543 2. If the received Query is a General Query, the Interface Timer is 1544 used to schedule a response to the General Query after the 1545 selected delay. Any previously pending response to a General 1546 Query is canceled. 1548 3. If the received Query is a Multicast Address Specific Query or a 1549 Multicast Address and Source Specific Query and there is no 1550 pending response to a previous Query for this multicast address, 1551 then the Multicast Address Timer is used to schedule a report. 1552 If the received Query is a Multicast Address and Source Specific 1553 Query, the list of queried sources is recorded to be used when 1554 generating a response. 1556 4. If there is already a pending response to a previous Query 1557 scheduled for this multicast address, and either the new Query is 1558 a Multicast Address Specific Query or the recorded source list 1559 associated with the multicast address is empty, then the 1560 multicast address source list is cleared and a single response is 1561 scheduled, using the Multicast Address Timer. The new response 1562 is scheduled to be sent at the earliest of the remaining time for 1563 the pending report and the selected delay. 1565 5. If the received Query is a Multicast Address and Source Specific 1566 Query and there is a pending response for this multicast address 1567 with a non-empty source list, then the multicast address source 1568 list is augmented to contain the list of sources in the new 1569 Query, and a single response is scheduled using the Multicast 1570 Address Timer. The new response is scheduled to be sent at the 1571 earliest of the remaining time for the pending report and the 1572 selected delay. 1574 6.3. Action on Timer Expiration 1576 There are several timers that, upon expiration, trigger protocol 1577 actions on an MLDv2 Multicast Address Listener node. All these 1578 actions are related to pending reports scheduled by the node. 1580 1. If the expired timer is the Interface Timer (i.e., there is a 1581 pending response to a General Query), then one Current State 1582 Record is sent for each multicast address for which the specified 1583 interface has listening state, as described in Section 4.2. The 1584 Current State Record carries the multicast address and its 1585 associated filter mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and 1586 Source list. Multiple Current State Records are packed into 1587 individual Report messages, to the extent possible. 1589 This naive algorithm may result in bursts of packets when a node 1590 listens to a large number of multicast addresses. Instead of 1591 using a single Interface Timer, implementations are recommended 1592 to spread transmission of such Report messages over the interval 1593 (0, [Maximum Response Delay]). Note that any such implementation 1594 MUST avoid the "ack-implosion" problem, i.e., MUST NOT send a 1595 Report immediately upon reception of a General Query. 1597 2. If the expired timer is a Multicast Address Timer and the list of 1598 recorded sources for that multicast address is empty (i.e., there 1599 is a pending response to a Multicast Address Specific Query), 1600 then if, and only if, the interface has listening state for that 1601 multicast address, a single Current State Record is sent for that 1602 address. The Current State Record carries the multicast address 1603 and its associated filter mode (MODE_IS_INCLUDE or 1604 MODE_IS_EXCLUDE) and source list, if any. 1606 3. If the expired timer is a Multicast Address Timer and the list of 1607 recorded sources for that multicast address is non-empty (i.e., 1608 there is a pending response to a Multicast Address and Source 1609 Specific Query), then if, and only if, the interface has 1610 listening state for that multicast address, the contents of the 1611 corresponding Current State Record are determined from the per- 1612 interface state and the pending response record, as specified in 1613 the following table: 1615 +=====================+=========================+==============+ 1616 | per-interface state | set of sources in the | Current | 1617 | | pending response record | State Record | 1618 +=====================+=========================+==============+ 1619 | INCLUDE (A) | B | IS_IN (A*B) | 1620 +---------------------+-------------------------+--------------+ 1621 | EXCLUDE (A) | B | IS_IN (B-A) | 1622 +---------------------+-------------------------+--------------+ 1624 Table 3 1626 If the resulting Current State Record has an empty set of source 1627 addresses, then no response is sent. After the required Report 1628 messages have been generated, the source lists associated with any 1629 reported multicast addresses are cleared. 1631 4. If the expired timer is a Retransmission Timer for a multicast 1632 address (i.e., there is a pending State Change Report for that 1633 multicast address), the contents of the report are determined as 1634 follows. If the report should contain a Filter Mode Change 1635 Record, i.e., the Filter Mode Retransmission Counter for that 1636 multicast address has a value higher than zero, then, if the 1637 current filter mode of the interface is INCLUDE, a TO_IN record 1638 is included in the report; otherwise a TO_EX record is included. 1639 In both cases, the Filter Mode Retransmission Counter for that 1640 multicast address is decremented by one unit after the 1641 transmission of the report. 1643 If instead the report should contain Source List Change Records, 1644 i.e., the Filter Mode Retransmission Counter for that multicast 1645 address is zero, an ALLOW and a BLOCK record is included. The 1646 contents of these records are built according to the table below: 1648 +========+=====================================================+ 1649 | Record | Sources included | 1650 +========+=====================================================+ 1651 | TO_IN | All in the current per-interface state that must be | 1652 | | forwarded | 1653 +--------+-----------------------------------------------------+ 1654 | TO_EX | All in the current per-interface state that must be | 1655 | | blocked | 1656 +--------+-----------------------------------------------------+ 1657 | ALLOW | All with retransmission state (i.e., all sources | 1658 | | from the Retransmission List) that must be | 1659 | | forwarded. For each included source, its Source | 1660 | | Retransmission Counter is decreased with one unit | 1661 | | after the transmission of the report. If the | 1662 | | counter reaches zero, the source is deleted from | 1663 | | the Retransmission List for that multicast address. | 1664 +--------+-----------------------------------------------------+ 1665 | BLOCK | All with retransmission state (i.e., all sources | 1666 | | from the Retransmission List) that must be blocked. | 1667 | | For each included source, its Source Retransmission | 1668 | | Counter is decreased with one unit after the | 1669 | | transmission of the report. If the counter reaches | 1670 | | zero, the source is deleted from the Retransmission | 1671 | | List for that multicast address. | 1672 +--------+-----------------------------------------------------+ 1674 Table 4 1676 If the computed source list for either an ALLOW or a BLOCK record is 1677 empty, that record is omitted from the State Change Report. 1679 7. Description of the Protocol for Multicast Routers 1681 The purpose of MLD is to enable each multicast router to learn, for 1682 each of its directly attached links, which multicast addresses have 1683 listeners on that link. MLD version 2 adds the capability for a 1684 multicast router to also learn which sources have listeners among the 1685 neighboring nodes, for packets sent to any particular multicast 1686 address. The information gathered by MLD is provided to whichever 1687 multicast routing protocol is used by the router, in order to ensure 1688 that multicast packets are delivered to all links where there are 1689 interested listeners. 1691 This section describes the part of MLDv2 that is performed by 1692 multicast routers. Multicast routers may themselves become multicast 1693 address listeners, and therefore also perform the multicast listener 1694 part of MLDv2, described in Section 6. 1696 A multicast router performs the protocol described in this section 1697 over each of its directly attached links. If a multicast router has 1698 more than one interface to the same link, it only needs to operate 1699 this protocol over one of those interfaces. 1701 For each interface over which the router operates the MLD protocol, 1702 the router must configure that interface to listen to all link-layer 1703 multicast addresses that can be generated by IPv6 multicasts. For 1704 example, an Ethernet-attached router must set its Ethernet address 1705 reception filter to accept all Ethernet multicast addresses that 1706 start with the hexadecimal value 3333 [RFC2464]; in the case of an 1707 Ethernet interface that does not support the filtering of such a 1708 multicast address range, it must be configured to accept ALL Ethernet 1709 multicast addresses, in order to meet the requirements of MLD. 1711 On each interface over which this protocol is being run, the router 1712 MUST enable reception of the link-scope "all MLDv2-capable routers" 1713 multicast address from all sources, and MUST perform the multicast 1714 address listener part of MLDv2 for that address on that interface. 1716 Multicast routers only need to know that at least one node on an 1717 attached link listens to packets for a particular multicast address 1718 from a particular source; a multicast router is not required to 1719 individually keep track of the interests of each neighboring node. 1720 (Nevertheless, see Appendix A.2 item 1 for discussion.) 1722 MLDv2 is backward compatible with the MLDv1 protocol. For a detailed 1723 description of compatibility issues see Section 8. 1725 7.1. Conditions for MLD Queries 1727 The behavior of a router that implements the MLDv2 protocol depends 1728 on whether there are several multicast routers on the same subnet, or 1729 not. If it is the case, a querier election mechanism (described in 1730 Section 7.6.2) is used to elect a single multicast router to be in 1731 Querier state. All the multicast routers on the subnet listen to the 1732 messages sent by multicast address listeners, and maintain the same 1733 multicast listening information state, so that they can quickly and 1734 correctly take over the querier functionality, should the present 1735 Querier fail. Nevertheless, it is only the Querier that sends 1736 periodical or triggered query messages on the subnet. 1738 The Querier periodically sends General Queries to request Multicast 1739 Address Listener information from an attached link. These queries 1740 are used to build and refresh the Multicast Address Listener state of 1741 routers on attached links. 1743 Nodes respond to these queries by reporting their Multicast Address 1744 Listening state (and set of sources they listen to) with Current 1745 State Multicast Address Records in MLDv2 Multicast Listener Reports. 1747 As a listener of a multicast address, a node may express interest in 1748 listening or not listening to traffic from particular sources. As 1749 the desired listening state of a node changes, it reports these 1750 changes using Filter Mode Change Records or Source List Change 1751 Records. These records indicate an explicit state change in a 1752 multicast address at a node in either the Multicast Address Record's 1753 source list or its filter mode. When Multicast Address Listening is 1754 terminated at a node or traffic from a particular source is no longer 1755 desired, the Querier must query for other listeners of the multicast 1756 address or of the source before deleting the multicast address (or 1757 source) from its Multicast Address Listener state and pruning its 1758 traffic. 1760 To enable all nodes on a link to respond to changes in multicast 1761 address listening, the Querier sends specific queries. A Multicast 1762 Address Specific Query is sent to verify that there are no nodes that 1763 listen to the specified multicast address or to "rebuild" the 1764 listening state for a particular multicast address. Multicast 1765 Address Specific Queries are sent when the Querier receives a State 1766 Change Record indicating that a node ceases to listen to a multicast 1767 address. They are also sent in order to enable a fast transition of 1768 a router from EXCLUDE to INCLUDE mode, in case a received State 1769 Change Record motivates this action. 1771 A Multicast Address and Source Specific Query is used to verify that 1772 there are no nodes on a link which listen to traffic from a specific 1773 set of sources. Multicast Address and Source Specific Queries list 1774 sources for a particular multicast address which have been requested 1775 to no longer be forwarded. This query is sent by the Querier in 1776 order to learn if any node listens to packets sent to the specified 1777 multicast address, from the specified source addresses. Multicast 1778 Address and Source Specific Queries are only sent in response to 1779 State Change Records and never in response to Current State Records. 1780 Section 5.1.13 describes each query in more detail. 1782 7.2. MLD State Maintained by Multicast Routers 1784 Multicast routers that implement the MLDv2 protocol keep state per 1785 multicast address per attached link. This multicast address state 1786 consists of a filter mode, a list of sources, and various timers. 1787 For each attached link on which MLD runs, a multicast router records 1788 the listening state for that link. That state conceptually consists 1789 of a set of records of the form: 1791 (IPv6 multicast address, Filter Timer, 1792 Router Filter Mode, (source records) ) 1794 Each source record is of the form: 1796 (IPv6 source address, source timer) 1798 If all sources for a multicast address are listened to, an empty 1799 source record list is kept with the Router Filter Mode set to 1800 EXCLUDE. This means that nodes on this link want all sources for 1801 this multicast address to be forwarded. This is the MLDv2 equivalent 1802 of an MLDv1 listening state. 1804 7.2.1. Definition of Router Filter Mode 1806 To reduce internal state, MLDv2 routers keep a filter mode per 1807 multicast address per attached link. This filter mode is used to 1808 summarize the total listening state of a multicast address to a 1809 minimum set such that all nodes' listening states are respected. The 1810 filter mode may change in response to the reception of particular 1811 types of Multicast Address Records or when certain timer conditions 1812 occur. In the following sections, we use the term "Router Filter 1813 Mode" to refer to the filter mode of a particular multicast address 1814 within a router. Section 7.4 describes the changes of the Router 1815 Filter Mode per Multicast Address Record received. 1817 A router is in INCLUDE mode for a specific multicast address on a 1818 given interface if all the listeners on the link interested in that 1819 address are in INCLUDE mode. The router state is represented through 1820 the notation INCLUDE (A), where A is called the "Include List". The 1821 Include List is the set of sources that one or more listeners on the 1822 link have requested to receive. All the sources from the Include 1823 List will be forwarded by the router. Any other source that is not 1824 in the Include List will be blocked by the router. 1826 A router is in EXCLUDE mode for a specific multicast address on a 1827 given interface if there is at least one listener in EXCLUDE mode 1828 interested in that address on the link. Conceptually, when a 1829 Multicast Address Record is received, the Router Filter Mode for that 1830 multicast address is updated to cover all the requested sources using 1831 the least amount of state. As a rule, once a Multicast Address 1832 Record with a filter mode of EXCLUDE is received, the Router Filter 1833 Mode for that multicast address will be set to EXCLUDE. 1834 Nevertheless, if all nodes with a multicast address record having 1835 filter mode set to EXCLUDE cease reporting, it is desirable for the 1836 Router Filter Mode for that multicast address to transition back to 1837 INCLUDE mode. This transition occurs when the Filter Timer expires, 1838 and is explained in detail in Section 7.5. 1840 When the router is in EXCLUDE mode, the router state is represented 1841 through the notation EXCLUDE (X,Y), where X is called the "Requested 1842 List" and Y is called the "Exclude List". All sources, except those 1843 from the Exclude List, will be forwarded by the router. The 1844 Requested List has no effect on forwarding. Nevertheless, it has to 1845 be maintained for several reasons, as explained in Section 7.2.3. 1847 The exact handling of both the INCLUDE and EXCLUDE mode router state, 1848 according to the received reports, is presented in details in 1849 Section 7.4.1 and Section 7.4.2. 1851 7.2.2. Definition of Filter Timers 1853 The Filter Timer is only used when the router is in EXCLUDE mode for 1854 a specific multicast address, and it represents the time for the 1855 Router Filter Mode of the multicast address to expire and switch to 1856 INCLUDE mode. A Filter Timer is a decrementing timer with a lower 1857 bound of zero. One Filter Timer exists per multicast address record. 1858 Filter Timers are updated according to the types of Multicast Address 1859 Records received. 1861 If a Filter Timer expires, with the Router Filter Mode for that 1862 multicast address being EXCLUDE, it means that there are no more 1863 listeners in EXCLUDE mode on the attached link. At this point, the 1864 router transitions to INCLUDE filter mode. Section 7.5 describes the 1865 actions taken when a Filter Timer expires while in EXCLUDE mode. 1867 The following table summarizes the role of the Filter Timer. 1868 Section 7.4 describes the details of setting the Filter Timer per 1869 type of Multicast Address Record received. 1871 +=========+========+================================================+ 1872 | Router | Filter | Actions/Comments | 1873 | Filter | Timer | | 1874 | Mode | Value | | 1875 +=========+========+================================================+ 1876 | INCLUDE | Not | All listeners in INCLUDE mode. | 1877 | | Used | | 1878 +---------+--------+------------------------------------------------+ 1879 | EXCLUDE | Timer | At least one listener in EXCLUDE mode. | 1880 | | > 0 | | 1881 +---------+--------+------------------------------------------------+ 1882 | EXCLUDE | Timer | No more listeners in EXCLUDE mode for | 1883 | | == 0 | the multicast address. If the Requested | 1884 | | | List is empty, delete Multicast Address | 1885 | | | Record. If not, switch to INCLUDE | 1886 | | | filter mode; the sources in the | 1887 | | | Requested List are moved to the Include | 1888 | | | List, and the Exclude List is deleted. | 1889 +---------+--------+------------------------------------------------+ 1891 Table 5 1893 7.2.3. Definition of Source Timers 1895 A Source Timer is a decrementing timer with a lower bound of zero. 1896 One Source Timer is kept per source record. Source timers are 1897 updated according to the type and filter mode of the Multicast 1898 Address Record received. Section 7.4 describes the setting of source 1899 timers per type of Multicast Address Records received. 1901 In the following, abbreviations are used for several variables (all 1902 of which are described in detail in Section 9). The variable MALI 1903 stands for the Multicast Address Listening Interval, which is the 1904 time in which multicast address listening state will time out. The 1905 variable LLQT is the Last Listener Query Time, which is the total 1906 time the router should wait for a report, after the Querier has sent 1907 the first query. During this time, the Querier should send [Last 1908 Member Query Count]-1 retransmissions of the query. LLQT represents 1909 the "leave latency", or the difference between the transmission of a 1910 listener state change and the modification of the information passed 1911 to the routing protocol. 1913 If the router is in INCLUDE filter mode, a source can be added to the 1914 current Include List if a listener in INCLUDE mode sends a Current 1915 State or a State Change Report which includes that source. Each 1916 source from the Include List is associated with a source timer that 1917 is updated whenever a listener in INCLUDE mode sends a report that 1918 confirms its interest in that specific source. If the timer of a 1919 source from the Include List expires, the source is deleted from the 1920 Include List. If there are no more source records left, the 1921 multicast address record is deleted from the router. 1923 Besides this "soft leave" mechanism, there is also a "fast leave" 1924 scheme in MLDv2; it is also based on the use of source timers. When 1925 a node in INCLUDE mode expresses its desire to stop listening to a 1926 specific source, all the multicast routers on the link lower their 1927 timer for that source to a small interval of LLQT milliseconds. The 1928 Querier then sends then a Multicast Address and Source Specific 1929 Query, to verify whether there are other listeners for that source on 1930 the link, or not. If a corresponding report is received before the 1931 timer expires, all the multicast routers on the link update their 1932 source timer. If not, the source is deleted from the Include List. 1933 The handling of the Include List, according to the received reports, 1934 is detailed in Section 7.4.1 and Section 7.4.2. 1936 Source timers are treated differently when the Router Filter Mode for 1937 a multicast address is EXCLUDE. For sources from the Requested List 1938 the source timers have running values; these sources are forwarded by 1939 the router. For sources from the Exclude List the source timers are 1940 set to zero; these sources are blocked by the router. If the timer 1941 of a source from the Requested List expires, the source is moved to 1942 the Exclude List. The router informs then the routing protocol that 1943 there is no longer a listener on the link interested in traffic from 1944 this source. 1946 The router has to maintain the Requested List for two reasons: 1948 * To keep track of sources that listeners in INCLUDE mode listen to. 1949 This is necessary in order to assure a seamless transition of the 1950 router to INCLUDE mode, when there will be no listener in EXCLUDE 1951 mode left. This transition should not interrupt the flow of 1952 traffic to the listeners in INCLUDE mode still interested in that 1953 multicast address. Therefore, at the moment of the transition, 1954 the Requested List should represent the set of sources that nodes 1955 in INCLUDE mode have explicitly requested. 1957 When the router switches to INCLUDE mode, the sources in the 1958 Requested List are moved to the Include List, and the Exclude List 1959 is deleted. Before the switch, the Requested List can contain an 1960 inexact guess at the sources that listeners in INCLUDE mode listen 1961 to - might be too large or too small. These inexactitudes are due 1962 to the fact that the Requested List is also used for fast blocking 1963 purposes, as described below. If such a fast blocking is 1964 required, some sources may be deleted from the Requested List (as 1965 shown in Section 7.4.1 and Section 7.4.2) in order to reduce 1966 router state. Nevertheless, in each such case the Filter Timer is 1967 updated as well. Therefore, listeners in INCLUDE mode will have 1968 enough time, before an eventual switching, to reconfirm their 1969 interest in the eliminated source(s), and rebuild the Requested 1970 List accordingly. The protocol ensures that when a switch to 1971 INCLUDE mode occurs, the Requested List will be accurate. Details 1972 about the transition of the router to INCLUDE mode are presented 1973 in Appendix A.3. 1975 * To allow a fast blocking of previously unblocked sources. If the 1976 router receives a report that contains such a request, the 1977 concerned sources are added to the Requested List. Their timers 1978 are set to a small interval of LLQT milliseconds, and a Multicast 1979 Address and Source Specific Query is sent by the Querier, to check 1980 whether there are nodes on the link still interested in those 1981 sources, or not. If no node confirms its interest in receiving a 1982 specific source, the timer of that source expires. Then, the 1983 source is moved from the Requested List to the Exclude List. From 1984 then on, the source will be blocked by the router. 1986 The handling of the EXCLUDE mode router state, according to the 1987 received reports, is detailed in Section 7.4.1 and Section 7.4.2. 1989 When the Router Filter Mode for a multicast address is EXCLUDE, 1990 source records are only deleted when the Filter Timer expires, or 1991 when newly received Multicast Address Records modify the source 1992 record list of the router. 1994 7.3. MLDv2 Source Specific Forwarding Rules 1996 When a multicast router receives a datagram from a source destined to 1997 a particular multicast address, a decision has to be made whether to 1998 forward the datagram on an attached link or not. The multicast 1999 routing protocol in use is in charge of this decision, and should use 2000 the MLDv2 information to ensure that all sources/multicast addresses 2001 that have listeners on a link are forwarded to that link. MLDv2 2002 information does not override multicast routing information; for 2003 example, if the MLDv2 filter mode for a multicast address is EXCLUDE, 2004 a router may still forward packets for excluded sources to a transit 2005 link. 2007 To summarize, the following table describes the forwarding 2008 suggestions made by MLDv2 to the routing protocol for traffic 2009 originating from a source destined to a multicast address. It also 2010 summarizes the actions taken upon the expiration of a source timer 2011 based on the Router Filter Mode of the multicast address. 2013 +=========+=========+=======================================+ 2014 | Router | Source | Action | 2015 | Filter | Timer | | 2016 | Mode | Value | | 2017 +=========+=========+=======================================+ 2018 | INCLUDE | TIMER > | Suggest to forward traffic from | 2019 | | 0 | source | 2020 +---------+---------+---------------------------------------+ 2021 | INCLUDE | TIMER | Suggest to stop forwarding traffic | 2022 | | == 0 | from source and remove source record. | 2023 | | | If there are no more source records, | 2024 | | | delete multicast address record | 2025 +---------+---------+---------------------------------------+ 2026 | EXCLUDE | TIMER > | Suggest to forward traffic from | 2027 | | 0 | source | 2028 +---------+---------+---------------------------------------+ 2029 | EXCLUDE | TIMER | Suggest to not forward traffic from | 2030 | | == 0 | source. Move the source from the | 2031 | | | Requested List to the Exclude List | 2032 | | | (DO NOT remove source record) | 2033 +---------+---------+---------------------------------------+ 2034 | EXCLUDE | No | Suggest to forward traffic from all | 2035 | | Source | sources | 2036 | | Element | | 2037 +---------+---------+---------------------------------------+ 2039 Table 6 2041 7.4. Action on Reception of Reports 2043 Upon reception of an MLD message that contains a Report, the router 2044 checks if the source address of the message is a valid link-local 2045 address, if the Hop Limit is set to 1, and if the Router Alert option 2046 is present in the Hop-By-Hop Options header of the IPv6 packet. If 2047 any of these checks fails, the packet is dropped. If the validity of 2048 the MLD message is verified, the router starts to process the Report. 2050 7.4.1. Reception of Current State Records 2052 When receiving Current State Records, a router updates both its 2053 Filter Timer and its source timers. In some circumstances, the 2054 reception of a type of multicast address record will cause the Router 2055 Filter Mode for that multicast address to change. The table below 2056 describes the actions, with respect to state and timers, that occur 2057 to a router's state upon reception of Current State Records. 2059 If the router is in INCLUDE filter mode for a multicast address, we 2060 will use the notation INCLUDE (A), where A denotes the associated 2061 Include List. If the router is in EXCLUDE filter mode for a 2062 multicast address, we will use the notation EXCLUDE (X,Y), where X 2063 and Y denote the associated Requested List and Exclude List 2064 respectively. 2066 Within the "Actions" section of the router state tables, we use the 2067 notation '(A)=J', which means that the set A of source records should 2068 have their source timers set to value J. 'Delete (A)' means that the 2069 set A of source records should be deleted. 'Filter Timer = J' means 2070 that the Filter Timer for the multicast address should be set to 2071 value J. 2073 Router State Report Received New Router State Actions 2074 ------------ --------------- ---------------- ------- 2076 INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B)=MALI 2078 INCLUDE (A) IS_EX (B) EXCLUDE (A*B, B-A) (B-A)=0 2079 Delete (A-B) 2080 Filter Timer=MALI 2082 EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+A, Y-A) (A)=MALI 2084 EXCLUDE (X,Y) IS_EX (A) EXCLUDE (A-Y, Y*A) (A-X-Y)=MALI 2085 Delete (X-A) 2086 Delete (Y-A) 2087 Filter Timer=MALI 2089 7.4.2. Reception of Filter Mode Change and Source List Change Records 2091 When a change in the global state of a multicast address occurs in a 2092 node, the node sends either a Source List Change Record or a Filter 2093 Mode Change Record for that multicast address. As with Current State 2094 Records, routers must act upon these records and possibly change 2095 their own state to reflect the new listening state of the link. 2097 The Querier must query sources or multicast addresses that are 2098 requested to be no longer forwarded. When a router queries or 2099 receives a query for a specific set of sources, it lowers its source 2100 timers for those sources to a small interval of Last Listener Query 2101 Time milliseconds. If multicast address records are received in 2102 response to the queries which express interest in listening the 2103 queried sources, the corresponding timers are updated. 2105 Multicast Address Specific queries can also be used in order to 2106 enable a fast transition of a router from EXCLUDE to INCLUDE mode, in 2107 case a received Multicast Address Record motivates this action. The 2108 Filter Timer for that multicast address is lowered to a small 2109 interval of Last Listener Query Time milliseconds. If any multicast 2110 address records that express EXCLUDE mode interest in the multicast 2111 address are received within this interval, the Filter Timer is 2112 updated and the suggestion to the routing protocol to forward the 2113 multicast address stands without any interruption. If not, the 2114 router will switch to INCLUDE filter mode for that multicast address. 2116 During the query period (i.e., Last Listener Query Time milliseconds) 2117 the MLD component in the router continues to suggest to the routing 2118 protocol to forward traffic from the multicast addresses or sources 2119 that are queried. It is not until after Last Listener Query Time 2120 milliseconds without receiving a record that expresses interest in 2121 the queried multicast address or sources that the router may prune 2122 the multicast address or sources from the link. 2124 The following table describes the changes in multicast address state 2125 and the action(s) taken when receiving either Filter Mode Change or 2126 Source List Change Records. This table also describes the queries 2127 which are sent by the Querier when a particular report is received. 2129 We use the following notation for describing the queries that are 2130 sent. We use the notation 'Q(MA)' to describe a Multicast Address 2131 Specific Query to the MA multicast address. We use the notation 2132 'Q(MA,A)' to describe a Multicast Address and Source Specific Query 2133 to the MA multicast address with source list A. If source list A is 2134 null as a result of the action (e.g. A*B), then no query is sent as 2135 a result of the operation. 2137 In order to maintain protocol robustness, queries defined in the 2138 Actions column of the table below need to be transmitted [Last 2139 Listener Query Count] times, once every [Last Listener Query 2140 Interval] period. 2142 If while scheduling new queries, there are already pending queries to 2143 be retransmitted for the same multicast address, the new and pending 2144 queries have to be merged. In addition, received host reports for a 2145 multicast address with pending queries may affect the contents of 2146 those queries. Section 7.6.3 describes the process of building and 2147 maintaining the state of pending queries. 2149 Router State Report Received New Router State Actions 2150 ------------ --------------- ---------------- ------- 2151 INCLUDE (A) ALLOW (B) INCLUDE(A+B) (B)=MALI 2153 INCLUDE (A) BLOCK (B) INCLUDE(A) Send Q(MA,A*B) 2155 INCLUDE (A) TO_EX (B) EXCLUDE(A*B,B-A) (B-A)=0 2156 Delete (A-B) 2157 Send Q(MA,A*B) 2158 Filter Timer=MALI 2160 INCLUDE (A) TO_IN (B) INCLUDE(A+B) (B)=MALI 2161 Send Q(MA,A-B) 2163 EXCLUDE (X,Y) ALLOW (A) EXCLUDE(X+A,Y-A) (A)=MALI 2165 EXCLUDE (X,Y) BLOCK (A) EXCLUDE(X+(A-Y),Y) (A-X-Y)=Filter Timer 2166 Send Q(MA,A-Y) 2168 EXCLUDE (X,Y) TO_EX (A) EXCLUDE(A-Y,Y*A) (A-X-Y)=Filter Timer 2169 Delete (X-A) 2170 Delete (Y-A) 2171 Send Q(MA,A-Y) 2172 Filter Timer=MALI 2174 EXCLUDE (X,Y) TO_IN (A) EXCLUDE(X+A,Y-A) (A)=MALI 2175 Send Q(MA,X-A) 2176 Send Q(MA) 2178 7.5. Switching Router Filter Modes 2180 The Filter Timer is used as a mechanism for transitioning the Router 2181 Filter Mode from EXCLUDE to INCLUDE. 2183 When a Filter Timer expires with a Router Filter Mode of EXCLUDE, a 2184 router assumes that there are no nodes with a filter mode of EXCLUDE 2185 present on the attached link. Thus, the router transitions to 2186 INCLUDE filter mode for the multicast address. 2188 A router uses the sources from the Requested List as its state for 2189 the switch to a filter mode of INCLUDE. Sources from the Requested 2190 List are moved in the Include List, while sources from the Exclude 2191 List are deleted. For example, if a router's state for a multicast 2192 address is EXCLUDE(X,Y) and the Filter Timer expires for that 2193 multicast address, the router switches to filter mode of INCLUDE with 2194 state INCLUDE(X). If at the moment of the switch the Requested List 2195 (X) is empty, the multicast address record is deleted from the 2196 router. 2198 7.6. Action on Reception of Queries 2200 Upon reception of an MLD message that contains a Query, the router 2201 checks if the source address of the message is a valid link-local 2202 address, if the Hop Limit is set to 1, and if the Router Alert option 2203 is present in the Hop-By-Hop Options header of the IPv6 packet. If 2204 any of these checks fails, the packet is dropped. 2206 If the validity of the MLD message is verified, the router starts to 2207 process the Query. 2209 7.6.1. Timer Updates 2211 MLDv2 uses the Suppress Router-Side Processing flag to ensure 2212 robustness, as explained in Section 2.1. When a router sends or 2213 receives a query with a clear Suppress Router-Side Processing flag, 2214 it must update its timers to reflect the correct timeout values for 2215 the multicast address or sources being queried. The following table 2216 describes the timer actions when sending or receiving a Multicast 2217 Address Specific or Multicast Address and Source Specific Query with 2218 the Suppress Router-Side Processing flag not set. 2220 Query Action 2221 ----- ------ 2222 Q(MA,A) Source Timers for sources in A are lowered to LLQT 2223 Q(MA) Filter Timer is lowered to LLQT 2225 When a router sends or receives a query with the Suppress Router-Side 2226 Processing flag set, it will not update its timers. 2228 7.6.2. Querier Election 2230 MLDv2 elects a single router per subnet to be in Querier state; all 2231 the other routers on the subnet should be in Non-Querier state. 2232 MLDv2 uses the same querier election mechanism as MLDv1, namely the 2233 IPv6 address. When a router starts operating on a subnet, by default 2234 it considers itself as being the Querier. Thus, it sends several 2235 General Queries separated by a small time interval (see Section 9.6 2236 and Section 9.7 for details). 2238 When a router receives a query with a lower IPv6 address than its 2239 own, it sets the Other Querier Present timer to Other Querier Present 2240 Timeout; if it was previously in Querier state, it switches to Non- 2241 Querier state and ceases to send queries on the link. After the 2242 Other Querier Present timer expires, it should re-enter the Querier 2243 state and begin sending General Queries. 2245 All MLDv2 queries MUST be sent with the FE80::/64 link-local source 2246 address prefix. Therefore, for the purpose of MLDv2 querier 2247 election, an IPv6 address A is considered to be lower than an IPv6 2248 address B if the interface ID represented by the last 64 bits of 2249 address A, in big-endian bit order, is lower than the interface ID 2250 represented by the last 64 bits of address B. 2252 7.6.3. Building and Sending Specific Queries 2254 7.6.3.1. Building and Sending Multicast Address Specific Queries 2256 When a table action "Send Q(MA)" is encountered, the Filter Timer 2257 must be lowered to LLQT. The Querier must then immediately send a 2258 Multicast Address Specific query as well as schedule [Last Listener 2259 Query Count - 1] query retransmissions to be sent every [Last 2260 Listener Query Interval], over [Last Listener Query Time]. 2262 When transmitting a Multicast Address Specific Query, if the Filter 2263 Timer is larger than LLQT, the "Suppress Router-Side Processing" bit 2264 is set in the query message. 2266 7.6.3.2. Building and Sending Multicast Address and Source Specific 2267 Queries 2269 When a table action "Send Q(MA,X)" is encountered by the Querier in 2270 the table in Section 7.4.2, the following actions must be performed 2271 for each of the sources in X that send to multicast address MA, with 2272 source timer larger than LLQT: 2274 * Lower source timer to LLQT; 2276 * Add the sources to the Retransmission List; 2278 * Set the Source Retransmission Counter for each source to [Last 2279 Listener Query Count]. 2281 The Querier must then immediately send a Multicast Address and Source 2282 Specific Query as well as schedule [Last Listener Query Count -1] 2283 query retransmissions to be sent every [Last Listener Query 2284 Interval], over [Last Listener Query Time]. The contents of these 2285 queries are calculated as follows. 2287 When building a Multicast Address and Source Specific Query for a 2288 multicast address MA, two separate query messages are sent for the 2289 multicast address. The first one has the "Suppress Router-Side 2290 Processing" bit set and contains all the sources with retransmission 2291 state (i.e., sources from the Retransmission List of that multicast 2292 address), and timers greater than LLQT. The second has the "Suppress 2293 Router-Side Processing" bit clear and contains all the sources with 2294 retransmission state and timers lower or equal to LLQT. If either of 2295 the two calculated messages does not contain any sources, then its 2296 transmission is suppressed. 2298 Note: If a Multicast Address Specific query is scheduled to be 2299 transmitted at the same time as a Multicast Address and Source 2300 specific query for the same multicast address, then transmission of 2301 the Multicast Address and Source Specific message with the "Suppress 2302 Router-Side Processing" bit set may be suppressed. 2304 8. Interoperation with MLDv1 2306 MLD version 2 hosts and routers interoperate with hosts and routers 2307 that have not yet been upgraded to MLDv2. This compatibility is 2308 maintained by hosts and routers taking appropriate actions depending 2309 on the versions of MLD operating on hosts and routers within a 2310 network. 2312 8.1. Query Version Distinctions 2314 The MLD version of a Multicast Listener Query message is determined 2315 as follows: 2317 MLDv1 Query: length = 24 octets 2319 MLDv2 Query: length >= 28 octets 2321 Query messages that do not match any of the above conditions (e.g., a 2322 Query of length 26 octets) MUST be silently ignored. 2324 8.2. Multicast Address Listener Behavior 2326 8.2.1. In the Presence of MLDv1 Routers 2328 In order to be compatible with MLDv1 routers, MLDv2 hosts MUST 2329 operate in version 1 compatibility mode. MLDv2 hosts MUST keep state 2330 per local interface regarding the compatibility mode of each attached 2331 link. A host's compatibility mode is determined from the Host 2332 Compatibility Mode variable which can be in one of the two states: 2333 MLDv1 or MLDv2. 2335 The Host Compatibility Mode of an interface is set to MLDv1 whenever 2336 an MLDv1 Multicast Address Listener Query is received on that 2337 interface. At the same time, the Older Version Querier Present timer 2338 for the interface is set to Older Version Querier Present Timeout 2339 seconds. The timer is re-set whenever a new MLDv1 Query is received 2340 on that interface. If the Older Version Querier Present timer 2341 expires, the host switches back to Host Compatibility Mode of MLDv2. 2343 When Host Compatibility Mode is MLDv2, a host acts using the MLDv2 2344 protocol on that interface. When Host Compatibility Mode is MLDv1, a 2345 host acts in MLDv1 compatibility mode, using only the MLDv1 protocol, 2346 on that interface. 2348 An MLDv1 Querier will send General Queries with the Maximum Response 2349 Code set to the desired Maximum Response Delay, i.e., the full range 2350 of this field is linear and the exponential algorithm described in 2351 Section 5.1.3. is not used. 2353 Whenever a host changes its compatibility mode, it cancels all its 2354 pending responses and retransmission timers. 2356 8.2.2. In the Presence of MLDv1 Multicast Address Listeners 2358 An MLDv2 host may be placed on a link where there are MLDv1 hosts. A 2359 host MAY allow its MLDv2 Multicast Listener Report to be suppressed 2360 by a Version 1 Multicast Listener Report. 2362 8.3. Multicast Router Behavior 2364 8.3.1. In the Presence of MLDv1 Routers 2366 MLDv2 routers may be placed on a network where there is at least one 2367 MLDv1 router. The following requirements apply: 2369 * If an MLDv1 router is present on the link, the Querier MUST use 2370 the lowest version of MLD present on the network. This must be 2371 administratively assured. Routers that desire to be compatible 2372 with MLDv1 MUST have a configuration option to act in MLDv1 mode; 2373 if an MLDv1 router is present on the link, the system 2374 administrator must explicitly configure all MLDv2 routers to act 2375 in MLDv1 mode. When in MLDv1 mode, the Querier MUST send periodic 2376 General Queries truncated at the Multicast Address field (i.e., 24 2377 bytes long), and SHOULD also warn about receiving an MLDv2 Query 2378 (such warnings must be rate-limited). The Querier MUST also fill 2379 in the Maximum Response Delay in the Maximum Response Code field, 2380 i.e., the exponential algorithm described in Section 5.1.3. is not 2381 used. 2383 * If a router is not explicitly configured to use MLDv1 and receives 2384 an MLDv1 General Query, it SHOULD log a warning. These warnings 2385 MUST be rate-limited. 2387 8.3.2. In the Presence of MLDv1 Multicast Address Listeners 2389 MLDv2 routers may be placed on a network where there are hosts that 2390 have not yet been upgraded to MLDv2. In order to be compatible with 2391 MLDv1 hosts, MLDv2 routers MUST operate in version 1 compatibility 2392 mode. MLDv2 routers keep a compatibility mode per multicast address 2393 record. The compatibility mode of a multicast address is determined 2394 from the Multicast Address Compatibility Mode variable, which can be 2395 in one of the two following states: MLDv1 or MLDv2. 2397 The Multicast Address Compatibility Mode of a multicast address 2398 record is set to MLDv1 whenever an MLDv1 Multicast Listener Report is 2399 received for that multicast address. At the same time, the Older 2400 Version Host Present timer for the multicast address is set to Older 2401 Version Host Present Timeout seconds. The timer is re-set whenever a 2402 new MLDv1 Report is received for that multicast address. If the 2403 Older Version Host Present timer expires, the router switches back to 2404 Multicast Address Compatibility Mode of MLDv2 for that multicast 2405 address. 2407 Note that when a router switches back to MLDv2 Multicast Address 2408 Compatibility Mode for a multicast address, it takes some time to 2409 regain source-specific state information. Source-specific 2410 information will be learned during the next General Query, but 2411 sources that should be blocked will not be blocked until [Multicast 2412 Address Listening Interval] after that. 2414 When Multicast Address Compatibility Mode is MLDv2, a router acts 2415 using the MLDv2 protocol for that multicast address. When Multicast 2416 Address Compatibility Mode is MLDv1, a router internally translates 2417 the following MLDv1 messages for that multicast address to their 2418 MLDv2 equivalents: 2420 +===============+==================+ 2421 | MLDv1 Message | MLDv2 Equivalent | 2422 +===============+==================+ 2423 | Report | IS_EX( {} ) | 2424 +---------------+------------------+ 2425 | Done | TO_IN( {} ) | 2426 +---------------+------------------+ 2428 Table 7 2430 MLDv2 BLOCK messages are ignored, as are source-lists in TO_EX() 2431 messages (i.e., any TO_EX() message is treated as TO_EX( {} )). On 2432 the other hand, the Querier continues to send MLDv2 queries, 2433 regardless of its Multicast Address Compatibility Mode. 2435 9. List of Timers, Counters, and their Default Values 2437 Most of these timers are configurable. If non-default settings are 2438 used, they MUST be consistent among all nodes on a single link. Note 2439 that parentheses are used to group expressions to make the algebra 2440 clear. 2442 9.1. Robustness Variable 2444 The Robustness Variable allows tuning for the expected packet loss on 2445 a link. If a link is expected to be lossy, the value of the 2446 Robustness Variable may be increased. MLD is robust to [Robustness 2447 Variable] - 1 packet losses. The value of the Robustness Variable 2448 MUST NOT be zero, and SHOULD NOT be one. Default value: 2. 2450 9.2. Query Interval 2452 The Query Interval variable denotes the interval between General 2453 Queries sent by the Querier. Default value: 125 seconds. 2455 By varying the [Query Interval], an administrator may tune the number 2456 of MLD messages on the link; larger values cause MLD Queries to be 2457 sent less often. 2459 9.3. Query Response Interval 2461 The Maximum Response Delay used to calculate the Maximum Response 2462 Code inserted into the periodic General Queries. Default value: 2463 10000 (10 seconds) 2465 By varying the [Query Response Interval], an administrator may tune 2466 the burstiness of MLD messages on the link; larger values make the 2467 traffic less bursty, as host responses are spread out over a larger 2468 interval. The number of seconds represented by the [Query Response 2469 Interval] must be less than the [Query Interval]. 2471 9.4. Multicast Address Listening Interval 2473 The Multicast Address Listening Interval (MALI) is the amount of time 2474 that must pass before a multicast router decides there are no more 2475 listeners of a multicast address or a particular source on a link. 2476 This value MUST be ([Robustness Variable] times [Query Interval]) 2477 plus 2 times [Query Response Interval]. 2479 9.5. Other Querier Present Timeout 2481 The Other Querier Present Timeout is the length of time that must 2482 pass before a multicast router decides that there is no longer 2483 another multicast router which should be the Querier. This value 2484 MUST be ([Robustness Variable] times ([Query Interval]) plus (one 2485 half of [Query Response Interval]). 2487 9.6. Startup Query Interval 2489 The Startup Query Interval is the interval between General Queries 2490 sent by a Querier on startup. Default value: 1/4 the [Query 2491 Interval]. 2493 9.7. Startup Query Count 2495 The Startup Query Count is the number of Queries sent out on startup, 2496 separated by the Startup Query Interval. Default value: [Robustness 2497 Variable]. 2499 9.8. Last Listener Query Interval 2501 The Last Listener Query Interval is the Maximum Response Delay used 2502 to calculate the Maximum Response Code inserted into Multicast 2503 Address Specific Queries sent in response to Version 1 Multicast 2504 Listener Done messages. It is also the Maximum Response Delay used 2505 to calculate the Maximum Response Code inserted into Multicast 2506 Address and Source Specific Query messages. Default value: 1000 (1 2507 second). 2509 Note that for values of LLQI greater than 32.768 seconds, a limited 2510 set of values can be represented, corresponding to sequential values 2511 of Maximum Response Code. When converting a configured time to a 2512 Maximum Response Code value, it is recommended to use the exact value 2513 if possible, or the next lower value if the requested value is not 2514 exactly representable. 2516 This value may be tuned to modify the "leave latency" of the link. A 2517 reduced value results in reduced time to detect the departure of the 2518 last listener for a multicast address or source. 2520 9.9. Last Listener Query Count 2522 The Last Listener Query Count is the number of Multicast Address 2523 Specific Queries sent before the router assumes there are no local 2524 listeners. The Last Listener Query Count is also the number of 2525 Multicast Address and Source Specific Queries sent before the router 2526 assumes there are no listeners for a particular source. Default 2527 value: [Robustness Variable]. 2529 9.10. Last Listener Query Time 2531 The Last Listener Query Time is the time value represented by the 2532 Last Listener Query Interval, multiplied by [Last Listener Query 2533 Count]. It is not a tunable value, but may be tuned by changing its 2534 components. 2536 9.11. Unsolicited Report Interval 2538 The Unsolicited Report Interval is the time between repetitions of a 2539 node's initial report of interest in a multicast address. Default 2540 value: 1 second. 2542 9.12. Older Version Querier Present Timeout 2544 The Older Version Querier Present Timeout is the time-out for 2545 transitioning a host back to MLDv2 Host Compatibility Mode. When an 2546 MLDv1 query is received, MLDv2 hosts set their Older Version Querier 2547 Present Timer to [Older Version Querier Present Timeout]. 2549 This value MUST be ([Robustness Variable] times (the [Query Interval] 2550 in the last Query received)) plus ([Query Response Interval]). 2552 9.13. Older Version Host Present Timeout 2554 The Older Version Host Present Timeout is the time-out for 2555 transitioning a router back to MLDv2 Multicast Address Compatibility 2556 Mode for a specific multicast address. When an MLDv1 report is 2557 received for that multicast address, routers set their Older Version 2558 Host Present Timer to [Older Version Host Present Timeout]. 2560 This value MUST be ([Robustness Variable] times [Query Interval]) 2561 plus ([Query Response Interval]). 2563 9.14. Configuring timers 2565 This section is meant to provide advice to network administrators on 2566 how to tune these settings to their network. Ambitious router 2567 implementations might tune these settings dynamically based upon 2568 changing characteristics of the network. 2570 9.14.1. Robustness Variable 2572 The Robustness Variable tunes MLD to expected losses on a link. 2573 MLDv2 is robust to [Robustness Variable] - 1 packet losses, e.g., if 2574 the Robustness Variable is set to the default value of 2, MLDv2 is 2575 robust to a single packet loss but may operate imperfectly if more 2576 losses occur. On lossy links, the value of the Robustness Variable 2577 should be increased to allow for the expected level of packet loss. 2578 However, increasing the value of the Robustness Variable increases 2579 the leave latency of the link (the time between when the last 2580 listener stops listening to a source or multicast address and when 2581 the traffic stops flowing). 2583 9.14.2. Query Interval 2585 The overall level of periodic MLD traffic is inversely proportional 2586 to the Query Interval. A longer Query Interval results in a lower 2587 overall level of MLD traffic. The value of the Query Interval MUST 2588 be equal to or greater than the Maximum Response Delay used to 2589 calculate the Maximum Response Code inserted in General Query 2590 messages. 2592 9.14.3. Maximum Response Delay 2594 The burstiness of MLD traffic is inversely proportional to the 2595 Maximum Response Delay. A longer Maximum Response Delay will spread 2596 Report messages over a longer interval. However, a longer Maximum 2597 Response Delay in Multicast Address Specific and Multicast Address 2598 And Source Specific Queries extends the leave latency (the time 2599 between when the last listener stops listening to a source or 2600 multicast address and when the traffic stops flowing.) The expected 2601 rate of Report messages can be calculated by dividing the expected 2602 number of Reporters by the Maximum Response Delay. The Maximum 2603 Response Delay may be dynamically calculated per Query by using the 2604 expected number of Reporters for that Query as follows: 2606 General Query All nodes on link 2608 Multicast Address Specific Query All nodes on the link that had 2609 expressed interest in the 2610 multicast address 2612 Multicast Address and Source All nodes on the link that had 2613 Specific Query expressed interest in the source 2614 and multicast address 2616 A router is not required to calculate these populations or tune the 2617 Maximum Response Delay dynamically; these are simply guidelines. 2619 10. Security Considerations 2621 We consider the ramifications of a forged message of each type. Note 2622 that before processing an MLD message, nodes verify if the source 2623 address of the message is a valid link-local address (or the 2624 unspecified address), if the Hop Limit is set to 1, and if the Router 2625 Alert option is present in the Hop-By-Hop Options header of the IPv6 2626 packet. If any of these checks fails, the packet is dropped. This 2627 defends the MLDv2 nodes from acting on forged MLD messages originated 2628 off-link. Therefore, in the following we discuss only the effects of 2629 on-link forgery. 2631 10.1. Query Message 2633 A forged Query message from a machine with a lower IPv6 address than 2634 the current Querier will cause Querier duties to be assigned to the 2635 forger. If the forger then sends no more Query messages, other 2636 routers' Other Querier Present timer will time out and one will 2637 resume the role of Querier. During this time, if the forger ignores 2638 Multicast Listener Done Messages, traffic might flow to multicast 2639 addresses with no listeners for up to [Multicast Address Listener 2640 Interval]. 2642 A forged Version 1 Query message will put MLDv2 listeners on that 2643 link in MLDv1 Host Compatibility Mode. This scenario can be avoided 2644 by providing MLDv2 hosts with a configuration option to ignore 2645 Version 1 messages completely. 2647 A DoS attack on a node could be staged through forged Multicast 2648 Address and Source Specific Queries. The attacker can find out about 2649 the listening state of a specific node with a general query. After 2650 that it could send a large number of Multicast Address and Source 2651 Specific Queries, each with a large source list and/or long Maximum 2652 Response Delay. The node will have to store and maintain the sources 2653 specified in all of those queries for as long as it takes to send the 2654 delayed response. This would consume both memory and CPU cycles in 2655 order to augment the recorded sources with the source lists included 2656 in the successive queries. 2658 To protect against such a DoS attack, a node stack implementation 2659 could restrict the number of Multicast Address and Source Specific 2660 Queries per multicast address within this interval, and/or record 2661 only a limited number of sources. 2663 10.2. Current State Report messages 2665 A forged Report message may cause multicast routers to think there 2666 are listeners of a multicast address on a link when there are not. 2667 Nevertheless, since listening to a multicast address on a host is 2668 generally an unprivileged operation, a local user may trivially gain 2669 the same result without forging any messages. 2671 A forged Version 1 Report Message may put a router into MLDv1 2672 Multicast Address Compatibility Mode for a particular multicast 2673 address, meaning that the router will ignore MLDv2 source specific 2674 state messages. This can cause traffic to flow from unwanted sources 2675 for up to [Multicast Address Listener Interval]. This can be solved 2676 by providing routers with a configuration switch to ignore Version 1 2677 messages completely. This breaks automatic compatibility with 2678 Version 1 hosts, so it should only be used in situations where source 2679 filtering is critical. 2681 10.3. State Change Report messages 2683 A forged State Change Report message will cause the Querier to send 2684 out Multicast Address Specific or Multicast Address and Source 2685 Specific Queries for the multicast address in question. This causes 2686 extra processing on each router and on each listener of the multicast 2687 address, but cannot cause loss of desired traffic. 2689 11. IANA Considerations 2691 IANA has assigned the IPv6 link-local multicast address 2692 FF02:0:0:0:0:0:0:16, called "all MLDv2-capable routers", as described 2693 in Section 5.2.15. Version 2 Multicast Listener Reports will be sent 2694 to this special address. 2696 In addition, IANA has assigned the ICMPv6 message type value of 143 2697 for Version 2 Multicast Listener Report messages, as specified in 2698 Section 4. 2700 12. Contributors 2702 Roland Vida, Luis Henrique Maciel Kosmalski Costa, Serge Fdida, Steve 2703 Deering, Bill Fenner, and Isidor Kouvelas are the authors of RFC 2704 3810, which makes up the majority of the content in this document. 2706 Anuj Budhiraja, Toerless Eckert, Olufemi Komolafe and Tim Winters 2707 have contributed valuable content to this version of the 2708 specification. 2710 13. Acknowledgments 2712 We would like to thank Hitoshi Asaeda, Randy Bush, Francis Dupont, 2713 Ted Hardie, Russ Housley, Konstantin Kabassanov, Erik Nordmark, 2714 Shinsuke Suzuki, Margaret Wasserman, Bert Wijnen, and Remi Zara for 2715 their valuable comments and suggestions on this document. 2717 Stig Venaas, Hitoshi Asaeda, and Mike McBride have provided valuable 2718 feedback on this version of the specification and we thank them for 2719 their input. 2721 14. References 2723 14.1. Normative References 2725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2726 Requirement Levels", BCP 14, RFC 2119, 2727 DOI 10.17487/RFC2119, March 1997, 2728 . 2730 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2731 IANA Considerations Section in RFCs", RFC 2434, 2732 DOI 10.17487/RFC2434, October 1998, 2733 . 2735 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2736 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2737 December 1998, . 2739 [RFC2463] Conta, A. and S. Deering, "Internet Control Message 2740 Protocol (ICMPv6) for the Internet Protocol Version 6 2741 (IPv6) Specification", RFC 2463, DOI 10.17487/RFC2463, 2742 December 1998, . 2744 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 2745 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 2746 . 2748 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 2749 Listener Discovery (MLD) for IPv6", RFC 2710, 2750 DOI 10.17487/RFC2710, October 1999, 2751 . 2753 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 2754 RFC 2711, DOI 10.17487/RFC2711, October 1999, 2755 . 2757 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 2758 (IPv6) Addressing Architecture", RFC 3513, 2759 DOI 10.17487/RFC3513, April 2003, 2760 . 2762 14.2. Informative References 2764 [I-D.haberman-pim-3228bis] 2765 Haberman, B., "IANA Considerations for Internet Group 2766 Management Protocols", Work in Progress, Internet-Draft, 2767 draft-haberman-pim-3228bis-00, 15 April 2022, 2768 . 2771 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 2772 Discovery for IP Version 6 (IPv6)", RFC 2461, 2773 DOI 10.17487/RFC2461, December 1998, 2774 . 2776 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 2777 Autoconfiguration", RFC 2462, DOI 10.17487/RFC2462, 2778 December 1998, . 2780 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2781 Thyagarajan, "Internet Group Management Protocol, Version 2782 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 2783 . 2785 [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific 2786 Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 2787 2003, . 2789 [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface 2790 Extensions for Multicast Source Filters", RFC 3678, 2791 DOI 10.17487/RFC3678, January 2004, 2792 . 2794 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 2795 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 2796 DOI 10.17487/RFC3810, June 2004, 2797 . 2799 Appendix A. Design Rationale 2801 A.1. The Need for State Change Messages 2803 MLDv2 specifies two types of Multicast Listener Reports: Current 2804 State and State Change. This section describes the rationale for the 2805 need for both these types of Reports. 2807 Routers need to distinguish Multicast Listener Reports that were sent 2808 in response to Queries from those that were sent as a result of a 2809 change in the per-interface state. Multicast Listener Reports that 2810 are sent in response to Multicast Address Listener Queries are used 2811 mainly to refresh the existing state at the router; they typically do 2812 not cause transitions in state at the router. Multicast Listener 2813 Reports that are sent in response to changes in the per-interface 2814 state require the router to take some action in response to the 2815 received report (see Section 7.4). 2817 The inability to distinguish between the two types of reports would 2818 force a router to treat all Multicast Listener Reports as potential 2819 changes in state and could result in increased processing at the 2820 router as well as an increase in MLD traffic on the link. 2822 A.2. Host Suppression 2824 In MLDv1, a host would not send a pending multicast listener report 2825 if a similar report was sent by another listener on the link. In 2826 MLDv2, the suppression of multicast listener reports has been 2827 removed. The following points explain this decision. 2829 1. Routers may want to track per-host multicast listener status on 2830 an interface. This would allow routers to implement fast leaves 2831 (e.g., for layered multicast congestion control schemes), as well 2832 as track listener status for possible security or accounting 2833 purposes. The present specification does not require routers to 2834 implement per-host tracking. Nevertheless, the lack of host 2835 suppression in MLDv2 makes possible to implement either 2836 proprietary or future standard behavior of multicast routers that 2837 would support per-host tracking, while being fully interoperable 2838 with MLDv2 listeners and routers that implement the exact 2839 behavior described in this specification. 2841 2. Multicast Listener Report suppression does not work well on 2842 bridged LANs. Many bridges and Layer2/Layer3 switches that 2843 implement MLD snooping do not forward MLD messages across LAN 2844 segments in order to prevent multicast listener report 2845 suppression. 2847 3. By eliminating multicast listener report suppression, hosts have 2848 fewer messages to process; this leads to a simpler state machine 2849 implementation. 2851 4. In MLDv2, a single multicast listener report now bundles multiple 2852 multicast address records to decrease the number of packets sent. 2853 In comparison, the previous version of MLD required that each 2854 multicast address be reported in a separate message. 2856 A.3. Switching router filter modes from EXCLUDE to INCLUDE 2858 If on a link there are nodes in both EXCLUDE and INCLUDE modes for a 2859 single multicast address, the router must be in EXCLUDE mode as well 2860 (see section 7.2.1). In EXCLUDE mode, a router forwards traffic from 2861 all sources except those in the Exclude List. If all nodes in 2862 EXCLUDE mode cease to exist or to listen, it would be desirable for 2863 the router to switch back to INCLUDE mode seamlessly, without 2864 interrupting the flow of traffic to existing listeners. 2866 One of the ways to accomplish this is for routers to keep track of 2867 all sources that nodes that are in INCLUDE mode listen to, even 2868 though the router itself is in EXCLUDE mode. If the Filter Timer for 2869 a multicast address expires, it implies that there are no nodes in 2870 EXCLUDE mode on the link (otherwise a multicast listener report from 2871 that node would have refreshed the Filter Timer). The router can 2872 then switch to INCLUDE mode seamlessly; sources from the Requested 2873 List are moved to the Include List, while sources from the Exclude 2874 List are deleted. 2876 Appendix B. Summary of Changes 2878 B.1. MLDv1 2880 The following is a summary of changes from MLDv1, specified in 2881 [RFC2710]. 2883 * MLDv2 introduces source filtering. 2885 * The IP service interface of MLDv2 nodes is modified accordingly. 2886 It enables the specification of a filter mode and a source list. 2888 * An MLDv2 node keeps per-socket and per-interface multicast 2889 listening states that include a filter mode and a source list for 2890 each multicast address. This enables packet filtering based on a 2891 socket's multicast reception state. 2893 * MLDv2 state kept on routers includes a filter mode and a list of 2894 sources and source timers for each multicast address that has 2895 listeners on the link. MLDv1 routers kept only the list of 2896 multicast addresses. 2898 * Queries include additional fields (Section 5.1). 2900 * The S flag (Suppress Router-Side Processing) is included in 2901 queries in order to fix robustness issues. 2903 * The Querier's Robustness Variable and Query Interval Code are 2904 included in Queries in order to synchronize all MLDv2 routers 2905 connected to the same link. 2907 * A new Query type (Multicast Address and Source Specific Query) is 2908 introduced. 2910 * The Maximum Response Delay is not directly included in the Query 2911 anymore. Instead, an exponential algorithm is used to calculate 2912 its value, based on the Maximum Response Code included in the 2913 Query. The maximum value is increased from 65535 milliseconds to 2914 about 140 minutes. 2916 * Reports include Multicast Address Records. Information on the 2917 listening state for several different multicast addresses can be 2918 included in the same Report message. 2920 * Reports are sent to the "all MLDv2-capable multicast routers" 2921 address, instead of the multicast address the host listens to, as 2922 in MLDv1. This facilitates the operation of layer-2 snooping 2923 switches. 2925 * There is no "host suppression", as in MLDv1. All nodes send 2926 Report messages. 2928 * Unsolicited Reports, announcing changes in receiver listening 2929 state, are sent [Robustness Variable] times. RFC 2710 is less 2930 explicit. 2932 * There are no Done messages. 2934 * Interoperability with MLDv1 systems is achieved by MLDv2 state 2935 operations. 2937 * In order to ensure interoperability, hosts maintain a Host 2938 Compatibility Mode variable and an Older Version Querier Present 2939 timer per interface. Routers maintain a Multicast Address 2940 Compatibility Mode variable and an Older Version Host Present 2941 timer per multicast address. 2943 B.2. MLDv2 2945 The following summarizes the changes made since RFC 3810. 2947 * Added definition of Resv to address Erratum 4773. 2949 * Added clarifying text on which multicast addresses require the 2950 sending of MLD messages to address Erratum 5977. 2952 Author's Address 2954 Brian Haberman (editor) 2955 Johns Hopkins University Applied Physics Lab 2956 Email: brian@innovationslab.net