idnits 2.17.00 (12 Aug 2021) /tmp/idnits47229/draft-ietf-pim-3810bis-01.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (October 2021) is 218 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 1023 -- Looks like a reference, but probably isn't: '2' on line 1031 == Missing Reference: 'N' is mentioned on line 1043, but not defined == Missing Reference: 'M' is mentioned on line 1002, but not defined ** 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: 3 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) October 2021 5 Intended status: Standards Track 6 Expires: 28 April 2022 8 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 9 draft-ietf-pim-3810bis-01 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 4 April 2022. 42 Copyright Notice 44 Copyright (c) 2021 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 Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified 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. Resv . . . . . . . . . . . . . . . . . . . . . . . . 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. Nr of Mcast Address Records (M) . . . . . . . . . . . 25 92 5.2.4. Multicast Address Record . . . . . . . . . . . . . . 25 93 5.2.5. Record Type . . . . . . . . . . . . . . . . . . . . . 25 94 5.2.6. Aux Data Len . . . . . . . . . . . . . . . . . . . . 25 95 5.2.7. Number of Sources (N) . . . . . . . . . . . . . . . . 25 96 5.2.8. Multicast Address . . . . . . . . . . . . . . . . . . 25 97 5.2.9. Source Address [i] . . . . . . . . . . . . . . . . . 26 98 5.2.10. Auxiliary Data . . . . . . . . . . . . . . . . . . . 26 99 5.2.11. Additional Data . . . . . . . . . . . . . . . . . . . 26 100 5.2.12. Multicast Address Record Types . . . . . . . . . . . 26 101 5.2.13. Source Addresses for Reports . . . . . . . . . . . . 29 102 5.2.14. Destination Addresses for Reports . . . . . . . . . . 29 103 5.2.15. Multicast Listener Report Size . . . . . . . . . . . 30 104 6. Protocol Description for Multicast Address Listeners . . . . 30 105 6.1. Action on Change of Per-Interface State . . . . . . . . . 31 106 6.2. Action on Reception of a Query . . . . . . . . . . . . . 34 107 6.3. Action on Timer Expiration . . . . . . . . . . . . . . . 36 108 7. Description of the Protocol for Multicast Routers . . . . . . 38 109 7.1. Conditions for MLD Queries . . . . . . . . . . . . . . . 39 110 7.2. MLD State Maintained by Multicast Routers . . . . . . . . 41 111 7.2.1. Definition of Router Filter Mode . . . . . . . . . . 41 112 7.2.2. Definition of Filter Timers . . . . . . . . . . . . . 42 113 7.2.3. Definition of Source Timers . . . . . . . . . . . . . 43 114 7.3. MLDv2 Source Specific Forwarding Rules . . . . . . . . . 45 115 7.4. Action on Reception of Reports . . . . . . . . . . . . . 46 116 7.4.1. Reception of Current State Records . . . . . . . . . 46 117 7.4.2. Reception of Filter Mode Change and Source List Change 118 Records . . . . . . . . . . . . . . . . . . . . . . . 47 119 7.5. Switching Router Filter Modes . . . . . . . . . . . . . . 49 120 7.6. Action on Reception of Queries . . . . . . . . . . . . . 50 121 7.6.1. Timer Updates . . . . . . . . . . . . . . . . . . . . 50 122 7.6.2. Querier Election . . . . . . . . . . . . . . . . . . 50 123 7.6.3. Building and Sending Specific Queries . . . . . . . . 51 124 8. Interoperation with MLDv1 . . . . . . . . . . . . . . . . . . 52 125 8.1. Query Version Distinctions . . . . . . . . . . . . . . . 52 126 8.2. Multicast Address Listener Behavior . . . . . . . . . . . 52 127 8.2.1. In the Presence of MLDv1 Routers . . . . . . . . . . 52 128 8.2.2. In the Presence of MLDv1 Multicast Address 129 Listeners . . . . . . . . . . . . . . . . . . . . . . 53 130 8.3. Multicast Router Behavior . . . . . . . . . . . . . . . . 53 131 8.3.1. In the Presence of MLDv1 Routers . . . . . . . . . . 53 132 8.3.2. In the Presence of MLDv1 Multicast Address 133 Listeners . . . . . . . . . . . . . . . . . . . . . . 54 134 9. List of Timers, Counters, and their Default Values . . . . . 55 135 9.1. Robustness Variable . . . . . . . . . . . . . . . . . . . 55 136 9.2. Query Interval . . . . . . . . . . . . . . . . . . . . . 55 137 9.3. Query Response Interval . . . . . . . . . . . . . . . . . 55 138 9.4. Multicast Address Listening Interval . . . . . . . . . . 55 139 9.5. Other Querier Present Timeout . . . . . . . . . . . . . . 56 140 9.6. Startup Query Interval . . . . . . . . . . . . . . . . . 56 141 9.7. Startup Query Count . . . . . . . . . . . . . . . . . . . 56 142 9.8. Last Listener Query Interval . . . . . . . . . . . . . . 56 143 9.9. Last Listener Query Count . . . . . . . . . . . . . . . . 57 144 9.10. Last Listener Query Time . . . . . . . . . . . . . . . . 57 145 9.11. Unsolicited Report Interval . . . . . . . . . . . . . . . 57 146 9.12. Older Version Querier Present Timeout . . . . . . . . . . 57 147 9.13. Older Version Host Present Timeout . . . . . . . . . . . 57 148 9.14. Configuring timers . . . . . . . . . . . . . . . . . . . 58 149 9.14.1. Robustness Variable . . . . . . . . . . . . . . . . 58 150 9.14.2. Query Interval . . . . . . . . . . . . . . . . . . . 58 151 9.14.3. Maximum Response Delay . . . . . . . . . . . . . . . 58 152 10. Security Considerations . . . . . . . . . . . . . . . . . . . 59 153 10.1. Query Message . . . . . . . . . . . . . . . . . . . . . 59 154 10.2. Current State Report messages . . . . . . . . . . . . . 60 155 10.3. State Change Report messages . . . . . . . . . . . . . . 60 156 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 157 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 61 158 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 61 159 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 61 160 14.1. Normative References . . . . . . . . . . . . . . . . . . 61 161 14.2. Informative References . . . . . . . . . . . . . . . . . 62 162 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 62 163 A.1. The Need for State Change Messages . . . . . . . . . . . 62 164 A.2. Host Suppression . . . . . . . . . . . . . . . . . . . . 63 165 A.3. Switching router filter modes from EXCLUDE to INCLUDE . . 64 166 Appendix B. Summary of Changes . . . . . . . . . . . . . . . . . 64 167 B.1. MLDv1 . . . . . . . . . . . . . . . . . . . . . . . . . . 64 168 B.2. MLDv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 65 169 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 66 171 1. Introduction 173 The Multicast Listener Discovery Protocol (MLD) is used by IPv6 174 routers to discover the presence of multicast listeners (i.e., nodes 175 that wish to receive multicast packets) on their directly attached 176 links, and to discover specifically which multicast addresses are of 177 interest to those neighboring nodes. Note that a multicast router 178 may itself be a listener of one or more multicast addresses; in this 179 case it performs both the "multicast router part" and the "multicast 180 address listener part" of the protocol, to collect the multicast 181 listener information needed by its multicast routing protocol on the 182 one hand, and to inform itself and other neighboring multicast 183 routers of its listening state on the other hand. 185 This document specifies Version 2 of MLD. The previous version of 186 MLD is specified in [RFC2710]. In this document we will refer to it 187 as MLDv1. MLDv2 is a translation of the IGMPv3 protocol [RFC3376] 188 for IPv6 semantics. 190 The MLDv2 protocol, when compared to MLDv1, adds support for "source 191 filtering", i.e., the ability for a node to report interest in 192 listening to packets only from specific source addresses, as required 193 to support Source-Specific Multicast [RFC3569], or from *all but* 194 specific source addresses, sent to a particular multicast address. 195 MLDv2 is designed to be interoperable with MLDv1. 197 This document obsoletes [RFC3810]. 199 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 200 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 201 "OPTIONAL" in this document are to be interpreted as described in 202 [RFC2119]. 204 2. Protocol Overview 206 This section gives a brief description of the protocol operation. 207 The following sections present the protocol details. 209 MLD is an asymmetric protocol; it specifies separate behaviors for 210 multicast address listeners (i.e., hosts or routers that listen to 211 multicast packets) and multicast routers. The purpose of MLD is to 212 enable each multicast router to learn, for each of its directly 213 attached links, which multicast addresses and which sources have 214 interested listeners on that link. The information gathered by MLD 215 is provided to whichever multicast routing protocol is used by the 216 router, in order to ensure that multicast packets are delivered to 217 all links where there are listeners interested in such packets. 219 Multicast routers only need to know that at least one node on an 220 attached link is listening to packets for a particular multicast 221 address, from a particular source; a multicast router is not required 222 to individually keep track of the interests of each neighboring node. 223 (Nevertheless, see Appendix A.2 item 1 for discussion.) 224 A multicast router performs the router part of the MLDv2 protocol 225 (described in details in Section 7) on each of its directly attached 226 links. If a multicast router has more than one interface connected 227 to the same link, it only needs to operate the protocol on one of 228 those interfaces. The router behavior depends on whether there are 229 several multicast routers on the same subnet, or not. If that is the 230 case, a querier election mechanism (described in Section 7.6.2) is 231 used to elect a single multicast router to be in Querier state. This 232 router is called the Querier. All multicast routers on the subnet 233 listen to the messages sent by multicast address listeners, and 234 maintain the same multicast listening information state, so that they 235 can take over the querier role, should the present Querier fail. 236 Nevertheless, only the Querier sends periodical or triggered query 237 messages on the subnet, as described in Section 7.1. 239 A multicast address listener performs the listener part of the MLDv2 240 protocol (described in details in Section 6) on all interfaces on 241 which multicast reception is supported, even if more than one of 242 those interfaces are connected to the same link. 244 2.1. Building Multicast Listening State on Multicast Address Listeners 246 Upper-layer protocols and applications that run on a multicast 247 address listener node use specific service interface calls (described 248 in Section 3) to ask the IP layer to enable or disable reception of 249 packets sent to specific multicast addresses. The node keeps 250 Multicast Address Listening state for each socket on which the 251 service interface calls have been invoked (Section 4.1). In addition 252 to this per-socket multicast listening state, a node must also 253 maintain or compute multicast listening state for each of its 254 interfaces (Section 4.2). Conceptually, that state consists of a set 255 of records, with each record containing an IPv6 multicast address, a 256 filter mode, and a source list. The filter mode may be either 257 INCLUDE or EXCLUDE. In INCLUDE mode, reception of packets sent to 258 the specified multicast address is enabled only from the source 259 addresses listed in the source list. In EXCLUDE mode, reception of 260 packets sent to the given multicast address is enabled from all 261 source addresses except those listed in the source list. 263 At most one record per multicast address exists for a given 264 interface. This per-interface state is derived from the per-socket 265 state, but may differ from it when different sockets have differing 266 filter modes and/or source lists for the same multicast address and 267 interface. After a multicast packet has been accepted from an 268 interface by the IP layer, its subsequent delivery to the application 269 connected to a particular socket depends on the multicast listening 270 state of that socket (and possibly also on other conditions, such as 271 what transport-layer port the socket is bound to). Note that MLDv2 272 messages are not subject to source filtering and must always be 273 processed by hosts and routers. 275 2.2. Exchanging Messages between the Querier and the Listening Nodes 277 There are three types of MLDv2 query messages: General Queries, 278 Multicast Address Specific Queries, and Multicast Address and Source 279 Specific Queries. The Querier periodically sends General Queries, to 280 learn multicast address listener information from an attached link. 281 These queries are used to build and refresh the Multicast Address 282 Listener state inside all multicast routers on the link. 284 Nodes respond to these queries by reporting their per-interface 285 Multicast Address Listening state, through Current State Report 286 messages sent to a specific multicast address all MLDv2 routers on 287 the link listen to. On the other hand, if the listening state of a 288 node changes, the node immediately reports these changes through a 289 State Change Report message. The State Change Report contains either 290 Filter Mode Change records, Source List Change records, or records of 291 both types. A detailed description of the report messages is 292 presented in Section 5.2.12. 294 Both router and listener state changes are mainly triggered by the 295 expiration of a specific timer, or the reception of an MLD message 296 (listener state change can be also triggered by the invocation of a 297 service interface call). Therefore, to enhance protocol robustness, 298 in spite of the possible unreliability of message exchanges, messages 299 are retransmitted several times. Furthermore, timers are set so as 300 to take into account the possible message losses, and to wait for 301 retransmissions. 303 Periodical General Queries and Current State Reports do not apply 304 this rule, in order not to overload the link; it is assumed that in 305 general these messages do not generate state changes, their main 306 purpose being to refresh existing state. Thus, even if one such 307 message is lost, the corresponding state will be refreshed during the 308 next reporting period. 310 As opposed to Current State Reports, State Change Reports are 311 retransmitted several times, in order to avoid them being missed by 312 one or more multicast routers. The number of retransmissions depends 313 on the so-called Robustness Variable. This variable allows tuning 314 the protocol according to the expected packet loss on a link. If a 315 link is expected to be lossy (e.g., a wireless connection), the value 316 of the Robustness Variable may be increased. MLD is robust to 317 [Robustness Variable]-1 packet losses. This document recommends a 318 default value of 2 for the Robustness Variable (see Section 9.1). 320 If more changes to the same per-interface state entry occur before 321 all the retransmissions of the State Change Report for the first 322 change have been completed, each additional change triggers the 323 immediate transmission of a new State Change Report. Section 6.1 324 shows how the content of this new report is computed. 325 Retransmissions of the new State Change Report will be scheduled as 326 well, in order to ensure that each instance of state change is 327 transmitted at least [Robustness Variable] times. 329 If a node on a link expresses, through a State Change Report, its 330 desire to no longer listen to a particular multicast address (or 331 source), the Querier must query for other listeners of the multicast 332 address (or source) before deleting the multicast address (or source) 333 from its Multicast Address Listener state and stopping the 334 corresponding traffic. Thus, the Querier sends a Multicast Address 335 Specific Query to verify whether there are nodes still listening to a 336 specified multicast address or not. Similarly, the Querier sends a 337 Multicast Address and Source Specific Query to verify whether, for a 338 specified multicast address, there are nodes still listening to a 339 specific set of sources, or not. Section 5.1.13 describes each query 340 in more detail. 342 Both Multicast Address Specific Queries and Multicast Address and 343 Source Specific Queries are only sent in response to State Change 344 Reports, never in response to Current State Reports. This 345 distinction between the two types of reports is needed to avoid the 346 router treating all Multicast Listener Reports as potential changes 347 in state. By doing so, the fast leave mechanism of MLDv2, described 348 in more detail in Section 2.2, might not be effective if a State 349 Change Report is lost, and only the following Current State Report is 350 received by the router. Nevertheless, it avoids an increased 351 processing at the router and it reduces the MLD traffic on the link. 352 More details on the necessity of distinguishing between the two 353 report types can be found in Appendix A.1. 355 Nodes respond to the above queries through Current State Reports, 356 that contain their per-interface Multicast Address Listening state 357 only for the multicast addresses (or sources) being queried. 359 As stated earlier, in order to ensure protocol robustness, all the 360 queries, except the periodical General Queries, are retransmitted 361 several times within a given time interval. The number of 362 retransmissions depends on the Robustness Variable. If, while 363 scheduling new queries, there are pending queries to be retransmitted 364 for the same multicast address, the new queries and the pending 365 queries have to be merged. In addition, host reports received for a 366 multicast address with pending queries may affect the contents of 367 those queries. The process of building and maintaining the state of 368 pending queries is presented in Section 7.6.3. 370 Protocol robustness is also enhanced through the use of the S flag 371 (Suppress Router-Side Processing). As described above, when a 372 Multicast Address Specific or a Multicast Address and Source Specific 373 Query is sent by the Querier, a number of retransmissions of the 374 query are scheduled. In the original (first) query the S flag is 375 clear. When the Querier sends this query, it lowers the timers for 376 the concerned multicast address (or source) to a given value; 377 similarly, any non-querier multicast router that receives the query 378 lowers its timers in the same way. Nevertheless, while waiting for 379 the next scheduled queries to be sent, the Querier may receive a 380 report that updates the timers. The scheduled queries still have to 381 be sent, in order to ensure that a non-querier router keeps its state 382 synchronized with the current Querier (the non-querier router might 383 have missed the first query). Nevertheless, the timers should not be 384 lowered again, as a valid answer was already received. Therefore, in 385 subsequent queries the Querier sets the S flag. 387 2.3. Building Multicast Address Listener State on Multicast Routers 389 Multicast routers that implement MLDv2 (whether they are in Querier 390 state or not) keep state per multicast address per attached link. 391 This multicast address listener state consists of a Filter Mode, a 392 Filter Timer, and a Source List, with a timer associated to each 393 source from the list. The Filter Mode is used to summarize the total 394 listening state of a multicast address to a minimum set, such that 395 all nodes' listening states are respected. The Filter Mode may 396 change in response to the reception of particular types of report 397 messages, or when certain timer conditions occur. 399 A router is in INCLUDE mode for a specific multicast address on a 400 given interface if all the listeners on the link interested in that 401 address are in INCLUDE mode. The router state is represented through 402 the notation INCLUDE (A), where A is a list of sources, called the 403 "Include List". The Include List is the set of sources that one or 404 more listeners on the link have requested to receive. All the 405 sources from the Include List will be forwarded by the router. Any 406 other source that is not in the Include List will be blocked by the 407 router. 409 A source can be added to the current Include List if a listener in 410 INCLUDE mode sends a Current State or a State Change Report that 411 includes that source. Each source from the Include List is 412 associated with a source timer that is updated whenever a listener in 413 INCLUDE mode sends a report that confirms its interest in that 414 specific source. If the timer of a source from the Include List 415 expires, the source is deleted from the Include List. 417 Besides this "soft leave" mechanism, there is also a "fast leave" 418 scheme in MLDv2; it is also based on the use of source timers. When 419 a node in INCLUDE mode expresses its desire to stop listening to a 420 specific source, all the multicast routers on the link lower their 421 timers for that source to a given value. The Querier then sends a 422 Multicast Address and Source Specific Query, to verify whether there 423 are other listeners for that source on the link, or not. If a report 424 that includes this source is received before the timer expiration, 425 all the multicast routers on the link update the source timer. If 426 not, the source is deleted from the Include List. The handling of 427 the Include List, according to the received reports, is detailed in 428 Section 7.4.1 and Section 7.4.2. 430 A router is in EXCLUDE mode for a specific multicast address on a 431 given interface if there is at least one listener in EXCLUDE mode for 432 that address on the link. When the first report is received from 433 such a listener, the router sets the Filter Timer that corresponds to 434 that address. This timer is reset each time an EXCLUDE mode listener 435 confirms its listening state through a Current State Report. The 436 timer is also updated when a listener, formerly in INCLUDE mode, 437 announces its filter mode change through a State Change Report 438 message. If the Filter Timer expires, it means that there are no 439 more listeners in EXCLUDE mode on the link. In this case, the router 440 switches back to INCLUDE mode for that multicast address. 442 When the router is in EXCLUDE mode, the router state is represented 443 by the notation EXCLUDE (X,Y), where X is called the "Requested List" 444 and Y is called the "Exclude List". All sources, except those from 445 the Exclude List, will be forwarded by the router. The Requested 446 List has no effect on forwarding. Nevertheless, the router has to 447 maintain the Requested List for two reasons: 449 * To keep track of sources that listeners in INCLUDE mode listen to. 450 This is necessary to assure a seamless transition of the router to 451 INCLUDE mode, when there is no listener in EXCLUDE mode left. 452 This transition should not interrupt the flow of traffic to 453 listeners in INCLUDE mode for that multicast address. Therefore, 454 at the time of the transition, the Requested List should contain 455 the set of sources that nodes in INCLUDE mode have explicitly 456 requested. 458 When the router switches to INCLUDE mode, the sources in the 459 Requested List are moved to the Include List, and the Exclude List 460 is deleted. Before switching, the Requested List can contain an 461 inexact guess of the sources listeners in INCLUDE mode listen to - 462 might be too large or too small. These inexactitudes are due to 463 the fact that the Requested List is also used for fast blocking 464 purposes, as described below. If such a fast blocking is 465 required, some sources may be deleted from the Requested List (as 466 shown in Section 7.4.1 and Section 7.4.2) in order to reduce 467 router state. Nevertheless, in each such case the Filter Timer is 468 updated as well. Therefore, listeners in INCLUDE mode will have 469 enough time, before an eventual switching, to reconfirm their 470 interest in the eliminated source(s), and rebuild the Requested 471 List accordingly. The protocol ensures that when a switch to 472 INCLUDE mode occurs, the Requested List will be accurate. Details 473 about the transition of the router to INCLUDE mode are presented 474 in Appendix A.3. 476 * To allow the fast blocking of previously unblocked sources. If 477 the router receives a report that contains such a request, the 478 concerned sources are added to the Requested List. Their timers 479 are set to a given small value, and a Multicast Address and Source 480 Specific Query is sent by the Querier, to check whether there are 481 nodes on the link still interested in those sources, or not. If 482 no node announces its interest in receiving those specific source, 483 the timers of those sources expire. Then, the sources are moved 484 from the Requested List to the Exclude List. From then on, the 485 sources will be blocked by the router. 487 The handling of the EXCLUDE mode router state, according to the 488 received reports, is detailed in Section 7.4.1 and Section 7.4.2. 490 Both the MLDv2 router and listener behaviors described in this 491 document were defined to ensure backward interoperability with MLDv1 492 hosts and routers. Interoperability issues are detailed in 493 Section 8. 495 3. The Service Interface for Requesting IP Multicast Reception 497 Within an IP system, there is (at least conceptually) a service 498 interface used by upper-layer protocols or application programs to 499 ask the IP layer to enable or disable reception of packets sent to 500 specific IP multicast addresses. In order to take full advantage of 501 the capabilities of MLDv2, a node's IP service interface must support 502 the following operation: 504 IPv6MulticastListen ( socket, interface, IPv6 multicast-address, 505 filter-mode, source-list ) 507 where: 509 * "socket" is an implementation-specific parameter used to 510 distinguish among different requesting entities (e.g., programs, 511 processes) within the node; the socket parameter of BSD Unix 512 system calls is a specific example. 514 * "interface" is a local identifier of the network interface on 515 which reception of the specified multicast address is to be 516 enabled or disabled. Interfaces may be physical (e.g., an 517 Ethernet interface) or virtual (e.g., the endpoint of a Frame 518 Relay virtual circuit or an IP-in-IP "tunnel"). An implementation 519 may allow a special "unspecified" value to be passed as the 520 interface parameter, in which case the request would apply to the 521 "primary" or "default" interface of the node (perhaps established 522 by system configuration). If reception of the same multicast 523 address is desired on more than one interface, IPv6MulticastListen 524 is invoked separately for each desired interface. 526 * "IPv6 multicast address" is the multicast address to which the 527 request pertains. If reception of more than one multicast address 528 on a given interface is desired, IPv6MulticastListen is invoked 529 separately for each desired address. 531 * "filter mode" may be either INCLUDE or EXCLUDE. In INCLUDE mode, 532 reception of packets sent to the specified multicast address is 533 requested only from the source addresses listed in the source list 534 parameter. In EXCLUDE mode, reception of packets sent to the 535 given multicast address is requested from all source addresses 536 except those listed in the source list parameter. 538 * "source list" is an unordered list of zero or more unicast 539 addresses from which multicast reception is desired or not 540 desired, depending on the filter mode. An implementation MAY 541 impose a limit on the size of source lists. When an operation 542 causes the source list size limit to be exceeded, the service 543 interface SHOULD return an error. 545 For a given combination of socket, interface, and IPv6 multicast 546 address, only a single filter mode and source list can be in effect 547 at any one time. Nevertheless, either the filter mode or the source 548 list, or both, may be changed by subsequent IPv6MulticastListen 549 requests that specify the same socket, interface, and IPv6 multicast 550 address. Each subsequent request completely replaces any earlier 551 request for the given socket, interface, and multicast address. 553 The MLDv1 protocol did not support source filters, and had a simpler 554 service interface; it consisted of Start Listening and Stop Listening 555 operations to enable and disable listening to a given multicast 556 address (from all sources) on a given interface. The equivalent 557 operations in the new service interface are as follows: 559 The Start Listening operation is equivalent to: 561 IPv6MulticastListen ( socket, interface, IPv6 multicast address, 562 EXCLUDE, {} ) 564 and the Stop Listening operation is equivalent to: 566 IPv6MulticastListen ( socket, interface, IPv6 multicast address, 567 INCLUDE, {} ) 569 where {} is an empty source list. 571 An example of an API that provides the capabilities outlined in this 572 service interface is given in [RFC3678]. 574 4. Multicast Listening State Maintained by Nodes 576 4.1. Per-Socket State 578 For each socket on which IPv6MulticastListen has been invoked, the 579 node records the desired multicast listening state for that socket. 580 That state conceptually consists of a set of records of the form: 582 (interface, IPv6 multicast address, filter mode, source list) 584 The per-socket state evolves in response to each invocation of 585 IPv6MulticastListen on the socket, as follows: 587 * If the requested filter mode is INCLUDE and the requested source 588 list is empty, then the entry that corresponds to the requested 589 interface and multicast address is deleted, if present. If no 590 such entry is present, the request has no effect. 592 * If the requested filter mode is EXCLUDE or the requested source 593 list is non-empty, then the entry that corresponds to the 594 requested interface and multicast address, if present, is changed 595 to contain the requested filter mode and source list. If no such 596 entry is present, a new entry is created, using the parameters 597 specified in the request. 599 4.2. Per-Interface State 601 In addition to the per-socket multicast listening state, a node must 602 also maintain or compute multicast listening state for each of its 603 interfaces. That state conceptually consists of a set of records of 604 the form: 606 (IPv6 multicast address, filter mode, source list) 608 At most one record per multicast address exists for a given 609 interface. This per-interface state is derived from the per-socket 610 state, but may differ from it when different sockets have differing 611 filter modes and/or source lists for the same multicast address and 612 interface. For example, suppose one application or process invokes 613 the following operation on socket s1: 615 IPv6MulticastListen ( s1, i, m, INCLUDE, {a, b, c} ) 617 requesting reception on interface i of packets sent to multicast 618 address m, only if they come from the sources a, b, or c. Suppose 619 another application or process invokes the following operation on 620 socket s2: 622 IPv6MulticastListen ( s2, i, m, INCLUDE, {b, c, d} ) 624 requesting reception on the same interface i of packets sent to the 625 same multicast address m, only if they come from sources b, c, or d. 626 In order to satisfy the reception requirements of both sockets, it is 627 necessary for interface i to receive packets sent to m from any one 628 of the sources a, b, c, or d. Thus, in this example, the listening 629 state of interface i for multicast address m has filter mode INCLUDE 630 and source list {a, b, c, d}. 632 After a multicast packet has been accepted from an interface by the 633 IP layer, its subsequent delivery to the application or process that 634 listens on a particular socket depends on the multicast listening 635 state of that socket (and possibly also on other conditions, such as 636 what transport-layer port the socket is bound to). So, in the above 637 example, if a packet arrives on interface i, destined to multicast 638 address m, with source address a, it may be delivered on socket s1 639 but not on socket s2. Note that MLDv2 messages are not subject to 640 source filtering and must always be processed by hosts and routers. 642 Requiring the filtering of packets based upon a socket's multicast 643 reception state is a new feature of this service interface. The 644 previous service interface described no filtering based upon 645 multicast listening state; rather, a Start Listening operation on a 646 socket simply caused the node to start to listen to a multicast 647 address on the given interface; packets sent to that multicast 648 address could be delivered to all sockets, whether they had started 649 to listen or not. 651 The general rules for deriving the per-interface state from the per- 652 socket state are as follows: for each distinct (interface, IPv6 653 multicast address) pair that appears in any per-socket state, a per- 654 interface record is created for that multicast address on that 655 interface. Considering all socket records that contain the same 656 (interface, IPv6 multicast address) pair, 658 * if any such record has a filter mode of EXCLUDE, then the filter 659 mode of the interface record is EXCLUDE, and the source list of 660 the interface record is the intersection of the source lists of 661 all socket records in EXCLUDE mode, minus those source addresses 662 that appear in any socket record in INCLUDE mode. For example, if 663 the socket records for multicast address m on interface i are: 665 from socket s1: ( i, m, EXCLUDE, {a, b, c, d} ) 667 from socket s2: ( i, m, EXCLUDE, {b, c, d, e} ) 669 from socket s3: ( i, m, INCLUDE, {d, e, f} ) 671 then the corresponding interface record on interface i is: 673 ( m, EXCLUDE, {b, c} ) 675 If a fourth socket is added, such as: 677 From socket s4: ( i, m, EXCLUDE, {} ) 679 then the interface record becomes: 681 ( m, EXCLUDE, {} ) 683 * if all such records have a filter mode of INCLUDE, then the filter 684 mode of the interface record is INCLUDE, and the source list of 685 the interface record is the union of the source lists of all the 686 socket records. For example, if the socket records for multicast 687 address m on interface i are: 689 from socket s1: ( i, m, INCLUDE, {a, b, c} ) 691 from socket s2: ( i, m, INCLUDE, {b, c, d} ) 693 from socket s3: ( i, m, INCLUDE, {e, f} ) 695 then the corresponding interface record on interface i is: 697 ( m, INCLUDE, {a, b, c, d, e, f} ) 699 An implementation MUST NOT use an EXCLUDE interface record for a 700 multicast address if all sockets for this multicast address are in 701 INCLUDE state. If system resource limits are reached when a per- 702 interface state source list is calculated, an error MUST be 703 returned to the application which requested the operation. 705 The above rules for deriving the per-interface state are 706 (re)evaluated whenever an IPv6MulticastListen invocation modifies the 707 per-socket state by adding, deleting, or modifying a per-socket state 708 record. Note that a change of the per-socket state does not 709 necessarily result in a change of the per-interface state. 711 5. Message Formats 713 MLDv2 is a sub-protocol of ICMPv6, that is, MLDv2 message types are a 714 subset of ICMPv6 messages, and MLDv2 messages are identified in IPv6 715 packets by a preceding Next Header value of 58. All MLDv2 messages 716 described in this document MUST be sent with a link-local IPv6 Source 717 Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option 718 [RFC2711] in a Hop-by-Hop Options header. (The Router Alert option 719 is necessary to cause routers to examine MLDv2 messages sent to IPv6 720 multicast addresses in which the routers themselves have no 721 interest.) MLDv2 Reports can be sent with the source address set to 722 the unspecified address [RFC3513], if a valid link-local IPv6 source 723 address has not been acquired yet for the sending interface. (See 724 Section 5.2.13. for details.) 726 There are two MLD message types of concern to the MLDv2 protocol 727 described in this document: 729 * Multicast Listener Query (Type = decimal 130) 730 * Version 2 Multicast Listener Report (Type = decimal 143). See 731 Section 11 for IANA considerations. 733 To assure the interoperability with nodes that implement MLDv1 (see 734 Section 8), an implementation of MLDv2 must also support the 735 following two message types: 737 * Version 1 Multicast Listener Report (Type = decimal 131) [RFC2710] 739 * Version 1 Multicast Listener Done (Type = decimal 132) [RFC2710] 741 Unrecognized message types MUST be silently ignored. Other message 742 types may be used by newer versions or extensions of MLD, by 743 multicast routing protocols, or for other uses. 745 In this document, unless otherwise qualified, the capitalized words 746 "Query" and "Report" refer to MLD Multicast Listener Queries and MLD 747 Version 2 Multicast Listener Reports, respectively. 749 5.1. Multicast Listener Query Message 751 Multicast Listener Queries are sent by multicast routers in Querier 752 State to query the multicast listening state of neighboring 753 interfaces. Queries have the following format: 755 0 1 2 3 756 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Type = 130 | Code | Checksum | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Maximum Response Code | Reserved | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | | 763 * * 764 | | 765 * Multicast Address * 766 | | 767 * * 768 | | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Resv |S| QRV | QQIC | Number of Sources (N) | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | | 773 * * 774 | | 775 * Source Address [1] * 776 | | 777 * * 778 | | 779 +- -+ 780 | | 781 * * 782 | | 783 * Source Address [2] * 784 | | 785 * * 786 | | 787 +- . -+ 788 . . . 789 . . . 790 +- -+ 791 | | 792 * * 793 | | 794 * Source Address [N] * 795 | | 796 * * 797 | | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 5.1.1. Code 802 Initialized to zero by the sender; ignored by receivers. 804 5.1.2. Checksum 806 The standard ICMPv6 checksum; it covers the entire MLDv2 message, 807 plus a "pseudo-header" of IPv6 header fields [RFC2463]. For 808 computing the checksum, the Checksum field is set to zero. When a 809 packet is received, the checksum MUST be verified before processing 810 it. 812 5.1.3. Maximum Response Code 814 The Maximum Response Code field specifies the maximum time allowed 815 before sending a responding Report. The actual time allowed, called 816 the Maximum Response Delay, is represented in units of milliseconds, 817 and is derived from the Maximum Response Code as follows: 819 If Maximum Response Code < 32768, Maximum Response Delay = Maximum 820 Response Code 822 If Maximum Response Code >=32768, Maximum Response Code represents a 823 floating-point value as follows: 825 0 1 2 3 4 5 6 7 8 9 A B C D E F 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 |1| exp | mant | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 Maximum Response Delay = (mant | 0x1000) << (exp+3) 832 Small values of Maximum Response Delay allow MLDv2 routers to tune 833 the "leave latency" (the time between the moment the last node on a 834 link ceases to listen to a specific multicast address and the moment 835 the routing protocol is notified that there are no more listeners for 836 that address). Larger values, especially in the exponential range, 837 allow the tuning of the burstiness of MLD traffic on a link. 839 5.1.4. Reserved 841 Initialized to zero by the sender; ignored by receivers. 843 5.1.5. Multicast Address 845 For a General Query, the Multicast Address field is set to zero. For 846 a Multicast Address Specific Query or Multicast Address and Source 847 Specific Query, it is set to the multicast address being queried (see 848 Section 5.1.10, below). 850 5.1.6. Resv 852 Initialized to zero by the sender; ignored by receivers. 854 5.1.7. S Flag (Suppress Router-Side Processing) 856 When set to one, the S Flag indicates to any receiving multicast 857 routers that they have to suppress the normal timer updates they 858 perform upon hearing a Query. Nevertheless, it does not suppress the 859 querier election or the normal "host-side" processing of a Query that 860 a router may be required to perform as a consequence of itself being 861 a multicast listener. 863 5.1.8. QRV (Querier's Robustness Variable) 865 If non-zero, the QRV field contains the [Robustness Variable] value 866 used by the Querier. If the Querier's [Robustness Variable] exceeds 867 7 (the maximum value of the QRV field), the QRV field is set to zero. 869 Routers adopt the QRV value from the most recently received Query as 870 their own [Robustness Variable] value, unless that most recently 871 received QRV was zero, in which case they use the default [Robustness 872 Variable] value specified in Section 9.1, or a statically configured 873 value. 875 5.1.9. QQIC (Querier's Query Interval Code) 877 The Querier's Query Interval Code field specifies the [Query 878 Interval] used by the Querier. The actual interval, called the 879 Querier's Query Interval (QQI), is represented in units of seconds, 880 and is derived from the Querier's Query Interval Code as follows: 882 If QQIC < 128, QQI = QQIC 884 If QQIC >= 128, QQIC represents a floating-point value as follows: 886 0 1 2 3 4 5 6 7 887 +-+-+-+-+-+-+-+-+ 888 |1| exp | mant | 889 +-+-+-+-+-+-+-+-+ 891 QQI = (mant | 0x10) << (exp + 3) 893 Multicast routers that are not the current Querier adopt the QQI 894 value from the most recently received Query as their own [Query 895 Interval] value, unless that most recently received QQI was zero, in 896 which case the receiving routers use the default [Query Interval] 897 value specified in Section 9.2. 899 5.1.10. Number of Sources (N) 901 The Number of Sources (N) field specifies how many source addresses 902 are present in the Query. This number is zero in a General Query or 903 a Multicast Address Specific Query, and non-zero in a Multicast 904 Address and Source Specific Query. This number is limited by the MTU 905 of the link over which the Query is transmitted. For example, on an 906 Ethernet link with an MTU of 1500 octets, the IPv6 header (40 octets) 907 together with the Hop-By-Hop Extension Header (8 octets) that 908 includes the Router Alert option consume 48 octets; the MLD fields up 909 to the Number of Sources (N) field consume 28 octets; thus, there are 910 1424 octets left for source addresses, which limits the number of 911 source addresses to 89 (1424/16). 913 5.1.11. Source Address [i] 915 The Source Address [i] fields are a vector of n unicast addresses, 916 where n is the value in the Number of Sources (N) field. 918 5.1.12. Additional Data 920 If the Payload Length field in the IPv6 header of a received Query 921 indicates that there are additional octets of data present, beyond 922 the fields described here, MLDv2 implementations MUST include those 923 octets in the computation to verify the received MLD Checksum, but 924 MUST otherwise ignore those additional octets. When sending a Query, 925 an MLDv2 implementation MUST NOT include additional octets beyond the 926 fields described above. 928 5.1.13. Query Variants 930 There are three variants of the Query message: 932 * A "General Query" is sent by the Querier to learn which multicast 933 addresses have listeners on an attached link. In a General Query, 934 both the Multicast Address field and the Number of Sources (N) 935 field are zero. 937 * A "Multicast Address Specific Query" is sent by the Querier to 938 learn if a particular multicast address has any listeners on an 939 attached link. In a Multicast Address Specific Query, the 940 Multicast Address field contains the multicast address of 941 interest, while the Number of Sources (N) field is set to zero. 943 * A "Multicast Address and Source Specific Query" is sent by the 944 Querier to learn if any of the sources from the specified list for 945 the particular multicast address has any listeners on an attached 946 link or not. In a Multicast Address and Source Specific Query the 947 Multicast Address field contains the multicast address of 948 interest, while the Source Address [i] field(s) contain(s) the 949 source address(es) of interest. 951 5.1.14. Source Addresses for Queries 953 All MLDv2 Queries MUST be sent with a valid IPv6 link-local source 954 address. If a node (router or host) receives a Query message with 955 the IPv6 Source Address set to the unspecified address (::), or any 956 other address that is not a valid IPv6 link-local address, it MUST 957 silently discard the message and SHOULD log a warning. 959 5.1.15. Destination Addresses for Queries 961 In MLDv2, General Queries are sent to the link-scope all-nodes 962 multicast address (FF02::1). Multicast Address Specific and 963 Multicast Address and Source Specific Queries are sent with an IP 964 destination address equal to the multicast address of interest. 965 However, a node MUST accept and process any Query whose IP 966 Destination Address field contains any of the addresses (unicast or 967 multicast) assigned to the interface on which the Query arrives. 968 This might be useful, e.g., for debugging purposes. 970 5.2. Version 2 Multicast Listener Report Message 972 Version 2 Multicast Listener Reports are sent by IP nodes to report 973 (to neighboring routers) the current multicast listening state, or 974 changes in the multicast listening state, of their interfaces. 975 Reports have the following format: 977 0 1 2 3 978 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 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Type = 143 | Reserved | Checksum | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Reserved |Nr of Mcast Address Records (M)| 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | | 985 . . 986 . Multicast Address Record [1] . 987 . . 988 | | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | | 991 . . 992 . Multicast Address Record [2] . 993 . . 994 | | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | . | 997 . . . 998 | . | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | | 1001 . . 1002 . Multicast Address Record [M] . 1003 . . 1004 | | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 Each Multicast Address Record has the following internal format: 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | Record Type | Aux Data Len | Number of Sources (N) | 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | | 1013 * * 1014 | | 1015 * Multicast Address * 1016 | | 1017 * * 1018 | | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | | 1021 * * 1022 | | 1023 * Source Address [1] * 1024 | | 1025 * * 1026 | | 1027 +- -+ 1028 | | 1029 * * 1030 | | 1031 * Source Address [2] * 1032 | | 1033 * * 1034 | | 1035 +- -+ 1036 . . . 1037 . . . 1038 . . . 1039 +- -+ 1040 | | 1041 * * 1042 | | 1043 * Source Address [N] * 1044 | | 1045 * * 1046 | | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | | 1049 . . 1050 . Auxiliary Data . 1051 . . 1052 | | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 5.2.1. Reserved 1057 The Reserved fields are set to zero on transmission, and ignored on 1058 reception. 1060 5.2.2. Checksum 1062 The standard ICMPv6 checksum; it covers the entire MLDv2 message, 1063 plus a "pseudo-header" of IPv6 header fields [RFC2460][RFC2463]. In 1064 order to compute the checksum, the Checksum field is set to zero. 1065 When a packet is received, the checksum MUST be verified before 1066 processing it. 1068 5.2.3. Nr of Mcast Address Records (M) 1070 The Nr of Mcast Address Records (M) field specifies how many 1071 Multicast Address Records are present in this Report. 1073 5.2.4. Multicast Address Record 1075 Each Multicast Address Record is a block of fields that contain 1076 information on the sender listening to a single multicast address on 1077 the interface from which the Report is sent. 1079 5.2.5. Record Type 1081 It specifies the type of the Multicast Address Record. See 1082 Section 5.2.12 for a detailed description of the different possible 1083 Record Types. 1085 5.2.6. Aux Data Len 1087 The Aux Data Len field contains the length of the Auxiliary Data 1088 Field in this Multicast Address Record, in units of 32-bit words. It 1089 may contain zero, to indicate the absence of any auxiliary data. 1091 5.2.7. Number of Sources (N) 1093 The Number of Sources (N) field specifies how many source addresses 1094 are present in this Multicast Address Record. 1096 5.2.8. Multicast Address 1098 The Multicast Address field contains the multicast address to which 1099 this Multicast Address Record pertains. 1101 5.2.9. Source Address [i] 1103 The Source Address [i] fields are a vector of n unicast addresses, 1104 where n is the value in this record's Number of Sources (N) field. 1106 5.2.10. Auxiliary Data 1108 The Auxiliary Data field, if present, contains additional information 1109 that pertain to this Multicast Address Record. The protocol 1110 specified in this document, MLDv2, does not define any auxiliary 1111 data. Therefore, implementations of MLDv2 MUST NOT include any 1112 auxiliary data (i.e., MUST set the Aux Data Len field to zero) in any 1113 transmitted Multicast Address Record, and MUST ignore any such data 1114 present in any received Multicast Address Record. The semantics and 1115 the internal encoding of the Auxiliary Data field are to be defined 1116 by any future version or extension of MLD that uses this field. 1118 5.2.11. Additional Data 1120 If the Payload Length field in the IPv6 header of a received Report 1121 indicates that there are additional octets of data present, beyond 1122 the last Multicast Address Record, MLDv2 implementations MUST include 1123 those octets in the computation to verify the received MLD Checksum, 1124 but MUST otherwise ignore those additional octets. When sending a 1125 Report, an MLDv2 implementation MUST NOT include additional octets 1126 beyond the last Multicast Address Record. 1128 5.2.12. Multicast Address Record Types 1130 There are a number of different types of Multicast Address Records 1131 that may be included in a Report message: 1133 * A "Current State Record" is sent by a node in response to a Query 1134 received on an interface. It reports the current listening state 1135 of that interface, with respect to a single multicast address. 1136 The Record Type of a Current State Record may be one of the 1137 following two values: 1139 1 - MODE_IS_INCLUDE - indicates that the interface has a filter 1140 mode of INCLUDE for the specified multicast address. The 1141 Source Address [i] fields in this Multicast Address Record 1142 contain the interface's source list for the specified 1143 multicast address. A MODE_IS_INCLUDE Record is never sent 1144 with an empty source list. 1146 2 - MODE_IS_EXCLUDE - indicates that the interface has a filter 1147 mode of EXCLUDE 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, if it is non-empty. 1152 * A "Filter Mode Change Record" is sent by a node whenever a local 1153 invocation of IPv6MulticastListen causes a change of the filter 1154 mode (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to 1155 INCLUDE) of the interface-level state entry for a particular 1156 multicast address, whether the source list changes at the same 1157 time or not. The Record is included in a Report sent from the 1158 interface on which the change occurred. The Record Type of a 1159 Filter Mode Change Record may be one of the following two values: 1161 3 - CHANGE_TO_INCLUDE_MODE - indicates that the interface has 1162 changed to INCLUDE filter mode for the specified multicast 1163 address. The Source Address [i] fields in this Multicast 1164 Address Record contain the interface's new source list for 1165 the specified multicast address, if it is non-empty. 1167 4 - CHANGE_TO_EXCLUDE_MODE - indicates that the interface has 1168 changed to EXCLUDE filter mode for the specified multicast 1169 address. The Source Address [i] fields in this Multicast 1170 Address Record contain the interface's new source list for 1171 the specified multicast address, if it is non-empty. 1173 * A "Source List Change Record" is sent by a node whenever a local 1174 invocation of IPv6MulticastListen causes a change of source list 1175 that is not coincident with a change of filter mode, of the 1176 interface-level state entry for a particular multicast address. 1177 The Record is included in a Report sent from the interface on 1178 which the change occurred. The Record Type of a Source List 1179 Change Record may be one of the following two values: 1181 5 - ALLOW_NEW_SOURCES - indicates that the Source Address [i] 1182 fields in this Multicast Address Record contain a list of the 1183 additional sources that the node wishes to listen to, for 1184 packets sent to the specified multicast address. If the 1185 change was to an INCLUDE source list, these are the addresses 1186 that were added to the list; if the change was to an EXCLUDE 1187 source list, these are the addresses that were deleted from 1188 the list. 1190 6 - BLOCK_OLD_SOURCES - indicates that the Source Address [i] 1191 fields in this Multicast Address Record contain a list of the 1192 sources that the node no longer wishes to listen to, for 1193 packets sent to the specified multicast address. If the 1194 change was to an INCLUDE source list, these are the addresses 1195 that were deleted from the list; if the change was to an 1196 EXCLUDE source list, these are the addresses that were added 1197 to the list. 1199 If a change of source list results in both allowing new sources and 1200 blocking old sources, then two Multicast Address Records are sent for 1201 the same multicast address, one of type ALLOW_NEW_SOURCES and one of 1202 type BLOCK_OLD_SOURCES. 1204 We use the term "State Change Record" to refer to either a Filter 1205 Mode Change Record or a Source List Change Record. 1207 Multicast Address Records with an unrecognized Record Type value MUST 1208 be silently ignored, with the rest of the report being processed. 1210 In the rest of this document, we use the following notation to 1211 describe the contents of a Multicast Address Record that pertains to 1212 a particular multicast address: 1214 IS_IN ( x ) - Type MODE_IS_INCLUDE, source addresses x 1215 IS_EX ( x ) - Type MODE_IS_EXCLUDE, source addresses x 1216 TO_IN ( x ) - Type CHANGE_TO_INCLUDE_MODE, source addresses x 1217 TO_EX ( x ) - Type CHANGE_TO_EXCLUDE_MODE, source addresses x 1218 ALLOW ( x ) - Type ALLOW_NEW_SOURCES, source addresses x 1219 BLOCK ( x ) - Type BLOCK_OLD_SOURCES, source addresses x 1221 where x is either: 1223 * a capital letter (e.g., "A") to represent the set of source 1224 addresses, or 1226 * a set expression (e.g., "A+B"), where "A+B" means the union of 1227 sets A and B, "A*B" means the intersection of sets A and B, and 1228 "A-B" means the removal of all elements of set B from set A. 1230 5.2.13. Source Addresses for Reports 1232 An MLDv2 Report MUST be sent with a valid IPv6 link-local source 1233 address, or the unspecified address (::), if the sending interface 1234 has not acquired a valid link-local address yet. Sending reports 1235 with the unspecified address is allowed to support the use of IP 1236 multicast in the Neighbor Discovery Protocol [RFC2461]. For 1237 stateless autoconfiguration, as defined in [RFC2462], a node is 1238 required to join several IPv6 multicast groups, in order to perform 1239 Duplicate Address Detection (DAD). Prior to DAD, the only address 1240 the reporting node has for the sending interface is a tentative one, 1241 which cannot be used for communication. Thus, the unspecified 1242 address must be used. 1244 On the other hand, routers MUST silently discard a message that is 1245 not sent with a valid link-local address, without taking any action 1246 on the contents of the packet. Thus, a Report is discarded if the 1247 router cannot identify the source address of the packet as belonging 1248 to a link connected to the interface on which the packet was 1249 received. A Report sent with the unspecified address is also 1250 discarded by the router. This enhances security, as unidentified 1251 reporting nodes cannot influence the state of the MLDv2 router(s). 1252 Nevertheless, the reporting node has modified its listening state for 1253 multicast addresses that are contained in the Multicast Address 1254 Records of the Report message. From now on, it will treat packets 1255 sent to those multicast addresses according to this new listening 1256 state. Once a valid link-local address is available, a node SHOULD 1257 generate new MLDv2 Report messages for all multicast addresses joined 1258 on the interface. 1260 5.2.14. Destination Addresses for Reports 1262 Version 2 Multicast Listener Reports are sent with an IP destination 1263 address of FF02:0:0:0:0:0:0:16, to which all MLDv2-capable multicast 1264 routers listen (see Section 11 for IANA considerations related to 1265 this special destination address). A node that operates in version 1 1266 compatibility mode (see details in Section 8) sends version 1 Reports 1267 to the multicast address specified in the Multicast Address field of 1268 the Report. In addition, a node MUST accept and process any version 1269 1 Report whose IP Destination Address field contains any of the IPv6 1270 addresses (unicast or multicast) assigned to the interface on which 1271 the Report arrives. This might be useful, e.g., for debugging 1272 purposes. 1274 5.2.15. Multicast Listener Report Size 1276 If the set of Multicast Address Records required in a Report does not 1277 fit within the size limit of a single Report message (as determined 1278 by the MTU of the link on which it will be sent), the Multicast 1279 Address Records are sent in as many Report messages as needed to 1280 report the entire set. 1282 If a single Multicast Address Record contains so many source 1283 addresses that it does not fit within the size limit of a single 1284 Report message, then: 1286 * if its Type is not IS_EX or TO_EX, it is split into multiple 1287 Multicast Address Records; each such record contains a different 1288 subset of the source addresses, and is sent in a separate Report. 1290 * if its Type is IS_EX or TO_EX, a single Multicast Address Record 1291 is sent, with as many source addresses as can fit; the remaining 1292 source addresses are not reported. Although the choice of which 1293 sources to report is arbitrary, it is preferable to report the 1294 same set of sources in each subsequent report, rather than 1295 reporting different sources each time. 1297 6. Protocol Description for Multicast Address Listeners 1299 MLD is an asymmetric protocol, as it specifies separate behaviors for 1300 multicast address listeners -- that is, hosts or routers that listen 1301 to multicast packets -- and multicast routers. This section 1302 describes the part of MLDv2 that applies to all multicast address 1303 listeners. (Note that a multicast router that is also a multicast 1304 address listener performs both parts of MLDv2; it receives and it 1305 responds to its own MLD messages, as well as to those of its 1306 neighbors.) The multicast router part of MLDv2 is described in 1307 Section 7. 1309 A node performs the protocol described in this section over all 1310 interfaces on which multicast reception is supported, even if more 1311 than one of those interfaces are connected to the same link. 1313 For interoperability with multicast routers that run the MLDv1 1314 protocol, nodes maintain a Host Compatibility Mode variable for each 1315 interface on which multicast reception is supported. This section 1316 describes the behavior of multicast address listener nodes on 1317 interfaces for which Host Compatibility Mode = MLDv2. The algorithm 1318 for determining Host Compatibility Mode, and the behavior if its 1319 value is set to MLDv1, are described in Section 8. 1321 The link-scope all-nodes multicast address, (FF02::1), is handled as 1322 a special case. On all nodes -- that is all hosts and routers, 1323 including multicast routers -- listening to packets destined to the 1324 all-nodes multicast address, from all sources, is permanently enabled 1325 on all interfaces on which multicast listening is supported. No MLD 1326 messages are ever sent regarding neither the link-scope all-nodes 1327 multicast address, nor any multicast address of scope 0 (reserved) or 1328 1 (node-local). Multicast listeners MUST send MLD messages for all 1329 multicast addresses except for the link-scope all-nodes multicast 1330 address and any multicast addresses of scope less than 2. 1332 There are three types of events that trigger MLDv2 protocol actions 1333 on an interface: 1335 * a change of the per-interface listening state, caused by a local 1336 invocation of IPv6MulticastListen; 1338 * the firing of a specific timer; 1340 * the reception of a Query. 1342 (Received MLD messages of types other than Query are silently 1343 ignored, except as required for interoperation with nodes that 1344 implement MLDv1.) 1346 The following subsections describe the actions to be taken for each 1347 case. Timer and counter names appear in square brackets. Default 1348 values for those timers and counters are specified in Section 9. 1350 6.1. Action on Change of Per-Interface State 1352 An invocation of IPv6MulticastListen may cause the multicast 1353 listening state of an interface to change, according to the rules in 1354 Section 4.2. Each such change affects the per-interface entry for a 1355 single multicast address. 1357 A change of per-interface state causes the node to immediately 1358 transmit a State Change Report from that interface. The type and 1359 contents of the Multicast Address Record(s) in that Report are 1360 determined by comparing the filter mode and source list for the 1361 affected multicast address before and after the change, according to 1362 the table below. If no per-interface state existed for that 1363 multicast address before the change (i.e., the change consisted of 1364 creating a new per-interface record), or if no state exists after the 1365 change (i.e., the change consisted of deleting a per-interface 1366 record), then the "non-existent" state is considered to have an 1367 INCLUDE filter mode and an empty source list. 1369 +=============+=============+==========================+ 1370 | Old State | New State | State Change Record Sent | 1371 +=============+=============+==========================+ 1372 | INCLUDE (A) | INCLUDE (B) | ALLOW (B-A), BLOCK (A-B) | 1373 +-------------+-------------+--------------------------+ 1374 | EXCLUDE (A) | EXCLUDE (B) | ALLOW (A-B), BLOCK (B-A) | 1375 +-------------+-------------+--------------------------+ 1376 | INCLUDE (A) | EXCLUDE (B) | TO_EX (B) | 1377 +-------------+-------------+--------------------------+ 1378 | EXCLUDE (A) | INCLUDE (B) | TO_IN (B) | 1379 +-------------+-------------+--------------------------+ 1381 Table 1 1383 If the computed source list for either an ALLOW or a BLOCK State 1384 Change Record is empty, that record is omitted from the Report. 1386 To cover the possibility of the State Change Report being missed by 1387 one or more multicast routers, [Robustness Variable] - 1 1388 retransmissions are scheduled, through a Retransmission Timer, at 1389 intervals chosen at random from the range (0, [Unsolicited Report 1390 Interval]). 1392 If more changes to the same per-interface state entry occur before 1393 all the retransmissions of the State Change Report for the first 1394 change have been completed, each such additional change triggers the 1395 immediate transmission of a new State Change Report. 1397 The contents of the new Report are calculated as follows: 1399 * As for the first Report, the per-interface state for the affected 1400 multicast address before and after the latest change is compared. 1402 * The records that express the difference are built according to the 1403 table above. Nevertheless, these records are not transmitted in a 1404 separate message, but they are instead merged with the contents of 1405 the pending report, to create the new State Change Report. The 1406 rules for calculating this merged report are described below. 1408 The transmission of the merged State Change Report terminates 1409 retransmissions of the earlier State Change Reports for the same 1410 multicast address, and becomes the first of [Robustness Variable] 1411 transmissions of the new State Change Reports. These transmissions 1412 are necessary in order to ensure that each instance of state change 1413 is transmitted at least [Robustness Variable] times. 1415 Each time a source is included in the difference report calculated 1416 above, retransmission state for that source needs to be maintained 1417 until [Robustness Variable] State Change Reports have been sent by 1418 the node. This is done in order to ensure that a series of 1419 successive state changes do not break the protocol robustness. 1420 Sources in retransmission state can be kept in a per multicast 1421 address Retransmission List, with a Source Retransmission Counter 1422 associated to each source in the list. When a source is included in 1423 the list, its counter is set to [Robustness Variable]. Each time a 1424 State Change Report is sent the counter is decreased by one unit. 1425 When the counter reaches zero, the source is deleted from the 1426 Retransmission List for that multicast address. 1428 If the per-interface listening change that triggers the new report is 1429 a filter mode change, then the next [Robustness Variable] State 1430 Change Reports will include a Filter Mode Change Record. This 1431 applies even if any number of source list changes occur in that 1432 period. The node has to maintain retransmission state for the 1433 multicast address until the [Robustness Variable] State Change 1434 Reports have been sent. This can be done through a per multicast 1435 address Filter Mode Retransmission Counter. When the filter mode 1436 changes, the counter is set to [Robustness Variable]. Each time a 1437 State Change Report is sent the counter is decreased by one unit. 1438 When the counter reaches zero, i.e., [Robustness Variable] State 1439 Change Reports with Filter Mode Change Records have been transmitted 1440 after the last filter mode change, and if source list changes have 1441 resulted in additional reports being scheduled, then the next State 1442 Change Report will include Source List Change Records. 1444 Each time a per-interface listening state change triggers the 1445 Immediate transmission of a new State Change Report, its contents are 1446 determined as follows. If the report should contain a Filter Mode 1447 Change Record, i.e., the Filter Mode Retransmission Counter for that 1448 multicast address has a value higher than zero, then, if the current 1449 filter mode of the interface is INCLUDE, a TO_IN record is included 1450 in the report; otherwise a TO_EX record is included. If instead the 1451 report should contain Source List Change Records, i.e., the Filter 1452 Mode Retransmission Counter for that multicast address is zero, an 1453 ALLOW and a BLOCK record is included. The contents of these records 1454 are built according to the table below. 1456 +========+======================================================+ 1457 | Record | Sources Included | 1458 +========+======================================================+ 1459 | TO_IN | All in the current per-interface state that must be | 1460 | | forwarded | 1461 +--------+------------------------------------------------------+ 1462 | TO_EX | All in the current per-interface state that must be | 1463 | | blocked | 1464 +--------+------------------------------------------------------+ 1465 | ALLOW | All with retransmission state (i.e., all sources | 1466 | | from the Retransmission List) that must be forwarded | 1467 +--------+------------------------------------------------------+ 1468 | BLOCK | All with retransmission state that must be blocked | 1469 +--------+------------------------------------------------------+ 1471 Table 2 1473 If the computed source list for either an ALLOW or a BLOCK record is 1474 empty, that record is omitted from the State Change Report. 1476 Note: When the first State Change Report is sent, the non-existent 1477 pending report to merge with can be treated as a Source Change Report 1478 with empty ALLOW and BLOCK records (no sources have retransmission 1479 state). 1481 The building of a scheduled State Change Report, triggered by the 1482 firing of a Retransmission Timer, instead of a per-interface 1483 listening state change, is described in Section 6.3. 1485 6.2. Action on Reception of a Query 1487 Upon reception of an MLD message that contains a Query, the node 1488 checks if the source address of the message is a valid link-local 1489 address, if the Hop Limit is set to 1, and if the Router Alert option 1490 is present in the Hop-By-Hop Options header of the IPv6 packet. If 1491 any of these checks fails, the packet is dropped. 1493 If the validity of the MLD message is verified, the node starts to 1494 process the Query. Instead of responding immediately, the node 1495 delays its response by a random amount of time, bounded by the 1496 Maximum Response Delay value derived from the Maximum Response Code 1497 in the received Query message. A node may receive a variety of 1498 Queries on different interfaces and of different kinds (e.g., General 1499 Queries, Multicast Address Specific Queries, and Multicast Address 1500 and Source Specific Queries), each of which may require its own 1501 delayed response. 1503 Before scheduling a response to a Query, the node must first consider 1504 previously scheduled pending responses and, in many cases, schedule a 1505 combined response. Therefore, for each of its interfaces on which it 1506 operates the listener part of the MLDv2 protocol, the node must be 1507 able to maintain the following state: 1509 * an Interface Timer for scheduling responses to General Queries; 1511 * a Multicast Address Timer for scheduling responses to Multicast 1512 Address (and Source) Specific Queries, for each multicast address 1513 the node has to report on; 1515 * a per-multicast-address list of sources to be reported in response 1516 to a Multicast Address and Source Specific Query. 1518 When a new valid General Query arrives on an interface, the node 1519 checks whether it has any per-interface listening state record to 1520 report on, or not. Similarly, when a new valid Multicast Address 1521 (and Source) Specific Query arrives on an interface, the node checks 1522 whether it has a per-interface listening state record that 1523 corresponds to the queried multicast address (and source), or not. 1524 If it does, a delay for a response is randomly selected in the range 1525 (0, [Maximum Response Delay]), where Maximum Response Delay is 1526 derived from the Maximum Response Code inserted in the received Query 1527 message. The following rules are then used to determine if a Report 1528 needs to be scheduled or not, and the type of Report to schedule. 1529 (The rules are considered in order and only the first matching rule 1530 is applied.) 1532 1. If there is a pending response to a previous General Query 1533 scheduled sooner than the selected delay, no additional response 1534 needs to be scheduled. 1536 2. If the received Query is a General Query, the Interface Timer is 1537 used to schedule a response to the General Query after the 1538 selected delay. Any previously pending response to a General 1539 Query is canceled. 1541 3. If the received Query is a Multicast Address Specific Query or a 1542 Multicast Address and Source Specific Query and there is no 1543 pending response to a previous Query for this multicast address, 1544 then the Multicast Address Timer is used to schedule a report. 1545 If the received Query is a Multicast Address and Source Specific 1546 Query, the list of queried sources is recorded to be used when 1547 generating a response. 1549 4. If there is already a pending response to a previous Query 1550 scheduled for this multicast address, and either the new Query is 1551 a Multicast Address Specific Query or the recorded source list 1552 associated with the multicast address is empty, then the 1553 multicast address source list is cleared and a single response is 1554 scheduled, using the Multicast Address Timer. The new response 1555 is scheduled to be sent at the earliest of the remaining time for 1556 the pending report and the selected delay. 1558 5. If the received Query is a Multicast Address and Source Specific 1559 Query and there is a pending response for this multicast address 1560 with a non-empty source list, then the multicast address source 1561 list is augmented to contain the list of sources in the new 1562 Query, and a single response is scheduled using the Multicast 1563 Address Timer. The new response is scheduled to be sent at the 1564 earliest of the remaining time for the pending report and the 1565 selected delay. 1567 6.3. Action on Timer Expiration 1569 There are several timers that, upon expiration, trigger protocol 1570 actions on an MLDv2 Multicast Address Listener node. All these 1571 actions are related to pending reports scheduled by the node. 1573 1. If the expired timer is the Interface Timer (i.e., there is a 1574 pending response to a General Query), then one Current State 1575 Record is sent for each multicast address for which the specified 1576 interface has listening state, as described in Section 4.2. The 1577 Current State Record carries the multicast address and its 1578 associated filter mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and 1579 Source list. Multiple Current State Records are packed into 1580 individual Report messages, to the extent possible. 1582 This naive algorithm may result in bursts of packets when a node 1583 listens to a large number of multicast addresses. Instead of 1584 using a single Interface Timer, implementations are recommended 1585 to spread transmission of such Report messages over the interval 1586 (0, [Maximum Response Delay]). Note that any such implementation 1587 MUST avoid the "ack-implosion" problem, i.e., MUST NOT send a 1588 Report immediately upon reception of a General Query. 1590 2. If the expired timer is a Multicast Address Timer and the list of 1591 recorded sources for that multicast address is empty (i.e., there 1592 is a pending response to a Multicast Address Specific Query), 1593 then if, and only if, the interface has listening state for that 1594 multicast address, a single Current State Record is sent for that 1595 address. The Current State Record carries the multicast address 1596 and its associated filter mode (MODE_IS_INCLUDE or 1597 MODE_IS_EXCLUDE) and source list, if any. 1599 3. If the expired timer is a Multicast Address Timer and the list of 1600 recorded sources for that multicast address is non-empty (i.e., 1601 there is a pending response to a Multicast Address and Source 1602 Specific Query), then if, and only if, the interface has 1603 listening state for that multicast address, the contents of the 1604 corresponding Current State Record are determined from the per- 1605 interface state and the pending response record, as specified in 1606 the following table: 1608 +=====================+=========================+==============+ 1609 | per-interface state | set of sources in the | Current | 1610 | | pending response record | State Record | 1611 +=====================+=========================+==============+ 1612 | INCLUDE (A) | B | IS_IN (A*B) | 1613 +---------------------+-------------------------+--------------+ 1614 | EXCLUDE (A) | B | IS_IN (B-A) | 1615 +---------------------+-------------------------+--------------+ 1617 Table 3 1619 If the resulting Current State Record has an empty set of source 1620 addresses, then no response is sent. After the required Report 1621 messages have been generated, the source lists associated with any 1622 reported multicast addresses are cleared. 1624 4. If the expired timer is a Retransmission Timer for a multicast 1625 address (i.e., there is a pending State Change Report for that 1626 multicast address), the contents of the report are determined as 1627 follows. If the report should contain a Filter Mode Change 1628 Record, i.e., the Filter Mode Retransmission Counter for that 1629 multicast address has a value higher than zero, then, if the 1630 current filter mode of the interface is INCLUDE, a TO_IN record 1631 is included in the report; otherwise a TO_EX record is included. 1632 In both cases, the Filter Mode Retransmission Counter for that 1633 multicast address is decremented by one unit after the 1634 transmission of the report. 1636 If instead the report should contain Source List Change Records, 1637 i.e., the Filter Mode Retransmission Counter for that multicast 1638 address is zero, an ALLOW and a BLOCK record is included. The 1639 contents of these records are built according to the table below: 1641 +========+=====================================================+ 1642 | Record | Sources included | 1643 +========+=====================================================+ 1644 | TO_IN | All in the current per-interface state that must be | 1645 | | forwarded | 1646 +--------+-----------------------------------------------------+ 1647 | TO_EX | All in the current per-interface state that must be | 1648 | | blocked | 1649 +--------+-----------------------------------------------------+ 1650 | ALLOW | All with retransmission state (i.e., all sources | 1651 | | from the Retransmission List) that must be | 1652 | | forwarded. For each included source, its Source | 1653 | | Retransmission Counter is decreased with one unit | 1654 | | after the transmission of the report. If the | 1655 | | counter reaches zero, the source is deleted from | 1656 | | the Retransmission List for that multicast address. | 1657 +--------+-----------------------------------------------------+ 1658 | BLOCK | All with retransmission state (i.e., all sources | 1659 | | from the Retransmission List) that must be blocked. | 1660 | | For each included source, its Source Retransmission | 1661 | | Counter is decreased with one unit after the | 1662 | | transmission of the report. If the counter reaches | 1663 | | zero, the source is deleted from the Retransmission | 1664 | | List for that multicast address. | 1665 +--------+-----------------------------------------------------+ 1667 Table 4 1669 If the computed source list for either an ALLOW or a BLOCK record is 1670 empty, that record is omitted from the State Change Report. 1672 7. Description of the Protocol for Multicast Routers 1674 The purpose of MLD is to enable each multicast router to learn, for 1675 each of its directly attached links, which multicast addresses have 1676 listeners on that link. MLD version 2 adds the capability for a 1677 multicast router to also learn which sources have listeners among the 1678 neighboring nodes, for packets sent to any particular multicast 1679 address. The information gathered by MLD is provided to whichever 1680 multicast routing protocol is used by the router, in order to ensure 1681 that multicast packets are delivered to all links where there are 1682 interested listeners. 1684 This section describes the part of MLDv2 that is performed by 1685 multicast routers. Multicast routers may themselves become multicast 1686 address listeners, and therefore also perform the multicast listener 1687 part of MLDv2, described in Section 6. 1689 A multicast router performs the protocol described in this section 1690 over each of its directly attached links. If a multicast router has 1691 more than one interface to the same link, it only needs to operate 1692 this protocol over one of those interfaces. 1694 For each interface over which the router operates the MLD protocol, 1695 the router must configure that interface to listen to all link-layer 1696 multicast addresses that can be generated by IPv6 multicasts. For 1697 example, an Ethernet-attached router must set its Ethernet address 1698 reception filter to accept all Ethernet multicast addresses that 1699 start with the hexadecimal value 3333 [RFC2464]; in the case of an 1700 Ethernet interface that does not support the filtering of such a 1701 multicast address range, it must be configured to accept ALL Ethernet 1702 multicast addresses, in order to meet the requirements of MLD. 1704 On each interface over which this protocol is being run, the router 1705 MUST enable reception of the link-scope "all MLDv2-capable routers" 1706 multicast address from all sources, and MUST perform the multicast 1707 address listener part of MLDv2 for that address on that interface. 1709 Multicast routers only need to know that at least one node on an 1710 attached link listens to packets for a particular multicast address 1711 from a particular source; a multicast router is not required to 1712 individually keep track of the interests of each neighboring node. 1713 (Nevertheless, see Appendix A.2 item 1 for discussion.) 1715 MLDv2 is backward compatible with the MLDv1 protocol. For a detailed 1716 description of compatibility issues see Section 8. 1718 7.1. Conditions for MLD Queries 1720 The behavior of a router that implements the MLDv2 protocol depends 1721 on whether there are several multicast routers on the same subnet, or 1722 not. If it is the case, a querier election mechanism (described in 1723 Section 7.6.2) is used to elect a single multicast router to be in 1724 Querier state. All the multicast routers on the subnet listen to the 1725 messages sent by multicast address listeners, and maintain the same 1726 multicast listening information state, so that they can quickly and 1727 correctly take over the querier functionality, should the present 1728 Querier fail. Nevertheless, it is only the Querier that sends 1729 periodical or triggered query messages on the subnet. 1731 The Querier periodically sends General Queries to request Multicast 1732 Address Listener information from an attached link. These queries 1733 are used to build and refresh the Multicast Address Listener state of 1734 routers on attached links. 1736 Nodes respond to these queries by reporting their Multicast Address 1737 Listening state (and set of sources they listen to) with Current 1738 State Multicast Address Records in MLDv2 Multicast Listener Reports. 1740 As a listener of a multicast address, a node may express interest in 1741 listening or not listening to traffic from particular sources. As 1742 the desired listening state of a node changes, it reports these 1743 changes using Filter Mode Change Records or Source List Change 1744 Records. These records indicate an explicit state change in a 1745 multicast address at a node in either the Multicast Address Record's 1746 source list or its filter mode. When Multicast Address Listening is 1747 terminated at a node or traffic from a particular source is no longer 1748 desired, the Querier must query for other listeners of the multicast 1749 address or of the source before deleting the multicast address (or 1750 source) from its Multicast Address Listener state and pruning its 1751 traffic. 1753 To enable all nodes on a link to respond to changes in multicast 1754 address listening, the Querier sends specific queries. A Multicast 1755 Address Specific Query is sent to verify that there are no nodes that 1756 listen to the specified multicast address or to "rebuild" the 1757 listening state for a particular multicast address. Multicast 1758 Address Specific Queries are sent when the Querier receives a State 1759 Change Record indicating that a node ceases to listen to a multicast 1760 address. They are also sent in order to enable a fast transition of 1761 a router from EXCLUDE to INCLUDE mode, in case a received State 1762 Change Record motivates this action. 1764 A Multicast Address and Source Specific Query is used to verify that 1765 there are no nodes on a link which listen to traffic from a specific 1766 set of sources. Multicast Address and Source Specific Queries list 1767 sources for a particular multicast address which have been requested 1768 to no longer be forwarded. This query is sent by the Querier in 1769 order to learn if any node listens to packets sent to the specified 1770 multicast address, from the specified source addresses. Multicast 1771 Address and Source Specific Queries are only sent in response to 1772 State Change Records and never in response to Current State Records. 1773 Section 5.1.13 describes each query in more detail. 1775 7.2. MLD State Maintained by Multicast Routers 1777 Multicast routers that implement the MLDv2 protocol keep state per 1778 multicast address per attached link. This multicast address state 1779 consists of a filter mode, a list of sources, and various timers. 1780 For each attached link on which MLD runs, a multicast router records 1781 the listening state for that link. That state conceptually consists 1782 of a set of records of the form: 1784 (IPv6 multicast address, Filter Timer, 1785 Router Filter Mode, (source records) ) 1787 Each source record is of the form: 1789 (IPv6 source address, source timer) 1791 If all sources for a multicast address are listened to, an empty 1792 source record list is kept with the Router Filter Mode set to 1793 EXCLUDE. This means that nodes on this link want all sources for 1794 this multicast address to be forwarded. This is the MLDv2 equivalent 1795 of an MLDv1 listening state. 1797 7.2.1. Definition of Router Filter Mode 1799 To reduce internal state, MLDv2 routers keep a filter mode per 1800 multicast address per attached link. This filter mode is used to 1801 summarize the total listening state of a multicast address to a 1802 minimum set such that all nodes' listening states are respected. The 1803 filter mode may change in response to the reception of particular 1804 types of Multicast Address Records or when certain timer conditions 1805 occur. In the following sections, we use the term "Router Filter 1806 Mode" to refer to the filter mode of a particular multicast address 1807 within a router. Section 7.4 describes the changes of the Router 1808 Filter Mode per Multicast Address Record received. 1810 A router is in INCLUDE mode for a specific multicast address on a 1811 given interface if all the listeners on the link interested in that 1812 address are in INCLUDE mode. The router state is represented through 1813 the notation INCLUDE (A), where A is called the "Include List". The 1814 Include List is the set of sources that one or more listeners on the 1815 link have requested to receive. All the sources from the Include 1816 List will be forwarded by the router. Any other source that is not 1817 in the Include List will be blocked by the router. 1819 A router is in EXCLUDE mode for a specific multicast address on a 1820 given interface if there is at least one listener in EXCLUDE mode 1821 interested in that address on the link. Conceptually, when a 1822 Multicast Address Record is received, the Router Filter Mode for that 1823 multicast address is updated to cover all the requested sources using 1824 the least amount of state. As a rule, once a Multicast Address 1825 Record with a filter mode of EXCLUDE is received, the Router Filter 1826 Mode for that multicast address will be set to EXCLUDE. 1827 Nevertheless, if all nodes with a multicast address record having 1828 filter mode set to EXCLUDE cease reporting, it is desirable for the 1829 Router Filter Mode for that multicast address to transition back to 1830 INCLUDE mode. This transition occurs when the Filter Timer expires, 1831 and is explained in detail in Section 7.5. 1833 When the router is in EXCLUDE mode, the router state is represented 1834 through the notation EXCLUDE (X,Y), where X is called the "Requested 1835 List" and Y is called the "Exclude List". All sources, except those 1836 from the Exclude List, will be forwarded by the router. The 1837 Requested List has no effect on forwarding. Nevertheless, it has to 1838 be maintained for several reasons, as explained in Section 7.2.3. 1840 The exact handling of both the INCLUDE and EXCLUDE mode router state, 1841 according to the received reports, is presented in details in 1842 Section 7.4.1 and Section 7.4.2. 1844 7.2.2. Definition of Filter Timers 1846 The Filter Timer is only used when the router is in EXCLUDE mode for 1847 a specific multicast address, and it represents the time for the 1848 Router Filter Mode of the multicast address to expire and switch to 1849 INCLUDE mode. A Filter Timer is a decrementing timer with a lower 1850 bound of zero. One Filter Timer exists per multicast address record. 1851 Filter Timers are updated according to the types of Multicast Address 1852 Records received. 1854 If a Filter Timer expires, with the Router Filter Mode for that 1855 multicast address being EXCLUDE, it means that there are no more 1856 listeners in EXCLUDE mode on the attached link. At this point, the 1857 router transitions to INCLUDE filter mode. Section 7.5 describes the 1858 actions taken when a Filter Timer expires while in EXCLUDE mode. 1860 The following table summarizes the role of the Filter Timer. 1861 Section 7.4 describes the details of setting the Filter Timer per 1862 type of Multicast Address Record received. 1864 +=========+========+================================================+ 1865 | Router | Filter | Actions/Comments | 1866 | Filter | Timer | | 1867 | Mode | Value | | 1868 +=========+========+================================================+ 1869 | INCLUDE | Not | All listeners in INCLUDE mode. | 1870 | | Used | | 1871 +---------+--------+------------------------------------------------+ 1872 | EXCLUDE | Timer | At least one listener in EXCLUDE mode. | 1873 | | > 0 | | 1874 +---------+--------+------------------------------------------------+ 1875 | EXCLUDE | Timer | No more listeners in EXCLUDE mode for | 1876 | | == 0 | the multicast address. If the Requested | 1877 | | | List is empty, delete Multicast Address | 1878 | | | Record. If not, switch to INCLUDE | 1879 | | | filter mode; the sources in the | 1880 | | | Requested List are moved to the Include | 1881 | | | List, and the Exclude List is deleted. | 1882 +---------+--------+------------------------------------------------+ 1884 Table 5 1886 7.2.3. Definition of Source Timers 1888 A Source Timer is a decrementing timer with a lower bound of zero. 1889 One Source Timer is kept per source record. Source timers are 1890 updated according to the type and filter mode of the Multicast 1891 Address Record received. Section 7.4 describes the setting of source 1892 timers per type of Multicast Address Records received. 1894 In the following, abbreviations are used for several variables (all 1895 of which are described in detail in Section 9). The variable MALI 1896 stands for the Multicast Address Listening Interval, which is the 1897 time in which multicast address listening state will time out. The 1898 variable LLQT is the Last Listener Query Time, which is the total 1899 time the router should wait for a report, after the Querier has sent 1900 the first query. During this time, the Querier should send [Last 1901 Member Query Count]-1 retransmissions of the query. LLQT represents 1902 the "leave latency", or the difference between the transmission of a 1903 listener state change and the modification of the information passed 1904 to the routing protocol. 1906 If the router is in INCLUDE filter mode, a source can be added to the 1907 current Include List if a listener in INCLUDE mode sends a Current 1908 State or a State Change Report which includes that source. Each 1909 source from the Include List is associated with a source timer that 1910 is updated whenever a listener in INCLUDE mode sends a report that 1911 confirms its interest in that specific source. If the timer of a 1912 source from the Include List expires, the source is deleted from the 1913 Include List. If there are no more source records left, the 1914 multicast address record is deleted from the router. 1916 Besides this "soft leave" mechanism, there is also a "fast leave" 1917 scheme in MLDv2; it is also based on the use of source timers. When 1918 a node in INCLUDE mode expresses its desire to stop listening to a 1919 specific source, all the multicast routers on the link lower their 1920 timer for that source to a small interval of LLQT milliseconds. The 1921 Querier then sends then a Multicast Address and Source Specific 1922 Query, to verify whether there are other listeners for that source on 1923 the link, or not. If a corresponding report is received before the 1924 timer expires, all the multicast routers on the link update their 1925 source timer. If not, the source is deleted from the Include List. 1926 The handling of the Include List, according to the received reports, 1927 is detailed in Section 7.4.1 and Section 7.4.2. 1929 Source timers are treated differently when the Router Filter Mode for 1930 a multicast address is EXCLUDE. For sources from the Requested List 1931 the source timers have running values; these sources are forwarded by 1932 the router. For sources from the Exclude List the source timers are 1933 set to zero; these sources are blocked by the router. If the timer 1934 of a source from the Requested List expires, the source is moved to 1935 the Exclude List. The router informs then the routing protocol that 1936 there is no longer a listener on the link interested in traffic from 1937 this source. 1939 The router has to maintain the Requested List for two reasons: 1941 * To keep track of sources that listeners in INCLUDE mode listen to. 1942 This is necessary in order to assure a seamless transition of the 1943 router to INCLUDE mode, when there will be no listener in EXCLUDE 1944 mode left. This transition should not interrupt the flow of 1945 traffic to the listeners in INCLUDE mode still interested in that 1946 multicast address. Therefore, at the moment of the transition, 1947 the Requested List should represent the set of sources that nodes 1948 in INCLUDE mode have explicitly requested. 1950 When the router switches to INCLUDE mode, the sources in the 1951 Requested List are moved to the Include List, and the Exclude List 1952 is deleted. Before the switch, the Requested List can contain an 1953 inexact guess at the sources that listeners in INCLUDE mode listen 1954 to - might be too large or too small. These inexactitudes are due 1955 to the fact that the Requested List is also used for fast blocking 1956 purposes, as described below. If such a fast blocking is 1957 required, some sources may be deleted from the Requested List (as 1958 shown in Section 7.4.1 and Section 7.4.2) in order to reduce 1959 router state. Nevertheless, in each such case the Filter Timer is 1960 updated as well. Therefore, listeners in INCLUDE mode will have 1961 enough time, before an eventual switching, to reconfirm their 1962 interest in the eliminated source(s), and rebuild the Requested 1963 List accordingly. The protocol ensures that when a switch to 1964 INCLUDE mode occurs, the Requested List will be accurate. Details 1965 about the transition of the router to INCLUDE mode are presented 1966 in Appendix A.3. 1968 * To allow a fast blocking of previously unblocked sources. If the 1969 router receives a report that contains such a request, the 1970 concerned sources are added to the Requested List. Their timers 1971 are set to a small interval of LLQT milliseconds, and a Multicast 1972 Address and Source Specific Query is sent by the Querier, to check 1973 whether there are nodes on the link still interested in those 1974 sources, or not. If no node confirms its interest in receiving a 1975 specific source, the timer of that source expires. Then, the 1976 source is moved from the Requested List to the Exclude List. From 1977 then on, the source will be blocked by the router. 1979 The handling of the EXCLUDE mode router state, according to the 1980 received reports, is detailed in Section 7.4.1 and Section 7.4.2. 1982 When the Router Filter Mode for a multicast address is EXCLUDE, 1983 source records are only deleted when the Filter Timer expires, or 1984 when newly received Multicast Address Records modify the source 1985 record list of the router. 1987 7.3. MLDv2 Source Specific Forwarding Rules 1989 When a multicast router receives a datagram from a source destined to 1990 a particular multicast address, a decision has to be made whether to 1991 forward the datagram on an attached link or not. The multicast 1992 routing protocol in use is in charge of this decision, and should use 1993 the MLDv2 information to ensure that all sources/multicast addresses 1994 that have listeners on a link are forwarded to that link. MLDv2 1995 information does not override multicast routing information; for 1996 example, if the MLDv2 filter mode for a multicast address is EXCLUDE, 1997 a router may still forward packets for excluded sources to a transit 1998 link. 2000 To summarize, the following table describes the forwarding 2001 suggestions made by MLDv2 to the routing protocol for traffic 2002 originating from a source destined to a multicast address. It also 2003 summarizes the actions taken upon the expiration of a source timer 2004 based on the Router Filter Mode of the multicast address. 2006 +=========+=========+=======================================+ 2007 | Router | Source | Action | 2008 | Filter | Timer | | 2009 | Mode | Value | | 2010 +=========+=========+=======================================+ 2011 | INCLUDE | TIMER > | Suggest to forward traffic from | 2012 | | 0 | source | 2013 +---------+---------+---------------------------------------+ 2014 | INCLUDE | TIMER | Suggest to stop forwarding traffic | 2015 | | == 0 | from source and remove source record. | 2016 | | | If there are no more source records, | 2017 | | | delete multicast address record | 2018 +---------+---------+---------------------------------------+ 2019 | EXCLUDE | TIMER > | Suggest to forward traffic from | 2020 | | 0 | source | 2021 +---------+---------+---------------------------------------+ 2022 | EXCLUDE | TIMER | Suggest to not forward traffic from | 2023 | | == 0 | source. Move the source from the | 2024 | | | Requested List to the Exclude List | 2025 | | | (DO NOT remove source record) | 2026 +---------+---------+---------------------------------------+ 2027 | EXCLUDE | No | Suggest to forward traffic from all | 2028 | | Source | sources | 2029 | | Element | | 2030 +---------+---------+---------------------------------------+ 2032 Table 6 2034 7.4. Action on Reception of Reports 2036 Upon reception of an MLD message that contains a Report, the router 2037 checks if the source address of the message is a valid link-local 2038 address, if the Hop Limit is set to 1, and if the Router Alert option 2039 is present in the Hop-By-Hop Options header of the IPv6 packet. If 2040 any of these checks fails, the packet is dropped. If the validity of 2041 the MLD message is verified, the router starts to process the Report. 2043 7.4.1. Reception of Current State Records 2045 When receiving Current State Records, a router updates both its 2046 Filter Timer and its source timers. In some circumstances, the 2047 reception of a type of multicast address record will cause the Router 2048 Filter Mode for that multicast address to change. The table below 2049 describes the actions, with respect to state and timers, that occur 2050 to a router's state upon reception of Current State Records. 2052 If the router is in INCLUDE filter mode for a multicast address, we 2053 will use the notation INCLUDE (A), where A denotes the associated 2054 Include List. If the router is in EXCLUDE filter mode for a 2055 multicast address, we will use the notation EXCLUDE (X,Y), where X 2056 and Y denote the associated Requested List and Exclude List 2057 respectively. 2059 Within the "Actions" section of the router state tables, we use the 2060 notation '(A)=J', which means that the set A of source records should 2061 have their source timers set to value J. 'Delete (A)' means that the 2062 set A of source records should be deleted. 'Filter Timer = J' means 2063 that the Filter Timer for the multicast address should be set to 2064 value J. 2066 Router State Report Received New Router State Actions 2067 ------------ --------------- ---------------- ------- 2069 INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B)=MALI 2071 INCLUDE (A) IS_EX (B) EXCLUDE (A*B, B-A) (B-A)=0 2072 Delete (A-B) 2073 Filter Timer=MALI 2075 EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+A, Y-A) (A)=MALI 2077 EXCLUDE (X,Y) IS_EX (A) EXCLUDE (A-Y, Y*A) (A-X-Y)=MALI 2078 Delete (X-A) 2079 Delete (Y-A) 2080 Filter Timer=MALI 2082 7.4.2. Reception of Filter Mode Change and Source List Change Records 2084 When a change in the global state of a multicast address occurs in a 2085 node, the node sends either a Source List Change Record or a Filter 2086 Mode Change Record for that multicast address. As with Current State 2087 Records, routers must act upon these records and possibly change 2088 their own state to reflect the new listening state of the link. 2090 The Querier must query sources or multicast addresses that are 2091 requested to be no longer forwarded. When a router queries or 2092 receives a query for a specific set of sources, it lowers its source 2093 timers for those sources to a small interval of Last Listener Query 2094 Time milliseconds. If multicast address records are received in 2095 response to the queries which express interest in listening the 2096 queried sources, the corresponding timers are updated. 2098 Multicast Address Specific queries can also be used in order to 2099 enable a fast transition of a router from EXCLUDE to INCLUDE mode, in 2100 case a received Multicast Address Record motivates this action. The 2101 Filter Timer for that multicast address is lowered to a small 2102 interval of Last Listener Query Time milliseconds. If any multicast 2103 address records that express EXCLUDE mode interest in the multicast 2104 address are received within this interval, the Filter Timer is 2105 updated and the suggestion to the routing protocol to forward the 2106 multicast address stands without any interruption. If not, the 2107 router will switch to INCLUDE filter mode for that multicast address. 2109 During the query period (i.e., Last Listener Query Time milliseconds) 2110 the MLD component in the router continues to suggest to the routing 2111 protocol to forward traffic from the multicast addresses or sources 2112 that are queried. It is not until after Last Listener Query Time 2113 milliseconds without receiving a record that expresses interest in 2114 the queried multicast address or sources that the router may prune 2115 the multicast address or sources from the link. 2117 The following table describes the changes in multicast address state 2118 and the action(s) taken when receiving either Filter Mode Change or 2119 Source List Change Records. This table also describes the queries 2120 which are sent by the Querier when a particular report is received. 2122 We use the following notation for describing the queries that are 2123 sent. We use the notation 'Q(MA)' to describe a Multicast Address 2124 Specific Query to the MA multicast address. We use the notation 2125 'Q(MA,A)' to describe a Multicast Address and Source Specific Query 2126 to the MA multicast address with source list A. If source list A is 2127 null as a result of the action (e.g. A*B), then no query is sent as 2128 a result of the operation. 2130 In order to maintain protocol robustness, queries defined in the 2131 Actions column of the table below need to be transmitted [Last 2132 Listener Query Count] times, once every [Last Listener Query 2133 Interval] period. 2135 If while scheduling new queries, there are already pending queries to 2136 be retransmitted for the same multicast address, the new and pending 2137 queries have to be merged. In addition, received host reports for a 2138 multicast address with pending queries may affect the contents of 2139 those queries. Section 7.6.3 describes the process of building and 2140 maintaining the state of pending queries. 2142 Router State Report Received New Router State Actions 2143 ------------ --------------- ---------------- ------- 2144 INCLUDE (A) ALLOW (B) INCLUDE(A+B) (B)=MALI 2146 INCLUDE (A) BLOCK (B) INCLUDE(A) Send Q(MA,A*B) 2148 INCLUDE (A) TO_EX (B) EXCLUDE(A*B,B-A) (B-A)=0 2149 Delete (A-B) 2150 Send Q(MA,A*B) 2151 Filter Timer=MALI 2153 INCLUDE (A) TO_IN (B) INCLUDE(A+B) (B)=MALI 2154 Send Q(MA,A-B) 2156 EXCLUDE (X,Y) ALLOW (A) EXCLUDE(X+A,Y-A) (A)=MALI 2158 EXCLUDE (X,Y) BLOCK (A) EXCLUDE(X+(A-Y),Y) (A-X-Y)=Filter Timer 2159 Send Q(MA,A-Y) 2161 EXCLUDE (X,Y) TO_EX (A) EXCLUDE(A-Y,Y*A) (A-X-Y)=Filter Timer 2162 Delete (X-A) 2163 Delete (Y-A) 2164 Send Q(MA,A-Y) 2165 Filter Timer=MALI 2167 EXCLUDE (X,Y) TO_IN (A) EXCLUDE(X+A,Y-A) (A)=MALI 2168 Send Q(MA,X-A) 2169 Send Q(MA) 2171 7.5. Switching Router Filter Modes 2173 The Filter Timer is used as a mechanism for transitioning the Router 2174 Filter Mode from EXCLUDE to INCLUDE. 2176 When a Filter Timer expires with a Router Filter Mode of EXCLUDE, a 2177 router assumes that there are no nodes with a filter mode of EXCLUDE 2178 present on the attached link. Thus, the router transitions to 2179 INCLUDE filter mode for the multicast address. 2181 A router uses the sources from the Requested List as its state for 2182 the switch to a filter mode of INCLUDE. Sources from the Requested 2183 List are moved in the Include List, while sources from the Exclude 2184 List are deleted. For example, if a router's state for a multicast 2185 address is EXCLUDE(X,Y) and the Filter Timer expires for that 2186 multicast address, the router switches to filter mode of INCLUDE with 2187 state INCLUDE(X). If at the moment of the switch the Requested List 2188 (X) is empty, the multicast address record is deleted from the 2189 router. 2191 7.6. Action on Reception of Queries 2193 Upon reception of an MLD message that contains a Query, the router 2194 checks if the source address of the message is a valid link-local 2195 address, if the Hop Limit is set to 1, and if the Router Alert option 2196 is present in the Hop-By-Hop Options header of the IPv6 packet. If 2197 any of these checks fails, the packet is dropped. 2199 If the validity of the MLD message is verified, the router starts to 2200 process the Query. 2202 7.6.1. Timer Updates 2204 MLDv2 uses the Suppress Router-Side Processing flag to ensure 2205 robustness, as explained in Section 2.1. When a router sends or 2206 receives a query with a clear Suppress Router-Side Processing flag, 2207 it must update its timers to reflect the correct timeout values for 2208 the multicast address or sources being queried. The following table 2209 describes the timer actions when sending or receiving a Multicast 2210 Address Specific or Multicast Address and Source Specific Query with 2211 the Suppress Router-Side Processing flag not set. 2213 Query Action 2214 ----- ------ 2215 Q(MA,A) Source Timers for sources in A are lowered to LLQT 2216 Q(MA) Filter Timer is lowered to LLQT 2218 When a router sends or receives a query with the Suppress Router-Side 2219 Processing flag set, it will not update its timers. 2221 7.6.2. Querier Election 2223 MLDv2 elects a single router per subnet to be in Querier state; all 2224 the other routers on the subnet should be in Non-Querier state. 2225 MLDv2 uses the same querier election mechanism as MLDv1, namely the 2226 IPv6 address. When a router starts operating on a subnet, by default 2227 it considers itself as being the Querier. Thus, it sends several 2228 General Queries separated by a small time interval (see Section 9.6 2229 and Section 9.7 for details). 2231 When a router receives a query with a lower IPv6 address than its 2232 own, it sets the Other Querier Present timer to Other Querier Present 2233 Timeout; if it was previously in Querier state, it switches to Non- 2234 Querier state and ceases to send queries on the link. After the 2235 Other Querier Present timer expires, it should re-enter the Querier 2236 state and begin sending General Queries. 2238 All MLDv2 queries MUST be sent with the FE80::/64 link-local source 2239 address prefix. Therefore, for the purpose of MLDv2 querier 2240 election, an IPv6 address A is considered to be lower than an IPv6 2241 address B if the interface ID represented by the last 64 bits of 2242 address A, in big-endian bit order, is lower than the interface ID 2243 represented by the last 64 bits of address B. 2245 7.6.3. Building and Sending Specific Queries 2247 7.6.3.1. Building and Sending Multicast Address Specific Queries 2249 When a table action "Send Q(MA)" is encountered, the Filter Timer 2250 must be lowered to LLQT. The Querier must then immediately send a 2251 Multicast Address Specific query as well as schedule [Last Listener 2252 Query Count - 1] query retransmissions to be sent every [Last 2253 Listener Query Interval], over [Last Listener Query Time]. 2255 When transmitting a Multicast Address Specific Query, if the Filter 2256 Timer is larger than LLQT, the "Suppress Router-Side Processing" bit 2257 is set in the query message. 2259 7.6.3.2. Building and Sending Multicast Address and Source Specific 2260 Queries 2262 When a table action "Send Q(MA,X)" is encountered by the Querier in 2263 the table in Section 7.4.2, the following actions must be performed 2264 for each of the sources in X that send to multicast address MA, with 2265 source timer larger than LLQT: 2267 * Lower source timer to LLQT; 2269 * Add the sources to the Retransmission List; 2271 * Set the Source Retransmission Counter for each source to [Last 2272 Listener Query Count]. 2274 The Querier must then immediately send a Multicast Address and Source 2275 Specific Query as well as schedule [Last Listener Query Count -1] 2276 query retransmissions to be sent every [Last Listener Query 2277 Interval], over [Last Listener Query Time]. The contents of these 2278 queries are calculated as follows. 2280 When building a Multicast Address and Source Specific Query for a 2281 multicast address MA, two separate query messages are sent for the 2282 multicast address. The first one has the "Suppress Router-Side 2283 Processing" bit set and contains all the sources with retransmission 2284 state (i.e., sources from the Retransmission List of that multicast 2285 address), and timers greater than LLQT. The second has the "Suppress 2286 Router-Side Processing" bit clear and contains all the sources with 2287 retransmission state and timers lower or equal to LLQT. If either of 2288 the two calculated messages does not contain any sources, then its 2289 transmission is suppressed. 2291 Note: If a Multicast Address Specific query is scheduled to be 2292 transmitted at the same time as a Multicast Address and Source 2293 specific query for the same multicast address, then transmission of 2294 the Multicast Address and Source Specific message with the "Suppress 2295 Router-Side Processing" bit set may be suppressed. 2297 8. Interoperation with MLDv1 2299 MLD version 2 hosts and routers interoperate with hosts and routers 2300 that have not yet been upgraded to MLDv2. This compatibility is 2301 maintained by hosts and routers taking appropriate actions depending 2302 on the versions of MLD operating on hosts and routers within a 2303 network. 2305 8.1. Query Version Distinctions 2307 The MLD version of a Multicast Listener Query message is determined 2308 as follows: 2310 MLDv1 Query: length = 24 octets 2312 MLDv2 Query: length >= 28 octets 2314 Query messages that do not match any of the above conditions (e.g., a 2315 Query of length 26 octets) MUST be silently ignored. 2317 8.2. Multicast Address Listener Behavior 2319 8.2.1. In the Presence of MLDv1 Routers 2321 In order to be compatible with MLDv1 routers, MLDv2 hosts MUST 2322 operate in version 1 compatibility mode. MLDv2 hosts MUST keep state 2323 per local interface regarding the compatibility mode of each attached 2324 link. A host's compatibility mode is determined from the Host 2325 Compatibility Mode variable which can be in one of the two states: 2326 MLDv1 or MLDv2. 2328 The Host Compatibility Mode of an interface is set to MLDv1 whenever 2329 an MLDv1 Multicast Address Listener Query is received on that 2330 interface. At the same time, the Older Version Querier Present timer 2331 for the interface is set to Older Version Querier Present Timeout 2332 seconds. The timer is re-set whenever a new MLDv1 Query is received 2333 on that interface. If the Older Version Querier Present timer 2334 expires, the host switches back to Host Compatibility Mode of MLDv2. 2336 When Host Compatibility Mode is MLDv2, a host acts using the MLDv2 2337 protocol on that interface. When Host Compatibility Mode is MLDv1, a 2338 host acts in MLDv1 compatibility mode, using only the MLDv1 protocol, 2339 on that interface. 2341 An MLDv1 Querier will send General Queries with the Maximum Response 2342 Code set to the desired Maximum Response Delay, i.e., the full range 2343 of this field is linear and the exponential algorithm described in 2344 Section 5.1.3. is not used. 2346 Whenever a host changes its compatibility mode, it cancels all its 2347 pending responses and retransmission timers. 2349 8.2.2. In the Presence of MLDv1 Multicast Address Listeners 2351 An MLDv2 host may be placed on a link where there are MLDv1 hosts. A 2352 host MAY allow its MLDv2 Multicast Listener Report to be suppressed 2353 by a Version 1 Multicast Listener Report. 2355 8.3. Multicast Router Behavior 2357 8.3.1. In the Presence of MLDv1 Routers 2359 MLDv2 routers may be placed on a network where there is at least one 2360 MLDv1 router. The following requirements apply: 2362 * If an MLDv1 router is present on the link, the Querier MUST use 2363 the lowest version of MLD present on the network. This must be 2364 administratively assured. Routers that desire to be compatible 2365 with MLDv1 MUST have a configuration option to act in MLDv1 mode; 2366 if an MLDv1 router is present on the link, the system 2367 administrator must explicitly configure all MLDv2 routers to act 2368 in MLDv1 mode. When in MLDv1 mode, the Querier MUST send periodic 2369 General Queries truncated at the Multicast Address field (i.e., 24 2370 bytes long), and SHOULD also warn about receiving an MLDv2 Query 2371 (such warnings must be rate-limited). The Querier MUST also fill 2372 in the Maximum Response Delay in the Maximum Response Code field, 2373 i.e., the exponential algorithm described in Section 5.1.3. is not 2374 used. 2376 * If a router is not explicitly configured to use MLDv1 and receives 2377 an MLDv1 General Query, it SHOULD log a warning. These warnings 2378 MUST be rate-limited. 2380 8.3.2. In the Presence of MLDv1 Multicast Address Listeners 2382 MLDv2 routers may be placed on a network where there are hosts that 2383 have not yet been upgraded to MLDv2. In order to be compatible with 2384 MLDv1 hosts, MLDv2 routers MUST operate in version 1 compatibility 2385 mode. MLDv2 routers keep a compatibility mode per multicast address 2386 record. The compatibility mode of a multicast address is determined 2387 from the Multicast Address Compatibility Mode variable, which can be 2388 in one of the two following states: MLDv1 or MLDv2. 2390 The Multicast Address Compatibility Mode of a multicast address 2391 record is set to MLDv1 whenever an MLDv1 Multicast Listener Report is 2392 received for that multicast address. At the same time, the Older 2393 Version Host Present timer for the multicast address is set to Older 2394 Version Host Present Timeout seconds. The timer is re-set whenever a 2395 new MLDv1 Report is received for that multicast address. If the 2396 Older Version Host Present timer expires, the router switches back to 2397 Multicast Address Compatibility Mode of MLDv2 for that multicast 2398 address. 2400 Note that when a router switches back to MLDv2 Multicast Address 2401 Compatibility Mode for a multicast address, it takes some time to 2402 regain source-specific state information. Source-specific 2403 information will be learned during the next General Query, but 2404 sources that should be blocked will not be blocked until [Multicast 2405 Address Listening Interval] after that. 2407 When Multicast Address Compatibility Mode is MLDv2, a router acts 2408 using the MLDv2 protocol for that multicast address. When Multicast 2409 Address Compatibility Mode is MLDv1, a router internally translates 2410 the following MLDv1 messages for that multicast address to their 2411 MLDv2 equivalents: 2413 +===============+==================+ 2414 | MLDv1 Message | MLDv2 Equivalent | 2415 +===============+==================+ 2416 | Report | IS_EX( {} ) | 2417 +---------------+------------------+ 2418 | Done | TO_IN( {} ) | 2419 +---------------+------------------+ 2421 Table 7 2423 MLDv2 BLOCK messages are ignored, as are source-lists in TO_EX() 2424 messages (i.e., any TO_EX() message is treated as TO_EX( {} )). On 2425 the other hand, the Querier continues to send MLDv2 queries, 2426 regardless of its Multicast Address Compatibility Mode. 2428 9. List of Timers, Counters, and their Default Values 2430 Most of these timers are configurable. If non-default settings are 2431 used, they MUST be consistent among all nodes on a single link. Note 2432 that parentheses are used to group expressions to make the algebra 2433 clear. 2435 9.1. Robustness Variable 2437 The Robustness Variable allows tuning for the expected packet loss on 2438 a link. If a link is expected to be lossy, the value of the 2439 Robustness Variable may be increased. MLD is robust to [Robustness 2440 Variable] - 1 packet losses. The value of the Robustness Variable 2441 MUST NOT be zero, and SHOULD NOT be one. Default value: 2. 2443 9.2. Query Interval 2445 The Query Interval variable denotes the interval between General 2446 Queries sent by the Querier. Default value: 125 seconds. 2448 By varying the [Query Interval], an administrator may tune the number 2449 of MLD messages on the link; larger values cause MLD Queries to be 2450 sent less often. 2452 9.3. Query Response Interval 2454 The Maximum Response Delay used to calculate the Maximum Response 2455 Code inserted into the periodic General Queries. Default value: 2456 10000 (10 seconds) 2458 By varying the [Query Response Interval], an administrator may tune 2459 the burstiness of MLD messages on the link; larger values make the 2460 traffic less bursty, as host responses are spread out over a larger 2461 interval. The number of seconds represented by the [Query Response 2462 Interval] must be less than the [Query Interval]. 2464 9.4. Multicast Address Listening Interval 2466 The Multicast Address Listening Interval (MALI) is the amount of time 2467 that must pass before a multicast router decides there are no more 2468 listeners of a multicast address or a particular source on a link. 2469 This value MUST be ([Robustness Variable] times [Query Interval]) 2470 plus [Query Response Interval]. 2472 9.5. Other Querier Present Timeout 2474 The Other Querier Present Timeout is the length of time that must 2475 pass before a multicast router decides that there is no longer 2476 another multicast router which should be the Querier. This value 2477 MUST be ([Robustness Variable] times ([Query Interval]) plus (one 2478 half of [Query Response Interval]). 2480 9.6. Startup Query Interval 2482 The Startup Query Interval is the interval between General Queries 2483 sent by a Querier on startup. Default value: 1/4 the [Query 2484 Interval]. 2486 9.7. Startup Query Count 2488 The Startup Query Count is the number of Queries sent out on startup, 2489 separated by the Startup Query Interval. Default value: [Robustness 2490 Variable]. 2492 9.8. Last Listener Query Interval 2494 The Last Listener Query Interval is the Maximum Response Delay used 2495 to calculate the Maximum Response Code inserted into Multicast 2496 Address Specific Queries sent in response to Version 1 Multicast 2497 Listener Done messages. It is also the Maximum Response Delay used 2498 to calculate the Maximum Response Code inserted into Multicast 2499 Address and Source Specific Query messages. Default value: 1000 (1 2500 second). 2502 Note that for values of LLQI greater than 32.768 seconds, a limited 2503 set of values can be represented, corresponding to sequential values 2504 of Maximum Response Code. When converting a configured time to a 2505 Maximum Response Code value, it is recommended to use the exact value 2506 if possible, or the next lower value if the requested value is not 2507 exactly representable. 2509 This value may be tuned to modify the "leave latency" of the link. A 2510 reduced value results in reduced time to detect the departure of the 2511 last listener for a multicast address or source. 2513 9.9. Last Listener Query Count 2515 The Last Listener Query Count is the number of Multicast Address 2516 Specific Queries sent before the router assumes there are no local 2517 listeners. The Last Listener Query Count is also the number of 2518 Multicast Address and Source Specific Queries sent before the router 2519 assumes there are no listeners for a particular source. Default 2520 value: [Robustness Variable]. 2522 9.10. Last Listener Query Time 2524 The Last Listener Query Time is the time value represented by the 2525 Last Listener Query Interval, multiplied by [Last Listener Query 2526 Count]. It is not a tunable value, but may be tuned by changing its 2527 components. 2529 9.11. Unsolicited Report Interval 2531 The Unsolicited Report Interval is the time between repetitions of a 2532 node's initial report of interest in a multicast address. Default 2533 value: 1 second. 2535 9.12. Older Version Querier Present Timeout 2537 The Older Version Querier Present Timeout is the time-out for 2538 transitioning a host back to MLDv2 Host Compatibility Mode. When an 2539 MLDv1 query is received, MLDv2 hosts set their Older Version Querier 2540 Present Timer to [Older Version Querier Present Timeout]. 2542 This value MUST be ([Robustness Variable] times (the [Query Interval] 2543 in the last Query received)) plus ([Query Response Interval]). 2545 9.13. Older Version Host Present Timeout 2547 The Older Version Host Present Timeout is the time-out for 2548 transitioning a router back to MLDv2 Multicast Address Compatibility 2549 Mode for a specific multicast address. When an MLDv1 report is 2550 received for that multicast address, routers set their Older Version 2551 Host Present Timer to [Older Version Host Present Timeout]. 2553 This value MUST be ([Robustness Variable] times [Query Interval]) 2554 plus ([Query Response Interval]). 2556 9.14. Configuring timers 2558 This section is meant to provide advice to network administrators on 2559 how to tune these settings to their network. Ambitious router 2560 implementations might tune these settings dynamically based upon 2561 changing characteristics of the network. 2563 9.14.1. Robustness Variable 2565 The Robustness Variable tunes MLD to expected losses on a link. 2566 MLDv2 is robust to [Robustness Variable] - 1 packet losses, e.g., if 2567 the Robustness Variable is set to the default value of 2, MLDv2 is 2568 robust to a single packet loss but may operate imperfectly if more 2569 losses occur. On lossy links, the value of the Robustness Variable 2570 should be increased to allow for the expected level of packet loss. 2571 However, increasing the value of the Robustness Variable increases 2572 the leave latency of the link (the time between when the last 2573 listener stops listening to a source or multicast address and when 2574 the traffic stops flowing). 2576 9.14.2. Query Interval 2578 The overall level of periodic MLD traffic is inversely proportional 2579 to the Query Interval. A longer Query Interval results in a lower 2580 overall level of MLD traffic. The value of the Query Interval MUST 2581 be equal to or greater than the Maximum Response Delay used to 2582 calculate the Maximum Response Code inserted in General Query 2583 messages. 2585 9.14.3. Maximum Response Delay 2587 The burstiness of MLD traffic is inversely proportional to the 2588 Maximum Response Delay. A longer Maximum Response Delay will spread 2589 Report messages over a longer interval. However, a longer Maximum 2590 Response Delay in Multicast Address Specific and Multicast Address 2591 And Source Specific Queries extends the leave latency (the time 2592 between when the last listener stops listening to a source or 2593 multicast address and when the traffic stops flowing.) The expected 2594 rate of Report messages can be calculated by dividing the expected 2595 number of Reporters by the Maximum Response Delay. The Maximum 2596 Response Delay may be dynamically calculated per Query by using the 2597 expected number of Reporters for that Query as follows: 2599 General Query All nodes on link 2601 Multicast Address Specific Query All nodes on the link that had 2602 expressed interest in the 2603 multicast address 2605 Multicast Address and Source All nodes on the link that had 2606 Specific Query expressed interest in the source 2607 and multicast address 2609 A router is not required to calculate these populations or tune the 2610 Maximum Response Delay dynamically; these are simply guidelines. 2612 10. Security Considerations 2614 We consider the ramifications of a forged message of each type. Note 2615 that before processing an MLD message, nodes verify if the source 2616 address of the message is a valid link-local address (or the 2617 unspecified address), if the Hop Limit is set to 1, and if the Router 2618 Alert option is present in the Hop-By-Hop Options header of the IPv6 2619 packet. If any of these checks fails, the packet is dropped. This 2620 defends the MLDv2 nodes from acting on forged MLD messages originated 2621 off-link. Therefore, in the following we discuss only the effects of 2622 on-link forgery. 2624 10.1. Query Message 2626 A forged Query message from a machine with a lower IPv6 address than 2627 the current Querier will cause Querier duties to be assigned to the 2628 forger. If the forger then sends no more Query messages, other 2629 routers' Other Querier Present timer will time out and one will 2630 resume the role of Querier. During this time, if the forger ignores 2631 Multicast Listener Done Messages, traffic might flow to multicast 2632 addresses with no listeners for up to [Multicast Address Listener 2633 Interval]. 2635 A forged Version 1 Query message will put MLDv2 listeners on that 2636 link in MLDv1 Host Compatibility Mode. This scenario can be avoided 2637 by providing MLDv2 hosts with a configuration option to ignore 2638 Version 1 messages completely. 2640 A DoS attack on a node could be staged through forged Multicast 2641 Address and Source Specific Queries. The attacker can find out about 2642 the listening state of a specific node with a general query. After 2643 that it could send a large number of Multicast Address and Source 2644 Specific Queries, each with a large source list and/or long Maximum 2645 Response Delay. The node will have to store and maintain the sources 2646 specified in all of those queries for as long as it takes to send the 2647 delayed response. This would consume both memory and CPU cycles in 2648 order to augment the recorded sources with the source lists included 2649 in the successive queries. 2651 To protect against such a DoS attack, a node stack implementation 2652 could restrict the number of Multicast Address and Source Specific 2653 Queries per multicast address within this interval, and/or record 2654 only a limited number of sources. 2656 10.2. Current State Report messages 2658 A forged Report message may cause multicast routers to think there 2659 are listeners of a multicast address on a link when there are not. 2660 Nevertheless, since listening to a multicast address on a host is 2661 generally an unprivileged operation, a local user may trivially gain 2662 the same result without forging any messages. 2664 A forged Version 1 Report Message may put a router into MLDv1 2665 Multicast Address Compatibility Mode for a particular multicast 2666 address, meaning that the router will ignore MLDv2 source specific 2667 state messages. This can cause traffic to flow from unwanted sources 2668 for up to [Multicast Address Listener Interval]. This can be solved 2669 by providing routers with a configuration switch to ignore Version 1 2670 messages completely. This breaks automatic compatibility with 2671 Version 1 hosts, so it should only be used in situations where source 2672 filtering is critical. 2674 10.3. State Change Report messages 2676 A forged State Change Report message will cause the Querier to send 2677 out Multicast Address Specific or Multicast Address and Source 2678 Specific Queries for the multicast address in question. This causes 2679 extra processing on each router and on each listener of the multicast 2680 address, but cannot cause loss of desired traffic. 2682 11. IANA Considerations 2684 IANA has assigned the IPv6 link-local multicast address 2685 FF02:0:0:0:0:0:0:16, called "all MLDv2-capable routers", as described 2686 in Section 5.2.14. Version 2 Multicast Listener Reports will be sent 2687 to this special address. 2689 In addition, IANA has assigned the ICMPv6 message type value of 143 2690 for Version 2 Multicast Listener Report messages, as specified in 2691 Section 4. 2693 12. Contributors 2695 Roland Vida, Luis Henrique Maciel Kosmalski Costa, Serge Fdida, Steve 2696 Deering, Bill Fenner, and Isidor Kouvelas are the authors of RFC 2697 3810, which makes up the majority of the content in this document. 2699 Anuj Budhiraja, Toerless Eckert, Olufemi Komolafe and Tim Winters 2700 have contributed valuable content to this version of the 2701 specification. 2703 13. Acknowledgments 2705 We would like to thank Hitoshi Asaeda, Randy Bush, Francis Dupont, 2706 Ted Hardie, Russ Housley, Konstantin Kabassanov, Erik Nordmark, 2707 Shinsuke Suzuki, Margaret Wasserman, Bert Wijnen, and Remi Zara for 2708 their valuable comments and suggestions on this document. 2710 Stig Venaas, Hitoshi Asaeda, and Mike McBride have provided valuable 2711 feedback on this version of the specification and we thank them for 2712 their input. 2714 14. References 2716 14.1. Normative References 2718 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2719 Requirement Levels", BCP 14, RFC 2119, 2720 DOI 10.17487/RFC2119, March 1997, 2721 . 2723 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2724 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2725 December 1998, . 2727 [RFC2463] Conta, A. and S. Deering, "Internet Control Message 2728 Protocol (ICMPv6) for the Internet Protocol Version 6 2729 (IPv6) Specification", RFC 2463, DOI 10.17487/RFC2463, 2730 December 1998, . 2732 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 2733 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 2734 . 2736 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 2737 Listener Discovery (MLD) for IPv6", RFC 2710, 2738 DOI 10.17487/RFC2710, October 1999, 2739 . 2741 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 2742 RFC 2711, DOI 10.17487/RFC2711, October 1999, 2743 . 2745 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 2746 (IPv6) Addressing Architecture", RFC 3513, 2747 DOI 10.17487/RFC3513, April 2003, 2748 . 2750 14.2. Informative References 2752 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 2753 Discovery for IP Version 6 (IPv6)", RFC 2461, 2754 DOI 10.17487/RFC2461, December 1998, 2755 . 2757 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 2758 Autoconfiguration", RFC 2462, DOI 10.17487/RFC2462, 2759 December 1998, . 2761 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2762 Thyagarajan, "Internet Group Management Protocol, Version 2763 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 2764 . 2766 [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific 2767 Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 2768 2003, . 2770 [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface 2771 Extensions for Multicast Source Filters", RFC 3678, 2772 DOI 10.17487/RFC3678, January 2004, 2773 . 2775 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 2776 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 2777 DOI 10.17487/RFC3810, June 2004, 2778 . 2780 Appendix A. Design Rationale 2782 A.1. The Need for State Change Messages 2784 MLDv2 specifies two types of Multicast Listener Reports: Current 2785 State and State Change. This section describes the rationale for the 2786 need for both these types of Reports. 2788 Routers need to distinguish Multicast Listener Reports that were sent 2789 in response to Queries from those that were sent as a result of a 2790 change in the per-interface state. Multicast Listener Reports that 2791 are sent in response to Multicast Address Listener Queries are used 2792 mainly to refresh the existing state at the router; they typically do 2793 not cause transitions in state at the router. Multicast Listener 2794 Reports that are sent in response to changes in the per-interface 2795 state require the router to take some action in response to the 2796 received report (see Section 7.4). 2798 The inability to distinguish between the two types of reports would 2799 force a router to treat all Multicast Listener Reports as potential 2800 changes in state and could result in increased processing at the 2801 router as well as an increase in MLD traffic on the link. 2803 A.2. Host Suppression 2805 In MLDv1, a host would not send a pending multicast listener report 2806 if a similar report was sent by another listener on the link. In 2807 MLDv2, the suppression of multicast listener reports has been 2808 removed. The following points explain this decision. 2810 1. Routers may want to track per-host multicast listener status on 2811 an interface. This would allow routers to implement fast leaves 2812 (e.g., for layered multicast congestion control schemes), as well 2813 as track listener status for possible security or accounting 2814 purposes. The present specification does not require routers to 2815 implement per-host tracking. Nevertheless, the lack of host 2816 suppression in MLDv2 makes possible to implement either 2817 proprietary or future standard behavior of multicast routers that 2818 would support per-host tracking, while being fully interoperable 2819 with MLDv2 listeners and routers that implement the exact 2820 behavior described in this specification. 2822 2. Multicast Listener Report suppression does not work well on 2823 bridged LANs. Many bridges and Layer2/Layer3 switches that 2824 implement MLD snooping do not forward MLD messages across LAN 2825 segments in order to prevent multicast listener report 2826 suppression. 2828 3. By eliminating multicast listener report suppression, hosts have 2829 fewer messages to process; this leads to a simpler state machine 2830 implementation. 2832 4. In MLDv2, a single multicast listener report now bundles multiple 2833 multicast address records to decrease the number of packets sent. 2834 In comparison, the previous version of MLD required that each 2835 multicast address be reported in a separate message. 2837 A.3. Switching router filter modes from EXCLUDE to INCLUDE 2839 If on a link there are nodes in both EXCLUDE and INCLUDE modes for a 2840 single multicast address, the router must be in EXCLUDE mode as well 2841 (see section 7.2.1). In EXCLUDE mode, a router forwards traffic from 2842 all sources except those in the Exclude List. If all nodes in 2843 EXCLUDE mode cease to exist or to listen, it would be desirable for 2844 the router to switch back to INCLUDE mode seamlessly, without 2845 interrupting the flow of traffic to existing listeners. 2847 One of the ways to accomplish this is for routers to keep track of 2848 all sources that nodes that are in INCLUDE mode listen to, even 2849 though the router itself is in EXCLUDE mode. If the Filter Timer for 2850 a multicast address expires, it implies that there are no nodes in 2851 EXCLUDE mode on the link (otherwise a multicast listener report from 2852 that node would have refreshed the Filter Timer). The router can 2853 then switch to INCLUDE mode seamlessly; sources from the Requested 2854 List are moved to the Include List, while sources from the Exclude 2855 List are deleted. 2857 Appendix B. Summary of Changes 2859 B.1. MLDv1 2861 The following is a summary of changes from MLDv1, specified in 2862 [RFC2710]. 2864 * MLDv2 introduces source filtering. 2866 * The IP service interface of MLDv2 nodes is modified accordingly. 2867 It enables the specification of a filter mode and a source list. 2869 * An MLDv2 node keeps per-socket and per-interface multicast 2870 listening states that include a filter mode and a source list for 2871 each multicast address. This enables packet filtering based on a 2872 socket's multicast reception state. 2874 * MLDv2 state kept on routers includes a filter mode and a list of 2875 sources and source timers for each multicast address that has 2876 listeners on the link. MLDv1 routers kept only the list of 2877 multicast addresses. 2879 * Queries include additional fields (Section 5.1). 2881 * The S flag (Suppress Router-Side Processing) is included in 2882 queries in order to fix robustness issues. 2884 * The Querier's Robustness Variable and Query Interval Code are 2885 included in Queries in order to synchronize all MLDv2 routers 2886 connected to the same link. 2888 * A new Query type (Multicast Address and Source Specific Query) is 2889 introduced. 2891 * The Maximum Response Delay is not directly included in the Query 2892 anymore. Instead, an exponential algorithm is used to calculate 2893 its value, based on the Maximum Response Code included in the 2894 Query. The maximum value is increased from 65535 milliseconds to 2895 about 140 minutes. 2897 * Reports include Multicast Address Records. Information on the 2898 listening state for several different multicast addresses can be 2899 included in the same Report message. 2901 * Reports are sent to the "all MLDv2-capable multicast routers" 2902 address, instead of the multicast address the host listens to, as 2903 in MLDv1. This facilitates the operation of layer-2 snooping 2904 switches. 2906 * There is no "host suppression", as in MLDv1. All nodes send 2907 Report messages. 2909 * Unsolicited Reports, announcing changes in receiver listening 2910 state, are sent [Robustness Variable] times. RFC 2710 is less 2911 explicit. 2913 * There are no Done messages. 2915 * Interoperability with MLDv1 systems is achieved by MLDv2 state 2916 operations. 2918 * In order to ensure interoperability, hosts maintain a Host 2919 Compatibility Mode variable and an Older Version Querier Present 2920 timer per interface. Routers maintain a Multicast Address 2921 Compatibility Mode variable and an Older Version Host Present 2922 timer per multicast address. 2924 B.2. MLDv2 2926 The following summarizes the changes made since RFC 3810. 2928 * Added definition of Resv to address Erratum 4773. 2930 * Added clarifying text on which multicast addresses require the 2931 sending of MLD messages to address Erratum 5977. 2933 Author's Address 2935 Brian Haberman (editor) 2936 Johns Hopkins University Applied Physics Lab 2938 Email: brian@innovationslab.net