idnits 2.17.1 draft-mcast-pim-3810bis-00.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 (July 12, 2021) is 1013 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 1022 -- Looks like a reference, but probably isn't: '2' on line 1030 == Missing Reference: 'N' is mentioned on line 1042, but not defined == Missing Reference: 'M' is mentioned on line 1001, 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) July 12, 2021 5 Intended status: Standards Track 6 Expires: January 13, 2022 8 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 9 draft-mcast-pim-3810bis-00 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 January 13, 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 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 61 2.1. Building Multicast Listening State on Multicast Address 62 Listeners . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2. Exchanging Messages between the Querier and the Listening 64 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.3. Building Multicast Address Listener State on Multicast 66 Routers . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3. The Service Interface for Requesting IP Multicast Reception . 11 68 4. Multicast Listening State Maintained by Nodes . . . . . . . . 13 69 4.1. Per-Socket State . . . . . . . . . . . . . . . . . . . . 13 70 4.2. Per-Interface State . . . . . . . . . . . . . . . . . . . 13 71 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 15 72 5.1. Multicast Listener Query Message . . . . . . . . . . . . 16 73 5.1.1. Code . . . . . . . . . . . . . . . . . . . . . . . . 18 74 5.1.2. Checksum . . . . . . . . . . . . . . . . . . . . . . 18 75 5.1.3. Maximum Response Code . . . . . . . . . . . . . . . . 18 76 5.1.4. Reserved . . . . . . . . . . . . . . . . . . . . . . 18 77 5.1.5. Multicast Address . . . . . . . . . . . . . . . . . . 18 78 5.1.6. Resv . . . . . . . . . . . . . . . . . . . . . . . . 19 79 5.1.7. S Flag (Suppress Router-Side Processing) . . . . . . 19 80 5.1.8. QRV (Querier's Robustness Variable) . . . . . . . . . 19 81 5.1.9. QQIC (Querier's Query Interval Code) . . . . . . . . 19 82 5.1.10. Number of Sources (N) . . . . . . . . . . . . . . . . 20 83 5.1.11. Source Address [i] . . . . . . . . . . . . . . . . . 20 84 5.1.12. Additional Data . . . . . . . . . . . . . . . . . . . 20 85 5.1.13. Query Variants . . . . . . . . . . . . . . . . . . . 20 86 5.1.14. Source Addresses for Queries . . . . . . . . . . . . 21 87 5.1.15. Destination Addresses for Queries . . . . . . . . . . 21 88 5.2. Version 2 Multicast Listener Report Message . . . . . . . 21 89 5.2.1. Reserved . . . . . . . . . . . . . . . . . . . . . . 24 90 5.2.2. Checksum . . . . . . . . . . . . . . . . . . . . . . 24 91 5.2.3. Nr of Mcast Address Records (M) . . . . . . . . . . . 24 92 5.2.4. Multicast Address Record . . . . . . . . . . . . . . 24 93 5.2.5. Record Type . . . . . . . . . . . . . . . . . . . . . 24 94 5.2.6. Aux Data Len . . . . . . . . . . . . . . . . . . . . 24 95 5.2.7. Number of Sources (N) . . . . . . . . . . . . . . . . 24 96 5.2.8. Multicast Address . . . . . . . . . . . . . . . . . . 24 97 5.2.9. Source Address [i] . . . . . . . . . . . . . . . . . 25 98 5.2.10. Auxiliary Data . . . . . . . . . . . . . . . . . . . 25 99 5.2.11. Additional Data . . . . . . . . . . . . . . . . . . . 25 100 5.2.12. Multicast Address Record Types . . . . . . . . . . . 25 101 5.2.13. Source Addresses for Reports . . . . . . . . . . . . 27 102 5.2.14. Destination Addresses for Reports . . . . . . . . . . 28 103 5.2.15. Multicast Listener Report Size . . . . . . . . . . . 28 104 6. Protocol Description for Multicast Address Listeners . . . . 29 105 6.1. Action on Change of Per-Interface State . . . . . . . . . 30 106 6.2. Action on Reception of a Query . . . . . . . . . . . . . 32 107 6.3. Action on Timer Expiration . . . . . . . . . . . . . . . 34 108 7. Description of the Protocol for Multicast Routers . . . . . . 36 109 7.1. Conditions for MLD Queries . . . . . . . . . . . . . . . 37 110 7.2. MLD State Maintained by Multicast Routers . . . . . . . . 38 111 7.2.1. Definition of Router Filter Mode . . . . . . . . . . 39 112 7.2.2. Definition of Filter Timers . . . . . . . . . . . . . 40 113 7.2.3. Definition of Source Timers . . . . . . . . . . . . . 41 114 7.3. MLDv2 Source Specific Forwarding Rules . . . . . . . . . 43 115 7.4. Action on Reception of Reports . . . . . . . . . . . . . 44 116 7.4.1. Reception of Current State Records . . . . . . . . . 44 117 7.4.2. Reception of Filter Mode Change and Source List 118 Change Records . . . . . . . . . . . . . . . . . . . 45 119 7.5. Switching Router Filter Modes . . . . . . . . . . . . . . 46 120 7.6. Action on Reception of Queries . . . . . . . . . . . . . 47 121 7.6.1. Timer Updates . . . . . . . . . . . . . . . . . . . . 47 122 7.6.2. Querier Election . . . . . . . . . . . . . . . . . . 47 123 7.6.3. Building and Sending Specific Queries . . . . . . . . 48 124 8. Interoperation with MLDv1 . . . . . . . . . . . . . . . . . . 49 125 8.1. Query Version Distinctions . . . . . . . . . . . . . . . 49 126 8.2. Multicast Address Listener Behavior . . . . . . . . . . . 49 127 8.2.1. In the Presence of MLDv1 Routers . . . . . . . . . . 50 128 8.2.2. In the Presence of MLDv1 Multicast Address Listeners 50 129 8.3. Multicast Router Behavior . . . . . . . . . . . . . . . . 50 130 8.3.1. In the Presence of MLDv1 Routers . . . . . . . . . . 50 131 8.3.2. In the Presence of MLDv1 Multicast Address Listeners 51 132 9. List of Timers, Counters, and their Default Values . . . . . 52 133 9.1. Robustness Variable . . . . . . . . . . . . . . . . . . . 52 134 9.2. Query Interval . . . . . . . . . . . . . . . . . . . . . 52 135 9.3. Query Response Interval . . . . . . . . . . . . . . . . . 52 136 9.4. Multicast Address Listening Interval . . . . . . . . . . 53 137 9.5. Other Querier Present Timeout . . . . . . . . . . . . . . 53 138 9.6. Startup Query Interval . . . . . . . . . . . . . . . . . 53 139 9.7. Startup Query Count . . . . . . . . . . . . . . . . . . . 53 140 9.8. Last Listener Query Interval . . . . . . . . . . . . . . 53 141 9.9. Last Listener Query Count . . . . . . . . . . . . . . . . 54 142 9.10. Last Listener Query Time . . . . . . . . . . . . . . . . 54 143 9.11. Unsolicited Report Interval . . . . . . . . . . . . . . . 54 144 9.12. Older Version Querier Present Timeout . . . . . . . . . . 54 145 9.13. Older Version Host Present Timeout . . . . . . . . . . . 54 146 9.14. Configuring timers . . . . . . . . . . . . . . . . . . . 54 147 9.14.1. Robustness Variable . . . . . . . . . . . . . . . . 55 148 9.14.2. Query Interval . . . . . . . . . . . . . . . . . . . 55 149 9.14.3. Maximum Response Delay . . . . . . . . . . . . . . . 55 150 10. Security Considerations . . . . . . . . . . . . . . . . . . . 56 151 10.1. Query Message . . . . . . . . . . . . . . . . . . . . . 56 152 10.2. Current State Report messages . . . . . . . . . . . . . 57 153 10.3. State Change Report messages . . . . . . . . . . . . . . 57 154 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 155 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 57 156 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57 157 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 158 14.1. Normative References . . . . . . . . . . . . . . . . . . 58 159 14.2. Informative References . . . . . . . . . . . . . . . . . 58 160 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 59 161 A.1. The Need for State Change Messages . . . . . . . . . . . 59 162 A.2. Host Suppression . . . . . . . . . . . . . . . . . . . . 60 163 A.3. Switching router filter modes from EXCLUDE to INCLUDE . . 60 164 Appendix B. Summary of Changes . . . . . . . . . . . . . . . . . 61 165 B.1. MLDv1 . . . . . . . . . . . . . . . . . . . . . . . . . . 61 166 B.2. MLDv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 62 167 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 62 169 1. Introduction 171 The Multicast Listener Discovery Protocol (MLD) is used by IPv6 172 routers to discover the presence of multicast listeners (i.e., nodes 173 that wish to receive multicast packets) on their directly attached 174 links, and to discover specifically which multicast addresses are of 175 interest to those neighboring nodes. Note that a multicast router 176 may itself be a listener of one or more multicast addresses; in this 177 case it performs both the "multicast router part" and the "multicast 178 address listener part" of the protocol, to collect the multicast 179 listener information needed by its multicast routing protocol on the 180 one hand, and to inform itself and other neighboring multicast 181 routers of its listening state on the other hand. 183 This document specifies Version 2 of MLD. The previous version of 184 MLD is specified in [RFC2710]. In this document we will refer to it 185 as MLDv1. MLDv2 is a translation of the IGMPv3 protocol [RFC3376] 186 for IPv6 semantics. 188 The MLDv2 protocol, when compared to MLDv1, adds support for "source 189 filtering", i.e., the ability for a node to report interest in 190 listening to packets only from specific source addresses, as required 191 to support Source-Specific Multicast [RFC3569], or from *all but* 192 specific source addresses, sent to a particular multicast address. 193 MLDv2 is designed to be interoperable with MLDv1. 195 This document obsoletes [RFC3810]. 197 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 198 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 199 "OPTIONAL" in this document are to be interpreted as described in 200 [RFC2119]. 202 2. Protocol Overview 204 This section gives a brief description of the protocol operation. 205 The following sections present the protocol details. 207 MLD is an asymmetric protocol; it specifies separate behaviors for 208 multicast address listeners (i.e., hosts or routers that listen to 209 multicast packets) and multicast routers. The purpose of MLD is to 210 enable each multicast router to learn, for each of its directly 211 attached links, which multicast addresses and which sources have 212 interested listeners on that link. The information gathered by MLD 213 is provided to whichever multicast routing protocol is used by the 214 router, in order to ensure that multicast packets are delivered to 215 all links where there are listeners interested in such packets. 217 Multicast routers only need to know that at least one node on an 218 attached link is listening to packets for a particular multicast 219 address, from a particular source; a multicast router is not required 220 to individually keep track of the interests of each neighboring node. 221 (Nevertheless, see Appendix A.2 item 1 for discussion.) 223 A multicast router performs the router part of the MLDv2 protocol 224 (described in details in Section 7) on each of its directly attached 225 links. If a multicast router has more than one interface connected 226 to the same link, it only needs to operate the protocol on one of 227 those interfaces. The router behavior depends on whether there are 228 several multicast routers on the same subnet, or not. If that is the 229 case, a querier election mechanism (described in Section 7.6.2) is 230 used to elect a single multicast router to be in Querier state. This 231 router is called the Querier. All multicast routers on the subnet 232 listen to the messages sent by multicast address listeners, and 233 maintain the same multicast listening information state, so that they 234 can take over the querier role, should the present Querier fail. 235 Nevertheless, only the Querier sends periodical or triggered query 236 messages on the subnet, as described in Section 7.1. 238 A multicast address listener performs the listener part of the MLDv2 239 protocol (described in details in Section 6) on all interfaces on 240 which multicast reception is supported, even if more than one of 241 those interfaces are connected to the same link. 243 2.1. Building Multicast Listening State on Multicast Address Listeners 245 Upper-layer protocols and applications that run on a multicast 246 address listener node use specific service interface calls (described 247 in Section 3) to ask the IP layer to enable or disable reception of 248 packets sent to specific multicast addresses. The node keeps 249 Multicast Address Listening state for each socket on which the 250 service interface calls have been invoked (Section 4.1). In addition 251 to this per-socket multicast listening state, a node must also 252 maintain or compute multicast listening state for each of its 253 interfaces (Section 4.2). Conceptually, that state consists of a set 254 of records, with each record containing an IPv6 multicast address, a 255 filter mode, and a source list. The filter mode may be either 256 INCLUDE or EXCLUDE. In INCLUDE mode, reception of packets sent to 257 the specified multicast address is enabled only from the source 258 addresses listed in the source list. In EXCLUDE mode, reception of 259 packets sent to the given multicast address is enabled from all 260 source addresses except those listed in the source list. 262 At most one record per multicast address exists for a given 263 interface. This per-interface state is derived from the per-socket 264 state, but may differ from it when different sockets have differing 265 filter modes and/or source lists for the same multicast address and 266 interface. After a multicast packet has been accepted from an 267 interface by the IP layer, its subsequent delivery to the application 268 connected to a particular socket depends on the multicast listening 269 state of that socket (and possibly also on other conditions, such as 270 what transport-layer port the socket is bound to). Note that MLDv2 271 messages are not subject to source filtering and must always be 272 processed by hosts and routers. 274 2.2. Exchanging Messages between the Querier and the Listening Nodes 276 There are three types of MLDv2 query messages: General Queries, 277 Multicast Address Specific Queries, and Multicast Address and Source 278 Specific Queries. The Querier periodically sends General Queries, to 279 learn multicast address listener information from an attached link. 280 These queries are used to build and refresh the Multicast Address 281 Listener state inside all multicast routers on the link. 283 Nodes respond to these queries by reporting their per-interface 284 Multicast Address Listening state, through Current State Report 285 messages sent to a specific multicast address all MLDv2 routers on 286 the link listen to. On the other hand, if the listening state of a 287 node changes, the node immediately reports these changes through a 288 State Change Report message. The State Change Report contains either 289 Filter Mode Change records, Source List Change records, or records of 290 both types. A detailed description of the report messages is 291 presented in Section 5.2.12. 293 Both router and listener state changes are mainly triggered by the 294 expiration of a specific timer, or the reception of an MLD message 295 (listener state change can be also triggered by the invocation of a 296 service interface call). Therefore, to enhance protocol robustness, 297 in spite of the possible unreliability of message exchanges, messages 298 are retransmitted several times. Furthermore, timers are set so as 299 to take into account the possible message losses, and to wait for 300 retransmissions. 302 Periodical General Queries and Current State Reports do not apply 303 this rule, in order not to overload the link; it is assumed that in 304 general these messages do not generate state changes, their main 305 purpose being to refresh existing state. Thus, even if one such 306 message is lost, the corresponding state will be refreshed during the 307 next reporting period. 309 As opposed to Current State Reports, State Change Reports are 310 retransmitted several times, in order to avoid them being missed by 311 one or more multicast routers. The number of retransmissions depends 312 on the so-called Robustness Variable. This variable allows tuning 313 the protocol according to the expected packet loss on a link. If a 314 link is expected to be lossy (e.g., a wireless connection), the value 315 of the Robustness Variable may be increased. MLD is robust to 316 [Robustness Variable]-1 packet losses. This document recommends a 317 default value of 2 for the Robustness Variable (see Section 9.1). 319 If more changes to the same per-interface state entry occur before 320 all the retransmissions of the State Change Report for the first 321 change have been completed, each additional change triggers the 322 immediate transmission of a new State Change Report. Section 6.1 323 shows how the content of this new report is computed. 324 Retransmissions of the new State Change Report will be scheduled as 325 well, in order to ensure that each instance of state change is 326 transmitted at least [Robustness Variable] times. 328 If a node on a link expresses, through a State Change Report, its 329 desire to no longer listen to a particular multicast address (or 330 source), the Querier must query for other listeners of the multicast 331 address (or source) before deleting the multicast address (or source) 332 from its Multicast Address Listener state and stopping the 333 corresponding traffic. Thus, the Querier sends a Multicast Address 334 Specific Query to verify whether there are nodes still listening to a 335 specified multicast address or not. Similarly, the Querier sends a 336 Multicast Address and Source Specific Query to verify whether, for a 337 specified multicast address, there are nodes still listening to a 338 specific set of sources, or not. Section 5.1.13 describes each query 339 in more detail. 341 Both Multicast Address Specific Queries and Multicast Address and 342 Source Specific Queries are only sent in response to State Change 343 Reports, never in response to Current State Reports. This 344 distinction between the two types of reports is needed to avoid the 345 router treating all Multicast Listener Reports as potential changes 346 in state. By doing so, the fast leave mechanism of MLDv2, described 347 in more detail in Section 2.2, might not be effective if a State 348 Change Report is lost, and only the following Current State Report is 349 received by the router. Nevertheless, it avoids an increased 350 processing at the router and it reduces the MLD traffic on the link. 351 More details on the necessity of distinguishing between the two 352 report types can be found in Appendix A.1. 354 Nodes respond to the above queries through Current State Reports, 355 that contain their per-interface Multicast Address Listening state 356 only for the multicast addresses (or sources) being queried. 358 As stated earlier, in order to ensure protocol robustness, all the 359 queries, except the periodical General Queries, are retransmitted 360 several times within a given time interval. The number of 361 retransmissions depends on the Robustness Variable. If, while 362 scheduling new queries, there are pending queries to be retransmitted 363 for the same multicast address, the new queries and the pending 364 queries have to be merged. In addition, host reports received for a 365 multicast address with pending queries may affect the contents of 366 those queries. The process of building and maintaining the state of 367 pending queries is presented in Section 7.6.3. 369 Protocol robustness is also enhanced through the use of the S flag 370 (Suppress Router-Side Processing). As described above, when a 371 Multicast Address Specific or a Multicast Address and Source Specific 372 Query is sent by the Querier, a number of retransmissions of the 373 query are scheduled. In the original (first) query the S flag is 374 clear. When the Querier sends this query, it lowers the timers for 375 the concerned multicast address (or source) to a given value; 376 similarly, any non-querier multicast router that receives the query 377 lowers its timers in the same way. Nevertheless, while waiting for 378 the next scheduled queries to be sent, the Querier may receive a 379 report that updates the timers. The scheduled queries still have to 380 be sent, in order to ensure that a non-querier router keeps its state 381 synchronized with the current Querier (the non-querier router might 382 have missed the first query). Nevertheless, the timers should not be 383 lowered again, as a valid answer was already received. Therefore, in 384 subsequent queries the Querier sets the S flag. 386 2.3. Building Multicast Address Listener State on Multicast Routers 388 Multicast routers that implement MLDv2 (whether they are in Querier 389 state or not) keep state per multicast address per attached link. 390 This multicast address listener state consists of a Filter Mode, a 391 Filter Timer, and a Source List, with a timer associated to each 392 source from the list. The Filter Mode is used to summarize the total 393 listening state of a multicast address to a minimum set, such that 394 all nodes' listening states are respected. The Filter Mode may 395 change in response to the reception of particular types of report 396 messages, or when certain timer conditions occur. 398 A router is in INCLUDE mode for a specific multicast address on a 399 given interface if all the listeners on the link interested in that 400 address are in INCLUDE mode. The router state is represented through 401 the notation INCLUDE (A), where A is a list of sources, called the 402 "Include List". The Include List is the set of sources that one or 403 more listeners on the link have requested to receive. All the 404 sources from the Include List will be forwarded by the router. Any 405 other source that is not in the Include List will be blocked by the 406 router. 408 A source can be added to the current Include List if a listener in 409 INCLUDE mode sends a Current State or a State Change Report that 410 includes that source. Each source from the Include List is 411 associated with a source timer that is updated whenever a listener in 412 INCLUDE mode sends a report that confirms its interest in that 413 specific source. If the timer of a source from the Include List 414 expires, the source is deleted from the Include List. 416 Besides this "soft leave" mechanism, there is also a "fast leave" 417 scheme in MLDv2; it is also based on the use of source timers. When 418 a node in INCLUDE mode expresses its desire to stop listening to a 419 specific source, all the multicast routers on the link lower their 420 timers for that source to a given value. The Querier then sends a 421 Multicast Address and Source Specific Query, to verify whether there 422 are other listeners for that source on the link, or not. If a report 423 that includes this source is received before the timer expiration, 424 all the multicast routers on the link update the source timer. If 425 not, the source is deleted from the Include List. The handling of 426 the Include List, according to the received reports, is detailed in 427 Tables 7.4.1 and 7.4.2. 429 A router is in EXCLUDE mode for a specific multicast address on a 430 given interface if there is at least one listener in EXCLUDE mode for 431 that address on the link. When the first report is received from 432 such a listener, the router sets the Filter Timer that corresponds to 433 that address. This timer is reset each time an EXCLUDE mode listener 434 confirms its listening state through a Current State Report. The 435 timer is also updated when a listener, formerly in INCLUDE mode, 436 announces its filter mode change through a State Change Report 437 message. If the Filter Timer expires, it means that there are no 438 more listeners in EXCLUDE mode on the link. In this case, the router 439 switches back to INCLUDE mode for that multicast address. 441 When the router is in EXCLUDE mode, the router state is represented 442 by the notation EXCLUDE (X,Y), where X is called the "Requested List" 443 and Y is called the "Exclude List". All sources, except those from 444 the Exclude List, will be forwarded by the router. The Requested 445 List has no effect on forwarding. Nevertheless, the router has to 446 maintain the Requested List for two reasons: 448 To keep track of sources that listeners in INCLUDE mode listen to. 449 This is necessary to assure a seamless transition of the router to 450 INCLUDE mode, when there is no listener in EXCLUDE mode left. 451 This transition should not interrupt the flow of traffic to 452 listeners in INCLUDE mode for that multicast address. Therefore, 453 at the time of the transition, the Requested List should contain 454 the set of sources that nodes in INCLUDE mode have explicitly 455 requested. 457 When the router switches to INCLUDE mode, the sources in the 458 Requested List are moved to the Include List, and the Exclude List 459 is deleted. Before switching, the Requested List can contain an 460 inexact guess of the sources listeners in INCLUDE mode listen to - 461 might be too large or too small. These inexactitudes are due to 462 the fact that the Requested List is also used for fast blocking 463 purposes, as described below. If such a fast blocking is 464 required, some sources may be deleted from the Requested List (as 465 shown in Tables 7.4.1 and 7.4.2) in order to reduce router state. 466 Nevertheless, in each such case the Filter Timer is updated as 467 well. Therefore, listeners in INCLUDE mode will have enough time, 468 before an eventual switching, to reconfirm their interest in the 469 eliminated source(s), and rebuild the Requested List accordingly. 470 The protocol ensures that when a switch to INCLUDE mode occurs, 471 the Requested List will be accurate. Details about the transition 472 of the router to INCLUDE mode are presented in Appendix A.3. 474 To allow the fast blocking of previously unblocked sources. If 475 the router receives a report that contains such a request, the 476 concerned sources are added to the Requested List. Their timers 477 are set to a given small value, and a Multicast Address and Source 478 Specific Query is sent by the Querier, to check whether there are 479 nodes on the link still interested in those sources, or not. If 480 no node announces its interest in receiving those specific source, 481 the timers of those sources expire. Then, the sources are moved 482 from the Requested List to the Exclude List. From then on, the 483 sources will be blocked by the router. 485 The handling of the EXCLUDE mode router state, according to the 486 received reports, is detailed in Tables 7.4.1 and 7.4.2. 488 Both the MLDv2 router and listener behaviors described in this 489 document were defined to ensure backward interoperability with MLDv1 490 hosts and routers. Interoperability issues are detailed in 491 Section 8. 493 3. The Service Interface for Requesting IP Multicast Reception 495 Within an IP system, there is (at least conceptually) a service 496 interface used by upper-layer protocols or application programs to 497 ask the IP layer to enable or disable reception of packets sent to 498 specific IP multicast addresses. In order to take full advantage of 499 the capabilities of MLDv2, a node's IP service interface must support 500 the following operation: 502 IPv6MulticastListen ( socket, interface, IPv6 multicast-address, 503 filter-mode, source-list ) 505 where: 507 o "socket" is an implementation-specific parameter used to 508 distinguish among different requesting entities (e.g., programs, 509 processes) within the node; the socket parameter of BSD Unix 510 system calls is a specific example. 512 o "interface" is a local identifier of the network interface on 513 which reception of the specified multicast address is to be 514 enabled or disabled. Interfaces may be physical (e.g., an 515 Ethernet interface) or virtual (e.g., the endpoint of a Frame 516 Relay virtual circuit or an IP-in-IP "tunnel"). An implementation 517 may allow a special "unspecified" value to be passed as the 518 interface parameter, in which case the request would apply to the 519 "primary" or "default" interface of the node (perhaps established 520 by system configuration). If reception of the same multicast 521 address is desired on more than one interface, IPv6MulticastListen 522 is invoked separately for each desired interface. 524 o "IPv6 multicast address" is the multicast address to which the 525 request pertains. If reception of more than one multicast address 526 on a given interface is desired, IPv6MulticastListen is invoked 527 separately for each desired address. 529 o "filter mode" may be either INCLUDE or EXCLUDE. In INCLUDE mode, 530 reception of packets sent to the specified multicast address is 531 requested only from the source addresses listed in the source list 532 parameter. In EXCLUDE mode, reception of packets sent to the 533 given multicast address is requested from all source addresses 534 except those listed in the source list parameter. 536 o "source list" is an unordered list of zero or more unicast 537 addresses from which multicast reception is desired or not 538 desired, depending on the filter mode. An implementation MAY 539 impose a limit on the size of source lists. When an operation 540 causes the source list size limit to be exceeded, the service 541 interface SHOULD return an error. 543 For a given combination of socket, interface, and IPv6 multicast 544 address, only a single filter mode and source list can be in effect 545 at any one time. Nevertheless, either the filter mode or the source 546 list, or both, may be changed by subsequent IPv6MulticastListen 547 requests that specify the same socket, interface, and IPv6 multicast 548 address. Each subsequent request completely replaces any earlier 549 request for the given socket, interface, and multicast address. 551 The MLDv1 protocol did not support source filters, and had a simpler 552 service interface; it consisted of Start Listening and Stop Listening 553 operations to enable and disable listening to a given multicast 554 address (from all sources) on a given interface. The equivalent 555 operations in the new service interface are as follows: 557 The Start Listening operation is equivalent to: 559 IPv6MulticastListen ( socket, interface, IPv6 multicast address, 560 EXCLUDE, {} ) 562 and the Stop Listening operation is equivalent to: 564 IPv6MulticastListen ( socket, interface, IPv6 multicast address, 565 INCLUDE, {} ) 567 where {} is an empty source list. 569 An example of an API that provides the capabilities outlined in this 570 service interface is given in [RFC3678]. 572 4. Multicast Listening State Maintained by Nodes 574 4.1. Per-Socket State 576 For each socket on which IPv6MulticastListen has been invoked, the 577 node records the desired multicast listening state for that socket. 578 That state conceptually consists of a set of records of the form: 580 (interface, IPv6 multicast address, filter mode, source list) 582 The per-socket state evolves in response to each invocation of 583 IPv6MulticastListen on the socket, as follows: 585 If the requested filter mode is INCLUDE and the requested source 586 list is empty, then the entry that corresponds to the requested 587 interface and multicast address is deleted, if present. If no 588 such entry is present, the request has no effect. 590 If the requested filter mode is EXCLUDE or the requested source 591 list is non-empty, then the entry that corresponds to the 592 requested interface and multicast address, if present, is changed 593 to contain the requested filter mode and source list. If no such 594 entry is present, a new entry is created, using the parameters 595 specified in the request. 597 4.2. Per-Interface State 599 In addition to the per-socket multicast listening state, a node must 600 also maintain or compute multicast listening state for each of its 601 interfaces. That state conceptually consists of a set of records of 602 the form: 604 (IPv6 multicast address, filter mode, source list) 606 At most one record per multicast address exists for a given 607 interface. This per-interface state is derived from the per-socket 608 state, but may differ from it when different sockets have differing 609 filter modes and/or source lists for the same multicast address and 610 interface. For example, suppose one application or process invokes 611 the following operation on socket s1: 613 IPv6MulticastListen ( s1, i, m, INCLUDE, {a, b, c} ) 615 requesting reception on interface i of packets sent to multicast 616 address m, only if they come from the sources a, b, or c. Suppose 617 another application or process invokes the following operation on 618 socket s2: 620 IPv6MulticastListen ( s2, i, m, INCLUDE, {b, c, d} ) 622 requesting reception on the same interface i of packets sent to the 623 same multicast address m, only if they come from sources b, c, or d. 624 In order to satisfy the reception requirements of both sockets, it is 625 necessary for interface i to receive packets sent to m from any one 626 of the sources a, b, c, or d. Thus, in this example, the listening 627 state of interface i for multicast address m has filter mode INCLUDE 628 and source list {a, b, c, d}. 630 After a multicast packet has been accepted from an interface by the 631 IP layer, its subsequent delivery to the application or process that 632 listens on a particular socket depends on the multicast listening 633 state of that socket (and possibly also on other conditions, such as 634 what transport-layer port the socket is bound to). So, in the above 635 example, if a packet arrives on interface i, destined to multicast 636 address m, with source address a, it may be delivered on socket s1 637 but not on socket s2. Note that MLDv2 messages are not subject to 638 source filtering and must always be processed by hosts and routers. 640 Requiring the filtering of packets based upon a socket's multicast 641 reception state is a new feature of this service interface. The 642 previous service interface described no filtering based upon 643 multicast listening state; rather, a Start Listening operation on a 644 socket simply caused the node to start to listen to a multicast 645 address on the given interface; packets sent to that multicast 646 address could be delivered to all sockets, whether they had started 647 to listen or not. 649 The general rules for deriving the per-interface state from the per- 650 socket state are as follows: for each distinct (interface, IPv6 651 multicast address) pair that appears in any per-socket state, a per- 652 interface record is created for that multicast address on that 653 interface. Considering all socket records that contain the same 654 (interface, IPv6 multicast address) pair, 656 if any such record has a filter mode of EXCLUDE, then the filter 657 mode of the interface record is EXCLUDE, and the source list of 658 the interface record is the intersection of the source lists of 659 all socket records in EXCLUDE mode, minus those source addresses 660 that appear in any socket record in INCLUDE mode. For example, if 661 the socket records for multicast address m on interface i are: 663 from socket s1: ( i, m, EXCLUDE, {a, b, c, d} ) 665 from socket s2: ( i, m, EXCLUDE, {b, c, d, e} ) 667 from socket s3: ( i, m, INCLUDE, {d, e, f} ) 669 then the corresponding interface record on interface i is: 671 ( m, EXCLUDE, {b, c} ) 673 If a fourth socket is added, such as: 675 From socket s4: ( i, m, EXCLUDE, {} ) 677 then the interface record becomes: 679 ( m, EXCLUDE, {} ) 681 if all such records have a filter mode of INCLUDE, then the filter 682 mode of the interface record is INCLUDE, and the source list of 683 the interface record is the union of the source lists of all the 684 socket records. For example, if the socket records for multicast 685 address m on interface i are: 687 from socket s1: ( i, m, INCLUDE, {a, b, c} ) 689 from socket s2: ( i, m, INCLUDE, {b, c, d} ) 691 from socket s3: ( i, m, INCLUDE, {e, f} ) 693 then the corresponding interface record on interface i is: 695 ( m, INCLUDE, {a, b, c, d, e, f} ) 697 An implementation MUST NOT use an EXCLUDE interface record for a 698 multicast address if all sockets for this multicast address are in 699 INCLUDE state. If system resource limits are reached when a per- 700 interface state source list is calculated, an error MUST be 701 returned to the application which requested the operation. 703 The above rules for deriving the per-interface state are 704 (re)evaluated whenever an IPv6MulticastListen invocation modifies the 705 per-socket state by adding, deleting, or modifying a per-socket state 706 record. Note that a change of the per-socket state does not 707 necessarily result in a change of the per-interface state. 709 5. Message Formats 711 MLDv2 is a sub-protocol of ICMPv6, that is, MLDv2 message types are a 712 subset of ICMPv6 messages, and MLDv2 messages are identified in IPv6 713 packets by a preceding Next Header value of 58. All MLDv2 messages 714 described in this document MUST be sent with a link-local IPv6 Source 715 Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option 716 [RFC2711] in a Hop-by-Hop Options header. (The Router Alert option 717 is necessary to cause routers to examine MLDv2 messages sent to IPv6 718 multicast addresses in which the routers themselves have no 719 interest.) MLDv2 Reports can be sent with the source address set to 720 the unspecified address [RFC3513], if a valid link-local IPv6 source 721 address has not been acquired yet for the sending interface. (See 722 Section 5.2.13. for details.) 724 There are two MLD message types of concern to the MLDv2 protocol 725 described in this document: 727 Multicast Listener Query (Type = decimal 130) 729 Version 2 Multicast Listener Report (Type = decimal 143). See 730 Section 11 for IANA considerations. 732 To assure the interoperability with nodes that implement MLDv1 (see 733 Section 8), an implementation of MLDv2 must also support the 734 following two message types: 736 Version 1 Multicast Listener Report (Type = decimal 131) [RFC2710] 738 Version 1 Multicast Listener Done (Type = decimal 132) [RFC2710] 740 Unrecognized message types MUST be silently ignored. Other message 741 types may be used by newer versions or extensions of MLD, by 742 multicast routing protocols, or for other uses. 744 In this document, unless otherwise qualified, the capitalized words 745 "Query" and "Report" refer to MLD Multicast Listener Queries and MLD 746 Version 2 Multicast Listener Reports, respectively. 748 5.1. Multicast Listener Query Message 750 Multicast Listener Queries are sent by multicast routers in Querier 751 State to query the multicast listening state of neighboring 752 interfaces. Queries have the following format: 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Type = 130 | Code | Checksum | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Maximum Response Code | Reserved | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | | 762 * * 763 | | 764 * Multicast Address * 765 | | 766 * * 767 | | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Resv |S| QRV | QQIC | Number of Sources (N) | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | | 772 * * 773 | | 774 * Source Address [1] * 775 | | 776 * * 777 | | 778 +- -+ 779 | | 780 * * 781 | | 782 * Source Address [2] * 783 | | 784 * * 785 | | 786 +- . -+ 787 . . . 788 . . . 789 +- -+ 790 | | 791 * * 792 | | 793 * Source Address [N] * 794 | | 795 * * 796 | | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 5.1.1. Code 801 Initialized to zero by the sender; ignored by receivers. 803 5.1.2. Checksum 805 The standard ICMPv6 checksum; it covers the entire MLDv2 message, 806 plus a "pseudo-header" of IPv6 header fields [RFC2463]. For 807 computing the checksum, the Checksum field is set to zero. When a 808 packet is received, the checksum MUST be verified before processing 809 it. 811 5.1.3. Maximum Response Code 813 The Maximum Response Code field specifies the maximum time allowed 814 before sending a responding Report. The actual time allowed, called 815 the Maximum Response Delay, is represented in units of milliseconds, 816 and is derived from the Maximum Response Code as follows: 818 If Maximum Response Code < 32768, Maximum Response Delay = Maximum 819 Response Code 821 If Maximum Response Code >=32768, Maximum Response Code represents a 822 floating-point value as follows: 824 0 1 2 3 4 5 6 7 8 9 A B C D E F 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 |1| exp | mant | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 Maximum Response Delay = (mant | 0x1000) << (exp+3) 831 Small values of Maximum Response Delay allow MLDv2 routers to tune 832 the "leave latency" (the time between the moment the last node on a 833 link ceases to listen to a specific multicast address and the moment 834 the routing protocol is notified that there are no more listeners for 835 that address). Larger values, especially in the exponential range, 836 allow the tuning of the burstiness of MLD traffic on a link. 838 5.1.4. Reserved 840 Initialized to zero by the sender; ignored by receivers. 842 5.1.5. Multicast Address 844 For a General Query, the Multicast Address field is set to zero. For 845 a Multicast Address Specific Query or Multicast Address and Source 846 Specific Query, it is set to the multicast address being queried (see 847 Section 5.1.10, below). 849 5.1.6. Resv 851 Initialized to zero by the sender; ignored by receivers. 853 5.1.7. S Flag (Suppress Router-Side Processing) 855 When set to one, the S Flag indicates to any receiving multicast 856 routers that they have to suppress the normal timer updates they 857 perform upon hearing a Query. Nevertheless, it does not suppress the 858 querier election or the normal "host-side" processing of a Query that 859 a router may be required to perform as a consequence of itself being 860 a multicast listener. 862 5.1.8. QRV (Querier's Robustness Variable) 864 If non-zero, the QRV field contains the [Robustness Variable] value 865 used by the Querier. If the Querier's [Robustness Variable] exceeds 866 7 (the maximum value of the QRV field), the QRV field is set to zero. 868 Routers adopt the QRV value from the most recently received Query as 869 their own [Robustness Variable] value, unless that most recently 870 received QRV was zero, in which case they use the default [Robustness 871 Variable] value specified in Section 9.1, or a statically configured 872 value. 874 5.1.9. QQIC (Querier's Query Interval Code) 876 The Querier's Query Interval Code field specifies the [Query 877 Interval] used by the Querier. The actual interval, called the 878 Querier's Query Interval (QQI), is represented in units of seconds, 879 and is derived from the Querier's Query Interval Code as follows: 881 If QQIC < 128, QQI = QQIC 883 If QQIC >= 128, QQIC represents a floating-point value as follows: 885 0 1 2 3 4 5 6 7 886 +-+-+-+-+-+-+-+-+ 887 |1| exp | mant | 888 +-+-+-+-+-+-+-+-+ 890 QQI = (mant | 0x10) << (exp + 3) 892 Multicast routers that are not the current Querier adopt the QQI 893 value from the most recently received Query as their own [Query 894 Interval] value, unless that most recently received QQI was zero, in 895 which case the receiving routers use the default [Query Interval] 896 value specified in Section 9.2. 898 5.1.10. Number of Sources (N) 900 The Number of Sources (N) field specifies how many source addresses 901 are present in the Query. This number is zero in a General Query or 902 a Multicast Address Specific Query, and non-zero in a Multicast 903 Address and Source Specific Query. This number is limited by the MTU 904 of the link over which the Query is transmitted. For example, on an 905 Ethernet link with an MTU of 1500 octets, the IPv6 header (40 octets) 906 together with the Hop-By-Hop Extension Header (8 octets) that 907 includes the Router Alert option consume 48 octets; the MLD fields up 908 to the Number of Sources (N) field consume 28 octets; thus, there are 909 1424 octets left for source addresses, which limits the number of 910 source addresses to 89 (1424/16). 912 5.1.11. Source Address [i] 914 The Source Address [i] fields are a vector of n unicast addresses, 915 where n is the value in the Number of Sources (N) field. 917 5.1.12. Additional Data 919 If the Payload Length field in the IPv6 header of a received Query 920 indicates that there are additional octets of data present, beyond 921 the fields described here, MLDv2 implementations MUST include those 922 octets in the computation to verify the received MLD Checksum, but 923 MUST otherwise ignore those additional octets. When sending a Query, 924 an MLDv2 implementation MUST NOT include additional octets beyond the 925 fields described above. 927 5.1.13. Query Variants 929 There are three variants of the Query message: 931 A "General Query" is sent by the Querier to learn which multicast 932 addresses have listeners on an attached link. In a General Query, 933 both the Multicast Address field and the Number of Sources (N) 934 field are zero. 936 A "Multicast Address Specific Query" is sent by the Querier to 937 learn if a particular multicast address has any listeners on an 938 attached link. In a Multicast Address Specific Query, the 939 Multicast Address field contains the multicast address of 940 interest, while the Number of Sources (N) field is set to zero. 942 A "Multicast Address and Source Specific Query" is sent by the 943 Querier to learn if any of the sources from the specified list for 944 the particular multicast address has any listeners on an attached 945 link or not. In a Multicast Address and Source Specific Query the 946 Multicast Address field contains the multicast address of 947 interest, while the Source Address [i] field(s) contain(s) the 948 source address(es) of interest. 950 5.1.14. Source Addresses for Queries 952 All MLDv2 Queries MUST be sent with a valid IPv6 link-local source 953 address. If a node (router or host) receives a Query message with 954 the IPv6 Source Address set to the unspecified address (::), or any 955 other address that is not a valid IPv6 link-local address, it MUST 956 silently discard the message and SHOULD log a warning. 958 5.1.15. Destination Addresses for Queries 960 In MLDv2, General Queries are sent to the link-scope all-nodes 961 multicast address (FF02::1). Multicast Address Specific and 962 Multicast Address and Source Specific Queries are sent with an IP 963 destination address equal to the multicast address of interest. 964 However, a node MUST accept and process any Query whose IP 965 Destination Address field contains any of the addresses (unicast or 966 multicast) assigned to the interface on which the Query arrives. 967 This might be useful, e.g., for debugging purposes. 969 5.2. Version 2 Multicast Listener Report Message 971 Version 2 Multicast Listener Reports are sent by IP nodes to report 972 (to neighboring routers) the current multicast listening state, or 973 changes in the multicast listening state, of their interfaces. 974 Reports have the following format: 976 0 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Type = 143 | Reserved | Checksum | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Reserved |Nr of Mcast Address Records (M)| 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | | 984 . . 985 . Multicast Address Record [1] . 986 . . 987 | | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | | 990 . . 991 . Multicast Address Record [2] . 992 . . 993 | | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | . | 996 . . . 997 | . | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | | 1000 . . 1001 . Multicast Address Record [M] . 1002 . . 1003 | | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 Each Multicast Address Record has the following internal format: 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | Record Type | Aux Data Len | Number of Sources (N) | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | | 1012 * * 1013 | | 1014 * Multicast Address * 1015 | | 1016 * * 1017 | | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | | 1020 * * 1021 | | 1022 * Source Address [1] * 1023 | | 1024 * * 1025 | | 1026 +- -+ 1027 | | 1028 * * 1029 | | 1030 * Source Address [2] * 1031 | | 1032 * * 1033 | | 1034 +- -+ 1035 . . . 1036 . . . 1037 . . . 1038 +- -+ 1039 | | 1040 * * 1041 | | 1042 * Source Address [N] * 1043 | | 1044 * * 1045 | | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | | 1048 . . 1049 . Auxiliary Data . 1050 . . 1051 | | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 5.2.1. Reserved 1056 The Reserved fields are set to zero on transmission, and ignored on 1057 reception. 1059 5.2.2. Checksum 1061 The standard ICMPv6 checksum; it covers the entire MLDv2 message, 1062 plus a "pseudo-header" of IPv6 header fields [RFC2460][RFC2463]. In 1063 order to compute the checksum, the Checksum field is set to zero. 1064 When a packet is received, the checksum MUST be verified before 1065 processing it. 1067 5.2.3. Nr of Mcast Address Records (M) 1069 The Nr of Mcast Address Records (M) field specifies how many 1070 Multicast Address Records are present in this Report. 1072 5.2.4. Multicast Address Record 1074 Each Multicast Address Record is a block of fields that contain 1075 information on the sender listening to a single multicast address on 1076 the interface from which the Report is sent. 1078 5.2.5. Record Type 1080 It specifies the type of the Multicast Address Record. See 1081 Section 5.2.12 for a detailed description of the different possible 1082 Record Types. 1084 5.2.6. Aux Data Len 1086 The Aux Data Len field contains the length of the Auxiliary Data 1087 Field in this Multicast Address Record, in units of 32-bit words. It 1088 may contain zero, to indicate the absence of any auxiliary data. 1090 5.2.7. Number of Sources (N) 1092 The Number of Sources (N) field specifies how many source addresses 1093 are present in this Multicast Address Record. 1095 5.2.8. Multicast Address 1097 The Multicast Address field contains the multicast address to which 1098 this Multicast Address Record pertains. 1100 5.2.9. Source Address [i] 1102 The Source Address [i] fields are a vector of n unicast addresses, 1103 where n is the value in this record's Number of Sources (N) field. 1105 5.2.10. Auxiliary Data 1107 The Auxiliary Data field, if present, contains additional information 1108 that pertain to this Multicast Address Record. The protocol 1109 specified in this document, MLDv2, does not define any auxiliary 1110 data. Therefore, implementations of MLDv2 MUST NOT include any 1111 auxiliary data (i.e., MUST set the Aux Data Len field to zero) in any 1112 transmitted Multicast Address Record, and MUST ignore any such data 1113 present in any received Multicast Address Record. The semantics and 1114 the internal encoding of the Auxiliary Data field are to be defined 1115 by any future version or extension of MLD that uses this field. 1117 5.2.11. Additional Data 1119 If the Payload Length field in the IPv6 header of a received Report 1120 indicates that there are additional octets of data present, beyond 1121 the last Multicast Address Record, MLDv2 implementations MUST include 1122 those octets in the computation to verify the received MLD Checksum, 1123 but MUST otherwise ignore those additional octets. When sending a 1124 Report, an MLDv2 implementation MUST NOT include additional octets 1125 beyond the last Multicast Address Record. 1127 5.2.12. Multicast Address Record Types 1129 There are a number of different types of Multicast Address Records 1130 that may be included in a Report message: 1132 A "Current State Record" is sent by a node in response to a Query 1133 received on an interface. It reports the current listening state 1134 of that interface, with respect to a single multicast address. 1135 The Record Type of a Current State Record may be one of the 1136 following two values: 1138 1 - MODE_IS_INCLUDE - indicates that the interface has a filter 1139 mode of INCLUDE for the specified multicast address. The 1140 Source Address [i] fields in this Multicast Address Record 1141 contain the interface's source list for the specified 1142 multicast address. A MODE_IS_INCLUDE Record is never sent 1143 with an empty source list. 1145 2 - MODE_IS_EXCLUDE - indicates that the interface has a filter 1146 mode of EXCLUDE for the specified multicast address. The 1147 Source Address [i] fields in this Multicast Address Record 1148 contain the interface's source list for the specified 1149 multicast address, if it is non-empty. 1151 A "Filter Mode Change Record" is sent by a node whenever a local 1152 invocation of IPv6MulticastListen causes a change of the filter 1153 mode (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to 1154 INCLUDE) of the interface-level state entry for a particular 1155 multicast address, whether the source list changes at the same 1156 time or not. The Record is included in a Report sent from the 1157 interface on which the change occurred. The Record Type of a 1158 Filter Mode Change Record may be one of the following two values: 1160 3 - CHANGE_TO_INCLUDE_MODE - indicates that the interface has 1161 changed to INCLUDE filter mode for the specified multicast 1162 address. The Source Address [i] fields in this Multicast 1163 Address Record contain the interface's new source list for 1164 the specified multicast address, if it is non-empty. 1166 4 - CHANGE_TO_EXCLUDE_MODE - indicates that the interface has 1167 changed to EXCLUDE filter mode for the specified multicast 1168 address. The Source Address [i] fields in this Multicast 1169 Address Record contain the interface's new source list for 1170 the specified multicast address, if it is non-empty. 1172 A "Source List Change Record" is sent by a node whenever a local 1173 invocation of IPv6MulticastListen causes a change of source list 1174 that is not coincident with a change of filter mode, of the 1175 interface-level state entry for a particular multicast address. 1176 The Record is included in a Report sent from the interface on 1177 which the change occurred. The Record Type of a Source List 1178 Change Record may be one of the following two values: 1180 5 - ALLOW_NEW_SOURCES - indicates that the Source Address [i] 1181 fields in this Multicast Address Record contain a list of 1182 the additional sources that the node wishes to listen to, 1183 for packets sent to the specified multicast address. If the 1184 change was to an INCLUDE source list, these are the 1185 addresses that were added to the list; if the change was to 1186 an EXCLUDE source list, these are the addresses that were 1187 deleted from the list. 1189 6 - BLOCK_OLD_SOURCES - indicates that the Source Address [i] 1190 fields in this Multicast Address Record contain a list of 1191 the sources that the node no longer wishes to listen to, for 1192 packets sent to the specified multicast address. If the 1193 change was to an INCLUDE source list, these are the 1194 addresses that were deleted from the list; if the change was 1195 to an EXCLUDE source list, these are the addresses that were 1196 added to the list. 1198 If a change of source list results in both allowing new sources and 1199 blocking old sources, then two Multicast Address Records are sent for 1200 the same multicast address, one of type ALLOW_NEW_SOURCES and one of 1201 type BLOCK_OLD_SOURCES. 1203 We use the term "State Change Record" to refer to either a Filter 1204 Mode Change Record or a Source List Change Record. 1206 Multicast Address Records with an unrecognized Record Type value MUST 1207 be silently ignored, with the rest of the report being processed. 1209 In the rest of this document, we use the following notation to 1210 describe the contents of a Multicast Address Record that pertains to 1211 a particular multicast address: 1213 IS_IN ( x ) - Type MODE_IS_INCLUDE, source addresses x 1214 IS_EX ( x ) - Type MODE_IS_EXCLUDE, source addresses x 1215 TO_IN ( x ) - Type CHANGE_TO_INCLUDE_MODE, source addresses x 1216 TO_EX ( x ) - Type CHANGE_TO_EXCLUDE_MODE, source addresses x 1217 ALLOW ( x ) - Type ALLOW_NEW_SOURCES, source addresses x 1218 BLOCK ( x ) - Type BLOCK_OLD_SOURCES, source addresses x 1220 where x is either: 1222 a capital letter (e.g., "A") to represent the set of source 1223 addresses, or 1225 a set expression (e.g., "A+B"), where "A+B" means the union of 1226 sets A and B, "A*B" means the intersection of sets A and B, and 1227 "A-B" means the removal of all elements of set B from set A. 1229 5.2.13. Source Addresses for Reports 1231 An MLDv2 Report MUST be sent with a valid IPv6 link-local source 1232 address, or the unspecified address (::), if the sending interface 1233 has not acquired a valid link-local address yet. Sending reports 1234 with the unspecified address is allowed to support the use of IP 1235 multicast in the Neighbor Discovery Protocol [RFC2461]. For 1236 stateless autoconfiguration, as defined in [RFC2462], a node is 1237 required to join several IPv6 multicast groups, in order to perform 1238 Duplicate Address Detection (DAD). Prior to DAD, the only address 1239 the reporting node has for the sending interface is a tentative one, 1240 which cannot be used for communication. Thus, the unspecified 1241 address must be used. 1243 On the other hand, routers MUST silently discard a message that is 1244 not sent with a valid link-local address, without taking any action 1245 on the contents of the packet. Thus, a Report is discarded if the 1246 router cannot identify the source address of the packet as belonging 1247 to a link connected to the interface on which the packet was 1248 received. A Report sent with the unspecified address is also 1249 discarded by the router. This enhances security, as unidentified 1250 reporting nodes cannot influence the state of the MLDv2 router(s). 1251 Nevertheless, the reporting node has modified its listening state for 1252 multicast addresses that are contained in the Multicast Address 1253 Records of the Report message. From now on, it will treat packets 1254 sent to those multicast addresses according to this new listening 1255 state. Once a valid link-local address is available, a node SHOULD 1256 generate new MLDv2 Report messages for all multicast addresses joined 1257 on the interface. 1259 5.2.14. Destination Addresses for Reports 1261 Version 2 Multicast Listener Reports are sent with an IP destination 1262 address of FF02:0:0:0:0:0:0:16, to which all MLDv2-capable multicast 1263 routers listen (see Section 11 for IANA considerations related to 1264 this special destination address). A node that operates in version 1 1265 compatibility mode (see details in Section 8) sends version 1 Reports 1266 to the multicast address specified in the Multicast Address field of 1267 the Report. In addition, a node MUST accept and process any version 1268 1 Report whose IP Destination Address field contains any of the IPv6 1269 addresses (unicast or multicast) assigned to the interface on which 1270 the Report arrives. This might be useful, e.g., for debugging 1271 purposes. 1273 5.2.15. Multicast Listener Report Size 1275 If the set of Multicast Address Records required in a Report does not 1276 fit within the size limit of a single Report message (as determined 1277 by the MTU of the link on which it will be sent), the Multicast 1278 Address Records are sent in as many Report messages as needed to 1279 report the entire set. 1281 If a single Multicast Address Record contains so many source 1282 addresses that it does not fit within the size limit of a single 1283 Report message, then: 1285 if its Type is not IS_EX or TO_EX, it is split into multiple 1286 Multicast Address Records; each such record contains a different 1287 subset of the source addresses, and is sent in a separate Report. 1289 if its Type is IS_EX or TO_EX, a single Multicast Address Record 1290 is sent, with as many source addresses as can fit; the remaining 1291 source addresses are not reported. Although the choice of which 1292 sources to report is arbitrary, it is preferable to report the 1293 same set of sources in each subsequent report, rather than 1294 reporting different sources each time. 1296 6. Protocol Description for Multicast Address Listeners 1298 MLD is an asymmetric protocol, as it specifies separate behaviors for 1299 multicast address listeners -- that is, hosts or routers that listen 1300 to multicast packets -- and multicast routers. This section 1301 describes the part of MLDv2 that applies to all multicast address 1302 listeners. (Note that a multicast router that is also a multicast 1303 address listener performs both parts of MLDv2; it receives and it 1304 responds to its own MLD messages, as well as to those of its 1305 neighbors.) The multicast router part of MLDv2 is described in 1306 Section 7. 1308 A node performs the protocol described in this section over all 1309 interfaces on which multicast reception is supported, even if more 1310 than one of those interfaces are connected to the same link. 1312 For interoperability with multicast routers that run the MLDv1 1313 protocol, nodes maintain a Host Compatibility Mode variable for each 1314 interface on which multicast reception is supported. This section 1315 describes the behavior of multicast address listener nodes on 1316 interfaces for which Host Compatibility Mode = MLDv2. The algorithm 1317 for determining Host Compatibility Mode, and the behavior if its 1318 value is set to MLDv1, are described in Section 8. 1320 The link-scope all-nodes multicast address, (FF02::1), is handled as 1321 a special case. On all nodes -- that is all hosts and routers, 1322 including multicast routers -- listening to packets destined to the 1323 all-nodes multicast address, from all sources, is permanently enabled 1324 on all interfaces on which multicast listening is supported. No MLD 1325 messages are ever sent regarding neither the link-scope all-nodes 1326 multicast address, nor any multicast address of scope 0 (reserved) or 1327 1 (node-local). Multicast listeners MUST send MLD messages for all 1328 multicast addresses except for the link-scope all-nodes multicast 1329 address and any multicast addresses of scope less than 2. 1331 There are three types of events that trigger MLDv2 protocol actions 1332 on an interface: 1334 a change of the per-interface listening state, caused by a local 1335 invocation of IPv6MulticastListen; 1337 the firing of a specific timer; 1338 the reception of a Query. 1340 (Received MLD messages of types other than Query are silently 1341 ignored, except as required for interoperation with nodes that 1342 implement MLDv1.) 1344 The following subsections describe the actions to be taken for each 1345 case. Timer and counter names appear in square brackets. Default 1346 values for those timers and counters are specified in Section 9. 1348 6.1. Action on Change of Per-Interface State 1350 An invocation of IPv6MulticastListen may cause the multicast 1351 listening state of an interface to change, according to the rules in 1352 Section 4.2. Each such change affects the per-interface entry for a 1353 single multicast address. 1355 A change of per-interface state causes the node to immediately 1356 transmit a State Change Report from that interface. The type and 1357 contents of the Multicast Address Record(s) in that Report are 1358 determined by comparing the filter mode and source list for the 1359 affected multicast address before and after the change, according to 1360 the table below. If no per-interface state existed for that 1361 multicast address before the change (i.e., the change consisted of 1362 creating a new per-interface record), or if no state exists after the 1363 change (i.e., the change consisted of deleting a per-interface 1364 record), then the "non-existent" state is considered to have an 1365 INCLUDE filter mode and an empty source list. 1367 +-------------+-------------+--------------------------+ 1368 | Old State | New State | State Change Record Sent | 1369 +-------------+-------------+--------------------------+ 1370 | INCLUDE (A) | INCLUDE (B) | ALLOW (B-A), BLOCK (A-B) | 1371 | EXCLUDE (A) | EXCLUDE (B) | ALLOW (A-B), BLOCK (B-A) | 1372 | INCLUDE (A) | EXCLUDE (B) | TO_EX (B) | 1373 | EXCLUDE (A) | INCLUDE (B) | TO_IN (B) | 1374 +-------------+-------------+--------------------------+ 1376 If the computed source list for either an ALLOW or a BLOCK State 1377 Change Record is empty, that record is omitted from the Report. 1379 To cover the possibility of the State Change Report being missed by 1380 one or more multicast routers, [Robustness Variable] - 1 1381 retransmissions are scheduled, through a Retransmission Timer, at 1382 intervals chosen at random from the range (0, [Unsolicited Report 1383 Interval]). 1385 If more changes to the same per-interface state entry occur before 1386 all the retransmissions of the State Change Report for the first 1387 change have been completed, each such additional change triggers the 1388 immediate transmission of a new State Change Report. 1390 The contents of the new Report are calculated as follows: 1392 As for the first Report, the per-interface state for the affected 1393 multicast address before and after the latest change is compared. 1395 The records that express the difference are built according to the 1396 table above. Nevertheless, these records are not transmitted in a 1397 separate message, but they are instead merged with the contents of 1398 the pending report, to create the new State Change Report. The 1399 rules for calculating this merged report are described below. 1401 The transmission of the merged State Change Report terminates 1402 retransmissions of the earlier State Change Reports for the same 1403 multicast address, and becomes the first of [Robustness Variable] 1404 transmissions of the new State Change Reports. These transmissions 1405 are necessary in order to ensure that each instance of state change 1406 is transmitted at least [Robustness Variable] times. 1408 Each time a source is included in the difference report calculated 1409 above, retransmission state for that source needs to be maintained 1410 until [Robustness Variable] State Change Reports have been sent by 1411 the node. This is done in order to ensure that a series of 1412 successive state changes do not break the protocol robustness. 1413 Sources in retransmission state can be kept in a per multicast 1414 address Retransmission List, with a Source Retransmission Counter 1415 associated to each source in the list. When a source is included in 1416 the list, its counter is set to [Robustness Variable]. Each time a 1417 State Change Report is sent the counter is decreased by one unit. 1418 When the counter reaches zero, the source is deleted from the 1419 Retransmission List for that multicast address. 1421 If the per-interface listening change that triggers the new report is 1422 a filter mode change, then the next [Robustness Variable] State 1423 Change Reports will include a Filter Mode Change Record. This 1424 applies even if any number of source list changes occur in that 1425 period. The node has to maintain retransmission state for the 1426 multicast address until the [Robustness Variable] State Change 1427 Reports have been sent. This can be done through a per multicast 1428 address Filter Mode Retransmission Counter. When the filter mode 1429 changes, the counter is set to [Robustness Variable]. Each time a 1430 State Change Report is sent the counter is decreased by one unit. 1431 When the counter reaches zero, i.e., [Robustness Variable] State 1432 Change Reports with Filter Mode Change Records have been transmitted 1433 after the last filter mode change, and if source list changes have 1434 resulted in additional reports being scheduled, then the next State 1435 Change Report will include Source List Change Records. 1437 Each time a per-interface listening state change triggers the 1438 Immediate transmission of a new State Change Report, its contents are 1439 determined as follows. If the report should contain a Filter Mode 1440 Change Record, i.e., the Filter Mode Retransmission Counter for that 1441 multicast address has a value higher than zero, then, if the current 1442 filter mode of the interface is INCLUDE, a TO_IN record is included 1443 in the report; otherwise a TO_EX record is included. If instead the 1444 report should contain Source List Change Records, i.e., the Filter 1445 Mode Retransmission Counter for that multicast address is zero, an 1446 ALLOW and a BLOCK record is included. The contents of these records 1447 are built according to the table below. 1449 +--------+----------------------------------------------------------+ 1450 | Record | Sources Included | 1451 +--------+----------------------------------------------------------+ 1452 | TO_IN | All in the current per-interface state that must be | 1453 | | forwarded | 1454 | TO_EX | All in the current per-interface state that must be | 1455 | | blocked | 1456 | ALLOW | All with retransmission state (i.e., all sources from | 1457 | | the Retransmission List) that must be forwarded | 1458 | BLOCK | All with retransmission state that must be blocked | 1459 +--------+----------------------------------------------------------+ 1461 If the computed source list for either an ALLOW or a BLOCK record is 1462 empty, that record is omitted from the State Change Report. 1464 Note: When the first State Change Report is sent, the non-existent 1465 pending report to merge with can be treated as a Source Change Report 1466 with empty ALLOW and BLOCK records (no sources have retransmission 1467 state). 1469 The building of a scheduled State Change Report, triggered by the 1470 firing of a Retransmission Timer, instead of a per-interface 1471 listening state change, is described in Section 6.3. 1473 6.2. Action on Reception of a Query 1475 Upon reception of an MLD message that contains a Query, the node 1476 checks if the source address of the message is a valid link-local 1477 address, if the Hop Limit is set to 1, and if the Router Alert option 1478 is present in the Hop-By-Hop Options header of the IPv6 packet. If 1479 any of these checks fails, the packet is dropped. 1481 If the validity of the MLD message is verified, the node starts to 1482 process the Query. Instead of responding immediately, the node 1483 delays its response by a random amount of time, bounded by the 1484 Maximum Response Delay value derived from the Maximum Response Code 1485 in the received Query message. A node may receive a variety of 1486 Queries on different interfaces and of different kinds (e.g., General 1487 Queries, Multicast Address Specific Queries, and Multicast Address 1488 and Source Specific Queries), each of which may require its own 1489 delayed response. 1491 Before scheduling a response to a Query, the node must first consider 1492 previously scheduled pending responses and, in many cases, schedule a 1493 combined response. Therefore, for each of its interfaces on which it 1494 operates the listener part of the MLDv2 protocol, the node must be 1495 able to maintain the following state: 1497 an Interface Timer for scheduling responses to General Queries; 1499 a Multicast Address Timer for scheduling responses to Multicast 1500 Address (and Source) Specific Queries, for each multicast address 1501 the node has to report on; 1503 a per-multicast-address list of sources to be reported in response 1504 to a Multicast Address and Source Specific Query. 1506 When a new valid General Query arrives on an interface, the node 1507 checks whether it has any per-interface listening state record to 1508 report on, or not. Similarly, when a new valid Multicast Address 1509 (and Source) Specific Query arrives on an interface, the node checks 1510 whether it has a per-interface listening state record that 1511 corresponds to the queried multicast address (and source), or not. 1512 If it does, a delay for a response is randomly selected in the range 1513 (0, [Maximum Response Delay]), where Maximum Response Delay is 1514 derived from the Maximum Response Code inserted in the received Query 1515 message. The following rules are then used to determine if a Report 1516 needs to be scheduled or not, and the type of Report to schedule. 1517 (The rules are considered in order and only the first matching rule 1518 is applied.) 1520 1. If there is a pending response to a previous General Query 1521 scheduled sooner than the selected delay, no additional response 1522 needs to be scheduled. 1524 2. If the received Query is a General Query, the Interface Timer is 1525 used to schedule a response to the General Query after the 1526 selected delay. Any previously pending response to a General 1527 Query is canceled. 1529 3. If the received Query is a Multicast Address Specific Query or a 1530 Multicast Address and Source Specific Query and there is no 1531 pending response to a previous Query for this multicast address, 1532 then the Multicast Address Timer is used to schedule a report. 1533 If the received Query is a Multicast Address and Source Specific 1534 Query, the list of queried sources is recorded to be used when 1535 generating a response. 1537 4. If there is already a pending response to a previous Query 1538 scheduled for this multicast address, and either the new Query is 1539 a Multicast Address Specific Query or the recorded source list 1540 associated with the multicast address is empty, then the 1541 multicast address source list is cleared and a single response is 1542 scheduled, using the Multicast Address Timer. The new response 1543 is scheduled to be sent at the earliest of the remaining time for 1544 the pending report and the selected delay. 1546 5. If the received Query is a Multicast Address and Source Specific 1547 Query and there is a pending response for this multicast address 1548 with a non-empty source list, then the multicast address source 1549 list is augmented to contain the list of sources in the new 1550 Query, and a single response is scheduled using the Multicast 1551 Address Timer. The new response is scheduled to be sent at the 1552 earliest of the remaining time for the pending report and the 1553 selected delay. 1555 6.3. Action on Timer Expiration 1557 There are several timers that, upon expiration, trigger protocol 1558 actions on an MLDv2 Multicast Address Listener node. All these 1559 actions are related to pending reports scheduled by the node. 1561 1. If the expired timer is the Interface Timer (i.e., there is a 1562 pending response to a General Query), then one Current State 1563 Record is sent for each multicast address for which the specified 1564 interface has listening state, as described in Section 4.2. The 1565 Current State Record carries the multicast address and its 1566 associated filter mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and 1567 Source list. Multiple Current State Records are packed into 1568 individual Report messages, to the extent possible. 1570 This naive algorithm may result in bursts of packets when a node 1571 listens to a large number of multicast addresses. Instead of 1572 using a single Interface Timer, implementations are recommended 1573 to spread transmission of such Report messages over the interval 1574 (0, [Maximum Response Delay]). Note that any such implementation 1575 MUST avoid the "ack-implosion" problem, i.e., MUST NOT send a 1576 Report immediately upon reception of a General Query. 1578 2. If the expired timer is a Multicast Address Timer and the list of 1579 recorded sources for that multicast address is empty (i.e., there 1580 is a pending response to a Multicast Address Specific Query), 1581 then if, and only if, the interface has listening state for that 1582 multicast address, a single Current State Record is sent for that 1583 address. The Current State Record carries the multicast address 1584 and its associated filter mode (MODE_IS_INCLUDE or 1585 MODE_IS_EXCLUDE) and source list, if any. 1587 3. If the expired timer is a Multicast Address Timer and the list of 1588 recorded sources for that multicast address is non-empty (i.e., 1589 there is a pending response to a Multicast Address and Source 1590 Specific Query), then if, and only if, the interface has 1591 listening state for that multicast address, the contents of the 1592 corresponding Current State Record are determined from the per- 1593 interface state and the pending response record, as specified in 1594 the following table: 1596 +----------------+--------------------------------+-----------------+ 1597 | per-interface | set of sources in the pending | Current State | 1598 | state | response record | Record | 1599 +----------------+--------------------------------+-----------------+ 1600 | INCLUDE (A) | B | IS_IN (A*B) | 1601 | EXCLUDE (A) | B | IS_IN (B-A) | 1602 +----------------+--------------------------------+-----------------+ 1604 If the resulting Current State Record has an empty set of source 1605 addresses, then no response is sent. After the required Report 1606 messages have been generated, the source lists associated with any 1607 reported multicast addresses are cleared. 1609 4. If the expired timer is a Retransmission Timer for a multicast 1610 address (i.e., there is a pending State Change Report for that 1611 multicast address), the contents of the report are determined as 1612 follows. If the report should contain a Filter Mode Change 1613 Record, i.e., the Filter Mode Retransmission Counter for that 1614 multicast address has a value higher than zero, then, if the 1615 current filter mode of the interface is INCLUDE, a TO_IN record 1616 is included in the report; otherwise a TO_EX record is included. 1617 In both cases, the Filter Mode Retransmission Counter for that 1618 multicast address is decremented by one unit after the 1619 transmission of the report. 1621 If instead the report should contain Source List Change Records, 1622 i.e., the Filter Mode Retransmission Counter for that multicast 1623 address is zero, an ALLOW and a BLOCK record is included. The 1624 contents of these records are built according to the table below: 1626 +--------+----------------------------------------------------------+ 1627 | Record | Sources included | 1628 +--------+----------------------------------------------------------+ 1629 | TO_IN | All in the current per-interface state that must be | 1630 | | forwarded | 1631 | TO_EX | All in the current per-interface state that must be | 1632 | | blocked | 1633 | ALLOW | All with retransmission state (i.e., all sources from | 1634 | | the Retransmission List) that must | 1635 | | be forwarded. For each included source, | 1636 | | its Source Retransmission Counter is decreased with one | 1637 | | unit after the transmission of the | 1638 | | report. If the counter reaches zero, the source is | 1639 | | deleted from the Retransmission List for that multicast | 1640 | | address. | 1641 | BLOCK | All with retransmission state (i.e., all sources from | 1642 | | the Retransmission List) that must | 1643 | | be blocked. For each included source, | 1644 | | its Source Retransmission Counter is decreased with one | 1645 | | unit after the transmission of the | 1646 | | report. If the counter reaches zero, the source is | 1647 | | deleted from the Retransmission List for that multicast | 1648 | | address. | 1649 +--------+----------------------------------------------------------+ 1651 If the computed source list for either an ALLOW or a BLOCK record is 1652 empty, that record is omitted from the State Change Report. 1654 7. Description of the Protocol for Multicast Routers 1656 The purpose of MLD is to enable each multicast router to learn, for 1657 each of its directly attached links, which multicast addresses have 1658 listeners on that link. MLD version 2 adds the capability for a 1659 multicast router to also learn which sources have listeners among the 1660 neighboring nodes, for packets sent to any particular multicast 1661 address. The information gathered by MLD is provided to whichever 1662 multicast routing protocol is used by the router, in order to ensure 1663 that multicast packets are delivered to all links where there are 1664 interested listeners. 1666 This section describes the part of MLDv2 that is performed by 1667 multicast routers. Multicast routers may themselves become multicast 1668 address listeners, and therefore also perform the multicast listener 1669 part of MLDv2, described in Section 6. 1671 A multicast router performs the protocol described in this section 1672 over each of its directly attached links. If a multicast router has 1673 more than one interface to the same link, it only needs to operate 1674 this protocol over one of those interfaces. 1676 For each interface over which the router operates the MLD protocol, 1677 the router must configure that interface to listen to all link-layer 1678 multicast addresses that can be generated by IPv6 multicasts. For 1679 example, an Ethernet-attached router must set its Ethernet address 1680 reception filter to accept all Ethernet multicast addresses that 1681 start with the hexadecimal value 3333 [RFC2464]; in the case of an 1682 Ethernet interface that does not support the filtering of such a 1683 multicast address range, it must be configured to accept ALL Ethernet 1684 multicast addresses, in order to meet the requirements of MLD. 1686 On each interface over which this protocol is being run, the router 1687 MUST enable reception of the link-scope "all MLDv2-capable routers" 1688 multicast address from all sources, and MUST perform the multicast 1689 address listener part of MLDv2 for that address on that interface. 1691 Multicast routers only need to know that at least one node on an 1692 attached link listens to packets for a particular multicast address 1693 from a particular source; a multicast router is not required to 1694 individually keep track of the interests of each neighboring node. 1695 (Nevertheless, see Appendix A.2 item 1 for discussion.) 1697 MLDv2 is backward compatible with the MLDv1 protocol. For a detailed 1698 description of compatibility issues see Section 8. 1700 7.1. Conditions for MLD Queries 1702 The behavior of a router that implements the MLDv2 protocol depends 1703 on whether there are several multicast routers on the same subnet, or 1704 not. If it is the case, a querier election mechanism (described in 1705 Section 7.6.2) is used to elect a single multicast router to be in 1706 Querier state. All the multicast routers on the subnet listen to the 1707 messages sent by multicast address listeners, and maintain the same 1708 multicast listening information state, so that they can quickly and 1709 correctly take over the querier functionality, should the present 1710 Querier fail. Nevertheless, it is only the Querier that sends 1711 periodical or triggered query messages on the subnet. 1713 The Querier periodically sends General Queries to request Multicast 1714 Address Listener information from an attached link. These queries 1715 are used to build and refresh the Multicast Address Listener state of 1716 routers on attached links. 1718 Nodes respond to these queries by reporting their Multicast Address 1719 Listening state (and set of sources they listen to) with Current 1720 State Multicast Address Records in MLDv2 Multicast Listener Reports. 1722 As a listener of a multicast address, a node may express interest in 1723 listening or not listening to traffic from particular sources. As 1724 the desired listening state of a node changes, it reports these 1725 changes using Filter Mode Change Records or Source List Change 1726 Records. These records indicate an explicit state change in a 1727 multicast address at a node in either the Multicast Address Record's 1728 source list or its filter mode. When Multicast Address Listening is 1729 terminated at a node or traffic from a particular source is no longer 1730 desired, the Querier must query for other listeners of the multicast 1731 address or of the source before deleting the multicast address (or 1732 source) from its Multicast Address Listener state and pruning its 1733 traffic. 1735 To enable all nodes on a link to respond to changes in multicast 1736 address listening, the Querier sends specific queries. A Multicast 1737 Address Specific Query is sent to verify that there are no nodes that 1738 listen to the specified multicast address or to "rebuild" the 1739 listening state for a particular multicast address. Multicast 1740 Address Specific Queries are sent when the Querier receives a State 1741 Change Record indicating that a node ceases to listen to a multicast 1742 address. They are also sent in order to enable a fast transition of 1743 a router from EXCLUDE to INCLUDE mode, in case a received State 1744 Change Record motivates this action. 1746 A Multicast Address and Source Specific Query is used to verify that 1747 there are no nodes on a link which listen to traffic from a specific 1748 set of sources. Multicast Address and Source Specific Queries list 1749 sources for a particular multicast address which have been requested 1750 to no longer be forwarded. This query is sent by the Querier in 1751 order to learn if any node listens to packets sent to the specified 1752 multicast address, from the specified source addresses. Multicast 1753 Address and Source Specific Queries are only sent in response to 1754 State Change Records and never in response to Current State Records. 1755 Section 5.1.13 describes each query in more detail. 1757 7.2. MLD State Maintained by Multicast Routers 1759 Multicast routers that implement the MLDv2 protocol keep state per 1760 multicast address per attached link. This multicast address state 1761 consists of a filter mode, a list of sources, and various timers. 1762 For each attached link on which MLD runs, a multicast router records 1763 the listening state for that link. That state conceptually consists 1764 of a set of records of the form: 1766 (IPv6 multicast address, Filter Timer, 1767 Router Filter Mode, (source records) ) 1769 Each source record is of the form: 1771 (IPv6 source address, source timer) 1773 If all sources for a multicast address are listened to, an empty 1774 source record list is kept with the Router Filter Mode set to 1775 EXCLUDE. This means that nodes on this link want all sources for 1776 this multicast address to be forwarded. This is the MLDv2 equivalent 1777 of an MLDv1 listening state. 1779 7.2.1. Definition of Router Filter Mode 1781 To reduce internal state, MLDv2 routers keep a filter mode per 1782 multicast address per attached link. This filter mode is used to 1783 summarize the total listening state of a multicast address to a 1784 minimum set such that all nodes' listening states are respected. The 1785 filter mode may change in response to the reception of particular 1786 types of Multicast Address Records or when certain timer conditions 1787 occur. In the following sections, we use the term "Router Filter 1788 Mode" to refer to the filter mode of a particular multicast address 1789 within a router. Section 7.4 describes the changes of the Router 1790 Filter Mode per Multicast Address Record received. 1792 A router is in INCLUDE mode for a specific multicast address on a 1793 given interface if all the listeners on the link interested in that 1794 address are in INCLUDE mode. The router state is represented through 1795 the notation INCLUDE (A), where A is called the "Include List". The 1796 Include List is the set of sources that one or more listeners on the 1797 link have requested to receive. All the sources from the Include 1798 List will be forwarded by the router. Any other source that is not 1799 in the Include List will be blocked by the router. 1801 A router is in EXCLUDE mode for a specific multicast address on a 1802 given interface if there is at least one listener in EXCLUDE mode 1803 interested in that address on the link. Conceptually, when a 1804 Multicast Address Record is received, the Router Filter Mode for that 1805 multicast address is updated to cover all the requested sources using 1806 the least amount of state. As a rule, once a Multicast Address 1807 Record with a filter mode of EXCLUDE is received, the Router Filter 1808 Mode for that multicast address will be set to EXCLUDE. 1809 Nevertheless, if all nodes with a multicast address record having 1810 filter mode set to EXCLUDE cease reporting, it is desirable for the 1811 Router Filter Mode for that multicast address to transition back to 1812 INCLUDE mode. This transition occurs when the Filter Timer expires, 1813 and is explained in detail in Section 7.5. 1815 When the router is in EXCLUDE mode, the router state is represented 1816 through the notation EXCLUDE (X,Y), where X is called the "Requested 1817 List" and Y is called the "Exclude List". All sources, except those 1818 from the Exclude List, will be forwarded by the router. The 1819 Requested List has no effect on forwarding. Nevertheless, it has to 1820 be maintained for several reasons, as explained in Section 7.2.3. 1822 The exact handling of both the INCLUDE and EXCLUDE mode router state, 1823 according to the received reports, is presented in details in Tables 1824 7.4.1 and 7.4.2. 1826 7.2.2. Definition of Filter Timers 1828 The Filter Timer is only used when the router is in EXCLUDE mode for 1829 a specific multicast address, and it represents the time for the 1830 Router Filter Mode of the multicast address to expire and switch to 1831 INCLUDE mode. A Filter Timer is a decrementing timer with a lower 1832 bound of zero. One Filter Timer exists per multicast address record. 1833 Filter Timers are updated according to the types of Multicast Address 1834 Records received. 1836 If a Filter Timer expires, with the Router Filter Mode for that 1837 multicast address being EXCLUDE, it means that there are no more 1838 listeners in EXCLUDE mode on the attached link. At this point, the 1839 router transitions to INCLUDE filter mode. Section 7.5 describes the 1840 actions taken when a Filter Timer expires while in EXCLUDE mode. 1842 The following table summarizes the role of the Filter Timer. 1843 Section 7.4 describes the details of setting the Filter Timer per 1844 type of Multicast Address Record received. 1846 +---------+--------+------------------------------------------------+ 1847 | Router | Filter | Actions/Comments | 1848 | Filter | Timer | | 1849 | Mode | Value | | 1850 +---------+--------+------------------------------------------------+ 1851 | INCLUDE | Not | All listeners in INCLUDE mode. | 1852 | | Used | | 1853 | EXCLUDE | Timer | At least one listener in EXCLUDE mode. | 1854 | | > 0 | | 1855 | EXCLUDE | Timer | No more listeners in EXCLUDE mode for | 1856 | | == 0 | the multicast address. If the Requested List | 1857 | | | is empty, delete Multicast | 1858 | | | Address Record. If not, switch to INCLUDE | 1859 | | | filter mode; the sources in | 1860 | | | the Requested List are moved to the Include | 1861 | | | List, and the Exclude List | 1862 | | | is deleted. | 1863 +---------+--------+------------------------------------------------+ 1865 7.2.3. Definition of Source Timers 1867 A Source Timer is a decrementing timer with a lower bound of zero. 1868 One Source Timer is kept per source record. Source timers are 1869 updated according to the type and filter mode of the Multicast 1870 Address Record received. Section 7.4 describes the setting of source 1871 timers per type of Multicast Address Records received. 1873 In the following, abbreviations are used for several variables (all 1874 of which are described in detail in Section 9). The variable MALI 1875 stands for the Multicast Address Listening Interval, which is the 1876 time in which multicast address listening state will time out. The 1877 variable LLQT is the Last Listener Query Time, which is the total 1878 time the router should wait for a report, after the Querier has sent 1879 the first query. During this time, the Querier should send [Last 1880 Member Query Count]-1 retransmissions of the query. LLQT represents 1881 the "leave latency", or the difference between the transmission of a 1882 listener state change and the modification of the information passed 1883 to the routing protocol. 1885 If the router is in INCLUDE filter mode, a source can be added to the 1886 current Include List if a listener in INCLUDE mode sends a Current 1887 State or a State Change Report which includes that source. Each 1888 source from the Include List is associated with a source timer that 1889 is updated whenever a listener in INCLUDE mode sends a report that 1890 confirms its interest in that specific source. If the timer of a 1891 source from the Include List expires, the source is deleted from the 1892 Include List. If there are no more source records left, the 1893 multicast address record is deleted from the router. 1895 Besides this "soft leave" mechanism, there is also a "fast leave" 1896 scheme in MLDv2; it is also based on the use of source timers. When 1897 a node in INCLUDE mode expresses its desire to stop listening to a 1898 specific source, all the multicast routers on the link lower their 1899 timer for that source to a small interval of LLQT milliseconds. The 1900 Querier then sends then a Multicast Address and Source Specific 1901 Query, to verify whether there are other listeners for that source on 1902 the link, or not. If a corresponding report is received before the 1903 timer expires, all the multicast routers on the link update their 1904 source timer. If not, the source is deleted from the Include List. 1905 The handling of the Include List, according to the received reports, 1906 is detailed in Tables 7.4.1 and 7.4.2. 1908 Source timers are treated differently when the Router Filter Mode for 1909 a multicast address is EXCLUDE. For sources from the Requested List 1910 the source timers have running values; these sources are forwarded by 1911 the router. For sources from the Exclude List the source timers are 1912 set to zero; these sources are blocked by the router. If the timer 1913 of a source from the Requested List expires, the source is moved to 1914 the Exclude List. The router informs then the routing protocol that 1915 there is no longer a listener on the link interested in traffic from 1916 this source. 1918 The router has to maintain the Requested List for two reasons: 1920 To keep track of sources that listeners in INCLUDE mode listen to. 1921 This is necessary in order to assure a seamless transition of the 1922 router to INCLUDE mode, when there will be no listener in EXCLUDE 1923 mode left. This transition should not interrupt the flow of 1924 traffic to the listeners in INCLUDE mode still interested in that 1925 multicast address. Therefore, at the moment of the transition, 1926 the Requested List should represent the set of sources that nodes 1927 in INCLUDE mode have explicitly requested. 1929 When the router switches to INCLUDE mode, the sources in the 1930 Requested List are moved to the Include List, and the Exclude List 1931 is deleted. Before the switch, the Requested List can contain an 1932 inexact guess at the sources that listeners in INCLUDE mode listen 1933 to - might be too large or too small. These inexactitudes are due 1934 to the fact that the Requested List is also used for fast blocking 1935 purposes, as described below. If such a fast blocking is 1936 required, some sources may be deleted from the Requested List (as 1937 shown in Tables 7.4.1 and 7.4.2) in order to reduce router state. 1938 Nevertheless, in each such case the Filter Timer is updated as 1939 well. Therefore, listeners in INCLUDE mode will have enough time, 1940 before an eventual switching, to reconfirm their interest in the 1941 eliminated source(s), and rebuild the Requested List accordingly. 1942 The protocol ensures that when a switch to INCLUDE mode occurs, 1943 the Requested List will be accurate. Details about the transition 1944 of the router to INCLUDE mode are presented in Appendix A.3. 1946 To allow a fast blocking of previously unblocked sources. If the 1947 router receives a report that contains such a request, the 1948 concerned sources are added to the Requested List. Their timers 1949 are set to a small interval of LLQT milliseconds, and a Multicast 1950 Address and Source Specific Query is sent by the Querier, to check 1951 whether there are nodes on the link still interested in those 1952 sources, or not. If no node confirms its interest in receiving a 1953 specific source, the timer of that source expires. Then, the 1954 source is moved from the Requested List to the Exclude List. From 1955 then on, the source will be blocked by the router. 1957 The handling of the EXCLUDE mode router state, according to the 1958 received reports, is detailed in Tables 7.4.1 and 7.4.2. 1960 When the Router Filter Mode for a multicast address is EXCLUDE, 1961 source records are only deleted when the Filter Timer expires, or 1962 when newly received Multicast Address Records modify the source 1963 record list of the router. 1965 7.3. MLDv2 Source Specific Forwarding Rules 1967 When a multicast router receives a datagram from a source destined to 1968 a particular multicast address, a decision has to be made whether to 1969 forward the datagram on an attached link or not. The multicast 1970 routing protocol in use is in charge of this decision, and should use 1971 the MLDv2 information to ensure that all sources/multicast addresses 1972 that have listeners on a link are forwarded to that link. MLDv2 1973 information does not override multicast routing information; for 1974 example, if the MLDv2 filter mode for a multicast address is EXCLUDE, 1975 a router may still forward packets for excluded sources to a transit 1976 link. 1978 To summarize, the following table describes the forwarding 1979 suggestions made by MLDv2 to the routing protocol for traffic 1980 originating from a source destined to a multicast address. It also 1981 summarizes the actions taken upon the expiration of a source timer 1982 based on the Router Filter Mode of the multicast address. 1984 +---------+---------+-----------------------------------------------+ 1985 | Router | Source | Action | 1986 | Filter | Timer | | 1987 | Mode | Value | | 1988 +---------+---------+-----------------------------------------------+ 1989 | INCLUDE | TIMER > | Suggest to forward traffic from source | 1990 | | 0 | | 1991 | INCLUDE | TIMER | Suggest to stop forwarding traffic from | 1992 | | == 0 | source and remove source record. If there | 1993 | | | are no more source records, | 1994 | | | delete multicast address record | 1995 | EXCLUDE | TIMER > | Suggest to forward traffic from source | 1996 | | 0 | | 1997 | EXCLUDE | TIMER | Suggest to not forward traffic from source. | 1998 | | == 0 | Move the source from the Requested List to | 1999 | | | the Exclude List (DO NOT remove source | 2000 | | | record) | 2001 | EXCLUDE | No | Suggest to forward traffic from all sources | 2002 | | Source | | 2003 | | Element | | 2004 +---------+---------+-----------------------------------------------+ 2006 7.4. Action on Reception of Reports 2008 Upon reception of an MLD message that contains a Report, the router 2009 checks if the source address of the message is a valid link-local 2010 address, if the Hop Limit is set to 1, and if the Router Alert option 2011 is present in the Hop-By-Hop Options header of the IPv6 packet. If 2012 any of these checks fails, the packet is dropped. If the validity of 2013 the MLD message is verified, the router starts to process the Report. 2015 7.4.1. Reception of Current State Records 2017 When receiving Current State Records, a router updates both its 2018 Filter Timer and its source timers. In some circumstances, the 2019 reception of a type of multicast address record will cause the Router 2020 Filter Mode for that multicast address to change. The table below 2021 describes the actions, with respect to state and timers, that occur 2022 to a router's state upon reception of Current State Records. 2024 If the router is in INCLUDE filter mode for a multicast address, we 2025 will use the notation INCLUDE (A), where A denotes the associated 2026 Include List. If the router is in EXCLUDE filter mode for a 2027 multicast address, we will use the notation EXCLUDE (X,Y), where X 2028 and Y denote the associated Requested List and Exclude List 2029 respectively. 2031 Within the "Actions" section of the router state tables, we use the 2032 notation '(A)=J', which means that the set A of source records should 2033 have their source timers set to value J. 'Delete (A)' means that the 2034 set A of source records should be deleted. 'Filter Timer = J' means 2035 that the Filter Timer for the multicast address should be set to 2036 value J. 2038 Router State Report Received New Router State Actions 2039 ------------ --------------- ---------------- ------- 2041 INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B)=MALI 2043 INCLUDE (A) IS_EX (B) EXCLUDE (A*B, B-A) (B-A)=0 2044 Delete (A-B) 2045 Filter Timer=MALI 2047 EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+A, Y-A) (A)=MALI 2049 EXCLUDE (X,Y) IS_EX (A) EXCLUDE (A-Y, Y*A) (A-X-Y)=MALI 2050 Delete (X-A) 2051 Delete (Y-A) 2052 Filter Timer=MALI 2054 7.4.2. Reception of Filter Mode Change and Source List Change Records 2056 When a change in the global state of a multicast address occurs in a 2057 node, the node sends either a Source List Change Record or a Filter 2058 Mode Change Record for that multicast address. As with Current State 2059 Records, routers must act upon these records and possibly change 2060 their own state to reflect the new listening state of the link. 2062 The Querier must query sources or multicast addresses that are 2063 requested to be no longer forwarded. When a router queries or 2064 receives a query for a specific set of sources, it lowers its source 2065 timers for those sources to a small interval of Last Listener Query 2066 Time milliseconds. If multicast address records are received in 2067 response to the queries which express interest in listening the 2068 queried sources, the corresponding timers are updated. 2070 Multicast Address Specific queries can also be used in order to 2071 enable a fast transition of a router from EXCLUDE to INCLUDE mode, in 2072 case a received Multicast Address Record motivates this action. The 2073 Filter Timer for that multicast address is lowered to a small 2074 interval of Last Listener Query Time milliseconds. If any multicast 2075 address records that express EXCLUDE mode interest in the multicast 2076 address are received within this interval, the Filter Timer is 2077 updated and the suggestion to the routing protocol to forward the 2078 multicast address stands without any interruption. If not, the 2079 router will switch to INCLUDE filter mode for that multicast address. 2081 During the query period (i.e., Last Listener Query Time milliseconds) 2082 the MLD component in the router continues to suggest to the routing 2083 protocol to forward traffic from the multicast addresses or sources 2084 that are queried. It is not until after Last Listener Query Time 2085 milliseconds without receiving a record that expresses interest in 2086 the queried multicast address or sources that the router may prune 2087 the multicast address or sources from the link. 2089 The following table describes the changes in multicast address state 2090 and the action(s) taken when receiving either Filter Mode Change or 2091 Source List Change Records. This table also describes the queries 2092 which are sent by the Querier when a particular report is received. 2094 We use the following notation for describing the queries that are 2095 sent. We use the notation 'Q(MA)' to describe a Multicast Address 2096 Specific Query to the MA multicast address. We use the notation 2097 'Q(MA,A)' to describe a Multicast Address and Source Specific Query 2098 to the MA multicast address with source list A. If source list A is 2099 null as a result of the action (e.g. A*B), then no query is sent as 2100 a result of the operation. 2102 In order to maintain protocol robustness, queries defined in the 2103 Actions column of the table below need to be transmitted [Last 2104 Listener Query Count] times, once every [Last Listener Query 2105 Interval] period. 2107 If while scheduling new queries, there are already pending queries to 2108 be retransmitted for the same multicast address, the new and pending 2109 queries have to be merged. In addition, received host reports for a 2110 multicast address with pending queries may affect the contents of 2111 those queries. Section 7.6.3 describes the process of building and 2112 maintaining the state of pending queries. 2114 Router State Report Received New Router State Actions 2115 ------------ --------------- ---------------- ------- 2116 INCLUDE (A) ALLOW (B) INCLUDE(A+B) (B)=MALI 2118 INCLUDE (A) BLOCK (B) INCLUDE(A) Send Q(MA,A*B) 2120 INCLUDE (A) TO_EX (B) EXCLUDE(A*B,B-A) (B-A)=0 2121 Delete (A-B) 2122 Send Q(MA,A*B) 2123 Filter Timer=MALI 2125 INCLUDE (A) TO_IN (B) INCLUDE(A+B) (B)=MALI 2126 Send Q(MA,A-B) 2128 EXCLUDE (X,Y) ALLOW (A) EXCLUDE(X+A,Y-A) (A)=MALI 2130 EXCLUDE (X,Y) BLOCK (A) EXCLUDE(X+(A-Y),Y) (A-X-Y)=Filter Timer 2131 Send Q(MA,A-Y) 2133 EXCLUDE (X,Y) TO_EX (A) EXCLUDE(A-Y,Y*A) (A-X-Y)=Filter Timer 2134 Delete (X-A) 2135 Delete (Y-A) 2136 Send Q(MA,A-Y) 2137 Filter Timer=MALI 2139 EXCLUDE (X,Y) TO_IN (A) EXCLUDE(X+A,Y-A) (A)=MALI 2140 Send Q(MA,X-A) 2141 Send Q(MA) 2143 7.5. Switching Router Filter Modes 2145 The Filter Timer is used as a mechanism for transitioning the Router 2146 Filter Mode from EXCLUDE to INCLUDE. 2148 When a Filter Timer expires with a Router Filter Mode of EXCLUDE, a 2149 router assumes that there are no nodes with a filter mode of EXCLUDE 2150 present on the attached link. Thus, the router transitions to 2151 INCLUDE filter mode for the multicast address. 2153 A router uses the sources from the Requested List as its state for 2154 the switch to a filter mode of INCLUDE. Sources from the Requested 2155 List are moved in the Include List, while sources from the Exclude 2156 List are deleted. For example, if a router's state for a multicast 2157 address is EXCLUDE(X,Y) and the Filter Timer expires for that 2158 multicast address, the router switches to filter mode of INCLUDE with 2159 state INCLUDE(X). If at the moment of the switch the Requested List 2160 (X) is empty, the multicast address record is deleted from the 2161 router. 2163 7.6. Action on Reception of Queries 2165 Upon reception of an MLD message that contains a Query, the router 2166 checks if the source address of the message is a valid link-local 2167 address, if the Hop Limit is set to 1, and if the Router Alert option 2168 is present in the Hop-By-Hop Options header of the IPv6 packet. If 2169 any of these checks fails, the packet is dropped. 2171 If the validity of the MLD message is verified, the router starts to 2172 process the Query. 2174 7.6.1. Timer Updates 2176 MLDv2 uses the Suppress Router-Side Processing flag to ensure 2177 robustness, as explained in Section 2.1. When a router sends or 2178 receives a query with a clear Suppress Router-Side Processing flag, 2179 it must update its timers to reflect the correct timeout values for 2180 the multicast address or sources being queried. The following table 2181 describes the timer actions when sending or receiving a Multicast 2182 Address Specific or Multicast Address and Source Specific Query with 2183 the Suppress Router-Side Processing flag not set. 2185 Query Action 2186 ----- ------ 2187 Q(MA,A) Source Timers for sources in A are lowered to LLQT 2188 Q(MA) Filter Timer is lowered to LLQT 2190 When a router sends or receives a query with the Suppress Router-Side 2191 Processing flag set, it will not update its timers. 2193 7.6.2. Querier Election 2195 MLDv2 elects a single router per subnet to be in Querier state; all 2196 the other routers on the subnet should be in Non-Querier state. 2197 MLDv2 uses the same querier election mechanism as MLDv1, namely the 2198 IPv6 address. When a router starts operating on a subnet, by default 2199 it considers itself as being the Querier. Thus, it sends several 2200 General Queries separated by a small time interval (see Section 9.6 2201 and Section 9.7 for details). 2203 When a router receives a query with a lower IPv6 address than its 2204 own, it sets the Other Querier Present timer to Other Querier Present 2205 Timeout; if it was previously in Querier state, it switches to Non- 2206 Querier state and ceases to send queries on the link. After the 2207 Other Querier Present timer expires, it should re-enter the Querier 2208 state and begin sending General Queries. 2210 All MLDv2 queries MUST be sent with the FE80::/64 link-local source 2211 address prefix. Therefore, for the purpose of MLDv2 querier 2212 election, an IPv6 address A is considered to be lower than an IPv6 2213 address B if the interface ID represented by the last 64 bits of 2214 address A, in big-endian bit order, is lower than the interface ID 2215 represented by the last 64 bits of address B. 2217 7.6.3. Building and Sending Specific Queries 2219 7.6.3.1. Building and Sending Multicast Address Specific Queries 2221 When a table action "Send Q(MA)" is encountered, the Filter Timer 2222 must be lowered to LLQT. The Querier must then immediately send a 2223 Multicast Address Specific query as well as schedule [Last Listener 2224 Query Count - 1] query retransmissions to be sent every [Last 2225 Listener Query Interval], over [Last Listener Query Time]. 2227 When transmitting a Multicast Address Specific Query, if the Filter 2228 Timer is larger than LLQT, the "Suppress Router-Side Processing" bit 2229 is set in the query message. 2231 7.6.3.2. Building and Sending Multicast Address and Source Specific 2232 Queries 2234 When a table action "Send Q(MA,X)" is encountered by the Querier in 2235 the table in Section 7.4.2, the following actions must be performed 2236 for each of the sources in X that send to multicast address MA, with 2237 source timer larger than LLQT: 2239 Lower source timer to LLQT; 2241 Add the sources to the Retransmission List; 2243 Set the Source Retransmission Counter for each source to [Last 2244 Listener Query Count]. 2246 The Querier must then immediately send a Multicast Address and Source 2247 Specific Query as well as schedule [Last Listener Query Count -1] 2248 query retransmissions to be sent every [Last Listener Query 2249 Interval], over [Last Listener Query Time]. The contents of these 2250 queries are calculated as follows. 2252 When building a Multicast Address and Source Specific Query for a 2253 multicast address MA, two separate query messages are sent for the 2254 multicast address. The first one has the "Suppress Router-Side 2255 Processing" bit set and contains all the sources with retransmission 2256 state (i.e., sources from the Retransmission List of that multicast 2257 address), and timers greater than LLQT. The second has the "Suppress 2258 Router-Side Processing" bit clear and contains all the sources with 2259 retransmission state and timers lower or equal to LLQT. If either of 2260 the two calculated messages does not contain any sources, then its 2261 transmission is suppressed. 2263 Note: If a Multicast Address Specific query is scheduled to be 2264 transmitted at the same time as a Multicast Address and Source 2265 specific query for the same multicast address, then transmission of 2266 the Multicast Address and Source Specific message with the "Suppress 2267 Router-Side Processing" bit set may be suppressed. 2269 8. Interoperation with MLDv1 2271 MLD version 2 hosts and routers interoperate with hosts and routers 2272 that have not yet been upgraded to MLDv2. This compatibility is 2273 maintained by hosts and routers taking appropriate actions depending 2274 on the versions of MLD operating on hosts and routers within a 2275 network. 2277 8.1. Query Version Distinctions 2279 The MLD version of a Multicast Listener Query message is determined 2280 as follows: 2282 MLDv1 Query: length = 24 octets 2284 MLDv2 Query: length >= 28 octets 2286 Query messages that do not match any of the above conditions (e.g., a 2287 Query of length 26 octets) MUST be silently ignored. 2289 8.2. Multicast Address Listener Behavior 2290 8.2.1. In the Presence of MLDv1 Routers 2292 In order to be compatible with MLDv1 routers, MLDv2 hosts MUST 2293 operate in version 1 compatibility mode. MLDv2 hosts MUST keep state 2294 per local interface regarding the compatibility mode of each attached 2295 link. A host's compatibility mode is determined from the Host 2296 Compatibility Mode variable which can be in one of the two states: 2297 MLDv1 or MLDv2. 2299 The Host Compatibility Mode of an interface is set to MLDv1 whenever 2300 an MLDv1 Multicast Address Listener Query is received on that 2301 interface. At the same time, the Older Version Querier Present timer 2302 for the interface is set to Older Version Querier Present Timeout 2303 seconds. The timer is re-set whenever a new MLDv1 Query is received 2304 on that interface. If the Older Version Querier Present timer 2305 expires, the host switches back to Host Compatibility Mode of MLDv2. 2307 When Host Compatibility Mode is MLDv2, a host acts using the MLDv2 2308 protocol on that interface. When Host Compatibility Mode is MLDv1, a 2309 host acts in MLDv1 compatibility mode, using only the MLDv1 protocol, 2310 on that interface. 2312 An MLDv1 Querier will send General Queries with the Maximum Response 2313 Code set to the desired Maximum Response Delay, i.e., the full range 2314 of this field is linear and the exponential algorithm described in 2315 Section 5.1.3. is not used. 2317 Whenever a host changes its compatibility mode, it cancels all its 2318 pending responses and retransmission timers. 2320 8.2.2. In the Presence of MLDv1 Multicast Address Listeners 2322 An MLDv2 host may be placed on a link where there are MLDv1 hosts. A 2323 host MAY allow its MLDv2 Multicast Listener Report to be suppressed 2324 by a Version 1 Multicast Listener Report. 2326 8.3. Multicast Router Behavior 2328 8.3.1. In the Presence of MLDv1 Routers 2330 MLDv2 routers may be placed on a network where there is at least one 2331 MLDv1 router. The following requirements apply: 2333 If an MLDv1 router is present on the link, the Querier MUST use 2334 the lowest version of MLD present on the network. This must be 2335 administratively assured. Routers that desire to be compatible 2336 with MLDv1 MUST have a configuration option to act in MLDv1 mode; 2337 if an MLDv1 router is present on the link, the system 2338 administrator must explicitly configure all MLDv2 routers to act 2339 in MLDv1 mode. When in MLDv1 mode, the Querier MUST send periodic 2340 General Queries truncated at the Multicast Address field (i.e., 24 2341 bytes long), and SHOULD also warn about receiving an MLDv2 Query 2342 (such warnings must be rate-limited). The Querier MUST also fill 2343 in the Maximum Response Delay in the Maximum Response Code field, 2344 i.e., the exponential algorithm described in Section 5.1.3. is not 2345 used. 2347 If a router is not explicitly configured to use MLDv1 and receives 2348 an MLDv1 General Query, it SHOULD log a warning. These warnings 2349 MUST be rate-limited. 2351 8.3.2. In the Presence of MLDv1 Multicast Address Listeners 2353 MLDv2 routers may be placed on a network where there are hosts that 2354 have not yet been upgraded to MLDv2. In order to be compatible with 2355 MLDv1 hosts, MLDv2 routers MUST operate in version 1 compatibility 2356 mode. MLDv2 routers keep a compatibility mode per multicast address 2357 record. The compatibility mode of a multicast address is determined 2358 from the Multicast Address Compatibility Mode variable, which can be 2359 in one of the two following states: MLDv1 or MLDv2. 2361 The Multicast Address Compatibility Mode of a multicast address 2362 record is set to MLDv1 whenever an MLDv1 Multicast Listener Report is 2363 received for that multicast address. At the same time, the Older 2364 Version Host Present timer for the multicast address is set to Older 2365 Version Host Present Timeout seconds. The timer is re-set whenever a 2366 new MLDv1 Report is received for that multicast address. If the 2367 Older Version Host Present timer expires, the router switches back to 2368 Multicast Address Compatibility Mode of MLDv2 for that multicast 2369 address. 2371 Note that when a router switches back to MLDv2 Multicast Address 2372 Compatibility Mode for a multicast address, it takes some time to 2373 regain source-specific state information. Source-specific 2374 information will be learned during the next General Query, but 2375 sources that should be blocked will not be blocked until [Multicast 2376 Address Listening Interval] after that. 2378 When Multicast Address Compatibility Mode is MLDv2, a router acts 2379 using the MLDv2 protocol for that multicast address. When Multicast 2380 Address Compatibility Mode is MLDv1, a router internally translates 2381 the following MLDv1 messages for that multicast address to their 2382 MLDv2 equivalents: 2384 +---------------+------------------+ 2385 | MLDv1 Message | MLDv2 Equivalent | 2386 +---------------+------------------+ 2387 | Report | IS_EX( {} ) | 2388 | Done | TO_IN( {} ) | 2389 +---------------+------------------+ 2391 MLDv2 BLOCK messages are ignored, as are source-lists in TO_EX() 2392 messages (i.e., any TO_EX() message is treated as TO_EX( {} )). On 2393 the other hand, the Querier continues to send MLDv2 queries, 2394 regardless of its Multicast Address Compatibility Mode. 2396 9. List of Timers, Counters, and their Default Values 2398 Most of these timers are configurable. If non-default settings are 2399 used, they MUST be consistent among all nodes on a single link. Note 2400 that parentheses are used to group expressions to make the algebra 2401 clear. 2403 9.1. Robustness Variable 2405 The Robustness Variable allows tuning for the expected packet loss on 2406 a link. If a link is expected to be lossy, the value of the 2407 Robustness Variable may be increased. MLD is robust to [Robustness 2408 Variable] - 1 packet losses. The value of the Robustness Variable 2409 MUST NOT be zero, and SHOULD NOT be one. Default value: 2. 2411 9.2. Query Interval 2413 The Query Interval variable denotes the interval between General 2414 Queries sent by the Querier. Default value: 125 seconds. 2416 By varying the [Query Interval], an administrator may tune the number 2417 of MLD messages on the link; larger values cause MLD Queries to be 2418 sent less often. 2420 9.3. Query Response Interval 2422 The Maximum Response Delay used to calculate the Maximum Response 2423 Code inserted into the periodic General Queries. Default value: 2424 10000 (10 seconds) 2426 By varying the [Query Response Interval], an administrator may tune 2427 the burstiness of MLD messages on the link; larger values make the 2428 traffic less bursty, as host responses are spread out over a larger 2429 interval. The number of seconds represented by the [Query Response 2430 Interval] must be less than the [Query Interval]. 2432 9.4. Multicast Address Listening Interval 2434 The Multicast Address Listening Interval (MALI) is the amount of time 2435 that must pass before a multicast router decides there are no more 2436 listeners of a multicast address or a particular source on a link. 2437 This value MUST be ([Robustness Variable] times [Query Interval]) 2438 plus [Query Response Interval]. 2440 9.5. Other Querier Present Timeout 2442 The Other Querier Present Timeout is the length of time that must 2443 pass before a multicast router decides that there is no longer 2444 another multicast router which should be the Querier. This value 2445 MUST be ([Robustness Variable] times ([Query Interval]) plus (one 2446 half of [Query Response Interval]). 2448 9.6. Startup Query Interval 2450 The Startup Query Interval is the interval between General Queries 2451 sent by a Querier on startup. Default value: 1/4 the [Query 2452 Interval]. 2454 9.7. Startup Query Count 2456 The Startup Query Count is the number of Queries sent out on startup, 2457 separated by the Startup Query Interval. Default value: [Robustness 2458 Variable]. 2460 9.8. Last Listener Query Interval 2462 The Last Listener Query Interval is the Maximum Response Delay used 2463 to calculate the Maximum Response Code inserted into Multicast 2464 Address Specific Queries sent in response to Version 1 Multicast 2465 Listener Done messages. It is also the Maximum Response Delay used 2466 to calculate the Maximum Response Code inserted into Multicast 2467 Address and Source Specific Query messages. Default value: 1000 (1 2468 second). 2470 Note that for values of LLQI greater than 32.768 seconds, a limited 2471 set of values can be represented, corresponding to sequential values 2472 of Maximum Response Code. When converting a configured time to a 2473 Maximum Response Code value, it is recommended to use the exact value 2474 if possible, or the next lower value if the requested value is not 2475 exactly representable. 2477 This value may be tuned to modify the "leave latency" of the link. A 2478 reduced value results in reduced time to detect the departure of the 2479 last listener for a multicast address or source. 2481 9.9. Last Listener Query Count 2483 The Last Listener Query Count is the number of Multicast Address 2484 Specific Queries sent before the router assumes there are no local 2485 listeners. The Last Listener Query Count is also the number of 2486 Multicast Address and Source Specific Queries sent before the router 2487 assumes there are no listeners for a particular source. Default 2488 value: [Robustness Variable]. 2490 9.10. Last Listener Query Time 2492 The Last Listener Query Time is the time value represented by the 2493 Last Listener Query Interval, multiplied by [Last Listener Query 2494 Count]. It is not a tunable value, but may be tuned by changing its 2495 components. 2497 9.11. Unsolicited Report Interval 2499 The Unsolicited Report Interval is the time between repetitions of a 2500 node's initial report of interest in a multicast address. Default 2501 value: 1 second. 2503 9.12. Older Version Querier Present Timeout 2505 The Older Version Querier Present Timeout is the time-out for 2506 transitioning a host back to MLDv2 Host Compatibility Mode. When an 2507 MLDv1 query is received, MLDv2 hosts set their Older Version Querier 2508 Present Timer to [Older Version Querier Present Timeout]. 2510 This value MUST be ([Robustness Variable] times (the [Query Interval] 2511 in the last Query received)) plus ([Query Response Interval]). 2513 9.13. Older Version Host Present Timeout 2515 The Older Version Host Present Timeout is the time-out for 2516 transitioning a router back to MLDv2 Multicast Address Compatibility 2517 Mode for a specific multicast address. When an MLDv1 report is 2518 received for that multicast address, routers set their Older Version 2519 Host Present Timer to [Older Version Host Present Timeout]. 2521 This value MUST be ([Robustness Variable] times [Query Interval]) 2522 plus ([Query Response Interval]). 2524 9.14. Configuring timers 2526 This section is meant to provide advice to network administrators on 2527 how to tune these settings to their network. Ambitious router 2528 implementations might tune these settings dynamically based upon 2529 changing characteristics of the network. 2531 9.14.1. Robustness Variable 2533 The Robustness Variable tunes MLD to expected losses on a link. 2534 MLDv2 is robust to [Robustness Variable] - 1 packet losses, e.g., if 2535 the Robustness Variable is set to the default value of 2, MLDv2 is 2536 robust to a single packet loss but may operate imperfectly if more 2537 losses occur. On lossy links, the value of the Robustness Variable 2538 should be increased to allow for the expected level of packet loss. 2539 However, increasing the value of the Robustness Variable increases 2540 the leave latency of the link (the time between when the last 2541 listener stops listening to a source or multicast address and when 2542 the traffic stops flowing). 2544 9.14.2. Query Interval 2546 The overall level of periodic MLD traffic is inversely proportional 2547 to the Query Interval. A longer Query Interval results in a lower 2548 overall level of MLD traffic. The value of the Query Interval MUST 2549 be equal to or greater than the Maximum Response Delay used to 2550 calculate the Maximum Response Code inserted in General Query 2551 messages. 2553 9.14.3. Maximum Response Delay 2555 The burstiness of MLD traffic is inversely proportional to the 2556 Maximum Response Delay. A longer Maximum Response Delay will spread 2557 Report messages over a longer interval. However, a longer Maximum 2558 Response Delay in Multicast Address Specific and Multicast Address 2559 And Source Specific Queries extends the leave latency (the time 2560 between when the last listener stops listening to a source or 2561 multicast address and when the traffic stops flowing.) The expected 2562 rate of Report messages can be calculated by dividing the expected 2563 number of Reporters by the Maximum Response Delay. The Maximum 2564 Response Delay may be dynamically calculated per Query by using the 2565 expected number of Reporters for that Query as follows: 2567 General Query All nodes on link 2569 Multicast Address Specific Query All nodes on the link that had 2570 expressed interest in the 2571 multicast address 2573 Multicast Address and Source All nodes on the link that had 2574 Specific Query expressed interest in the source 2575 and multicast address 2577 A router is not required to calculate these populations or tune the 2578 Maximum Response Delay dynamically; these are simply guidelines. 2580 10. Security Considerations 2582 We consider the ramifications of a forged message of each type. Note 2583 that before processing an MLD message, nodes verify if the source 2584 address of the message is a valid link-local address (or the 2585 unspecified address), if the Hop Limit is set to 1, and if the Router 2586 Alert option is present in the Hop-By-Hop Options header of the IPv6 2587 packet. If any of these checks fails, the packet is dropped. This 2588 defends the MLDv2 nodes from acting on forged MLD messages originated 2589 off-link. Therefore, in the following we discuss only the effects of 2590 on-link forgery. 2592 10.1. Query Message 2594 A forged Query message from a machine with a lower IPv6 address than 2595 the current Querier will cause Querier duties to be assigned to the 2596 forger. If the forger then sends no more Query messages, other 2597 routers' Other Querier Present timer will time out and one will 2598 resume the role of Querier. During this time, if the forger ignores 2599 Multicast Listener Done Messages, traffic might flow to multicast 2600 addresses with no listeners for up to [Multicast Address Listener 2601 Interval]. 2603 A forged Version 1 Query message will put MLDv2 listeners on that 2604 link in MLDv1 Host Compatibility Mode. This scenario can be avoided 2605 by providing MLDv2 hosts with a configuration option to ignore 2606 Version 1 messages completely. 2608 A DoS attack on a node could be staged through forged Multicast 2609 Address and Source Specific Queries. The attacker can find out about 2610 the listening state of a specific node with a general query. After 2611 that it could send a large number of Multicast Address and Source 2612 Specific Queries, each with a large source list and/or long Maximum 2613 Response Delay. The node will have to store and maintain the sources 2614 specified in all of those queries for as long as it takes to send the 2615 delayed response. This would consume both memory and CPU cycles in 2616 order to augment the recorded sources with the source lists included 2617 in the successive queries. 2619 To protect against such a DoS attack, a node stack implementation 2620 could restrict the number of Multicast Address and Source Specific 2621 Queries per multicast address within this interval, and/or record 2622 only a limited number of sources. 2624 10.2. Current State Report messages 2626 A forged Report message may cause multicast routers to think there 2627 are listeners of a multicast address on a link when there are not. 2628 Nevertheless, since listening to a multicast address on a host is 2629 generally an unprivileged operation, a local user may trivially gain 2630 the same result without forging any messages. 2632 A forged Version 1 Report Message may put a router into MLDv1 2633 Multicast Address Compatibility Mode for a particular multicast 2634 address, meaning that the router will ignore MLDv2 source specific 2635 state messages. This can cause traffic to flow from unwanted sources 2636 for up to [Multicast Address Listener Interval]. This can be solved 2637 by providing routers with a configuration switch to ignore Version 1 2638 messages completely. This breaks automatic compatibility with 2639 Version 1 hosts, so it should only be used in situations where source 2640 filtering is critical. 2642 10.3. State Change Report messages 2644 A forged State Change Report message will cause the Querier to send 2645 out Multicast Address Specific or Multicast Address and Source 2646 Specific Queries for the multicast address in question. This causes 2647 extra processing on each router and on each listener of the multicast 2648 address, but cannot cause loss of desired traffic. 2650 11. IANA Considerations 2652 IANA has assigned the IPv6 link-local multicast address 2653 FF02:0:0:0:0:0:0:16, called "all MLDv2-capable routers", as described 2654 in Section 5.2.14. Version 2 Multicast Listener Reports will be sent 2655 to this special address. 2657 In addition, IANA has assigned the ICMPv6 message type value of 143 2658 for Version 2 Multicast Listener Report messages, as specified in 2659 Section 4. 2661 12. Contributors 2663 Roland Vida, Luis Henrique Maciel Kosmalski Costa, Serge Fdida, Steve 2664 Deering, Bill Fenner, and Isidor Kouvelas are the authors of RFC 2665 3810, which makes up the majority of the content in this document. 2667 13. Acknowledgments 2669 We would like to thank Hitoshi Asaeda, Randy Bush, Francis Dupont, 2670 Ted Hardie, Russ Housley, Konstantin Kabassanov, Erik Nordmark, 2671 Shinsuke Suzuki, Margaret Wasserman, Bert Wijnen, and Remi Zara for 2672 their valuable comments and suggestions on this document. 2674 14. References 2676 14.1. Normative References 2678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2679 Requirement Levels", BCP 14, RFC 2119, 2680 DOI 10.17487/RFC2119, March 1997, 2681 . 2683 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2684 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2685 December 1998, . 2687 [RFC2463] Conta, A. and S. Deering, "Internet Control Message 2688 Protocol (ICMPv6) for the Internet Protocol Version 6 2689 (IPv6) Specification", RFC 2463, DOI 10.17487/RFC2463, 2690 December 1998, . 2692 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 2693 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 2694 . 2696 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 2697 Listener Discovery (MLD) for IPv6", RFC 2710, 2698 DOI 10.17487/RFC2710, October 1999, 2699 . 2701 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 2702 RFC 2711, DOI 10.17487/RFC2711, October 1999, 2703 . 2705 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 2706 (IPv6) Addressing Architecture", RFC 3513, 2707 DOI 10.17487/RFC3513, April 2003, 2708 . 2710 14.2. Informative References 2712 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 2713 Discovery for IP Version 6 (IPv6)", RFC 2461, 2714 DOI 10.17487/RFC2461, December 1998, 2715 . 2717 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 2718 Autoconfiguration", RFC 2462, DOI 10.17487/RFC2462, 2719 December 1998, . 2721 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2722 Thyagarajan, "Internet Group Management Protocol, Version 2723 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 2724 . 2726 [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific 2727 Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 2728 2003, . 2730 [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface 2731 Extensions for Multicast Source Filters", RFC 3678, 2732 DOI 10.17487/RFC3678, January 2004, 2733 . 2735 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 2736 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 2737 DOI 10.17487/RFC3810, June 2004, 2738 . 2740 Appendix A. Design Rationale 2742 A.1. The Need for State Change Messages 2744 MLDv2 specifies two types of Multicast Listener Reports: Current 2745 State and State Change. This section describes the rationale for the 2746 need for both these types of Reports. 2748 Routers need to distinguish Multicast Listener Reports that were sent 2749 in response to Queries from those that were sent as a result of a 2750 change in the per-interface state. Multicast Listener Reports that 2751 are sent in response to Multicast Address Listener Queries are used 2752 mainly to refresh the existing state at the router; they typically do 2753 not cause transitions in state at the router. Multicast Listener 2754 Reports that are sent in response to changes in the per-interface 2755 state require the router to take some action in response to the 2756 received report (see Section 7.4). 2758 The inability to distinguish between the two types of reports would 2759 force a router to treat all Multicast Listener Reports as potential 2760 changes in state and could result in increased processing at the 2761 router as well as an increase in MLD traffic on the link. 2763 A.2. Host Suppression 2765 In MLDv1, a host would not send a pending multicast listener report 2766 if a similar report was sent by another listener on the link. In 2767 MLDv2, the suppression of multicast listener reports has been 2768 removed. The following points explain this decision. 2770 1. Routers may want to track per-host multicast listener status on 2771 an interface. This would allow routers to implement fast leaves 2772 (e.g., for layered multicast congestion control schemes), as well 2773 as track listener status for possible security or accounting 2774 purposes. The present specification does not require routers to 2775 implement per-host tracking. Nevertheless, the lack of host 2776 suppression in MLDv2 makes possible to implement either 2777 proprietary or future standard behavior of multicast routers that 2778 would support per-host tracking, while being fully interoperable 2779 with MLDv2 listeners and routers that implement the exact 2780 behavior described in this specification. 2782 2. Multicast Listener Report suppression does not work well on 2783 bridged LANs. Many bridges and Layer2/Layer3 switches that 2784 implement MLD snooping do not forward MLD messages across LAN 2785 segments in order to prevent multicast listener report 2786 suppression. 2788 3. By eliminating multicast listener report suppression, hosts have 2789 fewer messages to process; this leads to a simpler state machine 2790 implementation. 2792 4. In MLDv2, a single multicast listener report now bundles multiple 2793 multicast address records to decrease the number of packets sent. 2794 In comparison, the previous version of MLD required that each 2795 multicast address be reported in a separate message. 2797 A.3. Switching router filter modes from EXCLUDE to INCLUDE 2799 If on a link there are nodes in both EXCLUDE and INCLUDE modes for a 2800 single multicast address, the router must be in EXCLUDE mode as well 2801 (see section 7.2.1). In EXCLUDE mode, a router forwards traffic from 2802 all sources except those in the Exclude List. If all nodes in 2803 EXCLUDE mode cease to exist or to listen, it would be desirable for 2804 the router to switch back to INCLUDE mode seamlessly, without 2805 interrupting the flow of traffic to existing listeners. 2807 One of the ways to accomplish this is for routers to keep track of 2808 all sources that nodes that are in INCLUDE mode listen to, even 2809 though the router itself is in EXCLUDE mode. If the Filter Timer for 2810 a multicast address expires, it implies that there are no nodes in 2811 EXCLUDE mode on the link (otherwise a multicast listener report from 2812 that node would have refreshed the Filter Timer). The router can 2813 then switch to INCLUDE mode seamlessly; sources from the Requested 2814 List are moved to the Include List, while sources from the Exclude 2815 List are deleted. 2817 Appendix B. Summary of Changes 2819 B.1. MLDv1 2821 The following is a summary of changes from MLDv1, specified in 2822 [RFC2710]. 2824 MLDv2 introduces source filtering. 2826 The IP service interface of MLDv2 nodes is modified accordingly. 2827 It enables the specification of a filter mode and a source list. 2829 An MLDv2 node keeps per-socket and per-interface multicast 2830 listening states that include a filter mode and a source list for 2831 each multicast address. This enables packet filtering based on a 2832 socket's multicast reception state. 2834 MLDv2 state kept on routers includes a filter mode and a list of 2835 sources and source timers for each multicast address that has 2836 listeners on the link. MLDv1 routers kept only the list of 2837 multicast addresses. 2839 Queries include additional fields (Section 5.1). 2841 The S flag (Suppress Router-Side Processing) is included in 2842 queries in order to fix robustness issues. 2844 The Querier's Robustness Variable and Query Interval Code are 2845 included in Queries in order to synchronize all MLDv2 routers 2846 connected to the same link. 2848 A new Query type (Multicast Address and Source Specific Query) is 2849 introduced. 2851 The Maximum Response Delay is not directly included in the Query 2852 anymore. Instead, an exponential algorithm is used to calculate 2853 its value, based on the Maximum Response Code included in the 2854 Query. The maximum value is increased from 65535 milliseconds to 2855 about 140 minutes. 2857 Reports include Multicast Address Records. Information on the 2858 listening state for several different multicast addresses can be 2859 included in the same Report message. 2861 Reports are sent to the "all MLDv2-capable multicast routers" 2862 address, instead of the multicast address the host listens to, as 2863 in MLDv1. This facilitates the operation of layer-2 snooping 2864 switches. 2866 There is no "host suppression", as in MLDv1. All nodes send 2867 Report messages. 2869 Unsolicited Reports, announcing changes in receiver listening 2870 state, are sent [Robustness Variable] times. RFC 2710 is less 2871 explicit. 2873 There are no Done messages. 2875 Interoperability with MLDv1 systems is achieved by MLDv2 state 2876 operations. 2878 In order to ensure interoperability, hosts maintain a Host 2879 Compatibility Mode variable and an Older Version Querier Present 2880 timer per interface. Routers maintain a Multicast Address 2881 Compatibility Mode variable and an Older Version Host Present 2882 timer per multicast address. 2884 B.2. MLDv2 2886 The following summarizes the changes made since RFC 3810. 2888 Added definition of Resv to address Erratum 4773. 2890 Added clarifying text on which multicast addresses require the 2891 sending of MLD messages to address Erratum 5977. 2893 Author's Address 2895 Brian Haberman (editor) 2896 Johns Hopkins University Applied Physics Lab 2898 Email: brian@innovationslab.net