idnits 2.17.1 draft-ietf-idmr-igmp-v3-01.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: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 4 instances of too long lines in the document, the longest one being 69 characters in excess of 72. == There are 1 instance 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 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 125: '... An implementation MAY impose a limit...' RFC 2119 keyword, line 126: '..., but that limit MUST NOT be less than...' RFC 2119 keyword, line 303: '...ed message types MUST be silently igno...' RFC 2119 keyword, line 352: '...ts, the checksum MUST be verified befo...' RFC 2119 keyword, line 389: '...e, IGMPv3 implementations MUST include...' (32 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 15 has weird spacing: '...d is in full ...' == Line 19 has weird spacing: '...), its areas...' == Line 20 has weird spacing: '...ups may also ...' == Line 24 has weird spacing: '... and may be ...' == Line 25 has weird spacing: '...opriate to u...' == (5 more instances...) -- 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 (August 1999) is 8993 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) == Missing Reference: 'RFC-1112' is mentioned on line 297, but not defined -- Looks like a reference, but probably isn't: '1' on line 473 -- Looks like a reference, but probably isn't: '2' on line 475 == Missing Reference: 'N' is mentioned on line 480, but not defined == Missing Reference: 'M' is mentioned on line 461, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMPv2' Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Inter-Domain Multicast Routing 3 Working Group 4 INTERNET-DRAFT Brad Cain, Nortel Networks 5 Steve Deering, Cisco Systems 6 draft-ietf-idmr-igmp-v3-01.txt Ajit Thyagarajan, Torrent Networks 7 February 1999 8 Expires August 1999 10 Internet Group Management Protocol, Version 3 11 13 STATUS OF THIS MEMO 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as work in progress. 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document specifies Version 3 of the Internet Group Management 37 Protocol, IGMPv3. IGMP is the protocol used by IP systems to report 38 their IP multicast group memberships to neighboring multicast routers. 39 Version 3 of IGMP adds support for ''source filtering'', that is, the 40 ability for a system to report interest in receiving packets *only* from 41 specific source addresses, or from *all but* specific source addresses, 42 sent to a particular multicast address. That information may be used 43 by multicast routing protocols to avoid delivering multicast packets 44 from specific sources to networks where there are no interested 45 receivers. 47 This document is a product of the Inter-Domain Multicast Routing working 48 group within the Internet Engineering Task Force. Comments are 49 solicited and should be addressed to the working group's mailing list at 50 idmr@cs.ucl.ac.uk and/or the author(s). 52 1. INTRODUCTION 54 The Internet Group Management Protocol (IGMP) is used by IP systems 55 (hosts and routers) to report their IP multicast group memberships to 56 any neighboring multicast routers. Note that an IP multicast router may 57 itself be a member of one or more multicast groups, in which case it 58 performs both the "multicast router part" of the protocol (to collect 59 the membership information needed by its multicast routing protocol) 60 and the "group member part" of the protocol (to inform itself and other, 61 neighboring multicast routers of its memberships). 63 IGMP is also used for other IP multicast management functions, using 64 message types other than those used for group membership reporting. 65 This document specifies only the group membership reporting functions 66 and messages. 68 This document specifies Version 3 of IGMP. Version 1, specified in 69 [RFC-1112], was the first widely-deployed version and the first version 70 to become an Internet Standard. Version 2, specified in [IGMPv2], 71 added support for "low leave latency", that is, a reduction in the time 72 it takes for a multicast router to learn that there are no longer any 73 members of a particular group present on an attached network. Version 3 74 adds support for "source filtering", that is, the ability for a system 75 to report interest in receiving packets *only* from specific source 76 addresses, or from *all but* specific source addresses, sent to a 77 particular multicast address. Version 3 is designed to be 78 interoperable with Versions 1 and 2. 80 2. THE API FOR REQUESTING IP MULTICAST RECEPTION 82 Within an IP system, there is (at least conceptually) an Application 83 Programmming Interface or API used by upper-layer protocols or 84 application programs to ask the IP layer to enable and disable reception 85 of packets sent to specific IP multicast addresses. In order to take 86 full advantage of the capabilities of IGMPv3, a system's IP API must 87 support the following operation (or any logical equivalent): 89 IPMulticastListen ( socket, interface, multicast-address, 90 filter-mode, source-list ) 92 where 94 "socket" is an implementation-specific parameter used to distinguish 95 among different requesting entities (e.g., programs or processes) 96 within the system; the socket parameter of BSD Unix system calls 97 is a specific example. 99 "interface" is a local identifier of the network interface on which 100 reception of the specified multicast address is to be enabled or 101 disabled. Interfaces may be physical (e.g., an Ethernet interface) 102 or virtual (e.g., the endpoint of a Frame Relay virtual circuit or 103 the endpoint of an IP-in-IP "tunnel"). An implementation may allow 104 a special "unspecified" value to be passed as the interface 105 parameter, in which case the request would apply to the "primary" or 106 "default" interface of the system (perhaps established by system 107 configuration). If reception of the same multicast address is 108 desired on more than one interface, IPMulticastListen is invoked 109 separately for each desired interface. 111 "multicast-address" is the IP multicast address to which the request 112 pertains. If reception of more than one multicast address on a given 113 interface is desired, IPMulticastListen is invoked separately for 114 each desired multicast address. 116 "filter-mode" may be either INCLUDE or EXCLUDE. In INCLUDE mode, 117 reception of packets sent to the specified multicast address is 118 requested *only* from those IP source addresses listed in the 119 source-list parameter. In EXCLUDE mode, reception of packets sent 120 to the given multicast address is requested from all IP source 121 addresses *except* those listed in the source-list parameter. 123 "source-list" is an unordered list of zero or more IP unicast 124 addresses from which multicast reception is desired or not desired, 125 depending on the filter mode. An implementation MAY impose a limit 126 on the size of source lists, but that limit MUST NOT be less than 127 64 addresses per list. 129 For a given combination of socket, interface, and multicast address, 130 only a single filter mode and source list can be in effect at any one 131 time. However, either the filter mode or the source list, or both, may 132 be changed by subsequent IPMulticastListen requests that specify the 133 same socket, interface, and multicast address. 135 Previous versions of IGMP did not support source filters and had a 136 simpler API consisting of Join and Leave operations to enable and 137 disable reception of a given multicast address (from *all* sources) on 138 a given interface. Those Join and Leave operations are supported by 139 the new API as follows: 141 The Join operation is equivalent to 143 IPMulticastListen ( socket, interface, multicast-address, 144 EXCLUDE, {} ) 146 and the Leave operation is equivalent to 148 IPMulticastListen ( socket, interface, multicast-address, 149 INCLUDE, {} ) 151 where {} is an empty source list. 153 It is recommended that implementations continue to support the old API, 154 (perhaps as calls on the new API) for compatibility with pre-existing IP 155 multicast applications. 157 3. MULTICAST RECEPTION STATE MAINTAINED BY SYSTEMS 159 3.1 Socket State 161 For each socket on which IPMulticastListen has been invoked, the system 162 records the desired multicast reception state for that socket. That 163 state conceptually consists of a set of records of the form: 165 (interface, multicast-address, filter-mode, source-list) 167 The socket state evolves in response to each invocation of 168 IPMulticastListen on the socket, as follows: 170 o If the requested filter mode is INCLUDE *and* the requested source 171 list is empty, then the entry corresponding to the requested 172 interface and multicast address is deleted if present. If no such 173 entry is present, the request is ignored. 175 o If the requested filter mode is EXCLUDE *or* the requested source 176 list is non-empty, then the entry corresponding to the requested 177 interface and multicast address, if present, is updated to contain 178 the requested filter mode and source list. If no such entry is 179 present, a new entry is created, using the parameters specified in 180 the request. 182 3.2 Interface State 184 In addition to the per-socket multicast reception state, a system must 185 also maintain or compute multicast reception state for each of its 186 interfaces. That state conceptually consists of a set of records of 187 the form: 189 (multicast-address, filter-mode, source-list) 191 This per-interface state is derived from the per-socket state, but may 192 differ from the per-socket state when different sockets have differing 193 filter modes and/or source lists for the same multicast address and 194 interface. For example, suppose one application or process invokes the 195 following operation on socket s1: 197 IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} ) 199 requesting reception on interface i of packets sent to multicast 200 address m, *only* if they come from source a, b, or c. Suppose another 201 application or process invokes the following operation on socket s2: 203 IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} ) 205 requesting reception on the same interface i of packets sent to the 206 same multicast address m, *only* if they come from sources b, c, or d. 207 In order to satisfy the reception requirements of both sockets, it is 208 necessary for interface i to receive packets sent to m from any one of 209 the sources a, b, c, or d. Thus, in this example, the reception state 210 of interface i for multicast address m has filter mode INCLUDE and 211 source list {a, b, c, d}. 213 (After a multicast packet has been accepted from an interface by the IP 214 layer, its subsequent delivery to the application or process listening 215 on a particular socket depends on the multicast reception state of that 216 socket [and possibly also on other conditions, such as what transport- 217 layer port the socket is bound to]. So, in the above example, if a 218 packet arrives on interface i, destined to multicast address m, with 219 source address a, it may be delivered on socket s1 but not on socket 220 s2.) 222 The general rules for deriving the per-interface state from the per- 223 socket state are as follows: For each distinct (interface, multicast- 224 address) pair that appears in any socket state, a per-interface record 225 is created for that multicast address on that interface. Considering 226 all socket records containing the same (interface, multicast-address) 227 pair, 229 o if *any* such record has a filter mode of EXCLUDE, then the filter 230 mode of the interface record is EXCLUDE, and the source list of 231 the interface record is the intersection of the source lists of all 232 socket records in EXCLUDE mode, minus those source addresses that 233 appear in any socket record in INCLUDE mode. For example, if the 234 socket records for multicast address m on interface i are: 236 from socket s1: ( i, m, EXCLUDE, {a, b, c, d} ) 237 from socket s2: ( i, m, EXCLUDE, {b, c, d, e} ) 238 from socket s3: ( i, m, INCLUDE, {d, e, f} ) 240 then the corresponding interface record on interface i is: 242 ( m, EXCLUDE, {b, c} ) 244 o if *all* such records have a filter mode of INCLUDE, then the 245 filter mode of the interface record is INCLUDE, and the source list 246 of the interface record is the union of the source lists of all the 247 socket records. For example, if the socket records for multicast 248 address m on interface i are: 250 from socket s1: ( i, m, INCLUDE, {a, b, c} ) 251 from socket s2: ( i, m, INCLUDE, {b, c, d} ) 252 from socket s3: ( i, m, INCLUDE, {e, f} ) 254 then the corresponding interface record on interface i is: 256 ( m, INCLUDE, {a, b, c, d, e, f} ) 258 *However*, there is one exception to this rule: if the source list 259 in an interface record in INCLUDE mode would contain too many 260 addresses to fit in an IGMP Version 3 Membership Report message (see 261 paragraph 4.2.5), an interface record of the following form is 262 created instead: 264 ( m, EXCLUDE, {} ) 266 That is, reception of packets to multicast address m from *all* 267 sources is enabled on the interface, whenever the specific list of desired sources is too long to include in an IGMP Report. The 268 exact limit depends on the MTU of the attached network; on Ethernet, for example, the limit is 366 addresses. 270 The above rules for deriving the interface state are (re-)evaluated 271 whenever an IPMulticastListen invocation modifies the socket state by 272 adding, deleting, or modifying a per-state record. Note that a change 273 of socket state does not necessarily result in a change of interface 274 state. 276 4. MESSAGE FORMATS 278 IGMP messages are encapsulated in IP datagrams, with an IP protocol 279 number of 2. Every IGMP message described in this document is sent 280 with an IP Time-to-Live of 1, and carries an IP Router Alert option 281 [RFC2113] in its IP header. 283 There are two IGMP message types of concern to the IGMPv3 protocol 284 described in this document: 286 Type Number (hex) Message Name 287 ----------------- ------------ 289 0x11 Membership Query 291 0x22 Version 3 Membership Report 293 An implementation of IGMPv3 must also support the following three 294 message types, for interoperation with previous versions of IGMP (see 295 section 6): 297 0x12 Version 1 Membership Report [RFC-1112] 299 0x16 Version 2 Membership Report [IGMPv2] 301 0x17 Version 2 Leave Group [IGMPv2] 303 Unrecognized message types MUST be silently ignored. Other message 304 types may be used by newer versions or extensions of IGMP, by multicast 305 routing protocols, or for other uses. 307 In this document, unless otherwise qualified, the capitalized words 308 "Query" and "Report" refer to IGMP Membership Queries and IGMP Version 309 3 Membership Reports, respectively. 311 4.1 Membership Query Message 313 Membership Queries are sent by IP multicast routers to query the 314 multicast reception state of neighboring interfaces. Queries have the 315 following format: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type = 0x11 | Max Resp Time | Checksum | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Group Address | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Reserved | Number of Sources (N) | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Source Address [1] | 327 +- -+ 328 | Source Address [2] | 329 +- . -+ 330 . . . 331 . . . 332 +- -+ 333 | Source Address [N] | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 4.1.1 Max Response Time 338 The Max Response Time field specifies the maximum time allowed 339 before sending a responding report, in units of 1/10 second. 341 Varying this setting allows IGMPv3 routers to tune the "leave 342 latency" (the time between the moment the last host leaves a group 343 and the moment the routing protocol is notified that there are no 344 more members). It also allows tuning of the burstiness of IGMP 345 traffic on a network. 347 4.1.2 Checksum 349 The Checksum is the 16-bit one's complement of the one's complement 350 sum of the whole IGMP message (the entire IP payload). For 351 computing the checksum, the Checksum field is set to zero. When 352 receiving packets, the checksum MUST be verified before processing 353 a packet. 355 4.1.3 Group Address 357 The Group address field is set to zero when sending a General 358 Query, and set to the IP multicast address being queried when 359 sending a Group-Specific Query or Group-and-Source-Specific Query 360 (see section 4.1.8, below). 362 4.1.4 Reserved 364 The Reserved field is set to zero on transmission, and ignored on 365 reception. 367 4.1.5 Number of Sources (N) 369 The Number of Sources (N) field specifies how many source addresses 370 are present in the Query. This number is zero in a General Query 371 or a Group-Specific Query, and non-zero in a Group-and-Source- 372 Specific Query. This number is limited by the MTU of the network 373 over which the Query is transmitted. For example, on an Ethernet 374 with an MTU of 1500 octets, the IP header including the Router 375 Alert option consumes 24 octets, and the IGMP fields up to 376 including the Number of Sources (N) field consume 12 octets, 377 leaving 1464 octets for source addresses, which limits the number 378 of source addresses to 366 (1464/4). 380 4.1.6 Source Address [i] 382 The Source Address [i] fields are a vector of n IP unicast 383 addresses, where n is the value in the Number of Sources (N) field. 385 4.1.7 Additional Data 387 If the Packet Length field in the IP header of a received Query 388 indicates that there are additional octets of data present, beyond 389 the fields described here, IGMPv3 implementations MUST include 390 those octets in the computation to verify the received IGMP 391 Checksum, but MUST otherwise ignore those additional octets. When 392 sending a Query, an IGMPv3 implementation MUST NOT include 393 additional octets beyond the fields described here. 395 4.1.8 Query Variants 397 There are three variants of the Query message: 399 (1) A "General Query" is sent by a multicast router to learn the 400 complete multicast reception state of the neighboring interfaces 401 (that is, the interfaces attached to the network on which the 402 Query is transmitted). In a General Query, both the Group 403 Address field and the Number of Sources (N) field are zero. 405 (2) A "Group-Specific Query" is sent by a multicast router to learn 406 the reception state, with respect to a *single* multicast 407 address, of the neighboring interfaces. In a Group-Specific 408 Query, the Group Address field contains the multicast address 409 of interest, and the Number of Sources (N) field contains zero. 411 (3) A "Group-and-Source-Specific Query" is sent by a multicast 412 router to learn if any neighboring interface desires reception 413 of packets sent to a specified multicast address, from any of a 414 specified list of sources. In a Group-and-Source-Specific 415 Query, the Group Address field contains the multicast address 416 of interest, and the Source Address [i] fields contain the 417 source address(es) of interest. 419 4.1.9 IP Destination Addresses for Queries 421 In IGMPv3, General Queries are sent with an IP destination address of 422 224.0.0.1, the all-systems multicast address. Group and Group-and- 423 Source Queries are sent with an IP destination address equal to the 424 multicast address of interest. *However*, a system MUST accept and 425 process any Query whose IP Destination Address field contains *any* of 426 the addresses (unicast or multicast) assigned to the interface on which 427 the Query arrives. 429 4.2 Version 3 Membership Report Message 431 Version 3 Membership Reports are sent by IP systems to report (to 432 neighboring routers) the current multicast reception state, or changes 433 in the multicast reception state, of their interfaces. Reports have 434 the following format: 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Type = 0x22 | Reserved | Checksum | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Reserved | Number of Group Records (M) | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | | 444 . . 445 . Group Record [1] . 446 . . 447 | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 . . 451 . Group Record [2] . 452 . . 453 | | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 . 456 . 457 . 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | | 460 . . 461 . Group Record [M] . 462 . . 463 | | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 where each Group Record has the following internal format: 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Record Type | Reserved | Number of Sources (N) | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Multicast Address | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Source Address [1] | 474 +- -+ 475 | Source Address [2] | 476 +- . -+ 477 . . . 478 . . . 479 +- -+ 480 | Source Address [N] | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 4.2.1 Reserved 485 The Reserved fields are set to zero on transmission, and ignored on 486 reception. 488 4.2.2 Checksum 490 The Checksum is the 16-bit one's complement of the one's complement 491 sum of the whole IGMP message (the entire IP payload). For 492 computing the checksum, the Checksum field is set to zero. When 493 receiving packets, the checksum MUST be verified before processing 494 a message. 496 4.2.3 Number of Group Records (M) 498 The Number of Group Records (M) field specifies how many Group 499 Records are present in this Report. 501 4.2.4 Group Record 503 Each Group Record is a block of fields containing information 504 pertaining to the sender's membership in a single multicast group 505 on the interface from which the Report is sent. 507 4.2.4 Record Type 509 See section 4.2.9, below. 511 4.2.5 Number of Sources (N) 513 The Number of Sources (N) field specifies how many source addresses 514 are present in this Group Record. 516 4.2.6 Multicast Address 517 The Multicast Address field contains the IP multicast address to 518 which this Group Record pertains. 520 4.2.7 Source Address [i] 522 The Source Address [i] fields are a vector of n IP unicast 523 addresses, where n is the value in this record's Number of Sources 524 (N) field. 526 4.2.8 Additional Data 528 If the Packet Length field in the IP header of a received Report 529 indicates that there are additional octets of data present, beyond 530 the last Group Record, IGMPv3 implementations MUST include those 531 octets in the computation to verify the received IGMP Checksum, but 532 MUST otherwise ignore those additional octets. When sending a 533 Report, an IGMPv3 implementation MUST NOT include additional octets 534 beyond the last Group Record. 536 4.2.9 Group Record Types 538 There are a number of different types of Group Records that may be 539 included in a Report message: 541 (1) A "Current-State Record" is sent by a system in response to a 542 Query received on an interface. It reports the current 543 reception state of that interface, with respect to a single 544 multicast address. The Record Type of a Current-State Record 545 may be one of the following two values: 547 Value Name and Meaning 548 ----- ---------------- 550 1 MODE_IS_INCLUDE - indicates that the interface has a 551 filter mode of INCLUDE for the specified multicast 552 address. The Source Address [i] fields in this Group 553 Record contain the interface's source list for the 554 specified multicast address, if it is non-empty. 556 2 MODE_IS_EXCLUDE - indicates that the interface has a 557 filter mode of EXCLUDE for the specified multicast 558 address. The Source Address [i] fields in this Group 559 Record contain the interface's source list for the 560 specified multicast address, if it is non-empty. 562 (2) A "Filter-Mode-Change Record" is sent by a system whenever a 563 local invocation of IPMulticastListen causes a change of the 564 filter mode (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to INCLUDE), of the interface-level state entry for a 565 particular multicast address. The Record is included in a 566 Report sent from the interface on which the change occurred. 567 The Record Type of a Filter-Mode-Change Record may be one of 568 the following two values: 570 3 CHANGE_TO_INCLUDE_MODE - indicates that the interface 571 has changed to INCLUDE filter mode for the specified 572 multicast address. The Source Address [i] fields 573 in this Group Record contain the interface's new 574 source list for the specified multicast address, 575 if it is non-empty. 577 4 CHANGE_TO_EXCLUDE_MODE - indicates that the interface 578 has changed to EXCLUDE filter mode for the specified 579 multicast address. The Source Address [i] fields 580 in this Group Record contain the interface's new 581 source list for the specified multicast address, 582 if it is non-empty. 584 (3) A "Source-List-Change Record" is sent by a system whenever a 585 local invocation of IPMulticastListen causes a change of source 586 list that is *not* coincident with a change of filter mode, of 587 the interface-level state entry for a particular multicast 588 address. The Record is included in a Report sent from the 589 interface on which the change occurred. The Record Type of a 590 Source-List-Change Record may be one of the following two 591 values: 593 5 ALLOW_NEW_SOURCES - indicates that the Source Address 594 [i] fields in this Group Record contain a list of the 595 additional sources that the system wishes to 596 hear from, for packets sent to the specified 597 multicast address. If the change was to an INCLUDE 598 source list, these are the addresses that were added 599 to the list; if the change was to an EXCLUDE source 600 list, these are the addresses that were deleted from 601 the list. 603 6 BLOCK_OLD_SOURCES - indicates that the Source Address 604 [i] fields in this Group Record contain a list of the 605 sources that the system no longer wishes to 606 hear from, for packets sent to the specified 607 multicast address. If the change was to an INCLUDE 608 source list, these are the addresses that were 609 deleted from the list; if the change was to an 610 EXCLUDE source list, these are the addresses that 611 were added to the list. 613 If a change of source list results in both allowing new sources 614 and blocking old sources, then two Group Records are sent for 615 the same multicast address, one of type ALLOW_NEW_SOURCES and 616 one of type BLOCK_OLD_SOURCES. 618 We use the term "State-Change Record" to refer to either a Filter-Mode- 619 Change Record or a Source-List-Change Record. 621 Unrecognized Record Type values MUST be silently ignored. 623 4.2.10 IP Destination Addresses for Reports 625 Version 3 Reports are sent with an IP destination address of 224.0.0.?, 626 the all-membership-reports multicast group address. A system that is 627 operating in version 1 or version 2 compatibility modes sends version 1 628 and version 2 Reports to the multicast group specified in the Group 629 Address field of the Report. In addition, a system MUST accept and 630 process any version 1 or version 2 Report whose IP Destination Address 631 field contains *any* of the addresses (unicast or multicast) assigned 632 to the interface on which the Report arrives. 634 4.2.11 Notation for Group Records 636 In the rest of this document, we use the following notation to describe 637 the contents of a Group Record pertaining to a particular multicast 638 address: 640 IS_IN ( x ) - Type MODE_IS_INCLUDE, source addresses x 641 IS_EX ( x ) - Type MODE_IS_EXCLUDE, source addresses x 642 TO_IN ( x ) - Type CHANGE_TO_INCLUDE_MODE, source addresses x 643 TO_EX ( x ) - Type CHANGE_TO_EXCLUDE_MODE, source addresses x 644 ALLOW ( x ) - Type ALLOW_NEW_SOURCES, source addresses x 645 BLOCK ( x ) - Type BLOCK_OLD_SOURCES, source addresses x 647 where x is either: 649 - a capital letter (e.g., "A") to represent the set of source 650 addresses, 652 - a list of zero or more lower-case letters enclosed in braces 653 (e.g., "{a, b, c}" or "{}") to represent the individual source 654 addresses in the list, or 656 - a set expression (e.g., "A + B"), where "x + y" means the 657 union of x and y, "x * y" means the intersection of x and y, 658 and "x - y" means the removal of all elements of set y from 659 set x. 661 4.2.12 Membership Report Size 663 If the entire list of Group Records does not fit within the MTU limits 664 of a single Report message, the Group Records are sent in as many Report 665 messages required to report the entire list of Group Records. Each 666 Report is filled with the maximum number of Group Records within the 667 MTU limit. 669 Similarly, if the list of source addresses comprising a single Group 670 Record does not fit within the MTU limits of a single Report message, 671 the Group Record is sent in as many Report messages required to report 672 the entire list of sources. 674 5. PROTOCOL DESCRIPTION 676 The purpose of IGMP is to enable each multicast router to learn, for 677 each of its directly attached networks, which multicast addresses are 678 of interest to the systems attached to those networks. This 679 information is then provided to whichever multicast routing protocol is 680 being used by the router, in order to ensure that multicast packets are 681 delivered to all networks where there are interested receivers. 683 IGMP version 3 adds the capability for a multicast router to learn 684 which *sources* are of interest to neighboring systems, for packets 685 sent to any particular multicast address. 687 It is important to understand that a multicast router needs to know 688 only that *at least one* system on an attached network is interested 689 in packets to a particular multicast address from a particular source; 690 the multicast router does not need to keep track of the interests of 691 each individual neighboring system. 693 IGMP is an asymmetric protocol, defining separate behaviors for group 694 members -- that is, hosts or routers that wish to receive multicast 695 packets -- and multicast routers. A multicast router that is also a 696 group member performs both parts of the protocol, receiving its own 697 IGMP message transmissions as well as those of its neighbors. 699 If a multicast router has more than one interface on the same network, 700 it needs to operate the multicast router part of IGMP over only one of 701 those interfaces. A group member, on the other hand, must operate the 702 group member part of IGMP over all interfaces from which reception of 703 multicast packets has been requested by IPMulticastListen invocations. 705 Membership in the all-systems multicast group, address 224.0.0.1, is 706 handled as a special case: reception of packets destined to the all- 707 systems multicast address, from all sources, is permanently enabled on 708 all interfaces on which multicast reception is supported. No IGMP 709 messages are ever sent reporting the all-systems multicast address. 711 Note that, in the following descriptions, timer and counter names 712 appear in square brackets. The default values for those timers and 713 counters are specified in section 7. 715 5.1 Group Member Behavior 717 For interoperability with multicast routers running older versions of 718 IGMP, systems maintain a MulticastRouterVersion variable for each 719 interface on which multicast reception is desired. This section 720 describes the behavior of group member systems on interfaces for which 721 MulticastRouterVersion = 3. The algorithm for determining 722 MulticastRouterVersion, and the behavior for versions other than 3, are 723 described in section 6.1. 725 There are three types of events that trigger IGMP protocol actions on 726 an interface on which multicast reception is enabled: 728 o a change of the interface reception state, caused by a local 729 invocation of IPmulticastListen. 731 o reception of a Query. 733 o reception of a Report. 735 The following subsections describe the actions to be taken for each of 736 these cases. 738 5.1.1 Action on Change of Interface State 740 An invocation of IPMulticastListen may cause the multicast reception 741 state of an interface to change, according to the rules in section 3.2. 742 Each such change affects the per-interface entry for a single multicast 743 address. 745 A change of interface state causes the system immediately to transmit a 746 State-Change Report from that interface, with the Group field of the 747 Report carrying the affected multicast address. The contents of the 748 rest of the report are determined by comparing the filter mode and 749 source list for that multicast address before and after the change, 750 according to the table below. If no interface state existed for that 751 multicast address before the change (i.e., the change consisted of 752 creating a new per-interface record), or if no state exists after the 753 change (i.e., the change consisted of deleting a per- interface record), 754 then the "non-existant" state is considered to have a filter mode of 755 INCLUDE and an empty source list. 757 Old State New State State-Change Report Sent 758 --------- --------- ------------------------ 760 INCLUDE (A) INCLUDE (B) ALLOW (B-A), BLOCK (A-B) 762 EXCLUDE (A) EXCLUDE (B) ALLOW (A-B), BLOCK (B-A) 764 INCLUDE (A) EXCLUDE (B) TO_EX (B) 766 EXCLUDE (A) INCLUDE (B) TO_IN (B) 768 To cover the possibility of the State-Change Report being missed by one 769 or more multicast routers, it is retransmitted [Robustness Variable] - 1 770 more times, at intervals chosen at random from the range (0, 771 [Unsolicited Report Interval]]. 773 If more changes to the same interface state entry occur before all the 774 retransmissions of the State-Change Report for the first change have 775 been completed, each such additional change triggers the immediate 776 transmission of a State-Change Report reflecting the difference between 777 the newest state and the state *before* the first change for which 778 retransmissions were not completed. The transmission of the newer 779 State-Change Report terminates retransmissions of the earlier State- 780 Change Reports for the same multicast address, and becomes the first of 781 [Robustness Variable] transmissions of the newer Report. 783 5.1.2 Action on Reception of a Query 785 A system may receive any of the three variants of IGMPv3 Query messages: 786 a General Query, a Group-Specific Query, or a Group-and-Source-Specific 787 Query (see section 4.1.8). 789 IGMPv3 hosts report multiple groups within the same "report packet". 790 Because of this "group bundling", a global report delay timer is used. 791 This timer is reset upon reception of a general query. When a global 792 group delay timer expires, a report is sent for all groups for which 793 the host is joined on that interface. For handling of Group-Specific 794 and Group-and-Source Specific Queries a per group timer is kept. 796 When a system receives a General Query, it adjusts the global "report 797 delay timer" on the interface from which the Query was received. If 798 the timer is not running, it is set to a random value, using the finest 799 clock granularity available on the system, from the range (0, 800 MaxResponseTime], where MaxResponseTime is obtained from the Query 801 message. If the global report timer is already running, it is reset to 802 a new random value only if the requested MaxResponseTime is less than 803 the remaining value of the running timer. Otherwise, it is left 804 running with its current value. 806 When the global report timer expires, the system transmits one or more 807 Reports reporting for each multicast address present on that interface, 808 its filter mode (either MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and the 809 list of sources associated with the multicast address; any group- 810 specific report delay timers, if running, on that interface are deleted 811 as well. If there is a change in filter mode or source address list of 812 a multicast group with the global report delay timer still running, a 813 State-Change Report is sent for that multicast group address as 814 specified in Section 5.1.1; the global report delay timer is not 815 deleted. 817 When a system receives a Group-Specific Query, it performs a similar 818 set of actions as it does when receiving a General Query, *except* that 819 the actions are performed only for the multicast address that was 820 specified in the Group-Specific Query and using the "group-specific 821 report delay timer" instead of the global timer. 823 When a multicast group report delay timer expires, the system 824 transmits a Report, reporting that multicast address and the filter mode 825 (either MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and the entire list of 826 sources addresses associated with the multicast address. 828 When a system receives a Group-and-Source-Specific Query, it performs 829 the same actions as it does when receiving a Group-Specific Query, 830 *except*: 832 o the pending report record and report delay timer it creates are 833 *in addition to* any record and timer it may have created for the 834 same multicast address in response to a General or Group-Specific 835 Query. 837 o the initial contents of the newly-created pending report record are 838 determined by comparing the source list in the received Query with 839 the local state, as specified in the following table: 841 Local State Query Source List Pending Report Record 842 ----------- ----------------- --------------------- 844 INCLUDE (A) B IS_IN (A*B) 846 EXCLUDE (A) B IS_IN (B-A) 848 5.1.3 Action on Reception of a Report 850 Earlier drafts of IGMPv3 specified that hosts perform suppression on 851 reports. This was removed due to the complexity of the merging 852 operations involved. IGMPv3 hosts send reports to the all-membership- 853 reports multicast address and do not perform suppression. 855 5.2 Multicast Router Behavior 857 5.2.1 Overview 859 Multicast routers use the IGMP protocol to periodically query the 860 multicast reception state of hosts attached to local subnetworks. 861 General Queries are sent periodically; Group-Specific and Group-and- 862 Source-Specific Queries are sent in response to Filter-Mode-Change and 863 Source-List-Change records. 865 It is important to understand that a multicast router needs to know 866 only that *at least one* system on an attached network is interested 867 in packets to a particular multicast address from a particular source; 868 the multicast router does not need to keep track of the interests of 869 each individual neighboring system. IGMPv3 router MAY track the 870 memberships of individual hosts (at the expense of additional state). 871 If a router chooses to keep individual membership information, it may 872 omit Group-Specific and Group-and-Source-Specific Queries from its 873 implementation. A router MUST implement IGMPv2 Group-Specific 874 queries for backwards compatibility. 876 IGMPv3 is backward compatible with previous versions of the IGMP 877 protocol. In order to remain backward compatible with older IGMP 878 hosts and routers, IGMPv3 routers must also implement versions 1 and 2 879 of the protocol (see section 6). 881 5.2.2 Conditions for IGMP Queries 883 IGMPv3 routers send General Queries periodically to request group 884 membership information. Hosts respond to these queries with Current- 885 State Reports. As hosts update the state of individual Group Records, 886 they may send send Filter-Mode-Change Records or Source-List-Change 887 Records. In order for all hosts on a subnet to respond to changes in 888 group membership, a router sends specific queries. A Group-Specific 889 Query is sent to verify there are no neighboring interfaces that desire 890 reception of the specified group. A Group-and-Source Specific Query 891 lists sources within a group that have been requested to be deleted 892 (i.e. not forwarded). This query is sent by a router to learn if any 893 neighboring interfaces desire reception of packets to the specified 894 group address from the specified source addresses. Section 4.1.8 895 describes each query in more detail. 897 5.2.3 IGMP State Maintained by Multicast Routers 899 Routers implementing the IGMPv3 protocol keep keep state per group 900 per interface. This state consists of a filter-mode, list of sources, 901 and various timers. For each interface on which IGMP exists, a router 902 records the desired reception state for that locally attached network. 903 That state conceptually consists of a set of records of the form: 905 (multicast address, group timer, filter-mode, source-element list) 907 Each member of the source-element list is a record of the form: 909 (source address, source timer) 911 If all sources within a given group are desired, an empty source 912 element list is kept with the filter-mode set to EXCLUSION. This means 913 forward all sources for this group. This is equivalent to the older 914 version join of single group (i.e. as in previous versions of IGMP). 916 5.2.3.1 Definition of Router Filter-Mode 918 To reduce internal state, IGMPv3 routers keep a filter-mode per group 919 per interface. This filter-mode is used to condense the total desired 920 reception state of a group to a minimum set such that all systems 921 memberships are satisfied. The filter-mode of a group record may 922 change when receiving new reports, or when certain timer conditions 923 occur. Upon receiving a host report, the filter-mode is updated to 924 represent the most number of sources desired with the least amount of 925 state. In general, once a filter-mode of EXCLUSION is received, the 926 router filter-mode for that group record will be EXCLUSION. A 927 mechanism to transition back to an INCLUSION filter-mode is specified 928 as all hosts with EXCLUSION filter-mode may cease reporting, leaving 929 the router filter-mode in an EXCLUSION state. Section 5.2.5 describes 930 the changes of a router-filter mode per host report received. Section 931 5.2.6 describes the change in filter-mode when certain timer conditions 932 are met. 934 5.2.3.2 Definition Group Timers 936 A group timer is kept per group per interface state record. A group 937 timer is a decrementing timer with a lower bound of zero. Group timers 938 are updated according to the filter-mode of the group record and type of 939 host report received. Group timers are not always updated per a 940 received group report. A group timer expiring when the filter-mode is 941 INCLUSION means there are no listeners on the attached subnet for that 942 group. A group timer expiring when the filter-mode is EXCLUSION means 943 there are no listeners on the attached subnet in EXCLUSION mode. 944 Section 5.2.5 details the exact setting of the group timer per filter 945 mode and report received. Section 5.2.6 details the events when a group 946 timer expires while in EXCLUSION mode. 948 5.2.3.3 Definition of Source Timers 950 A source timer is kept per source element record. A source timer is a 951 decrementing timer with a lower bound of zero. Source timers are 952 updated according to the filter-mode of the group record and type of 953 host report received. Unlike group timers, source timers are always 954 updated for a particular group whenever the source is present in a 955 received record for that group. Section 5.2.5 details the exact 956 setting of the source timer per filter mode and report received. 958 The actions performed upon the expiry of source element timers depend 959 upon the group filter-mode. If a source timer expires with the group 960 in INCLUSION filter-mode, the router concludes that traffic from thisi 961 particular source is no longer desired on the locally attached 962 interface, and deletes the associated record. If a source timer expires 963 with the group in EXCLUSION filter-mode, the router stops forwarding 964 traffic from this source onto the interface, but does not delete its 965 record. Section 5.2.4 details the actions that should be taken, 966 dependant upon the value of a source timer. 968 5.2.4 IGMPv3 Source Specific Forwarding Rules 970 When a router receives a datagram from a source destined to a particular 971 group, a decision has to be made whether to forward the datagram onto 972 the subnetwork or not. This decision is first dependent on any 973 multicast routing protocols present. Assuming that there are no other 974 routers downstream (or that downstream routers support source-specific 975 pruning/grafting), the forwarding decision depends on the presence of a 976 group record and/or a source-specific record. If no group record 977 exists, the datagram is not forwarded on the subnetwork. Even if a 978 group record exists, a source-specific record may or may not exist for 979 the particular source. 981 To summarize, the following table details the actions to be performed 982 for traffic originating from a source destined to a group, and upon 983 the expiry of a source-specific timer, based on the group mode and the 984 value of the source-specific timer, if it exists: 986 Group 987 Filter-Mode Source Timer Value Action 988 ----------- ------------------ ------ 990 INCLUDE TIMER > 0 Forward source 992 INCLUDE TIMER == 0 Stop forwarding source and 993 remove source record 995 INCLUDE None Don't forward source 997 EXCLUDE TIMER > 0 Don't forward source 999 EXCLUDE TIMER == 0 Start forwarding source 1001 EXCLUDE None Forward source 1003 5.2.5 Actions upon Reception of Reports 1005 5.2.5.1 Reception of Current-State reports 1007 When receiving Current-State Reports, routers update both group timers 1008 and source timers. Depending on the routers current filter-mode for a 1009 group and the filter-mode of a Current-State Report received for that 1010 group, a router may change to a different filter-mode per group. The 1011 table below details the actions, with respect to state and timers, that 1012 occur at a router when receiving Current-State Reports. 1014 The following notation is used to describe the updating of source 1015 timers. The notation ( A, B ) will be used to represent the total 1016 number of sources for a particular group, where 1018 A = set of sources whose timers > 0 (being forwarded) 1019 B = set of sources whose timers = 0 (not being forwarded) 1021 The variable TQ is one query period plus the time to report field of 1022 the last General Query. The variable RI is the time to report field of 1023 the last send Query. 1025 Router State Report Rec'd New Router State Actions 1026 ------------ ------------ ---------------- ------- 1028 INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B) = TQ 1029 Group Timer = TQ 1031 INCLUDE (A) IS_EX (B) EXCLUDE (A*B,B-A) (B-A) = 0 1032 Group Timer = TQ 1034 EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+A,Y-A) (A) = TQ 1036 EXCLUDE (X,Y) IS_EX (B) EXCLUDE (X*B,Y-B) Group Timer = TQ 1038 5.2.5.2 Reception of Filter-Mode-Change and Source-List-Change Reports 1040 When a change in the global state of a group occurs in a host, the host 1041 sends either a Source-List-Change Report or a Filter-Mode-Change Report 1042 for that group. As with Current-State Reports, routers must act upon 1043 these reports and possibly change their state to reflect the new 1044 desired membership state. 1046 Routers must query any sources that are requested to be deleted from the 1047 network. When a router queries a specific set of sources, it sets the 1048 source timers to a small interval (5 secs). If host membership reports 1049 are received which express interest in receiving traffic from the 1050 specific sources, the corresponding timers are updated. Similarly, when 1051 a router queries a specific group, it sets the group timer to a small 1052 interval (5 secs). If any membership reports expressing interest in 1053 the group are received within the interval, the group timer is updated 1054 and traffic is forwarded without any interruption. During the interval, 1055 the router continues to forward traffic from the sources that were 1056 requested to be deleted to prevent traffic from being interrupted to 1057 other interested hosts. 1059 The following table details the change in state and actions that are 1060 taken when receiving either Filter-Mode-Change or Source-List-Change 1061 Reports dependent upon the current state of the group. 1063 Router State Report Rec'd New Router State Actions 1064 ------------ ------------ ---------------- ------- 1066 INCLUDE (A) ALLOW (B) INCLUDE (A+B) (B)=TQ 1067 Group Timer=TQ 1069 INCLUDE (A) BLOCK (B) INCLUDE (A) (A*B)=RI 1070 Send Q(G,A*B) 1072 INCLUDE (A) ALLOW (B), INCLUDE (A+B) (B)=TQ 1073 BLOCK (C) (A*C)=RI 1074 Send Q(G,A*C) 1075 Group Timer=TQ 1077 INCLUDE (A) TO_EX (B) EXCLUDE (A*B,B-A) (A*B)=RI 1078 Send Q(G,A*B ) 1079 Group Timer=TQ 1081 INCLUDE (A) TO_IN (B) INCLUDE (A+B) (B)=TQ 1082 (A-B)=RI 1083 Send Q(G,A-B) 1084 Group Timer=TQ 1086 EXCLUDE (X,Y) ALLOW (A) EXCLUDE (X+A,Y-A) (A)=TQ 1088 EXCLUDE (X,Y) BLOCK (A) EXCLUDE (X+(A-Y),Y) (A-Y)=RI 1089 Send Q(G,A-Y) 1091 EXCLUDE (X,Y) ALLOW (A), EXCLUDE (X+A+(B-Y),Y-A) (A)=TQ 1092 BLOCK (B) (B-Y)=RI 1093 Send Q(G,B-Y) 1095 EXCLUDE (X,Y) TO_EX (A) EXCLUDE (X*A,Y*A) (A-Y)=RI 1096 Send Q(G,A-Y) 1097 Group Timer=TQ 1099 EXCLUDE (X,Y) TO_IN (A) EXCLUDE (X+A,Y-A) (A)=TQ 1100 (X-A)=RI 1101 Send Q(G,*) 1103 5.2.6 Switching Filter-Modes 1105 The IGMPv3 group timer is used as a mechanism for transitioning from 1106 EXCLUSION filter-mode to INCLUSION filter-mode. When a group timer 1107 expires with the group in INCLUSION filter-mode, a router concludes that 1108 there are no group members present on the locally attached interface and 1109 deletes the group record and the associated source records. 1111 When a group timer expires with the group in EXCLUSION filter-mode, a 1112 router assumes that there are no hosts in EXCLUSION filter-mode are 1113 present on the attached subnetwork, and switches to INCLUSION filter- 1114 mode. In addition, all source-element records with zero timer values 1115 are deleted and the group timer assumes the maximum value among all the 1116 remaining source-element records corresponding to that group. A Group- 1117 Specific Query is then sent for the group to determine the desired group 1118 and source state for that group. 1120 5.2.7 Action of Reception of Queries 1122 IGMPv3 uses the same querier election method as previous versions. Upon 1123 receiving an IGMPv3 General Query from another router, the querier 1124 ceases to send General Queries and sets the OTHER_QUERIER_PRESENT timer. 1125 Upon expiry of OTHER_QUERIER_PRESENT timer, a router becomes the 1126 querier. Routers who are not the acting querier reset 1127 OTHER_QUERIER_PRESENT timer upon reception of a IGMPv3 General Query. 1128 For details of compatibility between versions see section 6. 1130 6. INTEROPERATION WITH OLDER VERSIONS OF IGMP 1132 IGMP version 3 hosts and routers interoperate with hosts and routers 1133 that have not yet been upgraded to IGMPv3. This compatibility is 1134 maintained by hosts and routers taking appropriate actions depending on 1135 the versions of IGMP operating on hosts and routers within a network. 1137 6.1 Query Version Distinctions 1139 The IGMP version of a Host Membership Query message is determined as 1140 follows: 1142 IGMPv1 Query: length = 8 octets AND Max Response Time field is zero 1144 IGMPv2 Query: length = 8 octets AND Max Response Time field is 1145 non-zero 1147 IGMPv3 Query: length >= 12 octets AND Reserved field is zero 1149 Query messages that do not match any of the above conditions (e.g., a 1150 Query of length 10 octets) must be silently ignored. 1152 6.2 Group Member Behavior 1154 IGMPv3 hosts can operate in version 1 and version 2 compatibility modes. 1155 The mode in which a host operates is governed by the version of the 1156 querier router on an interface. The version of the querier can be 1157 determined from a Host Membership Query. 1159 IGMPv3 hosts keep state per local interface regarding the version of 1160 querier on the attached network. Hosts can be in one of three states 1161 depending on the version of querier on their attached networks. This 1162 state is reflected by Querier Version, a state variable kept per 1163 interface describing the version of querier on the attached network. 1164 This state variable can have only one of three values: IGMPv3, IGMPv2, 1165 IGMPv1. When Querier Version is IGMPv3, a host acts using the IGMPv3 1166 protocol. When Querier Version is IGMPv2, a host acts in IGMPv2 1167 compatibility mode, using only the IGMPv2 protocol. When Querier 1168 Version is IGMPv1, a host acts in IGMPv1 compatibility mode, using the 1169 IGMPv1 protocol. 1171 If a lower version query (as compared to Querier Version) is received on 1172 an interface, this state will change immediately to reflect the older 1173 version querier and the host will operate in that lower version 1174 compatibility mode. However, if a higher version query (as compared to 1175 Querier Version) is received, it will not immediately change it's state. 1176 This is to prevent the problem when newer version queries are sent by a 1177 router restarting and having not yet yielded to an older version 1178 querier. 1180 Each time a non-version 3 query is received, a host sets a timer: Older 1181 Version Querier Present Timeout. The state variable, Querier Version, 1182 reflecting the version of querier on an interface will be based on this 1183 timer. If a host hears a newer version query (as compared to Querier 1184 Version), it will not change its operating state until after the timer 1185 expires. 1187 6.2.1 In the Presence of Older Version Queriers 1189 An IGMPv3 host may be placed on a network where the Querier router has 1190 not yet been upgraded to IGMPv3. The following requirements apply: 1192 An older version router expects older version Membership Reports in 1193 response to its Queries, and will not understand Version 3 1194 Membership Reports. Therefore, a state variable MUST be kept for 1195 each interface, describing whether the multicast Querier on that 1196 interface is running IGMPv1, IGMPv2, or IGMPv3. This variable 1197 MUST be based upon whether or not the older version query was 1198 heard in the last [Older Version Querier Present Timeout] seconds, 1199 and MUST NOT be based upon the type of the last Query heard. This 1200 state variable MUST be used to decide what type of Membership 1201 Reports to send for unsolicited Membership Reports as well as 1202 Membership Reports in response to Queries. 1204 Version 1 Querier 1206 An IGMPv1 router will send General Queries with the Max Response 1207 Time set to 0. This MUST be interpreted as a value of 100 (10 1208 seconds). 1210 IGMPv3 hosts must send IGMPv1 Membership reports when an IGMPv1 1211 router is present. This is IGMPv1 compatibility mode. 1213 Version 2 Querier 1215 IGMPv3 hosts must send IGMPv2 Membership reports when an IGMPv2 1216 router is present. IGMPv3 hosts must use IGMPv2 Leave Group 1217 messages when an IGMPv2 router is present. This is IGMPv2 1218 compability mode. 1220 The following table summarizes an IGMPv3 host response to different 1221 types of queries: 1223 Querier 1224 Version Query Type Host Response 1225 ------- ---------- ------------- 1226 IGMPv1 Host Membership Query IGMPv1 Membership Report 1227 IGMPv2 Host Membership Query IGMPv2 Membership Report 1228 IGMPv2 Group-Specific Membership Query IGMPv2 Membership Report 1229 IGMPv3 Host Membership Query IGMPv3 Membership Report 1230 IGMPv3 Group-Specific Membership Query IGMPv3 Membership Report 1231 IGMPv3 Source-Specific Membership Query IGMPv3 Membership Report 1233 6.2.2 In the Presence of Older Version Group Members 1235 An IGMPv3 host may be placed on a network where there are hosts that 1236 have not yet been upgraded to IGMPv3. A host MAY allow its IGMPv3 1237 Membership Report to be suppressed by either a Version 1 Membership 1238 Report, or a Version 2 Membership Report. 1240 If a host is a member of any sources within a group reported in a V1 or 1241 V2 membership report, then it may suppress its report by marking the 1242 group so that it is not reported when the next IGMPv3 report is sent. 1244 6.2.3 Group Member Compatibility State Transition Diagram 1246 RQ3 1247 ----------- 1248 | | 1249 | V 1250 RQ1/ST ------------------- RQ2/ST 1251 ---------------| |---------------- 1252 | | V3 Mode | | 1253 | ------->| |<------- | 1254 | | ------------------- | | 1255 | | | | 1256 | |TE/DT TE/DT| | 1257 | | | | 1258 V | | V 1259 ------------------- ------------------ 1260 ----| | | |---- 1261 RQ3| | V1 Mode |<-------------------| V2 Mode | |RQ3 1262 --->| | RQ1/RT | |<--- 1263 ------------------- ------------------ 1264 | ^ | ^ | ^ 1265 | | | | | | 1266 ------ ------ ----------- 1267 RQ1/RT RQ2 RQ2/RT 1269 Actions 1270 ------- 1271 ST : start Older Version Querier Present Timer 1272 DT : delete Older Version Querier Present Timer 1273 TE : Older Version Querier Present Timer expires 1274 RT : reset Older Version Querier Present Timer 1276 Events 1277 ------ 1278 RQ1 : Receive IGMPv1 Host Membership Query 1279 RQ2 : Receive IGMPv2 Host Membership Query 1280 RQ3 : Receive IGMPv3 Host Membership Query 1282 States 1283 ------ 1284 V3 Mode : An IGMPv3 router is the present querier on an interface. 1285 The host uses IGMPv3 Membership Reports 1287 V2 Mode : An IGMPv2 router is the present querier on an interface. 1288 The host uses IGMPv2 Membership Reports and IGMPv2 Leave 1289 Group messages. 1291 V1 Mode : An IGMPv1 router is the present querier on an interface. 1292 The host uses IGMPv1 Membership Reports. 1294 6.3 Multicast Router Behavior 1296 6.3.1 In the Presence of Older Version Queriers 1298 IGMPv3 routers may be placed on a network where at least one router on 1299 the network has not not yet been upgraded to IGMPv3. The following 1300 requirements apply: 1302 If any older versions of IGMP are present on routers, the querier 1303 MUST use the lowest version of IGMP present on the network. 1304 This must be administratively assured; routers that desire to be 1305 compatible with IGMPv1 and IGMPv2 MUST have a configuration option 1306 to send IGMPv1 and IGMPv2 queries. When in IGMPv1 mode, routers 1307 MUST send Periodic Queries with a Max Response Time of 0, and MUST 1308 ignore Leave Group messages. They SHOULD also warn about 1309 receiving an IGMPv2 or IGMPv3 query, although such warnings MUST be rate-limited. 1311 If a router is not explicitly configured to use IGMPv1 and hears 1312 an IGMPv1 Query or IGMPv2 Query, it SHOULD log a warning. These 1313 warnings MUST be rate-limited. 1315 6.3.2 In the Presence of Older Version Group Members 1317 IGMPv3 routers may be placed on a network where there are hosts that 1318 have not yet been upgraded to IGMPv3. The following requirements apply: 1320 IGMPv3 routers MUST keep state per group being forwarded per 1321 interface regarding the lowest version of IGMP heard. For each 1322 group being forwarded per interface, the state variable Oldest 1323 Host Present is kept. Groups can be in one of three states 1324 reflected by the state variable: Oldest Host Present. 1326 Routers MUST act in a compatibility mode on a per group per 1327 interface. The following table summarizes the types of messages 1328 to be used dependent on the value of Oldest Host Present. 1330 Oldest Host Present Messages Utilized 1331 ------------------- ----------------- 1332 IGMPv1 Version 1 Host Membership Queries 1333 IGMPv2 Version 2 Host Membership Queries, 1334 Version 2 Group-Specific Host 1335 Membership Queries 1336 IGMPv3 Version 3 General Membership Queries, 1337 Version 3 Group-Specific Membership 1338 Queries, 1339 Version 3 Group-and-Source Specific 1340 Membership Queries 1342 A router MUST keep a timer per group, Older Host Present Timeout, 1343 if it hears an non-version 3 report for a group. This SHOULD be 1344 set to the value of two query periods. If a router does not hear 1345 a lower version report for the length of two query periods, it 1346 assumes that the older version members have left and reverts to 1347 version 3 operation for that group. 1349 6.3.3 Router Compatibility State Transition Diagram* 1351 RV3MR 1352 ----------- 1353 | | 1354 | V 1355 RV1MR/ST ------------------- RV2MR/ST 1356 -------------| |------------ 1357 | | V3 Mode | | 1358 | ------->| |<------- | 1359 | | ------------------- | | 1360 | | | | 1361 | |TE/DT TE/DT| | 1362 | | | | 1363 V | | V 1364 ----------------- ------------- 1365 ----| | | |--- 1366 RV3MR| | V1 Mode |<-------------------| V2 Mode | |RV3MR 1367 --->| | RV1MR/RT | |<-- 1368 ----------------- ------------- 1369 | ^ | ^ | ^ 1370 | | | | | | 1371 ------ ------ ------- 1372 RV1MR/RT RV2MR RV2MR/RT 1374 * with respect to a single multicast group 1376 Actions 1377 ------- 1378 ST : start Older Host Present Timer 1379 DT : delete Older Host Present Timer 1380 TE : Older Host Present Timer expires 1381 RT : reset Older Host Present Timer 1383 Events 1384 ------ 1385 RV1MR : Receive Version 1 Membership Report 1386 RV2MR : Receive Version 2 Membership Report 1387 RV3MR : Receive Version 3 Membership Report 1389 States 1390 ------ 1391 V3 Mode : A router operates using only IGMPv3 messages for this group. 1393 V2 Mode : An IGMPv2 Membership Report has been heard for this group 1394 within the last Older Host Present Timeout seconds. A 1395 router operates using only IGMPv2 messages for this group. 1397 V1 Mode : An IGMPv1 Membership Report has been heard for this group 1398 within the last Older Host Present Timeout seconds. A 1399 router operates using only IGMPv1 messages for this group. 1401 Note: In V1 Mode and V2 Mode, the Host Membership Query is still a 1402 version 3 query. 1404 7. LIST OF TIMERS, COUNTERS, AND THEIR DEFAULT VALUES 1406 Most of these timers are configurable. If non-default settings are 1407 used, they MUST be consistent among all systems on a single link. Note 1408 that parentheses are used to group expressions to make the algebra 1409 clear. 1411 7.1. Robustness Variable 1413 The Robustness Variable allows tuning for the expected packet loss on a 1414 network. If a network is expected to be lossy, the Robustness Variable 1415 may be increased. IGMP is robust to (Robustness Variable - 1) packet 1416 losses. The Robustness Variable MUST NOT be zero, and SHOULD NOT be 1417 one. Default: 2 1419 7.2. Query Interval 1421 The Query Interval is the interval between General Queries sent by the 1422 Querier. Default: 125 seconds. 1424 By varying the [Query Interval], an administrator may tune the number 1425 of IGMP messages on the network; larger values cause IGMP Queries to be 1426 sent less often. 1428 7.3. Query Response Interval 1430 The Max Response Time inserted into the periodic General Queries. 1431 Default: 100 (10 seconds) 1433 By varying the [Query Response Interval], an administrator may tune the 1434 burstiness of IGMP messages on the network; larger values make the 1435 traffic lest bursty, as host responses are spread out over a larger 1436 interval. The number of seconds represented by the [Query Response 1437 Interval] must me less than the [Query Interval]. 1439 7.4. Group Membership Interval 1441 The Group Membership Interval is the amount of time that must pass 1442 before a multicast router decides there are no more members of a group 1443 on a network. This value MUST be ((the Robustness Variable) times (the 1444 Query Interval)) plus (one Query Response Interval). 1446 7.5. Other Querier Present Interval 1448 The Other Querier Present Interval is the length of time that must pass 1449 before a multicast router decides that there is no longer another 1450 multicast router which should be the querier. This value MUST be ((the 1451 Robustness Variable) times (the Query Interval)) plus (one half of one 1452 Query Response Interval). 1454 7.6. Startup Query Interval 1456 The Startup Query Interval is the interval between General Queries sent 1457 by a Querier on startup. Default: 1/4 the Query Interval. 1459 7.7. Startup Query Count 1461 The Startup Query Count is the number of Queries sent out on startup, 1462 separated by the Startup Query Interval. Default: the Robustness 1463 Variable. 1465 7.8. Last Member Query Interval 1467 The Last Member Query Interval is the Max Response Time inserted into 1468 Group-Specific Queries sent in response to Leave Group messages, and is 1469 also the amount of time between Group-Specific Query messages. Default: 1470 10 (1 second) 1472 This value may be tuned to modify the "leave latency" of the network. A 1473 reduced value results in reduced time to detect the loss of the last 1474 member of a group. 1476 7.9. Last Member Query Count 1478 The Last Member Query Count is the number of Group-Specific Queries sent 1479 before the router assumes there are no local members. Default: the 1480 Robustness Variable. 1482 7.10. Unsolicited Report Interval 1484 The Unsolicited Report Interval is the time between repetitions of a 1485 host's initial report of membership in a group. Default: 10 seconds. 1487 7.11. Version 1 Router Present Timeout 1489 The Version 1 Router Present Timeout is how long a host must wait after 1490 hearing a Version 1 Query before it may send any IGMPv2 messages. 1491 Value: 400 seconds. 1493 8. SECURITY CONSIDERATIONS 1495 We consider the ramifications of a forged message of each type. 1497 Query Message: 1499 A forged Query message from a machine with a lower IP address than 1500 the current Querier will cause Querier duties to be assigned to the 1501 forger. If the forger then sends no more Query messages, other 1502 routers' Other Querier Present timer will time out and one will 1503 resume the role of Querier. During this time, if the forger 1504 ignores Leave Messages, traffic might flow to groups with no 1505 members for up to [Group Membership Interval]. 1507 Report messages: 1509 A forged Report message may cause multicast routers to think there 1510 are members of a group on a network when there are not. Forged 1511 Report messages from the local network are meaningless, since 1512 joining a group on a host is generally an unprivileged operation, 1513 so a local user may trivially gain the same result without forging 1514 any messages. Forged Report messages from external sources are 1515 more troublesome; there are two defenses against externally forged 1516 Reports: 1518 - Ignore the Report if you cannot identify the source address of 1519 the packet as belonging to a network assigned to the interface on 1520 which the packet was received. This solution means that Reports 1521 sent by mobile hosts without addresses on the local network will 1522 be ignored. 1523 - Ignore Report messages without Router Alert options [RFC2113], 1524 and require that routers not forward Report messages. (The 1525 requirement is not a requirement of generalized filtering in the 1526 forwarding path, since the packets already have Router Alert 1527 options in them). This solution breaks backwards compatibility 1528 with implementations of earlier versions of this specification 1529 which did not require Router Alert. 1531 A forged Version 1 Report Message may put a router into "version 1 1532 members present" state for a particular group, meaning that the 1533 router will ignore Leave messages. This can cause traffic to flow 1534 to groups with no members for up to [Group Membership Interval]. 1535 This can be solved by providing routers with a configuration switch 1536 to ignore Version 1 messages completely. This breaks automatic 1537 compatibility with Version 1 hosts, so should only be used in 1538 situations where "fast leave" is critical. 1540 Leave messages: 1542 A forged Leave message will cause the Querier to send out Group- 1543 Specific Queries for the group in question. This causes extra 1544 processing on each router and on each member of the group, but can 1545 not cause loss of desired traffic. 1547 9. ACKNOWLEDGMENTS 1549 Some of the text of this document was copied from [RFC1112] and [IGMPv2] 1550 . 1552 10. REFERENCES 1554 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 1555 August 1989. 1557 [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2", 1558 Internet-Draft, October 1996. 1560 [RFC2113] Katz, D., "IP Router Alert Option," RFC 2113, April 1996. 1562 11. APPENDIX A. 1564 This section elaborates on the need for the various types of Group 1565 Records described in Section 4.2.9 by considering an alternate approach 1566 in sending Group Membership Report messages. 1568 In this approach, the Group Records included within each Group 1569 Membership Report consist of the filter mode (either MODE_IS_INCLUDE or 1570 MODE_IS_EXCLUDE) and the complete list of sources specified for that 1571 address. In other words, each Report conveys the "Full State" of the 1572 Group Record on an interface. There are only two types of Group 1573 Records in this approach, and they follow the filter mode of the 1574 interface multicast address state. 1576 While this approach reduces the number of types of Group Records along 1577 with the processing required to "compute" the membership report by a 1578 system, it unfortunately requires additional processing by the router. 1579 Since the Group Records are only of two types, it is not possible to 1580 distinguish Reports that were sent in response to Queries from those 1581 that were sent by a change of interface state. Membership reports 1582 which are sent in response to Membership Queries are only used to 1583 refresh the existing state and typically do not modify the multicast 1584 address state on the router. Reports that are sent in response to 1585 changes in interface state of a multicast address require that the 1586 router take some action in response to the received report (see Section 1587 5.2.5). The inability to distinguish between the two types of reports 1588 would force a router to treat all Membership Reports as potential 1589 changes in state and could result in unnecessary queries from the 1590 router. 1592 12. AUTHORS' ADDRESSES 1594 Brad Cain 1595 Nortel Networks, Inc. 1596 3 Federal Street 1597 Billerica, MA 01821 1598 phone: +1-978-916-1316 1599 email: bcain@baynetworks.com 1601 Steve Deering 1602 Cisco Systems, Inc. 1603 170 Tasman Drive 1604 San Jose, CA 95134-1706 1605 phone: +1-408-527-8213 1606 email: deering@cisco.com 1608 Ajit Thyagarajan 1609 Torrent Networking Technologies 1610 8181 Professional Place 1611 Landover, MD 20785 1612 phone: +1-301-429-0246 1613 email: ajit@torrentnet.com