idnits 2.17.1 draft-ietf-idmr-igmp-v3-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 6) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 46 pages 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 18 instances of too long lines in the document, the longest one being 69 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 24 has weird spacing: '... The list o...' == Line 304 has weird spacing: '...change of soc...' == Line 455 has weird spacing: '... to the multi...' == Line 456 has weird spacing: '...ept and proce...' == Line 666 has weird spacing: '...ed from the l...' == (17 more instances...) == 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 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 (November 1999) is 8926 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 504 -- Looks like a reference, but probably isn't: '2' on line 506 == Missing Reference: 'N' is mentioned on line 512, but not defined == Missing Reference: 'M' is mentioned on line 492, but not defined Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Brad Cain, Nortel Networks 2 Steve Deering, Cisco Systems 3 Ajit Thyagarajan, Ericsson 4 Expires June 2000 November 1999 6 Internet Group Management Protocol, Version 3 7 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as work in progress. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document specifies Version 3 of the Internet Group Management 33 Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report 34 their IP multicast group memberships to neighboring multicast routers. 35 Version 3 of IGMP adds support for "source filtering", that is, the 36 ability for a system to report interest in receiving packets *only* from 37 specific source addresses, or from *all but* specific source addresses, 38 sent to a particular multicast address. That information may be used 39 by multicast routing protocols to avoid delivering multicast packets 40 from specific sources to networks where there are no interested 41 receivers. 43 This document is a product of the Inter-Domain Multicast Routing working 44 group within the Internet Engineering Task Force. Comments are 45 solicited and should be addressed to the working group's mailing list at 46 idmr@cs.ucl.ac.uk and/or the authors. 48 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 49 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 50 in this document are to be interpreted as described in [RFC 2119]. Due 51 to the lack of italics, emphasis is indicated herein by bracketing a word 52 or phrase in "*" characters. 54 TABLE OF CONTENTS 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. The API for Requesting IP Multicast Reception. . . . . . . . . 3 60 3. Multicast Reception State Maintained by Systems. . . . . . . . 5 62 4. Message Formats. . . . . . . . . . . . . . . . . . . . . . . . 8 64 5. Description of the Protocol for Group Members. . . . . . . . . 18 66 6. Description of the Protocol for Multicast Routers. . . . . . . 22 68 7. Interoperation with Older Versions of IGMP . . . . . . . . . . 32 70 8. List of Timers, Counters, and their Default Values . . . . . . 39 72 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 42 74 10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 43 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 78 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 44 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 82 1. INTRODUCTION 84 The Internet Group Management Protocol (IGMP) is used by IPv4 systems 85 (hosts and routers) to report their IP multicast group memberships to 86 any neighboring multicast routers. Note that an IP multicast router 87 may itself be a member of one or more multicast groups, in which case 88 it performs both the "multicast router part" of the protocol (to 89 collect the membership information needed by its multicast routing 90 protocol) and the "group member part" of the protocol (to inform itself 91 and other, neighboring multicast routers of its memberships). 93 IGMP is also used for other IP multicast management functions, using 94 message types other than those used for group membership reporting. 95 This document specifies only the group membership reporting functions 96 and messages. 98 This document specifies Version 3 of IGMP. Version 1, specified in 99 [RFC-1112], was the first widely-deployed version and the first version 100 to become an Internet Standard. Version 2, specified in [RFC-2236], 101 added support for "low leave latency", that is, a reduction in the time 102 it takes for a multicast router to learn that there are no longer any 103 members of a particular group present on an attached network. Version 3 104 adds support for "source filtering", that is, the ability for a system 105 to report interest in receiving packets *only* from specific source 106 addresses, or from *all but* specific source addresses, sent to a 107 particular multicast address. Version 3 is designed to be 108 interoperable with Versions 1 and 2. 110 2. THE API FOR REQUESTING IP MULTICAST RECEPTION 112 Within an IP system, there is (at least conceptually) an Application 113 Programming Interface or API used by upper-layer protocols or 114 application programs to ask the IP layer to enable and disable reception 115 of packets sent to specific IP multicast addresses. In order to take 116 full advantage of the capabilities of IGMPv3, a system's IP API must 117 support the following operation (or any logical equivalent): 119 IPMulticastListen ( socket, interface, multicast-address, 120 filter-mode, source-list ) 122 where 124 "socket" is an implementation-specific parameter used to distinguish 125 among different requesting entities (e.g., programs or processes) 126 within the system; the socket parameter of BSD Unix system calls 127 is a specific example. 129 "interface" is a local identifier of the network interface on which 130 reception of the specified multicast address is to be enabled or 131 disabled. Interfaces may be physical (e.g., an Ethernet interface) 132 or virtual (e.g., the endpoint of a Frame Relay virtual circuit or 133 the endpoint of an IP-in-IP "tunnel"). An implementation may allow 134 a special "unspecified" value to be passed as the interface 135 parameter, in which case the request would apply to the "primary" or 136 "default" interface of the system (perhaps established by system 137 configuration). If reception of the same multicast address is 138 desired on more than one interface, IPMulticastListen is invoked 139 separately for each desired interface. 141 "multicast-address" is the IP multicast address to which the request 142 pertains. If reception of more than one multicast address on a given 143 interface is desired, IPMulticastListen is invoked separately for 144 each desired multicast address. 146 "filter-mode" may be either INCLUDE or EXCLUDE. In INCLUDE mode, 147 reception of packets sent to the specified multicast address is 148 requested *only* from those IP source addresses listed in the 149 source-list parameter. In EXCLUDE mode, reception of packets sent 150 to the given multicast address is requested from all IP source 151 addresses *except* those listed in the source-list parameter. 153 "source-list" is an unordered list of zero or more IP unicast 154 addresses from which multicast reception is desired or not desired, 155 depending on the filter mode. An implementation MAY impose a limit 156 on the size of source lists, but that limit MUST NOT be less than 157 64 addresses per list. 159 For a given combination of socket, interface, and multicast address, 160 only a single filter mode and source list can be in effect at any one 161 time. However, either the filter mode or the source list, or both, may 162 be changed by subsequent IPMulticastListen requests that specify the 163 same socket, interface, and multicast address. 165 Previous versions of IGMP did not support source filters and had a 166 simpler API consisting of Join and Leave operations to enable and 167 disable reception of a given multicast address (from *all* sources) on 168 a given interface. Those Join and Leave operations are supported by 169 the new API as follows: 171 The Join operation is equivalent to 173 IPMulticastListen ( socket, interface, multicast-address, 174 EXCLUDE, {} ) 176 and the Leave operation is equivalent to: 178 IPMulticastListen ( socket, interface, multicast-address, 179 INCLUDE, {} ) 181 where {} is an empty source list. 183 It is recommended that implementations continue to support the old API, 184 (perhaps as calls on the new API) for compatibility with pre-existing IP 185 multicast applications. 187 3. MULTICAST RECEPTION STATE MAINTAINED BY SYSTEMS 189 3.1 Socket State 191 For each socket on which IPMulticastListen has been invoked, the system 192 records the desired multicast reception state for that socket. That 193 state conceptually consists of a set of records of the form: 195 (interface, multicast-address, filter-mode, source-list) 197 The socket state evolves in response to each invocation of 198 IPMulticastListen on the socket, as follows: 200 o If the requested filter mode is INCLUDE *and* the requested source 201 list is empty, then the entry corresponding to the requested 202 interface and multicast address is deleted if present. If no such 203 entry is present, the request is ignored. 205 o If the requested filter mode is EXCLUDE *or* the requested source 206 list is non-empty, then the entry corresponding to the requested 207 interface and multicast address, if present, is changed to contain 208 the requested filter mode and source list. If no such entry is 209 present, a new entry is created, using the parameters specified in 210 the request. 212 3.2 Interface State 214 In addition to the per-socket multicast reception state, a system must 215 also maintain or compute multicast reception state for each of its 216 interfaces. That state conceptually consists of a set of records of 217 the form: 219 (multicast-address, filter-mode, source-list) 221 This per-interface state is derived from the per-socket state, but may 222 differ from the per-socket state when different sockets have differing 223 filter modes and/or source lists for the same multicast address and 224 interface. For example, suppose one application or process invokes the 225 following operation on socket s1: 227 IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} ) 229 requesting reception on interface i of packets sent to multicast 230 address m, *only* if they come from source a, b, or c. Suppose another 231 application or process invokes the following operation on socket s2: 233 IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} ) 235 requesting reception on the same interface i of packets sent to the 236 same multicast address m, *only* if they come from sources b, c, or d. 237 In order to satisfy the reception requirements of both sockets, it is 238 necessary for interface i to receive packets sent to m from any one of 239 the sources a, b, c, or d. Thus, in this example, the reception state 240 of interface i for multicast address m has filter mode INCLUDE and 241 source list {a, b, c, d}. 243 (After a multicast packet has been accepted from an interface by the IP 244 layer, its subsequent delivery to the application or process listening 245 on a particular socket depends on the multicast reception state of that 246 socket [and possibly also on other conditions, such as what transport- 247 layer port the socket is bound to]. So, in the above example, if a 248 packet arrives on interface i, destined to multicast address m, with 249 source address a, it may be delivered on socket s1 but not on socket 250 s2.) 252 The general rules for deriving the per-interface state from the per- 253 socket state are as follows: For each distinct (interface, multicast- 254 address) pair that appears in any socket state, a per-interface record 255 is created for that multicast address on that interface. Considering 256 all socket records containing the same (interface, multicast-address) 257 pair, 259 o if *any* such record has a filter mode of EXCLUDE, then the filter 260 mode of the interface record is EXCLUDE, and the source list of 261 the interface record is the intersection of the source lists of all 262 socket records in EXCLUDE mode, minus those source addresses that 263 appear in any socket record in INCLUDE mode. For example, if the 264 socket records for multicast address m on interface i are: 266 from socket s1: ( i, m, EXCLUDE, {a, b, c, d} ) 267 from socket s2: ( i, m, EXCLUDE, {b, c, d, e} ) 268 from socket s3: ( i, m, INCLUDE, {d, e, f} ) 270 then the corresponding interface record on interface i is: 272 ( m, EXCLUDE, {b, c} ) 274 o if *all* such records have a filter mode of INCLUDE, then the 275 filter mode of the interface record is INCLUDE, and the source list 276 of the interface record is the union of the source lists of all the 277 socket records. For example, if the socket records for multicast 278 address m on interface i are: 280 from socket s1: ( i, m, INCLUDE, {a, b, c} ) 281 from socket s2: ( i, m, INCLUDE, {b, c, d} ) 282 from socket s3: ( i, m, INCLUDE, {e, f} ) 284 then the corresponding interface record on interface i is: 286 ( m, INCLUDE, {a, b, c, d, e, f} ) 288 In order to bound storage consumption, an implementation MAY impose 289 a limit on the size of the source list in an interface record whose 290 filter mode is INCLUDE, but that limit MUST NOT be less than 64 291 addresses. If such a limit is imposed, whenever the union of the 292 source lists of all the relevant socket records would exceed that 293 limit, an interface record of the following form would be created, 294 instead: 296 ( m, EXCLUDE, {} ) 298 which enables reception of packets to multicast address m from *all* 299 sources. 301 The above rules for deriving the interface state are (re-)evaluated 302 whenever an IPMulticastListen invocation modifies the socket state by 303 adding, deleting, or modifying a per-socket state record. Note that a 304 change of socket state does not necessarily result in a change of 305 interface state. 307 4. MESSAGE FORMATS 309 IGMP messages are encapsulated in IPv4 datagrams, with an IP protocol 310 number of 2. Every IGMP message described in this document is sent 311 with an IP Time-to-Live of 1, and carries an IP Router Alert option 312 [RFC-2113] in its IP header. 314 There are two IGMP message types of concern to the IGMPv3 protocol 315 described in this document: 317 Type Number (hex) Message Name 318 ----------------- ------------ 320 0x11 Membership Query 322 0x22 Version 3 Membership Report 324 An implementation of IGMPv3 must also support the following three 325 message types, for interoperation with previous versions of IGMP (see 326 section 7): 328 0x12 Version 1 Membership Report [RFC-1112] 330 0x16 Version 2 Membership Report [RFC-2236] 332 0x17 Version 2 Leave Group [RFC-2236] 334 Unrecognized message types MUST be silently ignored. Other message 335 types may be used by newer versions or extensions of IGMP, by multicast 336 routing protocols, or for other uses. 338 In this document, unless otherwise qualified, the capitalized words 339 "Query" and "Report" refer to IGMP Membership Queries and IGMP Version 340 3 Membership Reports, respectively. 342 4.1 Membership Query Message 344 Membership Queries are sent by IP multicast routers to query the 345 multicast reception state of neighboring interfaces. Queries have the 346 following format: 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Type = 0x11 | Max Resp Time | Checksum | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Group Address | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Reserved | Number of Sources (N) | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Source Address [1] | 358 +- -+ 359 | Source Address [2] | 360 +- . -+ 361 . . . 362 . . . 363 +- -+ 364 | Source Address [N] | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 4.1.1 Max Resp Time 369 The Max Resp Time field specifies the maximum time allowed before 370 sending a responding report, in units of 1/10 second. 372 Varying this setting allows IGMPv3 routers to tune the "leave 373 latency" (the time between the moment the last host leaves a group 374 and the moment the routing protocol is notified that there are no 375 more members). It also allows tuning of the burstiness of IGMP 376 traffic on a network. 378 4.1.2 Checksum 380 The Checksum is the 16-bit one's complement of the one's complement 381 sum of the whole IGMP message (the entire IP payload). For 382 computing the checksum, the Checksum field is set to zero. When 383 receiving packets, the checksum MUST be verified before processing 384 a packet. 386 4.1.3 Group Address 388 The Group Address field is set to zero when sending a General 389 Query, and set to the IP multicast address being queried when 390 sending a Group-Specific Query or Group-and-Source-Specific Query 391 (see section 4.1.8, below). 393 4.1.4 Reserved 395 The Reserved field is set to zero on transmission, and ignored on 396 reception. 398 4.1.5 Number of Sources (N) 400 The Number of Sources (N) field specifies how many source addresses 401 are present in the Query. This number is zero in a General Query 402 or a Group-Specific Query, and non-zero in a Group-and-Source- 403 Specific Query. This number is limited by the MTU of the network 404 over which the Query is transmitted. For example, on an Ethernet 405 with an MTU of 1500 octets, the IP header including the Router 406 Alert option consumes 24 octets, and the IGMP fields up to 407 including the Number of Sources (N) field consume 12 octets, 408 leaving 1464 octets for source addresses, which limits the number 409 of source addresses to 366 (1464/4). 411 4.1.6 Source Address [i] 413 The Source Address [i] fields are a vector of n IP unicast 414 addresses, where n is the value in the Number of Sources (N) field. 416 4.1.7 Additional Data 418 If the Packet Length field in the IP header of a received Query 419 indicates that there are additional octets of data present, beyond 420 the fields described here, IGMPv3 implementations MUST include 421 those octets in the computation to verify the received IGMP 422 Checksum, but MUST otherwise ignore those additional octets. When 423 sending a Query, an IGMPv3 implementation MUST NOT include 424 additional octets beyond the fields described here. 426 4.1.8 Query Variants 428 There are three variants of the Query message: 430 (1) A "General Query" is sent by a multicast router to learn the 431 complete multicast reception state of the neighboring interfaces 432 (that is, the interfaces attached to the network on which the 433 Query is transmitted). In a General Query, both the Group 434 Address field and the Number of Sources (N) field are zero. 436 (2) A "Group-Specific Query" is sent by a multicast router to learn 437 the reception state, with respect to a *single* multicast 438 address, of the neighboring interfaces. In a Group-Specific 439 Query, the Group Address field contains the multicast address 440 of interest, and the Number of Sources (N) field contains zero. 442 (3) A "Group-and-Source-Specific Query" is sent by a multicast 443 router to learn if any neighboring interface desires reception 444 of packets sent to a specified multicast address, from any of a 445 specified list of sources. In a Group-and-Source-Specific 446 Query, the Group Address field contains the multicast address 447 of interest, and the Source Address [i] fields contain the 448 source address(es) of interest. 450 4.1.9 IP Destination Addresses for Queries 452 In IGMPv3, General Queries are sent with an IP destination address 453 of 224.0.0.1, the all-systems multicast address. Group-Specific and 454 Group-and-Source-Specific Queries are sent with an IP destination 455 address equal to the multicast address of interest. *However*, a 456 system MUST accept and process any Query whose IP Destination 457 Address field contains *any* of the addresses (unicast or multicast) 458 assigned to the interface on which the Query arrives. 460 4.2 Version 3 Membership Report Message 462 Version 3 Membership Reports are sent by IP systems to report (to 463 neighboring routers) the current multicast reception state, or changes 464 in the multicast reception state, of their interfaces. Reports have 465 the following format: 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Type = 0x22 | Reserved | Checksum | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Reserved | Number of Group Records (M) | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | | 475 . . 476 . Group Record [1] . 477 . . 478 | | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | | 481 . . 482 . Group Record [2] . 483 . . 484 | | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 . 487 . 488 . 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | | 491 . . 492 . Group Record [M] . 493 . . 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 where each Group Record has the following internal format: 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Record Type | Aux Data Len | Number of Sources (N) | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Multicast Address | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Source Address [1] | 505 +- -+ 506 | Source Address [2] | 507 +- -+ 508 . . . 509 . . . 510 . . . 511 +- -+ 512 | Source Address [N] | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | | 515 . . 516 . Auxiliary Data . 517 . . 518 | | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 4.2.1 Reserved 523 The Reserved fields are set to zero on transmission, and ignored on 524 reception. 526 4.2.2 Checksum 528 The Checksum is the 16-bit one's complement of the one's complement 529 sum of the whole IGMP message (the entire IP payload). For 530 computing the checksum, the Checksum field is set to zero. When 531 receiving packets, the checksum MUST be verified before processing 532 a message. 534 4.2.3 Number of Group Records (M) 536 The Number of Group Records (M) field specifies how many Group 537 Records are present in this Report. 539 4.2.4 Group Record 541 Each Group Record is a block of fields containing information 542 pertaining to the sender's membership in a single multicast group 543 on the interface from which the Report is sent. 545 4.2.5 Record Type 547 See section 4.2.12, below. 549 4.2.6 Aux Data Len 551 The Aux Data Len field contains the length of the Auxiliary Data 552 field in this Group Record, in units of 32-bit words. It may 553 contain zero, to indicate the absence of any auxiliary data. 555 4.2.7 Number of Sources (N) 557 The Number of Sources (N) field specifies how many source addresses 558 are present in this Group Record. 560 4.2.8 Multicast Address 562 The Multicast Address field contains the IP multicast address to 563 which this Group Record pertains. 565 4.2.9 Source Address [i] 567 The Source Address [i] fields are a vector of n IP unicast 568 addresses, where n is the value in this record's Number of Sources 569 (N) field. 571 4.2.10 Auxiliary Data 573 The Auxiliary Data field, if present, contains additional 574 information pertaining to this Group Record. The protocol specified 575 in this document, IGMPv3, does not define any auxiliary data. 576 Therefore, implementations of IGMPv3 MUST NOT include any auxiliary 577 data (i.e., MUST set the Aux Data Len field to zero) in any 578 transmitted Group Record, and MUST ignore any auxiliary data present 579 in any received Group Record. The semantics and internal encoding 580 of the Auxiliary Data field are to be defined by any future version 581 or extension of IGMP that uses this field. 583 4.2.11 Additional Data 585 If the Packet Length field in the IP header of a received Report 586 indicates that there are additional octets of data present, beyond 587 the last Group Record, IGMPv3 implementations MUST include those 588 octets in the computation to verify the received IGMP Checksum, but 589 MUST otherwise ignore those additional octets. When sending a 590 Report, an IGMPv3 implementation MUST NOT include additional octets 591 beyond the last Group Record. 593 4.2.12 Group Record Types 595 There are a number of different types of Group Records that may be 596 included in a Report message: 598 (1) A "Current-State Record" is sent by a system in response to a 599 Query received on an interface. It reports the current 600 reception state of that interface, with respect to a single 601 multicast address. The Record Type of a Current-State Record 602 may be one of the following two values: 604 Value Name and Meaning 605 ----- ---------------- 607 1 MODE_IS_INCLUDE - indicates that the interface has a 608 filter mode of INCLUDE for the specified multicast 609 address. The Source Address [i] fields in this Group 610 Record contain the interface's source list for the 611 specified multicast address, if it is non-empty. 613 2 MODE_IS_EXCLUDE - indicates that the interface has a 614 filter mode of EXCLUDE for the specified multicast 615 address. The Source Address [i] fields in this Group 616 Record contain the interface's source list for the 617 specified multicast address, if it is non-empty. 619 (2) A "Filter-Mode-Change Record" is sent by a system whenever a 620 local invocation of IPMulticastListen causes a change of the 621 filter mode (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to INCLUDE), of the interface-level state entry for a 622 particular multicast address. The Record is included in a 623 Report sent from the interface on which the change occurred. 624 The Record Type of a Filter-Mode-Change Record may be one of 625 the following two values: 627 3 CHANGE_TO_INCLUDE_MODE - indicates that the interface 628 has changed to INCLUDE filter mode for the specified 629 multicast address. The Source Address [i] fields 630 in this Group Record contain the interface's new 631 source list for the specified multicast address, 632 if it is non-empty. 634 4 CHANGE_TO_EXCLUDE_MODE - indicates that the interface 635 has changed to EXCLUDE filter mode for the specified 636 multicast address. The Source Address [i] fields 637 in this Group Record contain the interface's new 638 source list for the specified multicast address, 639 if it is non-empty. 641 (3) A "Source-List-Change Record" is sent by a system whenever a 642 local invocation of IPMulticastListen causes a change of source 643 list that is *not* coincident with a change of filter mode, of 644 the interface-level state entry for a particular multicast 645 address. The Record is included in a Report sent from the 646 interface on which the change occurred. The Record Type of a 647 Source-List-Change Record may be one of the following two 648 values: 650 5 ALLOW_NEW_SOURCES - indicates that the Source Address 651 [i] fields in this Group Record contain a list of the 652 additional sources that the system wishes to 653 hear from, for packets sent to the specified 654 multicast address. If the change was to an INCLUDE 655 source list, these are the addresses that were added 656 to the list; if the change was to an EXCLUDE source 657 list, these are the addresses that were deleted from 658 the list. 660 6 BLOCK_OLD_SOURCES - indicates that the Source Address 661 [i] fields in this Group Record contain a list of the 662 sources that the system no longer wishes to 663 hear from, for packets sent to the specified 664 multicast address. If the change was to an INCLUDE 665 source list, these are the addresses that were 666 deleted from the list; if the change was to an 667 EXCLUDE source list, these are the addresses that 668 were added to the list. 670 If a change of source list results in both allowing new sources 671 and blocking old sources, then two Group Records are sent for 672 the same multicast address, one of type ALLOW_NEW_SOURCES and 673 one of type BLOCK_OLD_SOURCES. 675 We use the term "State-Change Record" to refer to either a Filter- 676 Mode-Change Record or a Source-List-Change Record. 678 Unrecognized Record Type values MUST be silently ignored. 680 4.2.13 IP Destination Addresses for Reports 682 Version 3 Reports are sent with an IP destination address of 683 224.0.0.22, to which all IGMPv3-capable multicast routers listen. 684 A system that is operating in version 1 or version 2 compatibility 685 modes sends version 1 or version 2 Reports to the multicast group 686 specified in the Group Address field of the Report. In addition, 687 a system MUST accept and process any version 1 or version 2 Report 688 whose IP Destination Address field contains *any* of the addresses 689 (unicast or multicast) assigned to the interface on which the Report 690 arrives. 692 4.2.14 Notation for Group Records 694 In the rest of this document, we use the following notation to 695 describe the contents of a Group Record pertaining to a particular 696 multicast address: 698 IS_IN ( x ) - Type MODE_IS_INCLUDE, source addresses x 699 IS_EX ( x ) - Type MODE_IS_EXCLUDE, source addresses x 700 TO_IN ( x ) - Type CHANGE_TO_INCLUDE_MODE, source addresses x 701 TO_EX ( x ) - Type CHANGE_TO_EXCLUDE_MODE, source addresses x 702 ALLOW ( x ) - Type ALLOW_NEW_SOURCES, source addresses x 703 BLOCK ( x ) - Type BLOCK_OLD_SOURCES, source addresses x 705 where x is either: 707 - a capital letter (e.g., "A") to represent the set of source 708 addresses, or 710 - a set expression (e.g., "A+B"), where "A+B" means the union 711 of sets A and B, "A*B" means the intersection of sets A and 712 B, and "A-B" means the removal of all elements of set B from 713 set A. 715 4.2.15 Membership Report Size 717 If the set of Group Records required in a Report does not fit within 718 the size limit of a single Report message (as determined by the MTU 719 of the network on which it will be sent), the Group Records are sent 720 in as many Report messages as needed to report the entire set. 722 If a single Group Record contains so many source addresses that it 723 does not fit within the size limit of a single Report message, it is 724 split into multiple Group Records, each containing a different subset 725 of the source addresses. 727 5. DESCRIPTION OF THE PROTOCOL FOR GROUP MEMBERS 729 IGMP is an asymmetric protocol, specifying separate behaviors for group 730 members -- that is, hosts or routers that wish to receive multicast 731 packets -- and multicast routers. This section describes the part 732 of IGMPv3 that applies to all group members. (Note that a multicast 733 router that is also a group member performs both parts of IGMPv3, 734 receiving and responding to its own IGMP message transmissions as well 735 as those of its neighbors. The multicast router part of IGMPv3 is 736 described in section 6.) 738 A system performs the protocol described in this section over all 739 interfaces on which multicast reception is supported, even if more than 740 one of those interfaces is connected to the same network. 742 For interoperability with multicast routers running older versions of 743 IGMP, systems maintain a MulticastRouterVersion variable for each 744 interface on which multicast reception is supported. This section 745 describes the behavior of group member systems on interfaces for which 746 MulticastRouterVersion = 3. The algorithm for determining 747 MulticastRouterVersion, and the behavior for versions other than 3, 748 are described in section 7. 750 The all-systems multicast address, 224.0.0.1, is handled as a special 751 case. On all systems -- that is all hosts and routers, including 752 multicast routers -- reception of packets destined to the all-systems 753 multicast address, from all sources, is permanently enabled on all 754 interfaces on which multicast reception is supported. No IGMP messages 755 are ever sent regarding the all-systems multicast address. 757 There are two types of events that trigger IGMPv3 protocol actions on 758 an interface: 760 o a change of the interface reception state, caused by a local 761 invocation of IPMulticastListen. 763 o reception of a Query. 765 (Received IGMP messages of types other than Query are silently ignored, 766 except as required for interoperation with earlier versions of IGMP.) 768 The following subsections describe the actions to be taken for each of 769 these two cases. In those descriptions, timer and counter names appear 770 in square brackets. The default values for those timers and counters 771 are specified in section 8. 773 5.1 Action on Change of Interface State 775 An invocation of IPMulticastListen may cause the multicast reception 776 state of an interface to change, according to the rules in section 3.2. 777 Each such change affects the per-interface entry for a single multicast 778 address. 780 A change of interface state causes the system to immediately transmit a 781 State-Change Report from that interface. The type and contents of the 782 Group Record(s) in that Report are determined by comparing the filter 783 mode and source list for the effected multicast address before and after 784 the change, according to the table below. If no interface state existed 785 for that multicast address before the change (i.e., the change consisted 786 of creating a new per-interface record), or if no state exists after the 787 change (i.e., the change consisted of deleting a per-interface record), 788 then the "non-existent" state is considered to have a filter mode of 789 INCLUDE and an empty source list. 791 Old State New State State-Change Record Sent 792 --------- --------- ------------------------ 794 INCLUDE (A) INCLUDE (B) ALLOW (B-A), BLOCK (A-B) 796 EXCLUDE (A) EXCLUDE (B) ALLOW (A-B), BLOCK (B-A) 798 INCLUDE (A) EXCLUDE (B) TO_EX (B) 800 EXCLUDE (A) INCLUDE (B) TO_IN (B) 802 If the computed source list for either an ALLOW or a BLOCK State-Change 803 Record is empty, that record is omitted from the Report message. 805 To cover the possibility of the State-Change Report being missed by one 806 or more multicast routers, it is retransmitted [Robustness Variable] - 1 807 more times, at intervals chosen at random from the range (0, 808 [Unsolicited Report Interval]]. 810 If more changes to the same interface state entry occur before all the 811 retransmissions of the State-Change Report for the first change have 812 been completed, each such additional change triggers the immediate 813 transmission of a State-Change Report reflecting the difference between 814 the newest state and the state *before* the first change for which 815 retransmissions were not completed. The transmission of the newer 816 State-Change Report terminates retransmissions of the earlier State- 817 Change Reports for the same multicast address, and becomes the first of 818 [Robustness Variable] transmissions of the newer Report. 820 5.2 Action on Reception of a Query 822 When a system receives a Query, it does not respond immediately. 823 Instead, it delays its response by a random amount of time, bounded by 824 the Max Resp Time value in the received Query message. A system may 825 receive a variety of Queries from different interfaces and of different 826 kinds (e.g., General Queries, Group-Specific Queries, and Group-and- 827 Source-Specific Queries), each of which may require its own delayed 828 response. Therefore, the system must be able to create and temporarily 829 store multiple "pending response records" of the following (conceptual) 830 form: 832 (timer, interface, group, sources) 833 where: 835 "timer" is an active timer, counting down the time remaining until 836 a response is sent. 838 "interface" is the interface from which the Query was received and 839 to which the response will be sent. 841 "group" is the multicast address for which the response is pending. 842 For a pending response to a General Query, this will be zero. 844 "sources" is the set of source addresses for which the response is 845 pending. For a pending response to a General Query or a Group- 846 Specific Query, this set will be empty. 848 When a new Query arrives from an interface, a new pending response 849 record is created as follows: 851 o the timer is initialized to a random value chosen, using the finest 852 clock granularity available in the system, from the range 853 (0, MaxResponseTime], where MaxResponseTime is obtained from the 854 Max Resp Time field of the received Query. 856 o the interface is set to that from which the Query arrived. 858 o the group value is obtained from the Group Address field of the 859 Query (which may be zero). 861 o the set of sources are taken from the Source Address [i] fields of 862 the Query (which may be the empty set). 864 Then, the new pending response record is compared with the existing 865 pending response records in the system. If the new record is superceded 866 by any existing record (as defined in the next paragraph), the new 867 record is discarded. Otherwise, if the new record supercedes any 868 existing records, those existing records are discarded. 870 A pending response record is said to supercede another if it pertains 871 to the same interface, has the same or shorter remaining timer, and 872 has the same or greater "coverage", where: 874 o a record whose group value is zero has the same or greater 875 coverage than any other record. 877 o a record whose set of sources is empty has the same or greater 878 coverage than any other record with the same group value. 880 o a record whose set of sources is non-empty has the same or greater 881 coverage than any other record with the same group value and a 882 set of sources that is the same as, or a non-empty subset of, the 883 first record's set. 885 When the timer in a pending response record expires, the system 886 transmits, on the interface identified in that record, one or more 887 Report messages carrying one or more Current-State Records (see 888 section 4.2.9(1)), as follows: 890 o If the group address in the pending response record is zero (i.e., 891 it is a pending response to a General Query), then one Current- 892 State Record is sent for each multicast address for which the 893 specified interface has reception state, as described in section 894 3.2. The Current-Report Record carries the multicast address 895 and its associated filter mode (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) 896 and source list. Multiple Current-State Records are packed into 897 individual Report messages, to the extent possible. 899 o If the group address in the pending response record is non-zero and 900 the set of sources in that record is empty (i.e., it is a pending 901 response to a Group-Specific Query), then if and only if the 902 interface has reception state for that group address, a single 903 Current-State Record is sent for that address. The Current-Report 904 Record carries the multicast address and its associated filter mode 905 (MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and source list. 907 o If the group address in the pending response record is non-zero and 908 the set of sources in that record is non-empty (i.e., it is a 909 pending response to a Group-and-Source-Specific Query), then if and 910 only if the interface has reception state for that group address, 911 the contents of the responding Current-State Record is determined 912 from the interface state and the pending response record, as 913 specified in the following table: 915 set of sources in the 916 interface state pending response record Current-State Record 917 --------------- ----------------------- -------------------- 919 INCLUDE (A) B IS_IN (A*B) 921 EXCLUDE (A) B IS_IN (B-A) 923 If the resulting Current-State Record has an empty set of source 924 addresses, then no response is sent. 926 Finally, after any required Report messages have ben generated, the 927 pending report record with the expired timer is discarded. 929 6. DESCRIPTION OF THE PROTOCOL FOR MULTICAST ROUTERS 931 The purpose of IGMP is to enable each multicast router to learn, for 932 each of its directly attached networks, which multicast addresses are 933 of interest to the systems attached to those networks. IGMP version 3 934 adds the capability for a multicast router to also learn which 935 *sources* are of interest to neighboring systems, for packets sent to 936 any particular multicast address. The information gathered by IGMP is 937 provided to whichever multicast routing protocol is being used by the 938 router, in order to ensure that multicast packets are delivered to all 939 networks where there are interested receivers. 941 This section describes the part of IGMPv3 that is performed by multicast 942 routers. Multicast routers may also themselves become members of 943 multicast groups, and therefore also perform the group member part of 944 IGMPv3, described in section 5. 946 A multicast router performs the protocol described in this section 947 over each of its directly-attached networks. If a multicast router has 948 more than one interface to the same network, it only needs to operate 949 this protocol over one of those interfaces. On each interface over 950 which this protocol is being run, the router MUST enable reception of 951 multicast address 224.0.0.22, from all sources (and MUST perform the 952 group member part of IGMPv3 for that address on that interface). 954 Multicast routers need to know only that *at least one* system on 955 an attached network is interested in packets to a particular multicast 956 address from a particular source; the multicast router does not need 957 to keep track of the interests of each individual neighboring system. 958 A router MAY track the interests of individual systems (at the expense 959 of additional state). If a router chooses to keep individual interest 960 information, it may omit Group-Specific and Group-and-Source-Specific 961 Queries from its implementation. A router MUST implement IGMPv2 962 Group-Specific queries for backwards compatibility. 964 IGMPv3 is backward compatible with previous versions of the IGMP 965 protocol. In order to remain backward compatible with older IGMP 966 systems, IGMPv3 multicast routers must also implement versions 1 and 2 967 of the protocol (see section 7). 969 6.1 Conditions for IGMP Queries 971 Multicast routers send General Queries periodically to request group 972 membership information from an attached network. These queries are 973 used to build and refresh the group membership state of systems on 974 attached networks. Systems respond to these queries by reporting 975 their group membership state (and their desired set of sources) with 976 Current-State Group Records in IGMPv3 Membership Reports. 978 As a member of a multicast group, a system may express interest in 979 receiving or not receiving traffic from particular sources. As the 980 desired reception state of a system changes, it sends send 981 Filter-Mode-Change Records or Source-List-Change Records. These records 982 indicate an explicit state change in a group at a system in either the 983 group record's source list or its filter-mode. When a group membership 984 is terminated at a system or traffic from a particular source is no longer 985 desired, a multicast router must query for other members of the group or 986 listeners of the source before deleting the group and pruning its 987 traffic. 989 To enable all systems on a network to respond to changes in 990 group membership, multicast routers send specific queries. A Group- 991 Specific Query is sent to verify there are no systems that desire 992 reception of the specified group or to "rebuild" the desired reception 993 state for a particular group. Group-Specific Queries are sent when a 994 system is leaving a group or when a multicast router desires to change 995 its filter-mode for the group (see section 6.5). 997 A Group-and-Source Specific Query is used to verify there are no 998 systems on a network which desire to receive a set of sources. 999 Group-and-Source Specific Queries list sources for a particular 1000 group which been requested to be no longer forwarded. This 1001 query is sent by a multicast router to learn if any systems desire 1002 reception of packets to the specified group address from the specified 1003 source addresses. Group-and-Source Specific Queries are only sent in 1004 response to State-Change Records and never in response to Current-State 1005 Records. Section 4.1.8 describes each query in more detail. 1007 6.2 IGMP State Maintained by Multicast Routers 1009 Multicast routers implementing IGMPv3 keep state per group per attached 1010 network. This group state consists of a filter-mode, a list of sources, 1011 and various timers. For each attached network running IGMP, a multicast 1012 router records the desired reception state for that network. That state 1013 conceptually consists of a set of records of the form: 1015 (multicast address, group timer, filter-mode, (source records) ) 1017 Each source record is of the form: 1019 (source address, source timer) 1021 If all sources within a given group are desired, an empty source 1022 record list is kept with filter-mode set to EXCLUDE. This 1023 means forward all sources for this group. This is the IGMPv3 equivalent 1024 to a IGMPv1 or IGMPv2 group join. 1026 6.2.1 Definition of Router Filter-Mode 1028 To reduce internal state, IGMPv3 routers keep a filter-mode per group 1029 per attached network. This filter-mode is used to condense the total 1030 desired reception state of a group to a minimum set such that all 1031 systems' memberships are satisfied. This filter-mode may change in 1032 response to the reception of particular types of group records or when 1033 certain timer conditions occur. In the following sections, we use 1034 the term "router filter-mode" to refer to the filter-mode of a 1035 particular group within a router. 1037 Conceptually, when a group record is received, the router filter-mode 1038 for that group is updated to represent the most number of sources 1039 desired with the least amount of state. As a rule, once a group 1040 record with a filter-mode of EXCLUDE is received, the router 1041 filter-mode for that group will be EXCLUDE. When a router filter-mode 1042 for a group is INCLUDE, the source record list is the list of sources 1043 desired for the group. 1045 When a router filter-mode for a group is EXCLUDE, the source record 1046 list contains two types of sources. The first type is the 1047 set of sources which are not being forwarded (i.e. the set that all 1048 systems have agreed NOT to forward). The second set is the set where 1049 there are conflicts in the desired reception state; this set must 1050 be forwarded. Appendix A describes the reasons for keeping this second 1051 set when in EXCLUDE mode. Section 6.4 describes the changes of a 1052 router filter-mode per group record received. 1054 Because a reported group record with a filter-mode of EXCLUDE will 1055 cause a router to transition its filter-mode for that group to EXCLUDE, 1056 a mechanism for transitioning a router's filter-mode back to INCLUDE 1057 must exist. If all systems with a group record with filter-mode EXCLUDE 1058 mode cease reporting, it is desirable for the router filter-mode for 1059 that group to transition back to INCLUDE mode (which will likely cause 1060 fewer sources to be forwarded). This transition occurs when the group 1061 timer expires and is explained in detail in section 6.5. 1063 6.2.2 Definition of Group Timers 1065 Group timers represent the time for the *filter-mode* of the group 1066 to expire. We define a group timer as a decrementing timer with a 1067 lower bound of zero kept per group per attached network. Group timers 1068 are updated according to the types of group records received. 1070 When a Current-State Record is received with a filter-mode matching the 1071 router filter-mode for that group, the group timer is updated. Group 1072 timers are also updated when the router filter-mode for a group is 1073 changed and when certain State-Change Records are received. 1075 A group timer expiring when a router filter-mode for the group is 1076 INCLUDE means there are no listeners in INCLUDE filter-mode present 1077 on the attached network for that group. In IGMPv3, this is the 1078 indication that there are no longer any listeners to the group and 1079 the group record may be deleted. 1081 A group timer expiring when a router filter-mode for the group is 1082 EXCLUDE means there are no listeners on the attached network in 1083 EXCLUDE mode. However, there may still be listeners with filter-mode 1084 of INCLUDE for the group. When a group timer reaches Filter-Mode 1085 Query Interval with the router filter-mode for the group equal to 1086 EXCLUDE, a Group-Specific Query is sent for the group. This is to 1087 check if there are systems in INCLUDE filter-mode on the network. 1088 Section 6.5 details the actions taken when a group timer expires while 1089 in EXCLUDE mode. 1091 The following table summarizes the role of the group timer. Section 1092 6.4 describes the details of setting the group timer per type of group 1093 record received. 1095 Group 1096 Filter-Mode Group Timer Value Actions/Comments 1097 ----------- ------------------ ---------------- 1099 INCLUDE Timer > 0 All members in INCLUDE 1100 mode. 1102 INCLUDE Timer == 0 No more listeners to 1103 group. Delete Group 1104 Record. 1106 EXCLUDE Timer > 0 At least one member in 1107 EXCLUDE mode. 1109 EXCLUDE Timer == Filter-Mode Query group (there may 1110 Query Interval still be systems in 1111 INCLUDE mode). 1113 EXCLUDE Timer == 0 No more listeners to 1114 group. If all source 1115 timers have expired then 1116 delete Group Record. 1117 If there are still 1118 source record timers 1119 running, switch to 1120 INCLUDE filter-mode 1121 using those source records 1122 with running timers as the 1123 INCLUDE source record 1124 state. 1126 6.2.3 Definition of Source Timers 1128 A source timer is kept per source record and is a decrementing timer 1129 with a lower bound of zero. Source timers are updated according to the 1130 type and filter-mode of the group record received. Source timers are 1131 always updated (for a particular group) whenever the source is present 1132 in a received record for that group. Section 6.4 details the setting 1133 the source timers per type of group records received. 1135 A source record with a running timer with a router filter-mode for 1136 the group of INCLUDE means that there is currently one or more systems 1137 (in INCLUDE filter-mode) which desire to receive that source. If a 1138 source timer expires with a router filter-mode for the group of 1139 INCLUDE, the router concludes that traffic from this particular source 1140 is no longer desired on the attached network, and deletes the 1141 associated source record. 1143 Source timers are treated differently when a router filter-mode for 1144 a group is EXCLUDE. If a source record has a running timer with a 1145 router filter-mode for the group of EXCLUDE, it means that a "conflict" 1146 has occurred with respect to desired reception state of that source (i.e. 1147 one system desires the source and another one doesn't). Therefore, when a 1148 source record has a running timer with a router filter-mode for the group 1149 of EXCLUDE it should be forwarded. Appendix A details the reasons 1150 for keeping sources that are being forwarded while in EXCLUDE state. 1152 If a source timer expires with a router filter-mode for the group 1153 of EXCLUDE, the router stops forwarding traffic from this source onto 1154 the network (and takes appropriate actions dependent on the multicast 1155 routing protocol). 1157 When a router filter-mode for a group is EXCLUDE, source records are 1158 only deleted when the group timer expires. Section 6.3 details the 1159 actions that should be taken dependant upon the value of a source 1160 timer. 1162 6.3 IGMPv3 Source-Specific Forwarding Rules 1164 When a multicast router receives a datagram from a source destined to a 1165 particular group, a decision has to be made whether to forward the 1166 datagram onto an attached network or not. This decision is first 1167 dependent on any multicast routing protocols present. Assuming that 1168 there are no other routers downstream (or that downstream routers 1169 support source-specific pruning/grafting), the forwarding decision 1170 depends on the presence of a group record and/or a source record. If 1171 no group record exists, the datagram is not forwarded on the network. 1172 If a source record exists which matches the datagrams source address, 1173 the source is forwarded according to the router filter-mode for the 1174 group and the value of the source timer of the source record. 1176 To summarize, the following table details the forwarding actions 1177 for traffic originating from a source destined to a group. It also 1178 summarizes the actions taken upon the expiration of a source timer 1179 based on the router filter-mode of the group. 1181 Group 1182 Filter-Mode Source Timer Value Action 1183 ----------- ------------------ ------ 1185 INCLUDE TIMER > 0 Forward traffic from 1186 source 1188 INCLUDE TIMER == 0 Stop forwarding traffic 1189 from source and remove 1190 source record 1192 INCLUDE No Source Elements Don't forward source 1194 EXCLUDE TIMER > 0 Forward traffic from 1195 source 1197 EXCLUDE TIMER == 0 Don't forward traffic 1198 from source 1199 (DO NOT remove record) 1201 EXCLUDE No Source Elements Forward traffic from 1202 source 1204 6.4 Action on Reception of Reports 1206 6.4.1 Reception of Current-State Records 1208 When receiving Current-State Records, a router updates both its group 1209 and source timers. In some circumstances, the reception of a type of 1210 group record will cause the router filter-mode for that group to 1211 change. The table below describes the actions, with respect to state 1212 and timers that occur to a router's state upon reception of 1213 Current-State Records. 1215 The following notation is used to describe the updating of source 1216 timers. The notation ( A, B ) will be used to represent the total 1217 number of sources for a particular group, where 1219 A = set of source records whose source timers > 0 (being forwarded) 1220 B = set of source records whose source timers = 0 (not being forwarded) 1222 Note that there will only be two sets when a router's filter-mode 1223 for a group is EXCLUDE. When a router's filter-mode for a group 1224 is INCLUDE, a single set is used to describe the set of sources 1225 being forwarded (e.g. simply ( A ) ). 1227 In the following tables, abbreviations are used for several variables 1228 (all of which are described in detail in section 8). The variable GMI 1229 is an abbreviation for the Group Membership Interval which is the time 1230 in which group memberships will time out. The variable LMQI is an 1231 abbreviation for the Last Member Query Interval (default 1s) which is 1232 the Maximum Response Time in Group or Group and Source Specific Queries. 1234 Within the "Actions" section of the router state tables, we use the 1235 notation 'A=J', which means that the set A of source records should 1236 have their source timers set to value J. 'Delete A' means that the set A 1237 of source records should be deleted. 'Group Timer=J' means that the 1238 Group Timer for the group should be set to value J. 1240 Router State Report Rec'd New Router State Actions 1241 ------------ ------------ ---------------- ------- 1243 INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B)=GMI 1244 Group Timer=GMI 1246 INCLUDE (A) IS_EX (B) EXCLUDE (A*B,B-A) (B-A)=0 1247 Delete (A-B) 1248 Group Timer=GMI 1250 EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+A,Y-A) (A)=GMI 1252 EXCLUDE (X,Y) IS_EX (B) EXCLUDE (X+(B-Y),Y*B) Group Timer=GMI 1253 (B-Y)=GMI 1254 Delete (Y-B) 1256 6.4.2 Reception of Filter-Mode-Change and Source-List-Change Records 1258 When a change in the global state of a group occurs in a system, the system 1259 sends either a Source-List-Change Record or a Filter-Mode-Change Record 1260 for that group. As with Current-State Records, routers must act upon 1261 these records and possibly change their own state to reflect the new 1262 desired membership state of the network. 1264 Routers must query sources that are requested to be no longer forwarded 1265 to a group. When a router queries a specific set of sources, it sets its 1266 source timers for those source to a small interval of Last Member Query 1267 Interval seconds. If group records are received which express interest 1268 in receiving traffic from the queried sources, the corresponding timers are 1269 updated. Similarly, when a router queries a specific group, it sets its 1270 group timer for that group to a small interval of Last Member Query 1271 Interval seconds. If any group records expressing interest in the group 1272 are received within the interval, the group timer for the group is updated 1273 and traffic is forwarded without any interruption. 1275 During a query period (i.e. Last Member Query Interval seconds), a 1276 router continues to forward traffic from the groups or sources that it 1277 is querying. It is not until after Last Member Query Interval seconds 1278 without receiving a record expressing interest in the queried group or 1279 sources that the router may prune the group or sources from the setwork. 1281 The following table describes the changes in group state and the action(s) 1282 taken when receiving either Filter-Mode-Change or Source-List-Change 1283 Records. We use the notation 'Q(G)' to describe a Group-Specific query 1284 to group G. We use the notation 'Q(G,A)' to describe a Group-and-Source 1285 Specific Query to G with source-list A. 1287 Router State Report Rec'd New Router State Actions 1288 ------------ ------------ ---------------- ------- 1290 INCLUDE (A) ALLOW (B) INCLUDE (A+B) (B)=GMI 1291 Group Timer=GMI 1293 INCLUDE (A) BLOCK (B) INCLUDE (A) (A*B)=LMQI 1294 Send Q(G,A*B) 1296 INCLUDE (A) ALLOW (B), INCLUDE (A+B) (B)=GMI 1297 BLOCK (C) (A*C)=LMQI 1298 Send Q(G,A*C) 1299 Group Timer=GMI 1301 INCLUDE (A) TO_EX (B) EXCLUDE (A*B,B-A) (A*B)=LMQI 1302 (B-A)=0 1303 Delete (A-B) 1304 Send Q(G,A*B) 1305 Group Timer=GMI 1307 INCLUDE (A) TO_IN (B) INCLUDE (A+B) (B)=GMI 1308 Group Timer=GMI 1310 EXCLUDE (X,Y) ALLOW (A) EXCLUDE (X+A,Y-A) (A)=GMI 1312 EXCLUDE (X,Y) BLOCK (A) EXCLUDE (X+(A-Y),Y) (A-Y)=LMQI 1313 Send Q(G,A-Y) 1315 EXCLUDE (X,Y) ALLOW (A), EXCLUDE (X+A+(B-Y),Y-A) (A)=GMI 1316 BLOCK (B) (B-Y)=LMQI 1317 Send Q(G,B-Y) 1319 EXCLUDE (X,Y) TO_EX (A) EXCLUDE (X+(A-Y),Y*A) (A-Y)=LMQI 1320 Send Q(G,A-Y) 1321 Group Timer=GMI 1322 Delete (Y-A) 1324 EXCLUDE (X,Y) TO_IN (A) EXCLUDE (X+A,Y-A) (A)=GMI 1325 (X-A)=LMQI 1326 Send Q(G) 1327 Group Timer=LMQI 1329 6.5 Switching Filter-Modes 1331 The group timer is used as a mechanism for transitioning the router 1332 filter-mode from EXCLUDE to INCLUDE. When a group timer expires 1333 with a router filter-mode of INCLUDE, a router concludes that there 1334 are no group members present on the attached network and 1335 deletes the group record and the associated source records. 1337 When a router's filter-mode for a group is EXCLUDE and the group 1338 timer expires, a query must be sent to ensure that there are no 1339 remaining systems with filter-mode of EXCLUDE. When the group timer 1340 reaches Filter-Mode Query Interval with a router filter-mode of 1341 EXCLUDE for the group, a Group-Specific Query is sent for that 1342 group. If there are systems with filter-mode of INCLUDE for the 1343 queried group, they will report their INCLUDE state (with 1344 Current-State Records), causing source timers for that group to be 1345 set/reset and therefore the sources to be forwarded. 1347 When a group timer expires with a router filter-mode of EXCLUDE, a 1348 router assumes that there are no systems with *filter-mode of EXCLUDE* 1349 present on the attached network. If there are any source records 1350 with source timers greater than zero, a router switches to filter-mode 1351 of INCLUDE using those source records with timers greater than zero (the 1352 Group-Specific Query sent at Filter-Mode Query Interval seconds would 1353 have caused these to be set). Source records whose timers are zero 1354 (from the previous EXCLUDE mode) are deleted. When the router switches 1355 its filter-mode for a group to INCLUDE, the group timer is reset to 1356 the maximum value of the source timers of that group. 1358 6.6 Action on Reception of Queries 1360 IGMPv3 uses the same querier election method as previous versions. Upon 1361 receiving an IGMPv3 General Query from another router, the querier 1362 ceases to send General Queries and sets the OTHER_QUERIER_PRESENT timer. 1363 Upon expiration of OTHER_QUERIER_PRESENT timer, a router becomes the 1364 querier. Routers who are not the acting querier reset 1365 OTHER_QUERIER_PRESENT timer upon reception of a IGMPv3 General Query. 1366 For details of compatibility between IGMP versions see section 7. 1368 7. INTEROPERATION WITH OLDER VERSIONS OF IGMP 1370 IGMP version 3 hosts and routers interoperate with hosts and routers 1371 that have not yet been upgraded to IGMPv3. This compatibility is 1372 maintained by hosts and routers taking appropriate actions depending on 1373 the versions of IGMP operating on hosts and routers within a network. 1375 7.1 Query Version Distinctions 1377 The IGMP version of a Membership Query message is determined as 1378 follows: 1380 IGMPv1 Query: length = 8 octets AND Max Response Time field is zero 1382 IGMPv2 Query: length = 8 octets AND Max Response Time field is 1383 non-zero 1385 IGMPv3 Query: length >= 12 octets AND Reserved field is zero 1387 Query messages that do not match any of the above conditions (e.g., a 1388 Query of length 10 octets) must be silently ignored. 1390 7.2 Group Member Behavior 1392 IGMPv3 hosts can operate in version 1 and version 2 compatibility modes. 1393 The mode in which a host operates is governed by the version of the 1394 querier router on a network. The version of the querier can be 1395 determined from a Membership Query. 1397 IGMPv3 hosts keep state per local interface regarding the version of 1398 querier on the attached network. Hosts can be in one of three states 1399 depending on the version of querier on their attached networks. This 1400 state is reflected by Querier Version, a state variable kept per 1401 interface describing the version of querier on the attached network. 1402 This state variable can have only one of three values: IGMPv3, IGMPv2, 1403 IGMPv1. When Querier Version is IGMPv3, a host acts using the IGMPv3 1404 protocol. When Querier Version is IGMPv2, a host acts in IGMPv2 1405 compatibility mode, using only the IGMPv2 protocol. When Querier 1406 Version is IGMPv1, a host acts in IGMPv1 compatibility mode, using the 1407 IGMPv1 protocol. 1409 If a lower version query (as compared to Querier Version) is received on 1410 an interface, this state will change immediately to reflect the older 1411 version querier and the host will operate in that lower version 1412 compatibility mode. However, if a higher version query (as compared to 1413 Querier Version) is received, it will not immediately change it's state. 1414 This is to prevent the problem when newer version queries are sent by a 1415 router restarting and having not yet yielded to an older version 1416 querier. 1418 Each time a non-version 3 query is received, a host sets a timer: Older 1419 Version Querier Present Timeout. The state variable, Querier Version, 1420 reflecting the version of querier on an interface will be based on this 1421 timer. If a host hears a newer version query (as compared to Querier 1422 Version), it will not change its operating state until after the timer 1423 expires. 1425 7.2.1 In the Presence of Older Version Queriers 1427 An IGMPv3 host may be placed on a network where the Querier router has 1428 not yet been upgraded to IGMPv3. The following requirements apply: 1430 An older version router expects older version Membership Reports in 1431 response to its Queries, and will not understand Version 3 1432 Membership Reports. Therefore, a state variable MUST be kept for 1433 each interface, describing whether the multicast Querier on that 1434 interface is running IGMPv1, IGMPv2, or IGMPv3. This variable 1435 MUST be based upon whether or not the older version query was 1436 heard in the last [Older Version Querier Present Timeout] seconds, 1437 and MUST NOT be based upon the type of the last Query heard. This 1438 state variable MUST be used to decide what type of Membership 1439 Reports to send for unsolicited Membership Reports as well as 1440 Membership Reports in response to Queries. 1442 Version 1 Querier 1444 An IGMPv1 router will send General Queries with the Max Response 1445 Time set to 0. This MUST be interpreted as a value of 100 (10 1446 seconds). 1448 IGMPv3 hosts must send IGMPv1 Membership reports when an IGMPv1 1449 router is present. This is IGMPv1 compatibility mode. 1451 Version 2 Querier 1453 IGMPv3 hosts must send IGMPv2 Membership reports when an IGMPv2 1454 router is present. IGMPv3 hosts must use IGMPv2 Leave Group 1455 messages when an IGMPv2 router is present. This is IGMPv2 1456 compability mode. 1458 The following table summarizes an IGMPv3 host response to different 1459 types of queries: 1461 Querier 1462 Version Query Type Host Response 1463 ------- ---------- ------------- 1464 IGMPv1 Membership Query IGMPv1 Membership Report 1465 IGMPv2 Membership Query IGMPv2 Membership Report 1466 IGMPv2 Group-Specific Query IGMPv2 Membership Report 1467 IGMPv3 Membership Query IGMPv3 Membership Report 1468 IGMPv3 Group-Specific Query IGMPv3 Membership Report 1469 IGMPv3 Group-and-Source-Specific Query IGMPv3 Membership Report 1471 7.2.2 In the Presence of Older Version Group Members 1473 An IGMPv3 host may be placed on a network where there are hosts that 1474 have not yet been upgraded to IGMPv3. A host MAY allow its IGMPv3 1475 Membership Report to be suppressed by either a Version 1 Membership 1476 Report, or a Version 2 Membership Report. 1478 If a host is a member of any sources within a group reported in a V1 or 1479 V2 membership report, then it may suppress its report by marking the 1480 group so that it is not reported when the next IGMPv3 report is sent. 1482 7.2.3 Group Member Compatibility State Transition Diagram 1484 RQ3 1485 ----------- 1486 | | 1487 | V 1488 RQ1/ST ------------------- RQ2/ST 1489 ---------------| |---------------- 1490 | | V3 Mode | | 1491 | ------->| |<------- | 1492 | | ------------------- | | 1493 | | | | 1494 | |TE/DT TE/DT| | 1495 | | | | 1496 V | | V 1497 ------------------- ------------------ 1498 ----| | | |---- 1499 RQ3| | V1 Mode |<-------------------| V2 Mode | |RQ3 1500 --->| | RQ1/RT | |<--- 1501 ------------------- ------------------ 1502 | ^ | ^ | ^ 1503 | | | | | | 1504 ------ ------ ----------- 1505 RQ1/RT RQ2 RQ2/RT 1507 Actions 1508 ------- 1509 ST : start Older Version Querier Present Timer 1510 DT : delete Older Version Querier Present Timer 1511 TE : Older Version Querier Present Timer expires 1512 RT : reset Older Version Querier Present Timer 1514 Events 1515 ------ 1516 RQ1 : Receive IGMPv1 Membership Query 1517 RQ2 : Receive IGMPv2 Membership Query 1518 RQ3 : Receive IGMPv3 Membership Query 1520 States 1521 ------ 1522 V3 Mode : An IGMPv3 router is the present querier on an interface. 1523 The host uses IGMPv3 Membership Reports 1525 V2 Mode : An IGMPv2 router is the present querier on an interface. 1526 The host uses IGMPv2 Membership Reports and IGMPv2 Leave 1527 Group messages. 1529 V1 Mode : An IGMPv1 router is the present querier on an interface. 1530 The host uses IGMPv1 Membership Reports. 1532 7.3 Multicast Router Behavior 1534 7.3.1 In the Presence of Older Version Queriers 1536 IGMPv3 routers may be placed on a network where at least one router on 1537 the network has not not yet been upgraded to IGMPv3. The following 1538 requirements apply: 1540 If any older versions of IGMP are present on routers, the querier 1541 MUST use the lowest version of IGMP present on the network. 1542 This must be administratively assured; routers that desire to be 1543 compatible with IGMPv1 and IGMPv2 MUST have a configuration option 1544 to send IGMPv1 and IGMPv2 queries. When in IGMPv1 mode, routers 1545 MUST send Periodic Queries with a Max Response Time of 0, and MUST 1546 ignore Leave Group messages. They SHOULD also warn about 1547 receiving an IGMPv2 or IGMPv3 query, although such warnings MUST 1548 be rate-limited. 1550 If a router is not explicitly configured to use IGMPv1 and hears 1551 an IGMPv1 Query or IGMPv2 Query, it SHOULD log a warning. These 1552 warnings MUST be rate-limited. 1554 7.3.2 In the Presence of Older Version Group Members 1556 IGMPv3 routers may be placed on a network where there are hosts that 1557 have not yet been upgraded to IGMPv3. The following requirements apply: 1559 IGMPv3 routers MUST keep state per group being forwarded per 1560 interface regarding the lowest version of IGMP heard. For each 1561 group being forwarded per interface, the state variable Oldest 1562 Host Present is kept. Groups can be in one of three states 1563 reflected by the state variable: Oldest Host Present. 1565 Routers MUST act in a compatibility mode on a per group per 1566 interface. The following table summarizes the types of messages 1567 to be used dependent on the value of Oldest Host Present. 1569 Oldest Host Present Messages Utilized 1570 ------------------- ----------------- 1571 IGMPv1 Version 1 Membership Queries 1572 IGMPv2 Version 2 Membership Queries, 1573 Version 2 Group-Specific 1574 Membership Queries 1575 IGMPv3 Version 3 General Membership Queries, 1576 Version 3 Group-Specific Membership 1577 Queries, 1578 Version 3 Group-and-Source Specific 1579 Membership Queries 1581 A router MUST keep a timer per group, Older Host Present Timeout, 1582 if it hears an non-version 3 report for a group. This SHOULD be 1583 set to the value of two query periods. If a router does not hear 1584 a lower version report for the length of two query periods, it 1585 assumes that the older version members have left and reverts to 1586 version 3 operation for that group. 1588 7.3.3 Router Compatibility State Transition Diagram* 1590 RV3MR 1591 ----------- 1592 | | 1593 | V 1594 RV1MR/ST ------------------- RV2MR/ST 1595 -------------| |------------ 1596 | | V3 Mode | | 1597 | ------->| |<------- | 1598 | | ------------------- | | 1599 | | | | 1600 | |TE/DT TE/DT| | 1601 | | | | 1602 V | | V 1603 ----------------- ------------- 1604 ----| | | |--- 1605 RV3MR| | V1 Mode |<-------------------| V2 Mode | |RV3MR 1606 --->| | RV1MR/RT | |<-- 1607 ----------------- ------------- 1608 | ^ | ^ | ^ 1609 | | | | | | 1610 ------ ------ ------- 1611 RV1MR/RT RV2MR RV2MR/RT 1613 * with respect to a single multicast group 1615 Actions 1616 ------- 1617 ST : start Older Host Present Timer 1618 DT : delete Older Host Present Timer 1619 TE : Older Host Present Timer expires 1620 RT : reset Older Host Present Timer 1622 Events 1623 ------ 1624 RV1MR : Receive Version 1 Membership Report 1625 RV2MR : Receive Version 2 Membership Report 1626 RV3MR : Receive Version 3 Membership Report 1627 States 1628 ------ 1629 V3 Mode : A router operates using only IGMPv3 messages for this group. 1631 V2 Mode : An IGMPv2 Membership Report has been heard for this group 1632 within the last Older Host Present Timeout seconds. A 1633 router operates using only IGMPv2 messages for this group. 1635 V1 Mode : An IGMPv1 Membership Report has been heard for this group 1636 within the last Older Host Present Timeout seconds. A 1637 router operates using only IGMPv1 messages for this group. 1639 Note: In V1 Mode and V2 Mode, the Membership Query is still a 1640 version 3 query. 1642 8. LIST OF TIMERS, COUNTERS, AND THEIR DEFAULT VALUES 1644 Most of these timers are configurable. If non-default settings are 1645 used, they MUST be consistent among all systems on a single link. Note 1646 that parentheses are used to group expressions to make the algebra 1647 clear. 1649 8.1 Robustness Variable 1651 The Robustness Variable allows tuning for the expected packet loss on a 1652 network. If a network is expected to be lossy, the Robustness Variable 1653 may be increased. IGMP is robust to (Robustness Variable - 1) packet 1654 losses. The Robustness Variable MUST NOT be zero, and SHOULD NOT be 1655 one. Default: 2 1657 8.2 Query Interval 1659 The Query Interval is the interval between General Queries sent by the 1660 Querier. Default: 125 seconds. 1662 By varying the [Query Interval], an administrator may tune the number 1663 of IGMP messages on the network; larger values cause IGMP Queries to be 1664 sent less often. 1666 8.3 Query Response Interval 1668 The Max Response Time inserted into the periodic General Queries. 1669 Default: 100 (10 seconds) 1671 By varying the [Query Response Interval], an administrator may tune the 1672 burstiness of IGMP messages on the network; larger values make the 1673 traffic lest bursty, as host responses are spread out over a larger 1674 interval. The number of seconds represented by the [Query Response 1675 Interval] must me less than the [Query Interval]. 1677 8.4 Group Membership Interval 1679 The Group Membership Interval is the amount of time that must pass 1680 before a multicast router decides there are no more members of a group 1681 or a particular source on a network. 1683 This value MUST be ((the Robustness Variable) times (the Query Interval)) 1684 plus (one Query Response Interval). 1686 8.5 Other Querier Present Interval 1688 The Other Querier Present Interval is the length of time that must pass 1689 before a multicast router decides that there is no longer another 1690 multicast router which should be the querier. This value MUST be ((the 1691 Robustness Variable) times (the Query Interval)) plus (one half of one 1692 Query Response Interval). 1694 8.6 Startup Query Interval 1696 The Startup Query Interval is the interval between General Queries sent 1697 by a Querier on startup. Default: 1/4 the Query Interval. 1699 8.7 Startup Query Count 1701 The Startup Query Count is the number of Queries sent out on startup, 1702 separated by the Startup Query Interval. Default: the Robustness 1703 Variable. 1705 8.8 Last Member Query Interval 1707 The Last Member Query Interval is the Max Response Time inserted into 1708 Group-Specific Queries sent in response to Leave Group messages. It is 1709 also the Max Response Time inserted into Group-and-Source-Specific Query 1710 messages. Default: 10 (1 second) 1712 This value may be tuned to modify the "leave latency" of the network. A 1713 reduced value results in reduced time to detect the loss of the last 1714 member of a group or source. 1716 8.9 Last Member Query Count 1718 The Last Member Query Count is the number of Group-Specific Queries sent 1719 before the router assumes there are no local members. The Last Member 1720 Query Count is also the number of Group-and-Source-Specific Queries sent 1721 before the router assume there are no listeners to particular source. 1722 Default: the Robustness Variable. 1724 8.10 Unsolicited Report Interval 1726 The Unsolicited Report Interval is the time between repetitions of a 1727 host's initial report of membership in a group. Default: 10 seconds. 1729 8.11 Filter-Mode Query Interval 1731 When a router group timer for a group with a filter-mode of EXCLUDE 1732 reaches Filter-Mode Query Interval, a Group-Specific Query is sent 1733 (see section 6.5). The Group-Specific Query must have its Max 1734 Response Time set to Filter-Mode Query Interval. Default: 5 seconds. 1736 8.12 Older Version Querier Interval 1738 The Older Version Querier Interval is the time-out for transitioning a 1739 host back to IGMPv3 mode once an older version query is heard. When an 1740 older version query is received, hosts set their Older Version Querier 1741 Present Timer to Older Version Querier Interval. 1743 This value MUST be ((the Robustness Variable) times (the Query Interval)) 1744 plus (one Query Response Interval). 1746 8.13 Older Host Present Interval 1748 The Older Host Present Interval is the time-out for transitioning a 1749 group back to IGMPv3 mode once an older version report is sent for 1750 that group. When an older version report is received, routers set 1751 their Older Host Present Timer to Older Host Present Interval. 1753 This value MUST be ((the Robustness Variable) times (the Query Interval)) 1754 plus (one Query Response Interval). 1756 9. SECURITY CONSIDERATIONS 1758 We consider the ramifications of a forged message of each type. 1760 Query Message: 1762 A forged Query message from a machine with a lower IP address than 1763 the current Querier will cause Querier duties to be assigned to the 1764 forger. If the forger then sends no more Query messages, other 1765 routers' Other Querier Present timer will time out and one will 1766 resume the role of Querier. During this time, if the forger 1767 ignores Leave Messages, traffic might flow to groups with no 1768 members for up to [Group Membership Interval]. 1770 Report messages: 1772 A forged Report message may cause multicast routers to think there 1773 are members of a group on a network when there are not. Forged 1774 Report messages from the local network are meaningless, since 1775 joining a group on a host is generally an unprivileged operation, 1776 so a local user may trivially gain the same result without forging 1777 any messages. Forged Report messages from external sources are 1778 more troublesome; there are two defenses against externally forged 1779 Reports: 1781 - Ignore the Report if you cannot identify the source address of 1782 the packet as belonging to a network assigned to the interface on 1783 which the packet was received. This solution means that Reports 1784 sent by mobile hosts without addresses on the local network will 1785 be ignored. 1786 - Ignore Report messages without Router Alert options [RFC-2113], 1787 and require that routers not forward Report messages. (The 1788 requirement is not a requirement of generalized filtering in the 1789 forwarding path, since the packets already have Router Alert 1790 options in them). This solution breaks backwards compatibility 1791 with implementations of earlier versions of this specification 1792 which did not require Router Alert. 1794 A forged Version 1 Report Message may put a router into "version 1 1795 members present" state for a particular group, meaning that the 1796 router will ignore Leave messages. This can cause traffic to flow 1797 to groups with no members for up to [Group Membership Interval]. 1798 This can be solved by providing routers with a configuration switch 1799 to ignore Version 1 messages completely. This breaks automatic 1800 compatibility with Version 1 hosts, so should only be used in 1801 situations where "fast leave" is critical. 1803 10. ACKNOWLEDGMENTS 1805 Some of the text of this document was copied from [RFC-1112] and 1806 [RFC-2236]. 1808 11. REFERENCES 1810 [RFC-1112] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 1811 August 1989. 1813 [RFC-2113] Katz, D., "IP Router Alert Option," RFC 2113, April 1996. 1815 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 1816 Requirement Levels", RFC 2119, BCP14, March 1997. 1818 [RFC-2236] Fenner, W., "Internet Group Management Protocol, Version 2", 1819 RFC 2236, November 1997. 1821 APPENDIX A. DESIGN RATIONALE 1823 A.1 The Need for State-Change Messages 1825 IGMPv3 specifies two types of Membership Reports: Current-State 1826 and State Change. This section describes the rationale for the 1827 need for both these types of Reports. 1829 Routers need to distinguish Membership Reports that were sent in 1830 response to Queries from those that were sent as a result of a change 1831 in interface state. Membership reports that are sent in response to 1832 Membership Queries are used mainly to refresh the existing state at 1833 the router; they typically do not cause transitions in state at the 1834 router. Membership Reports that are sent in response to changes in 1835 interface state require the router to take some action in response to 1836 the received report (see Section 6.4). 1838 The inability to distinguish between the two types of reports would 1839 force a router to treat all Membership Reports as potential changes in 1840 state and could result in increased processing at the router as well 1841 as an increase in IGMP traffic on the network. 1843 A.2 API Rationale 1845 The IGMPv3 API specifies only full-state requests for source 1846 and filter-mode state. This section discusses the advantages in 1847 using full-state API requests in comparison to an alternative design 1848 using state-change API requests for the IGMPv3 API. 1850 A "full-state" API operation specifies the complete reception state 1851 of the application program, whereas a "state-change" API operation 1852 specifies only the change in filter-mode or the incremental change 1853 in source lists from the last reported state. 1855 The following points summarize the differences in these APIs: 1857 1. State-change API requests require additional filter-modes to 1858 describe whether sources are being added or deleted or whether 1859 the filter-mode is being changed. 1861 2. State-change API requests require the IP layer to compute the 1862 full state at the socket before computing the per-interface state. 1864 3. Applications that use state-change API requests may have to 1865 determine the IP source addresses to be added or deleted from 1866 the full state. This leads to unnecessary computation at both 1867 the application and the IP layers. 1869 4. API requests for adding and deleting sources at the same time may 1870 have to be split across multiple requests and this could lead to 1871 multiple messages being sent which could cause confusion at the 1872 router (unless there is some mechanism to indicate that the 1873 messages are somehow linked) 1875 A.3 Host Suppression 1877 In IGMPv1 and IGMPv2, a host would cancel sending a pending membership 1878 reports if a similar report was observed from another member on the 1879 network. In IGMPv3, this suppression of host membership reports 1880 has been removed. The following points explain the reasons behind 1881 this decision. 1883 1. Routers may want to track per-host membership status on an 1884 interface This allows routers to implement fast leaves (e.g. 1885 for layered multicast congestion control schemes) as well as 1886 track membership status for possible accounting purposes. 1888 2. Membership Report suppression does not work well on bridged 1889 LANs. Many bridges and Layer2/Layer3 switches that implement IGMP 1890 snooping do not forward IGMP messages across LAN segments in 1891 order to prevent membership report suppression. Removing 1892 membership report suppression eases the job of these IGMP snooping 1893 devices. 1895 3. By eliminating membership report suppression, hosts have 1896 fewer messages to process; this leads to a simpler state machine 1897 implementation. 1899 4. In IGMPv3, a single membership report now bundles multiple 1900 multicast group records to decrease the number of packets sent. 1901 In comparison, the previous versions of IGMP required that each 1902 multicast group be reported in a separate message. 1904 A.4 Switching router filter modes from EXCLUDE to INCLUDE 1906 If there exist hosts in both EXCLUDE and INCLUDE modes for a 1907 single multicast group in a network, the router must be in 1908 EXCLUDE mode as well (see section 6.2.1). In EXCLUDE mode, a router 1909 forwards traffic from all sources unless that source exists in the 1910 exclusion source list. If all hosts in EXCLUDE mode cease to exist, 1911 it would be desirable for the router to switch back to INCLUDE mode 1912 seamlessly without interrupting the flow of traffic to existing 1913 receivers. 1915 One of the ways to accomplish this is for routers to keep track of all 1916 sources desired by hosts that are in INCLUDE mode even though the 1917 router itself is in EXCLUDE mode. If the group timer now expires in 1918 EXCLUDE mode, it implies that there are no hosts in EXCLUDE mode 1919 on the network (otherwise a membership report from that host would 1920 have refreshed the group timer). The router can then switch to 1921 INCLUDE mode seamlessly with the list of sources currently being 1922 forwarded in its source list. 1924 AUTHORS' ADDRESSES 1926 Brad Cain 1927 Nortel Networks, Inc. 1928 600 Technology Park 1929 Billerica, MA 01821 1930 phone: +1-978-916-1316 1931 email: bcain@nortelnetworks.com 1933 Steve Deering 1934 Cisco Systems, Inc. 1935 170 Tasman Drive 1936 San Jose, CA 95134-1706 1937 phone: +1-408-527-8213 1938 email: deering@cisco.com 1940 Ajit Thyagarajan 1941 Ericsson IP Infrastructure 1942 12120 Plum Orchard Dr. 1943 Silver Spring, MD 20904 1944 phone: +1-301-586-8200 1945 email: ajit@torrentnet.com