idnits 2.17.1 draft-ietf-ipngwg-mld-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 776 has weird spacing: '...c Query the ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1999) is 9083 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) ** Obsolete normative reference: RFC 2373 (ref. 'ADDR-ARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2463 (ref. 'ICMPv6') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'RTR-ALERT' Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force S. Deering, Cisco Systems 2 IPng Working Group W. Fenner, AT&T Research 3 INTERNET-DRAFT B. Haberman, IBM 4 Expires December 1999 June 1999 6 Multicast Listener Discovery (MLD) for IPv6 8 draft-ietf-ipngwg-mld-02.txt 10 Status of this Memo 12 This document is an Internet Draft and is in full conformance with all 13 provisions of Section 10 of RFC 2026 [STD-PROC]. 15 This document is an Internet Draft. Internet Drafts are working docu- 16 ments of the Internet Engineering Task Force (IETF), its Areas, and its 17 Working Groups. Note that other groups may also distribute working doc- 18 uments as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six months. 21 Internet Drafts may be updated, replaced, or obsoleted by other docu- 22 ments at any time. It is not appropriate to use Internet Drafts as ref- 23 erence material or to cite them other than as a "working draft" or "work 24 in progress." 26 The list of current Internet Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This document is a product of the IP Next Generation working group 33 within the Internet Engineering Task Force. Comments are solicited and 34 should be addressed to the working group's mailing list at ipng@sun- 35 roof.Eng.Sun.COM and/or the author(s). 37 Abstract 39 This document specifies the protocol used by an IPv6 router to dis- 40 cover the presence of multicast listeners (that is, nodes wishing 41 to receive multicast packets) on its directly attached links, and 42 to discover specifically which multicast addresses are of interest 43 to those neighboring nodes. This protocol is referred to as Multi- 44 cast Listener Discovery or MLD. 46 MLD is derived from version 2 of IPv4's Internet Group Management 47 Protocol, IGMPv2. One important difference to note is that MLD 48 uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP 49 Protocol 2) message types. 51 1. Definitions 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 57 2. Introduction 59 The purpose of Multicast Listener Discovery (MLD) is to enable each IPv6 60 router to discover the presence of multicast listeners (that is, nodes 61 wishing to receive multicast packets) on its directly attached links, 62 and to discover specifically which multicast addresses are of interest 63 to those neighboring nodes. This information is then provided to 64 whichever multicast routing protocol is being used by the router, in 65 order to ensure that multicast packets are delivered to all links where 66 there are interested receivers. 68 MLD is an asymmetric protocol, specifying different behaviors for multi- 69 cast listeners and for routers. For those multicast addresses to which 70 a router itself is listening, the router performs both parts of the pro- 71 tocol, including responding to its own messages. 73 If a router has more than one interface to the same link, it need per- 74 form the router part of MLD over only one of those interfaces. Listen- 75 ers, on the other hand, must perform the listener part of MLD on all 76 interfaces from which an application or upper-layer protocol has 77 requested reception of multicast packets. 79 3. Message Format 81 MLD is a sub-protocol of ICMPv6, that is, MLD message types are a subset 82 of the set of ICMPv6 messages, and MLD messages are identified in IPv6 83 packets by a preceding Next Header value of 58. All MLD messages 84 described in this document are sent with a link-local IPv6 Source 85 Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option [RTR- 86 ALERT] in a Hop-by-Hop Options header. (The Router Alert option is nec- 87 essary to cause routers to examine MLD messages sent to multicast 88 addresses in which the routers themselves have no interest.) 89 MLD messages have the following format: 91 0 1 2 3 92 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 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | Type | Code | Checksum | 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 | Maximum Response Delay | Reserved | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | | 99 + + 100 | | 101 + Multicast Address + 102 | | 103 + + 104 | | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 3.1. Type 109 There are three types of MLD messages: 111 Multicast Listener Query (Type = decimal 130) 113 There are two subtypes of Multicast Listener Query messages: 114 - General Query, used to learn which multicast addresses have 115 listeners on an attached link. 116 - Multicast-Address-Specific Query, used to learn if a partic- 117 ular multicast address has any listeners on an attached 118 link. 119 These two subtypes are differentiated by the contents of the 120 Multicast Address field, as described in section 3.6. 122 Multicast Listener Report (Type = decimal 131) 124 Multicast Listener Done (Type = decimal 132) 126 In the rest of this document, the above messages types are referred 127 to simply as "Query", "Report", and "Done". 129 3.2. Code 131 Initialized to zero by the sender; ignored by receivers. 133 3.3. Checksum 135 The standard ICMPv6 checksum, covering the entire MLD message plus 136 a "pseudo-header" of IPv6 header fields [ICMPv6,IPv6]. 138 3.4. Maximum Response Delay 140 The Maximum Response Delay field is meaningful only in Query mes- 141 sages, and specifies the maximum allowed delay before sending a 142 responding Report, in units of milliseconds. In all other mes- 143 sages, it is set to zero by the sender and ignored by receivers. 145 Varying this value allows the routers to tune the "leave latency" 146 (the time between the moment the last node on a link ceases listen- 147 ing to a particular multicast address and moment the routing proto- 148 col is notified that there are no longer any listeners for that 149 address), as discussed in section 7.8. It also allows tuning of 150 the burstiness of MLD traffic on a link, as discussed in section 151 7.3. 153 3.5. Reserved 155 Initialized to zero by the sender; ignored by receivers. 157 3.6. Multicast Address 159 In a Query message, the Multicast Address field is set to zero when 160 sending a General Query, and set to a specific IPv6 multicast 161 address when sending a Multicast-Address-Specific Query. 163 In a Report or Done message, the Multicast Address field holds a 164 specific IPv6 multicast address to which the message sender is lis- 165 tening or is ceasing to listen, respectively. 167 3.7. Other fields 169 The length of a received MLD message is computed by taking the IPv6 170 Payload Length value and subtracting the length of any IPv6 exten- 171 sion headers present between the IPv6 header and the MLD message. 172 If that length is greater than 24 octets, that indicates that there 173 are other fields present beyond the fields described above, perhaps 174 belonging to a future backwards-compatible version of MLD. An 175 implementation of the version of MLD specified in this document 176 MUST NOT send an MLD message longer than 24 octets and MUST ignore 177 anything past the first 24 octets of a received MLD message. In 178 all cases, the MLD checksum MUST be computed over the entire MLD 179 message, not just the first 24 octets. 181 4. Protocol Description 183 Note that defaults for timer values are described later in this docu- 184 ment. Timer and counter names appear in square brackets. 186 Routers use MLD to learn which multicast addresses have listeners on 187 each of their attached links. Each router keeps a list, for each 188 attached link, of which multicast addresses have listeners on that link, 189 and a timer associated with each of those addresses. Note that the 190 router needs to learn only that listeners for a given multicast address 191 are present on a link; it does NOT need to learn the identity (e.g., 192 unicast address) of those listeners or even how many listeners are pre- 193 sent. 195 For each attached link, a router selects one of its link-local unicast 196 addresses on that link to be used as the IPv6 Source Address in all MLD 197 packets it transmits on that link. 199 For each interface over which the router is operating the MLD protocol, 200 the router must configure that interface to listen to all link-layer 201 multicast address that can be generated by IPv6 multicasts. For exam- 202 ple, an Ethernet-attached router must set its Ethernet address reception 203 filter to accept all Ethernet multicast addresses that start with the 204 hexadecimal value 3333 [IPv6-ETHER]; in the case of an Ethernet inter- 205 face that does not support the filtering of such a range of multicast 206 address, it must be configured to accept ALL Ethernet multicast 207 addresses, in order to meet the requirements of MLD. 209 With respect to each of its attached links, a router may assume one of 210 two roles: Querier or Non-Querier. There is normally only one Querier 211 per link. All routers start up as a Querier on each of their attached 212 links. If a router hears a Query message whose IPv6 Source Address is 213 numerically less than its own selected address for that link, it MUST 214 become a Non-Querier on that link. If [Other Querier Present Interval] 215 passes without receiving, from a particular attached link, any Queries 216 from a router with an address less than its own, a router resumes the 217 role of Querier on that link. 219 A Querier for a link periodically [Query Interval] sends a General Query 220 on that link, to solicit reports of all multicast addresses of interest 221 on that link. On startup, a router SHOULD send [Startup Query Count] 222 General Queries spaced closely together [Startup Query Interval] on all 223 attached links in order to quickly and reliably discover the presence of 224 multicast listeners on those links. 226 General Queries are sent to the link-scope all-nodes multicast address 227 (FF02::1), with a Multicast Address field of 0, and a Maximum Response 228 Delay of [Query Response Interval]. 230 When a node receives a General Query, it sets a delay timer for each 231 multicast address to which it is listening on the interface from which 232 it received the Query, EXCLUDING the link-scope all-nodes address and 233 any multicast addresses of scope 0 (reserved) or 1 (node-local). Each 234 timer is set to a different random value, using the highest clock granu- 235 larity available on the node, selected from the range [0, Maximum 236 Response Delay] with Maximum Response Delay as specified in the Query 237 packet. If a timer for any address is already running, it is reset to 238 the new random value only if the requested Maximum Response Delay is 239 less than the remaining value of the running timer. If the Query packet 240 specifies a Maximum Response Delay of zero, each timer is effectively 241 set to zero, and the action specified below for timer expiration is per- 242 formed immediately. 244 When a node receives a Multicast-Address-Specific Query, if it is lis- 245 tening to the queried Multicast Address on the interface from which the 246 Query was received, it sets a delay timer for that address to a random 247 value selected from the range [0, Maximum Response Delay], as above. If 248 a timer for the address is already running, it is reset to the new ran- 249 dom value only if the requested Maximum Response Delay is less than the 250 remaining value of the running timer. If the Query packet specifies a 251 Maximum Response Delay of zero, the timer is effectively set to zero, 252 and the action specified below for timer expiration is performed immedi- 253 ately. 255 If a node's timer for a particular multicast address on a particular 256 interface expires, the node transmits a Report to that address via that 257 interface; the address being reported is carried in both the IPv6 Desti- 258 nation Address field and the MLD Multicast Address field of the Report 259 packet. The IPv6 Hop Limit of 1 (as well as the presence of a link- 260 local IPv6 Source Address) prevent the packet from traveling beyond the 261 link to which the reporting interface is attached. 263 If a node receives another node's Report from an interface for a multi- 264 cast address while it has a timer running for that same address on that 265 interface, it stops its timer and does not send a Report for that 266 address, thus suppressing duplicate reports on the link. 268 When a router receives a Report from a link, if the reported address is 269 not already present in the router's list of multicast address having 270 listeners on that link, the reported address is added to the list, its 271 timer is set to [Multicast Listener Interval], and its appearance is 272 made known to the router's multicast routing component. If a Report is 273 received for a multicast address that is already present in the router's 274 list, the timer for that address is reset to [Multicast Listener Inter- 275 val]. If an address's timer expires, it is assumed that there are no 276 longer any listeners for that address present on the link, so it is 277 deleted from the list and its disappearance is made known to the 278 multicast routing component. 280 When a node starts listening to a multicast address on an interface, it 281 should immediately transmit an unsolicited Report for that address on 282 that interface, in case it is the first listener on the link. To cover 283 the possibility of the initial Report being lost or damaged, it is rec- 284 ommended that it be repeated once or twice after short delays [Unso- 285 licited Report Interval]. (A simple way to accomplish this is to send 286 the initial Report and then act as if a Multicast-Address-Specific Query 287 was received for that address, and set a timer appropriately). 289 When a node ceases to listen to a multicast address on an interface, it 290 SHOULD send a single Done message to the link-scope all-routers multi- 291 cast address (FF02::2), carrying in its Multicast Address field the 292 address to which it is ceasing to listen. If the node's most recent 293 Report message was suppressed by hearing another Report message, it MAY 294 send nothing, as it is highly likely that there is another listener for 295 that address still present on the same link. If this optimization is 296 implemented, it MUST be able to be turned off but SHOULD default to on. 298 When a router in Querier state receives a Done message from a link, if 299 the Multicast Address identified in the message is present in the 300 Querier's list of addresses having listeners on that link, the Querier 301 sends [Last Listener Query Count] Multicast-Address-Specific Queries, 302 one every [Last Listener Query Interval] to that multicast address. 303 These Multicast-Address-Specific Queries have their Maximum Response 304 Delay set to [Last Listener Query Interval]. If no Reports for the 305 address are received from the link after the response delay of the last 306 query has passed, the routers on the link assume that the address no 307 longer has any listeners there; the address is therefore deleted from 308 the list and its disappearance is made known to the multicast routing 309 component. This process is continued to its resolution (i.e. until a 310 Report is received or the last Multicast-Address-Specific Query is sent 311 with no response) despite any transition from Querier to Non-Querier on 312 this link. 314 Routers in Non-Querier state MUST ignore Done messages. 316 When a router in Non-Querier state receives a Multicast-Address-Specific 317 Query, if its timer value for the identified multicast address is 318 greater than [Last Listener Query Count] times the Maximum Response 319 Delay specified in the message, it sets the address's timer to that lat- 320 ter value. 322 5. Node State Transition Diagram 324 Node behavior is more formally specified by the state transition diagram 325 below. A node may be in one of three possible states with respect to 326 any single IPv6 multicast address on any single interface: 328 - "Non-Listener" state, when the node is not listening to the address on 329 the interface (i.e., no upper-layer protocol or application has 330 requested reception of packets to that multicast address). This is 331 the initial state for all multicast addresses on all interfaces; it 332 requires no storage in the node. 334 - "Delaying Listener" state, when the node is listening to the address 335 on the interface and has a report delay timer running for that 336 address. 338 - "Idle Listener" state, when the node is listening to the address on 339 the interface and does not have a report delay timer running for that 340 address. 342 There are five significant events that can cause MLD state transitions: 344 - "start listening" occurs when the node starts listening to the address 345 on the interface. It may occur only in the Non-Listener state. 347 - "stop listening" occurs when the node stops listening to the address 348 on the interface. It may occur only in the Delaying Listener and Idle 349 Listener states. 351 - "query received" occurs when the node receives either a valid General 352 Query message, or a valid Multicast-Address-Specific Query message. 353 To be valid, the Query message MUST come from a link-local IPv6 Source 354 Address, be at least 24 octets long, and have a correct MLD checksum. 355 The Multicast Address field in the MLD message must contain either 356 zero (a General Query) or a valid multicast address (a Multicast- 357 Address-Specific Query). A General Query applies to all multicast 358 addresses on the interface from which the Query is received. A Multi- 359 cast-Address-Specific Query applies to a single multicast address on 360 the interface from which the Query is received. Queries are ignored 361 for addresses in the Non-Listener state. 363 - "report received" occurs when the node receives a valid MLD Report 364 message. To be valid, the Report message MUST come from a link-local 365 IPv6 Source Address, be at least 24 octets long, and have a correct 366 MLD checksum. A Report applies only to the address identified in the 367 Multicast Address field of the Report, on the interface from which the 368 Report is received. It is ignored in the Non-Listener or Idle Lis- 369 tener state. 371 - "timer expired" occurs when the report delay timer for the address on 372 the interface expires. It may occur only in the Delaying Listener 373 state. 375 All other events, such as receiving invalid MLD messages or MLD message 376 types other than Query or Report, are ignored in all states. 378 There are seven possible actions that may be taken in response to the 379 above events: 381 - "send report" for the address on the interface. The Report message is 382 sent to the address being reported. 384 - "send done" for the address on the interface. If the flag saying we 385 were the last node to report is cleared, this action MAY be skipped. 386 The Done message is sent to the link-scope all-routers address 387 (FF02::2). 389 - "set flag" that we were the last node to send a report for this 390 address. 392 - "clear flag" since we were not the last node to send a report for this 393 address. 395 - "start timer" for the address on the interface, using a delay value 396 chosen uniformly from the interval [0, Maximum Response Delay], where 397 Maximum Response Delay is specified in the Query. If this is an unso- 398 licited Report, the timer is set to a delay value chosen uniformly 399 from the interval [0, [Unsolicited Report Interval] ]. 401 - "reset timer" for the address on the interface to a new value, using a 402 delay value chosen uniformly from the interval [0, Maximum Response 403 Delay], as described in "start timer". 405 - "stop timer" for the address on the interface. 407 In all of the following state transition diagrams, each state transition 408 arc is labeled with the event that causes the transition, and, in paren- 409 theses, any actions taken during the transition. Note that the transi- 410 tion is always triggered by the event; even if the action is condi- 411 tional, the transition still occurs. 413 ________________ 414 | | 415 | | 416 | | 417 | | 418 --------->| Non-Listener |<--------- 419 | | | | 420 | | | | 421 | | | | 422 | |________________| | 423 | | | 424 | stop listening | start listening | stop listening 425 | (stop timer, |(send report, | (send done if 426 | send done if | set flag, | flag set) 427 | flag set) | start timer) | 428 ________|________ | ________|________ 429 | |<--------- | | 430 | | | | 431 | |<-------------------| | 432 | | query received | | 433 | Delaying | (start timer) | Idle | 434 ---->| Listener |------------------->| Listener | 435 | | | report received | | 436 | | | (stop timer, | | 437 | | | clear flag) | | 438 | |_________________|------------------->|_________________| 439 | query received | timer expired 440 | (reset timer if | (send report, 441 | Max Resp Delay | set flag) 442 | < current timer) | 443 ------------------- 445 The link-scope all-nodes address (FF02::1) is handled as a special case. 446 The node starts in Idle Listener state for that address on every inter- 447 face, never transitions to another state, and never sends a Report or 448 Done for that address. 450 MLD messages are never sent for multicast addresses whose scope is 0 451 (reserved) or 1 (node-local). 453 MLD messages ARE sent for multicast addresses whose scope is 2 (link- 454 local), including Solicited-Node multicast addresses [ADDR-ARCH], except 455 for the link-scope, all-nodes address (FF02::1). 457 6. Router State Transition Diagram 459 Router behavior is more formally specified by the state transition dia- 460 grams below. 462 A router may be in one of two possible states with respect to any single 463 attached link: 465 - "Querier", when this router is designated to transmit MLD Queries on 466 this link. 468 - "Non-Querier", when there is another router designated to transmit MLD 469 Queries on this link. 471 The following three events can cause the router to change states: 473 - "query timer expired" occurs when the timer set for query transmission 474 expires. This event is significant only when in the Querier state. 476 - "query received from a router with a lower IP address" occurs when a 477 valid MLD Query is received from a router on the same link with a 478 lower IPv6 Source Address. To be valid, the Query message MUST come 479 from a link-local IPv6 Source Address, be at least 24 octets long, and 480 have a correct MLD checksum. 482 - "other querier present timer expired" occurs when the timer set to 483 note the presence of another querier with a lower IP address on the 484 link expires. This event is significant only when in the Non-Querier 485 state. 487 There are three actions that may be taken in response to the above 488 events: 490 - "start general query timer" for the attached link to [Query Interval]. 492 - "start other querier present timer" for the attached link to [Other 493 Querier Present Interval]. 495 - "send general query" on the attached link. The General Query is sent 496 to the link-scope all-nodes address (FF02::1), and has a Maximum 497 Response Delay of [Query Response Interval]. 499 -------------------------------- 500 _______|________ gen. query timer | 501 --------- | | expired | 502 | Initial |---------------->| | (send general query, | 503 --------- (send gen. q., | | start gen. q. timer) | 504 start initial gen. q. | |<---------------------- 505 timer) | Querier | 506 | | 507 -----| |<--- 508 | | | | 509 | |________________| | 510 query received from a | | other querier 511 router with a lower | | present timer 512 IP address | | expired 513 (start other querier | ________________ | (send gen. query, 514 present timer) | | | | start gen. q. timer) 515 | | | | 516 | | | | 517 ---->| Non |---- 518 | Querier | 519 | | 520 | | 521 ---->| |---- 522 | |________________| | 523 | query received from a | 524 | router with a lower IP | 525 | address | 526 | (start other querier | 527 | present timer) | 528 --------------------------- 530 A router starts in the Initial state on all attached links, and immedi- 531 ately transitions to Querier state. 533 In addition, to keep track of which multicast addresses have listeners, 534 a router may be in one of three possible states with respect to any sin- 535 gle IPv6 multicast address on any single attached link: 537 - "No Listeners Present" state, when there are no nodes on the link that 538 have sent a Report for this multicast address. This is the initial 539 state for all multicast addresses on the router; it requires no stor- 540 age in the router. 542 - "Listeners Present" state, when there is a node on the link that has 543 sent a Report for this multicast address. 545 - "Checking Listeners" state, when the router has received a Done mes- 546 sage but has not yet heard a Report for the identified address. 548 There are five significant events that can cause router state transi- 549 tions: 551 - "report received" occurs when the router receives a Report for the 552 address from the link. To be valid, the Report message MUST come from 553 a link-local IPv6 Source Address, be at least 24 octets long, and have 554 a correct MLD checksum. 556 - "done received" occurs when the router receives a Done message for the 557 address from the link. To be valid, the Done message MUST come from a 558 link-local IPv6 Source Address, be at least 24 octets long, and have a 559 correct MLD checksum. This event is significant only in the "Listen- 560 ers Present" state and when the router is a Querier. 562 - "multicast-address-specific query received" occurs when a router 563 receives a Multicast-Address-Specific Query for the address from the 564 link. To be valid, the Query message MUST come from a link-local IPv6 565 Source Address, be at least 24 octets long, and have a correct MLD 566 checksum. This event is significant only in the "Listeners Present" 567 state and when the router is a Non-Querier. 569 - "timer expired" occurs when the timer set for a multicast address 570 expires. This event is significant only in the "Listeners Present" or 571 "Checking Listeners" state. 573 - "retransmit timer expired" occurs when the timer set to retransmit a 574 Multicast-Address-Specific Query expires. This event is significant 575 only in the "Checking Listeners" state. 577 There are seven possible actions that may be taken in response to the 578 above events: 580 - "start timer" for the address on the link - also resets the timer to 581 its initial value [Multicast Listener Interval] if the timer is cur- 582 rently running. 584 - "start timer*" for the address on the link - this alternate action 585 sets the timer to the minimum of its current value and either [Last 586 Listener Query Interval] * [Last Listener Query Count] if this router 587 is a Querier, or the Maximum Response Delay in the Query message * 588 [Last Listener Query Count] if this router is a non-Querier. 590 - "start retransmit timer" for the address on the link [Last Listener 591 Query Interval]. 593 - "clear retransmit timer" for the address on the link. 595 - "send multicast-address-specific query" for the address on the link. 596 The Multicast-Address-Specific Query is sent to the address being 597 queried, and has a Maximum Response Delay of [Last Listener Query 598 Interval]. 600 - "notify routing +" internally notify the multicast routing protocol 601 that there are listeners to this address on this link. 603 - "notify routing -" internally notify the multicast routing protocol 604 that there are no longer any listeners to this address on this link. 606 The following state diagrams apply per group per link. There are two 607 diagrams; one for routers in Querier state and one for routers in Non- 608 Querier state. The transition between Querier and Non-Querier state on 609 a link is handled specially. All groups on that link in "No Listeners 610 Present" or "Listeners Present" states switch state transition diagrams 611 when the Querier/Non-Querier state transition occurs. However, any 612 groups in "Checking Listeners" state continue with the same state tran- 613 sition diagram until the "Checking Listeners" state is exited. E.g. a 614 router that starts as a Querier, receives a Done message for a group and 615 then receives a Query from a router with a lower address (causing a 616 transition to the Non-Querier state) continues to send multicast- 617 address-specific queries for the group in question until it either 618 receives a Report or its timer expires, at which time it starts perform- 619 ing the actions of a Non-Querier for this group. 621 The state transition diagram for a router in Querier state follows: 623 ________________ 624 | | 625 | |timer expired 626 timer expired| |(notify routing -, 627 (notify routing -)| No Listeners |clear rxmt tmr) 628 ------->| Present |<--------- 629 | | | | 630 | | | | 631 | |________________| | --------------- 632 | | | | rexmt timer | 633 | report received| | | expired | 634 | (notify routing +,| | | (send m-a-s | 635 | start timer)| | | query, | 636 __________|______ | ________|_|______ st rxmt | 637 | |<------------ | | tmr) | 638 | | | |<------- 639 | | report received | | 640 | | (start timer, | | 641 | | clear rxmt tmr) | | 642 | Listeners |<-------------------| Checking | 643 | Present | done received | Listeners | 644 | | (start timer*, | | 645 | | start rxmt timer, | | 646 | | send m-a-s query) | | 647 --->| |------------------->| | 648 | |_________________| |_________________| 649 | report received | 650 | (start timer) | 651 ----------------- 653 The state transition diagram for a router in Non-Querier state is simi- 654 lar, but non-Queriers do not send any messages and are only driven by 655 message reception. 657 ________________ 658 | | 659 | | 660 timer expired| |timer expired 661 (notify routing -)| No Listeners |(notify routing -) 662 --------->| Present |<--------- 663 | | | | 664 | | | | 665 | | | | 666 | |________________| | 667 | | | 668 | |report received | 669 | |(notify routing +,| 670 | | start timer) | 671 ________|________ | ________|________ 672 | |<--------- | | 673 | | report received | | 674 | | (start timer) | | 675 | Listeners |<-------------------| Checking | 676 | Present | m-a-s query rec'd | Listeners | 677 | | (start timer*) | | 678 ---->| |------------------->| | 679 | |_________________| |_________________| 680 | report received | 681 | (start timer) | 682 ----------------- 684 7. List of timers and default values 686 Most of these timers are configurable. If non-default settings are 687 used, they MUST be consistent among all routers on a single link. Note 688 that parentheses are used to group expressions to make the algebra 689 clear. 691 7.1. Robustness Variable 693 The Robustness Variable allows tuning for the expected packet loss on a 694 link. If a link is expected to be lossy, the Robustness Variable may be 695 increased. MLD is robust to (Robustness Variable - 1) packet losses. 696 The Robustness Variable MUST NOT be zero, and SHOULD NOT be one. 697 Default: 2 699 7.2. Query Interval 701 The Query Interval is the interval between General Queries sent by the 702 Querier. Default: 125 seconds. 704 By varying the [Query Interval], an administrator may tune the number of 705 MLD messages on the link; larger values cause MLD Queries to be sent 706 less often. 708 7.3. Query Response Interval 710 The Maximum Response Delay inserted into the periodic General Queries. 711 Default: 10000 (10 seconds) 713 By varying the [Query Response Interval], an administrator may tune the 714 burstiness of MLD messages on the link; larger values make the traffic 715 less bursty, as node responses are spread out over a larger interval. 716 The number of seconds represented by the [Query Response Interval] must 717 be less than the [Query Interval]. 719 7.4. Multicast Listener Interval 721 The Multicast Listener Interval is the amount of time that must pass 722 before a router decides there are no more listeners for an address on a 723 link. This value MUST be ((the Robustness Variable) times (the Query 724 Interval)) plus (one Query Response Interval). 726 7.5. Other Querier Present Interval 728 The Other Querier Present Interval is the length of time that must pass 729 before a router decides that there is no longer another router which 730 should be the querier on a link. This value MUST be ((the Robustness 731 Variable) times (the Query Interval)) plus (one half of one Query 732 Response Interval). 734 7.6. Startup Query Interval 736 The Startup Query Interval is the interval between General Queries sent 737 by a Querier on startup. Default: 1/4 the Query Interval. 739 7.7. Startup Query Count 741 The Startup Query Count is the number of Queries sent out on startup, 742 separated by the Startup Query Interval. Default: the Robustness Vari- 743 able. 745 7.8. Last Listener Query Interval 747 The Last Listener Query Interval is the Maximum Response Delay inserted 748 into Multicast-Address-Specific Queries sent in response to Done mes- 749 sages, and is also the amount of time between Multicast-Address-Specific 750 Query messages. Default: 1000 (1 second) 752 This value may be tuned to modify the "leave latency" of the link. A 753 reduced value results in reduced time to detect the departure of the 754 last listener for an address. 756 7.9. Last Listener Query Count 758 The Last Listener Query Count is the number of Multicast-Address-Spe- 759 cific Queries sent before the router assumes there are no remaining lis- 760 teners for an address on a link. Default: the Robustness Variable. 762 7.10. Unsolicited Report Interval 764 The Unsolicited Report Interval is the time between repetitions of a 765 node's initial report of interest in a multicast address. Default: 10 766 seconds. 768 8. Message Destinations 770 This information is provided elsewhere in the document, but is summa- 771 rized here for convenience. 773 Message Type IPv6 Destination Address 774 ------------ ------------------------ 775 General Query link-scope all-nodes (FF02::1) 776 Multicast-Address-Specific Query the multicast address being queried 777 Report the multicast address being reported 778 Done link-scope all-routers (FF02::2) 780 9. Security Considerations 782 We consider the ramifications of a forged message of each type. Note 783 that the requirement that nodes verify that the IPv6 Source Address of 784 all received MLD messages is a link-local address defends them from act- 785 ing on forged MLD messages originated off-link, so we discuss only the 786 effects of on-link forgery. 788 Query message: 790 A forged Query message from a machine with a lower IP address than 791 the current Querier will cause Querier duties to be assigned to the 792 forger. If the forger then sends no more Query messages, other 793 routers' Other Querier Present timer will time out and one will 794 resume the role of Querier. During this time, if the forger 795 ignores Done messages, traffic might flow to addresses with no lis- 796 teners for up to [Multicast Listener Interval]. 798 A forged Query message sent to an address with listeners will cause 799 one or more nodes that are listeners to that address to send a 800 Report. This causes a small amount of extra traffic on the link, 801 but causes no protocol problems. 803 Report message: 805 A forged Report message may cause routers to think there are lis- 806 teners for an address present on a link when there are not. How- 807 ever, since listening to a multicast address is generally an 808 unprivileged operation, a local user may trivially gain the same 809 result without forging any messages. 811 Done message: 813 A forged Done message will cause the Querier to send out Multicast- 814 Address-Specific Queries for the address in question. This causes 815 extra processing on each router and on each of the address's lis- 816 teners, and extra packets on the link, but cannot cause loss of 817 desired traffic. 819 10. Acknowledgments 821 MLD was derived from IGMPv2 [IGMPv2], which was designed by Rosen Sharma 822 and Steve Deering and documented by Bill Fenner. 824 11. References 826 [ADDR-ARCH] Hinden, R. and Deering, S., "IP Version 6 Addressing 827 Architecture", RFC 2373, July 1998. 829 [ICMPv6] Conta, A. and Deering, S., "Internet Control Message Pro- 830 tocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 831 Specification", RFC 2463, December 1998. 833 [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 834 2", RFC 2236, November 1997. 836 [IPv6] Deering, S. and Hinden, R., "Internet Protocol, Version 6 837 (IPv6) Specification", RFC 2460, December 1998. 839 [IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet 840 Networks", RFC 2464, December, 1998. 842 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", RFC 2119/BCP 14, March 1997. 845 [RTR-ALERT] Katz, D., Atkinson, R., Partridge, C. and Jackson, A., 846 "IPv6 Router Alert Option", RFC ????, ??? 1999. 848 [STD-PROC] Bradner, S., "The Internet Standards Process -- Revision 849 3", RFC 2026, October 1996. 851 12. Authors' Addresses 853 Stephen E. Deering 854 Cisco Systems, Inc. 855 170 West Tasman Drive 856 San Jose, CA 95134-1706 857 USA 858 Phone: +1 408 527 8213 859 Email: deering@cisco.com 861 William C. Fenner 862 AT&T Research 863 75 Willow Road 864 Menlo Park, CA 94025 865 USA 866 Phone: +1 650 867 6073 867 Email: fenner@research.att.com 868 Brian Haberman 869 IBM Corporation 870 800 Park Office Drive 871 Research Triangle Park, NC 27709 872 USA 873 Phone: +1 919 254 2673 874 Email: haberman@raleigh.ibm.com 876 13. Changes From Previous Draft 878 13.1. Changes from draft -00 880 - Moved description of MLD message format onto a separate section. 882 - Added a sentence explaining why the Router Alert option is required in 883 MLD messages. 885 - Added a paragraph explaining that routers must set their link-layer 886 address filters (e.g., Ethernet address filters) to accept all link- 887 layer multicast addresses that can be generated by IPv6 multicast. 889 - Specified the required behavior when the Maximum Response Time in a 890 received Query packet is zero. 892 - Added clarification that MLD messages are generated for link-local 893 multicast addresses, including Solicited-Node addresses. 895 - Corrected one of the state-transition diagrams to refer to "done 896 received" instead of "leave received". 898 - Added some references and updated some others. 900 13.2. Changes from draft -01 902 - Fixed several consistency and clarity problems pointed out during AD 903 review. 905 - Suppression of Done messages is based upon whether or not this 906 node's last Report was suppressed. 908 - The text about the special case of a Querier<>Non-Querier transition 909 while a router is performing the Checking Listener function was con- 910 fusing and inadequately specified the actions taken. 912 - Added missing states and actions on state diagram transitions. 914 - Added descriptions of in what state(s) an event is significant to 915 the router state diagrams. 917 - Added wording about only decreasing running timers to General Queries 918 too. This should not be a common occurrence but is possible so should 919 be documented.