idnits 2.17.1 draft-ietf-idmr-igmp-v3-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** 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 == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 18) being 267 lines 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 407 instances of too long lines in the document, the longest one being 6 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 116: '...n implementation MAY impose a limit on...' RFC 2119 keyword, line 117: '..., but that limit MUST NOT be less than...' RFC 2119 keyword, line 285: '...ed message types MUST be silently igno...' RFC 2119 keyword, line 333: '...ts, the checksum MUST be verified befo...' RFC 2119 keyword, line 369: '... implementations MUST include those oc...' (34 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '...t other group...' == Line 15 has weird spacing: '...cuments as In...' == Line 18 has weird spacing: '... may be updat...' == Line 19 has weird spacing: '...other documen...' == Line 20 has weird spacing: '...afts as refer...' == (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 (May 1998) is 9477 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 279, but not defined -- Looks like a reference, but probably isn't: '1' on line 450 -- Looks like a reference, but probably isn't: '2' on line 452 == Missing Reference: 'N' is mentioned on line 457, but not defined == Missing Reference: 'M' is mentioned on line 438, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMPv2' Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Inter-Domain Multicast Routing Working Group 2 INTERNET-DRAFT Brad Cain, Bay Networks 3 Steve Deering, Cisco Systems 4 draft-ietf-idmr-igmp-v3-00.txt Ajit Thyagarajan, Torrent Networks 5 November 21, 1997 6 Expires May 1998 8 Internet Group Management Protocol, Version 3 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts). 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a 21 "working draft" or "work in progress." 23 Please check the I-D abstract listing contained in each Internet 24 Draft directory to learn the current status of this or any other 25 Internet Draft. 27 Distribution of this document is unlimited. 29 Abstract 31 This document specifies Version 3 of the Internet Group Management Protocol, 32 IGMPv3. IGMP is the protocol used by IP systems to report their IP multicast 33 group memberships to neighboring multicast routers. Version 3 of IGMP adds 34 support for ''source filtering'', that is, the ability for a system to report 35 interest in receiving packets *only* from specific source addresses, or from 36 *all but* specific source addresses, sent to a particular multicast address. 37 That information may be used by multicast routing protocols to avoid 38 delivering multicast packets from specific sources to networks where there 39 are no interested receivers. 41 This document is a product of the Inter-Domain Multicast Routing working 42 group within the Internet Engineering Task Force. Comments are 43 solicited and should be addressed to the working group's mailing list at 44 idmr@cs.ucl.ac.uk and/or the author(s). 46 1. INTRODUCTION 48 The Internet Group Management Protocol (IGMP) is used by IP systems (hosts 49 and routers) to report their IP multicast group memberships to any neighboring 50 multicast routers. Note that an IP multicast router may itself be a member of 51 one or more multicast groups, in which case it performs both the "multicast 52 router part" of the protocol (to collect the membership information needed by 53 its multicast routing protocol) and the "group member part" of the protocol 54 (to inform itself and other, neighboring multicast routers of its 55 memberships). 57 IGMP is also used for other IP multicast management functions, using message 58 types other than those used for group membership reporting. This document 59 specifies only the group membership reporting functions and messages. 61 This document specifies Version 3 of IGMP. Version 1, specified in 62 [RFC-1112], was the first widely-deployed version and the first version to 63 become an Internet Standard. Version 2, specified in [IGMPv2], added support 64 for "low leave latency", that is, a reduction in the time it takes for a 65 multicast router to learn that there are no longer any members of a particular 66 group present on an attached network. Version 3 adds support for "source 67 filtering", that is, the ability for a system to report interest in receiving 68 packets *only* from specific source addresses, or from *all but* specific 69 source addresses, sent to a particular multicast address. Version 3 is 70 designed to be interoperable with Versions 1 and 2. 72 2. THE API FOR REQUESTING IP MULTICAST RECEPTION 74 Within an IP system, there is (at least conceptually) an Application 75 Programmming Interface or API used by upper-layer protocols or application 76 programs to ask the IP layer to enable and disable reception of packets sent 77 to specific IP multicast addresses. In order to take full advantage of the 78 capabilities of IGMPv3, a system's IP API must support the following operation 79 (or any logical equivalent): 81 IPMulticastListen ( socket, interface, multicast-address, 82 filter-mode, source-list ) 84 where 86 "socket" is an implementation-specific parameter used to distinguish among 87 different requesting entities (e.g., programs or processes) within the 88 system; the socket parameter of BSD Unix system calls is a specific 89 example. 91 "interface" is a local identifier of the network interface on which 92 reception of the specified multicast address is to be enabled or disabled. 93 Interfaces may be physical (e.g., an Ethernet interface) or virtual 94 (e.g., the endpoint of a Frame Relay virtual circuit or the endpoint of an 95 IP-in-IP "tunnel"). An implementation may allow a special "unspecified" 96 value to be passed as the interface parameter, in which case the request 97 would apply to the "primary" or "default" interface of the system (perhaps 98 established by system configuration). If reception of the same multicast 99 address is desired on more than one interface, IPMulticastListen is 100 invoked separately for each desired interface. 102 "multicast-address" is the IP multicast address to which the request 103 pertains. If reception of more than one multicast address on a given 104 interface is desired, IPMulticastListen is invoked separately for 105 each desired multicast address. 107 "filter-mode" may be either INCLUDE or EXCLUDE. In INCLUDE mode, 108 reception of packets sent to the specified multicast address is requested 109 *only* from those IP source addresses listed in the source-list parameter. 110 In EXCLUDE mode, reception of packets sent to the given multicast address 111 is requested from all IP source addresses *except* those listed in the 112 source-list parameter. 114 "source-list" is an unordered list of zero or more IP unicast addresses 115 from which multicast reception is desired or not desired, depending on 116 the filter mode. An implementation MAY impose a limit on the size of 117 source lists, but that limit MUST NOT be less than 64 addresses per list. 119 For a given combination of socket, interface, and multicast address, only a 120 single filter mode and source list can be in effect at any one time. However, 121 either the filter mode or the source list, or both, may be changed by 122 subsequent IPMulticastListen requests that specify the same socket, interface, 123 and multicast address. 125 Previous versions of IGMP did not support source filters and had a simpler 126 API consisting of Join and Leave operations to enable and disable reception of 127 a given multicast address (from *all* sources) on a given interface. Those 128 Join and Leave operations are supported by the new API as follows: 130 The Join operation is equivalent to 132 IPMulticastListen ( socket, interface, multicast-address, 133 EXCLUDE, {} ) 135 and the Leave operation is equivalent to 137 IPMulticastListen ( socket, interface, multicast-address, 138 INCLUDE, {} ) 140 where {} is an empty source list. 142 It is recommended that implementations continue to support the old API, 143 (perhaps as calls on the new API) for compatibility with pre-existing IP 144 multicast applications. 146 3. MULTICAST RECEPTION STATE MAINTAINED BY SYSTEMS 148 3.1 Socket State 150 For each socket on which IPMulticastListen has been invoked, the system 151 records the desired multicast reception state for that socket. That state 152 conceptually consists of a set of records of the form: 154 (interface, multicast-address, filter-mode, source-list) 156 The socket state evolves in response to each invocation of IPMulticastListen 157 on the socket, as follows: 159 o If the requested filter mode is INCLUDE *and* the requested source list is 160 empty, then the entry corresponding to the requested interface and 161 multicast address is deleted if present. If no such entry is present, the 162 request is ignored. 164 o If the requested filter mode is EXCLUDE *or* the requested source list is 165 non-empty, then the entry corresponding to the requested interface and 166 multicast address, if present, is updated to contain the requested 167 filter mode and source list. If no such entry is present, a new entry is 168 created, using the parameters specified in the request. 170 3.2 Interface State 172 In addition to the per-socket multicast reception state, a system must also 173 maintain or compute multicast reception state for each of its interfaces. 174 That state conceptually consists of a set of records of the form: 176 (multicast-address, filter-mode, source-list) 178 This per-interface state is derived from the per-socket state, but may differ 179 from the per-socket state when different sockets have differing filter modes 180 and/or source lists for the same multicast address and interface. For 181 example, suppose one application or process invokes the following operation on 182 socket s1: 184 IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} ) 186 requesting reception on interface i of packets sent to multicast address m, 187 *only* if they come from source a, b, or c. Suppose another application or 188 process invokes the following operation on socket s2: 190 IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} ) 192 requesting reception on the same interface i of packets sent to the same 193 multicast address m, *only* if they come from sources b, c, or d. In order to 194 satisfy the reception requirements of both sockets, it is necessary for 195 interface i to receive packets sent to m from any one of the sources a, b, c, 196 or d. Thus, in this example, the reception state of interface i for multicast 197 address m has filter mode INCLUDE and source list {a, b, c, d}. 199 (After a multicast packet has been accepted from an interface by the IP layer, 200 its subsequent delivery to the application or process listening on a 201 particular socket depends on the multicast reception state of that socket 202 [and possibly also on other conditions, such as what transport-layer port the 203 socket is bound to]. So, in the above example, if a packet arrives on 204 interface i, destined to multicast address m, with source address a, it may 205 be delivered on socket s1 but not on socket s2.) 207 The general rules for deriving the per-interface state from the per-socket 208 state are as follows: For each distinct (interface, multicast-address) pair 209 that appears in any socket state, a per-interface record is created for that 210 multicast address on that interface. Considering all socket records 211 containing the same (interface, multicast-address) pair, 213 o if *any* such record has a filter mode of EXCLUDE, then the filter mode 214 of the interface record is EXCLUDE, and the source list of the interface 215 record is the intersection of the source lists of all socket records in 216 EXCLUDE mode, minus those source addresses that appear in any socket 217 record in INCLUDE mode. For example, if the socket records for multicast 218 address m on interface i are: 220 from socket s1: ( i, m, EXCLUDE, {a, b, c, d} ) 221 from socket s2: ( i, m, EXCLUDE, {b, c, d, e} ) 222 from socket s3: ( i, m, INCLUDE, {d, e, f} ) 224 then the corresponding interface record on interface i is: 226 ( m, EXCLUDE, {b, c} ) 228 o if *all* such records have a filter mode of INCLUDE, then the filter mode 229 of the interface record is INCLUDE, and the source list of the interface 230 record is the union of the source lists of all the socket records. For 231 example, if the socket records for multicast address m on interface i are: 233 from socket s1: ( i, m, INCLUDE, {a, b, c} ) 234 from socket s2: ( i, m, INCLUDE, {b, c, d} ) 235 from socket s3: ( i, m, INCLUDE, {e, f} ) 237 then the corresponding interface record on interface i is: 239 ( m, INCLUDE, {a, b, c, d, e, f} ) 241 *However*, there is one exception to this rule: if the source list in an 242 interface record in INCLUDE mode would contain too many addresses to fit 243 in an IGMP Version 3 Membership Report message (see paragraph 4.2.5), an 244 interface record of the following form is created instead: 246 ( m, EXCLUDE, {} ) 248 That is, reception of packets to multicast address m from *all* sources is 249 enabled on the interface, whenever the specific list of desired sources is 250 too long to include in an IGMP Report. The exact limit depends on the 251 MTU of the attached network; on Ethernet, for example, the limit is 366 252 addresses. 254 The above rules for deriving the interface state are (re-)evaluated whenever 255 an IPMulticastListen invocation modifies the socket state by adding, deleting, 256 or modifying a per-state record. Note that a change of socket state does not 257 necessarily result in a change of interface state. 259 4. MESSAGE FORMATS 261 IGMP messages are encapsulated in IP datagrams, with an IP protocol number 262 of 2. Every IGMP message described in this document is sent with an IP 263 Time-to-Live of 1, and carries an IP Router Alert option [RFC2113] in its 264 IP header. 266 There are two IGMP message types of concern to the IGMPv3 protocol described 267 in this document: 269 Type Number (hex) Message Name 270 ----------------- ------------ 272 0x11 Membership Query 274 0x22 Version 3 Membership Report 276 An implementation of IGMPv3 must also support the following three message 277 types, for interoperation with previous versions of IGMP (see section ?): 279 0x12 Version 1 Membership Report [RFC-1112] 281 0x16 Version 2 Membership Report [IGMPv2] 283 0x17 Version 2 Leave Group [IGMPv2] 285 Unrecognized message types MUST be silently ignored. Other message types 286 may be used by newer versions or extensions of IGMP, by multicast routing 287 protocols, or for other uses. 289 In this document, unless otherwise qualified, the capitalized words "Query" 290 and "Report" refer to IGMP Membership Queries and IGMP Version 3 Membership 291 Reports, respectively. 293 4.1 Membership Query Message 295 Membership Queries are sent by IP multicast routers to query the multicast 296 reception state of neighboring interfaces. Queries have the following format: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Type = 0x11 | Max Resp Time | Checksum | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Group Address | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Reserved | Number of Sources (N) | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Source Address [1] | 308 +- -+ 309 | Source Address [2] | 310 +- . -+ 311 . . . 312 . . . 313 +- -+ 314 | Source Address [N] | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 4.1.1 Max Response Time 319 The Max Response Time field specifies the maximum time allowed before 320 sending a responding report, in units of 1/10 second. 322 Varying this setting allows IGMPv3 routers to tune the "leave 323 latency" (the time between the moment the last host leaves a group 324 and the moment the routing protocol is notified that there are no more 325 members). It also allows tuning of the burstiness of IGMP traffic on 326 a network. 328 4.1.2 Checksum 330 The Checksum is the 16-bit one's complement of the one's complement 331 sum of the whole IGMP message (the entire IP payload). For 332 computing the checksum, the Checksum field is set to zero. When 333 receiving packets, the checksum MUST be verified before processing 334 a packet. 336 4.1.3 Group Address 338 The Group address field is set to zero when sending a General Query, 339 and set to the IP multicast address being queried when sending a 340 Group-Specific Query or Group-and-Source-Specific Query (see section 341 4.1.8, below). 343 4.1.4 Reserved 345 The Reserved field is set to zero on transmission, and ignored on 346 reception. 348 4.1.5 Number of Sources (N) 350 The Number of Sources (N) field specifies how many source addresses are 351 present in the Query. This number is zero in a General Query or a 352 Group-Specific Query, and non-zero in a Group-and-Source-Specific Query. 353 This number is limited by the MTU of the network over which the Query is 354 transmitted. For example, on an Ethernet with an MTU of 1500 octets, 355 the IP header including the Router Alert option consumes 24 octets, and 356 the IGMP fields up to including the Number of Sources (N) field consume 357 12 octets, leaving 1464 octets for source addresses, which limits the 358 number of source addresses to 366 (1464/4). 360 4.1.6 Source Address [i] 362 The Source Address [i] fields are a vector of n IP unicast addresses, 363 where n is the value in the Number of Sources (N) field. 365 4.1.7 Additional Data 367 If the Packet Length field in the IP header of a received Query indicates 368 that there are additional octets of data present, beyond the fields 369 described here, IGMPv3 implementations MUST include those octets in 370 the computation to verify the received IGMP Checksum, but MUST otherwise 371 ignore those additional octets. When sending a Query, an IGMPv3 372 implementation MUST NOT include additional octets beyond the fields 373 described here. 375 4.1.8 Query Variants 377 There are three variants of the Query message: 379 (1) A "General Query" is sent by a multicast router to learn the complete 380 multicast reception state of the neighboring interfaces (that is, 381 the interfaces attached to the network on which the Query is 382 transmitted). In a General Query, both the Group Address field and 383 the Number of Sources (N) field are zero. 385 (2) A "Group-Specific Query" is sent by a multicast router to learn the 386 reception state, with respect to a *single* multicast address, of the 387 neighboring interfaces. In a Group-Specific Query, the Group Address 388 field contains the multicast address of interest, and the Number of 389 Sources (N) field contains zero. 391 (2) A "Group-and-Source-Specific Query" is sent by a multicast router to 392 learn if any neighboring interface desires reception of packets sent 393 to a specified multicast address, from any of a specified list of 394 sources. In a Group-and-Source-SPecific Query, the Group Address 395 field contains the multicast address of interest, and the Source 396 Address [i] fields contain the source address(es) of interest. 398 4.1.9 IP Destination Addresses for Queries 400 In IGMPv3, General Queries are sent with an IP destination address of 401 224.0.0.1, the all-systems multicast address. Group and Group-and-Source 402 Queries are sent with an IP destination address equal to the multicast address 403 of interest. *However*, a system MUST accept and process any Query whose IP 404 Destination Address field contains *any* of the addresses (unicast or 405 multicast) assigned to the interface on which the Query arrives. 407 4.2 Version 3 Membership Report Message 409 Version 3 Membership Reports are sent by IP systems to report (to neighboring 410 routers) the current multicast reception state, or changes in the multicast 411 reception state, of their interfaces. Reports have the following format: 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type = 0x22 | Reserved | Checksum | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Reserved | Number of Group Records (M) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | 421 . . 422 . Group Record [1] . 423 . . 424 | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | | 427 . . 428 . Group Record [2] . 429 . . 430 | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 . 433 . 434 . 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | | 437 . . 438 . Group Record [M] . 439 . . 440 | | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 where each Group Record has the following internal format: 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Record Type | Reserved | Number of Sources (N) | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Multicast Address | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Source Address [1] | 451 +- -+ 452 | Source Address [2] | 453 +- . -+ 454 . . . 455 . . . 456 +- -+ 457 | Source Address [N] | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 4.2.1 Reserved 462 The Reserved fields are set to zero on transmission, and ignored on 463 reception. 465 4.2.2 Checksum 467 The Checksum is the 16-bit one's complement of the one's complement 468 sum of the whole IGMP message (the entire IP payload). For 469 computing the checksum, the Checksum field is set to zero. When 470 receiving packets, the checksum MUST be verified before processing 471 a message. 473 4.2.3 Number of Group Records (M) 475 The Number of Group Records (M) field specifies how many Group Records 476 are present in this Report. 478 4.2.4 Group Record 480 Each Group Record is a block of fields containing information pertaining 481 to the sender's membership in a single multicast group on the interface 482 from which the Report is sent. 484 4.2.4 Record Type 486 See section 4.2.9, below. 488 4.2.5 Number of Sources (N) 490 The Number of Sources (N) field specifies how many source addresses are 491 present in this Group Record. 493 4.2.6 Multicast Address 495 The Multicast Address field contains the IP multicast address to which 496 this Group Record pertains. 498 4.2.7 Source Address [i] 500 The Source Address [i] fields are a vector of n IP unicast addresses, 501 where n is the value in this record's Number of Sources (N) field. 503 4.2.8 Additional Data 505 If the Packet Length field in the IP header of a received Report indicates 506 that there are additional octets of data present, beyond the last Group 507 Record, IGMPv3 implementations MUST include those octets in the 508 computation to verify the received IGMP Checksum, but MUST otherwise 509 ignore those additional octets. When sending a Report, an IGMPv3 510 implementation MUST NOT include additional octets beyond the last Group 511 Record. 513 4.2.9 Group Record Types 515 There are a number of different types of Group Records that may be included 516 in a Report message: 518 (1) A "Current-State Record" is sent by a system in response to a Query 519 received on an interface. It reports the current reception state of 520 that interface, with respect to a single multicast address. The 521 Record Type of a Current-State Record may be one of the following 522 two values: 524 Value Name and Meaning 525 ----- ---------------- 527 1 MODE_IS_INCLUDE - indicates that the interface has a filter 528 mode of INCLUDE for the specified multicast address. 529 The Source Address [i] fields in this Group Record 530 contain the interface's source list for the 531 specified multicast address, if it is non-empty. 533 2 MODE_IS_EXCLUDE - indicates that the interface has a filter 534 mode of EXCLUDE for the specified multicast address. 535 The Source Address [i] fields in this Group Record 536 contain the interface's source list for the 537 specified multicast address, if it is non-empty. 539 (2) A "Filter-Mode-Change Record" is sent by a system whenever a local 540 invocation of IPMulticastListen causes a change of the filter mode 541 (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to INCLUDE), 542 of the interface-level state entry for a particular multicast address. 543 The Record is included in a Report sent from the interface on which 544 the change occurred. The Record Type of a Filter-Mode-Change Record 545 may be one of the following two values: 547 3 CHANGE_TO_INCLUDE_MODE - indicates that the interface has 548 changed to INCLUDE filter mode for the specified 549 multicast address. The Source Address [i] fields 550 in this Group Record contain the interface's new 551 source list for the specified multicast address, 552 if it is non-empty. 554 4 CHANGE_TO_EXCLUDE_MODE - indicates that the interface has 555 changed to EXCLUDE filter mode for the specified 556 multicast address. The Source Address [i] fields 557 in this Group Record contain the interface's new 558 source list for the specified multicast address, 559 if it is non-empty. 561 (3) A "Source-List-Change Record" is sent by a system whenever a local 562 invocation of IPMulticastListen causes a change of source list 563 that is *not* coincident with a change of filter mode, of the 564 interface-level state entry for a particular multicast address. 565 The Record is included in a Report sent from the interface on which 566 the change occurred. The Record Type of a Source-List-Change Record 567 may be one of the following two values: 569 5 ALLOW_NEW_SOURCES - indicates that the Source Address [i] 570 fields in this Group Record contain a list of the 571 additional sources that the system wishes to 572 hear from, for packets sent to the specified 573 multicast address. If the change was to an INCLUDE 574 source list, these are the addresses that were added 575 to the list; if the change was to an EXCLUDE source 576 list, these are the addresses that were deleted from 577 the list. 579 6 BLOCK_OLD_SOURCES - indicates that the Source Address [i] 580 fields in this Group Record contain a list of the 581 sources that the system no longer wishes to 582 hear from, for packets sent to the specified 583 multicast address. If the change was to an INCLUDE 584 source list, these are the addresses that were 585 deleted from the list; if the change was to an 586 EXCLUDE source list, these are the addresses that 587 were added to the list. 589 If a change of source list results in both allowing new sources and 590 blocking old sources, then two Group Records are sent for the same 591 multicast address, one of type ALLOW_NEW_SOURCES and one of type 592 BLOCK_OLD_SOURCES. 594 We use the term "State-Change Record" to refer to either a Filter-Mode-Change 595 Record or a Source-List-Change Record. 597 Unrecognized Record Type values MUST be silently ignored. 599 4.2.10 IP Destination Addresses for Reports 601 Version 3 Reports are sent with an IP destination address of 224.0.0.?, the 602 all-membership-reports multicast group address. A system that is operating in 603 version 1 or version 2 compatibility modes sends version 1 and version 2 604 Reports to the multicast group specified in the Group Address field of the 605 Report. In addition, a system MUST accept and process any version 1 or 606 version 2 Report whose IP Destination Address field contains *any* of the 607 addresses (unicast or multicast) assigned to the interface on which the Report 608 arrives. 610 4.2.11 Notation for Group Records 612 In the rest of this document, we use the following notation to describe the 613 contents of a Group Record pertaining to a particular multicast address: 615 IS_IN ( x ) - Type MODE_IS_INCLUDE, source addresses x 616 IS_EX ( x ) - Type MODE_IS_EXCLUDE, source addresses x 617 TO_IN ( x ) - Type CHANGE_TO_INCLUDE_MODE, source addresses x 618 TO_EX ( x ) - Type CHANGE_TO_EXCLUDE_MODE, source addresses x 619 ALLOW ( x ) - Type ALLOW_NEW_SOURCES, source addresses x 620 BLOCK ( x ) - Type BLOCK_OLD_SOURCES, source addresses x 622 where x is either: 624 - a capital letter (e.g., "A") to represent the set of source 625 addresses, 627 - a list of zero or more lower-case letters enclosed in braces 628 (e.g., "{a, b, c}" or "{}") to represent the individual source 629 addresses in the list, or 631 - a set expression (e.g., "A + B"), where "x + y" means the union of 632 x and y, "x * y" means the intersection of x and y, and "x - y" 633 means the removal of all elements of set y from set x. 635 4.2.12 Membership Report Size 637 If the entire list of Group Records does not fit within the MTU limits of a 638 single Report message, the Group Records are sent in as many Report 639 messages required to report the entire list of Group Records. Each Report 640 is filled with the maximum number of Group Records within the MTU limit. 642 Similarly, if the list of source addresses comprising a single Group Record 643 does not fit within the MTU limits of a single Report message, the Group 644 Record is sent in as many Report messages required to report the entire list 645 of sources. 647 5. PROTOCOL DESCRIPTION 649 The purpose of IGMP is to enable each multicast router to learn, for each of 650 its directly attached networks, which multicast addresses are of interest to 651 the systems attached to those networks. This information is then provided to 652 whichever multicast routing protocol is being used by the router, in order to 653 ensure that multicast packets are delivered to all networks where there are 654 interested receivers. 656 IGMP version 3 adds the capability for a multicast router to learn which 657 *sources* are of interest to neighboring systems, for packets sent to any 658 particular multicast address. 660 It is important to understand that a multicast router needs to know only that 661 *at least one* system on an attached network is interested in packets to a 662 particular multicast address from a particular source; the multicast router 663 does not need to keep track of the interests of each individual neighboring 664 system. 666 IGMP is an asymmetric protocol, defining separate behaviors for group members 667 -- that is, hosts or routers that wish to receive multicast packets -- and 668 multicast routers. A multicast router that is also a group member performs 669 both parts of the protocol, receiving its own IGMP message transmissions as 670 well as those of its neighbors. 672 If a multicast router has more than one interface on the same network, it 673 needs to operate the multicast router part of IGMP over only one of those 674 interfaces. A group member, on the other hand, must operate the group 675 member part of IGMP over all interfaces from which reception of multicast 676 packets has been requested by IPMulticastListen invocations. 678 Membership in the all-systems multicast group, address 224.0.0.1, is handled 679 as a special case: reception of packets destined to the all-systems multicast 680 address, from all sources, is permanently enabled on all interfaces on which 681 multicast reception is supported. No IGMP messages are ever sent regarding 682 the all-systems multicast address. 684 Note that, in the following descriptions, timer and counter names appear in 685 square brackets. The default values for those timers and counters are 686 specified in section 7. 688 5.1 Group Member Behavior 690 For interoperability with multicast routers running older versions of IGMP, 691 systems maintain a MulticastRouterVersion variable for each interface on which 692 multicast reception is desired. This section describes the behavior of group 693 member systems on interfaces for which MulticastRouterVersion = 3. The 694 algorithm for determining MulticastRouterVersion, and the behavior for 695 versions other than 3, are described in section 6.1. 697 There are three types of events that trigger IGMP protocol actions on an 698 interface on which multicast reception is enabled: 700 o a change of the interface reception state, caused by a local invocation of 701 IPmulticastListen. 703 o reception of a Query. 705 o reception of a Report. 707 The following subsections describe the actions to be taken for each of those 708 cases. 710 5.1.1 Action on Change of Interface State 712 An invocation of IPMulticastListen may cause the multicast reception state of 713 an interface to change, according to the rules in section 3.2. Each such 714 change affects the per-interface entry for a single multicast address. 716 A change of interface state causes the system immediately to transmit a State- 717 Change Report from that interface, with the Group field of the Report carrying 718 the affected multicast address. The contents of the rest of the report are 719 determined by comparing the filter mode and source list for that multicast 720 address before and after the change, according to the table below. If no 721 interface state existed for that multicast address before the change (i.e., 722 the change consisted of creating a new per-interface record), or if no state 723 exists after the change (i.e., the change consisted of deleting a per- 724 interface record), then the "non-existant" state is considered to have a 725 filter mode of INCLUDE and an empty source list. 727 Old State New State State-Change Report Sent 728 --------- --------- ------------------------ 730 INCLUDE (A) INCLUDE (B) ALLOW (B-A), BLOCK (A-B) 732 EXCLUDE (A) EXCLUDE (B) ALLOW (A-B), BLOCK (B-A) 734 INCLUDE (A) EXCLUDE (B) TO_EX (B) 736 EXCLUDE (A) INCLUDE (B) TO_IN (B) 738 To cover the possibility of the State-Change Report being missed by one or 739 more multicast routers, it is retransmitted [Robustness Variable] - 1 more 740 times, at intervals chosen at random from the range (0, [Unsolicited Report 741 Interval]]. 743 If more changes to the same interface state entry occur before all the 744 retransmissions of the State-Change Report for the first change have been 745 completed, each such additional change triggers the immediate transmission of 746 a State-Change Report reflecting the difference between the newest state and 747 the state *before* the first change for which retransmissions were not 748 completed. The transmission of the newer State-Change Report terminates 749 retransmissions of the earlier State-Change Reports for the same multicast 750 address, and becomes the first of [Robustness Variable] transmissions of the 751 newer Report. 753 5.1.2 Action on Reception of a Query 755 A system may receive any of the three variants of IGMPv3 Query messages: a 756 General Query, a Group-Specific Query, or a Group-and-Source-Specific Query 757 (see section 4.1.8). 759 When a system receives a General Query, it adjusts the global "report delay 760 timer" on the interface from which the Query was received. If the timer is 761 not running, it is set to a random value, using the finest clock granularity 762 available on the system, from the range (0, MaxResponseTime], where 763 MaxResponseTime is obtained from the Query message. If the global report 764 timer is already running, it is reset to a new random value only if the 765 requested MaxResponseTime is less than the remaining value of the running 766 timer. Otherwise, it is left running with its current value. 768 When the global report timer expires, the system transmits one or more 769 Reports reporting for each multicast address present on that interface, its 770 filter mode (either MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and the list of 771 sources associated with the multicast address; any group-specific report 772 delay timers, if running, on that interface are deleted as well. If there 773 is a change in filter mode or source address list of a multicast group with 774 the global report delay timer still running, a State-Change Report is sent 775 for that multicast group address as specified in Section 5.1.1; the global 776 report delay timer is not deleted. 778 When a system receives a Group-Specific Query, it performs a similar set of 779 actions as it does when receiving a General Query, *except* that the actions 780 are performed only for the multicast address that was specified in the 781 Group-Specific Query and using the "group-specific report delay timer" 782 instead of the global timer. 784 When a multicast group address's report delay timer expires, the system 785 transmits a Report, reporting that multicast address and the filter mode 786 (either MODE_IS_INCLUDE or MODE_IS_EXCLUDE) and the entire list of sources 787 addresses associated with the multicast address. 789 When a system receives a Group-and-Source-Specific Query, it performs the same 790 actions as it does when receiving a Group-Specific Query, *except*: 792 o the pending report record and report delay timer it creates are 793 *in addition to* any record and timer it may have created for the same 794 multicast address in response to a General or Group-Specific Query. 796 o the initial contents of the newly-created pending report record are 797 determined by comparing the source list in the received Query with the 798 local state, as specified in the following table: 800 Local State Query Source List Pending Report Record 801 ----------- ----------------- --------------------- 803 INCLUDE (A) B IS_IN (A*B) 805 EXCLUDE (A) B IS_IN (B-A) 807 5.2 Multicast Router Behavior 809 5.2.1 Overview 811 Multicast routers use the IGMP protocol to periodically query the multicast 812 reception state of hosts attached to local subnetworks. General Queries are 813 sent periodically; Group-Specific and Group-and-Source-Specific Queries are 814 sent in response to Filter-Mode-Change and Source-List-Change records. 816 IGMPv3 is backward compatible with previous versions of the IGMP protocol. 817 In order to remain backward compatible with older IGMP hosts and routers, 818 IGMPv3 routers must also implement versions 1 and 2 of the protocol 819 (see section 6). 821 5.2.2 Conditions for IGMP Queries 823 IGMPv3 routers send General Queries periodically to request group membership 824 information. Hosts respond to these queries with Current-State Reports. As 825 hosts update the state of individual Group Records, they may send send 826 Filter-Mode-Change Records or Source-List-Change Records. In order for all 827 hosts on a subnet to respond to changes in group membership, a router sends 828 specific queries. A Group-Specific Query is sent to verify there are no 829 neighboring interfaces that desire reception of the specified group. A 830 Group-and-Source Specific Query lists sources within a group that have been 831 requested to be deleted (i.e. not forwarded). This query is sent by a 832 router to learn if any neighboring interfaces desire reception of packets to 833 the specified group address from the specified source addresses. Section 834 4.1.8 describes each query in more detail. 836 5.2.3 IGMP State Maintained by Multicast Routers 838 Routers implementing the IGMPv3 protocol must keep keep state per group 839 per interface. This state consists of a filter-mode, list of sources, and 840 various timers. For each interface on which IGMP exists, a router records 841 the desired reception state for that locally attached network. That state 842 conceptually consists of a set of records of the form: 844 (multicast address, group timer, filter-mode, source-element list) 846 Each member of the source-element list is a record of the form: 848 (source address, source timer) 850 If all sources within a given group are desired, an empty source element list 851 is kept with the filter-mode set to EXCLUSION. This means forward all 852 sources for this group. This is equivalent to the older version join of 853 single group (i.e. as in previous versions of IGMP). 855 5.2.3.1 Definition of Router Filter-Mode 857 To reduce internal state, IGMPv3 routers keep a filter-mode per group per 858 interface. This filter-mode is used to condense the total desired reception 859 state of a group to a minimum set such that all systems memberships are 860 satisfied. The filter-mode of a group record may change when receiving new 861 reports, or when certain timer conditions occur. Upon receiving a host 862 report, the filter-mode is updated to represent the most number of sources 863 desired with the least amount of state. In general, once a filter-mode of 864 EXCLUSION is received, the router filter-mode for that group record will be 865 EXCLUSION. A mechanism to transition back to an INCLUSION filter-mode is 866 specified as all hosts with EXCLUSION filter-mode may cease reporting, 867 leaving the router filter-mode in an EXCLUSION state. Section 5.2.5 868 describes the changes of a router-filter mode per host report received. 869 Section 5.2.6 describes the change in filter-mode when certain timer 870 conditions are met. 872 5.2.3.2 Definition Group Timers 874 A group timer is kept per group per interface state record. A group timer 875 is a decrementing timer with a lower bound of zero. Group timers are updated 876 according to the filter-mode of the group record and type of host report 877 received. Group timers are not always updated per a received group report. 878 A group timer expiring when the filter-mode is INCLUSION means there are no 879 listeners on the attached subnet for that group. A group timer expiring 880 when the filter-mode is EXCLUSION means there are no listeners on the 881 attached subnet in EXCLUSION mode. Section 5.2.5 details the exact setting 882 of the group timer per filter mode and report received. Section 5.2.6 883 details the events when a group timer expires while in EXCLUSION mode. 885 5.2.3.3 Definition of Source Timers 887 A source timer is kept per source element record. A source timer is a 888 decrementing timer with a lower bound of zero. Source timers are updated 889 according to the filter-mode of the group record and type of host report 890 received. Unlike group timers, source timers are always updated for a 891 particular group whenever the source is present in a received record for 892 that group. Section 5.2.5 details the exact setting of the source timer per 893 filter mode and report received. 895 The actions performed upon the expiry of source element timers depend upon 896 the group filter-mode. If a source timer expires with the group in 897 INCLUSION filter-mode, the router concludes that traffic from this particular 898 source is no longer desired on the locally attached interface, and deletes the 899 associated record. If a source timer expires with the group in EXCLUSION 900 filter-mode, the router stops forwarding traffic from this source onto the 901 interface, but does not delete its record. Section 5.2.4 details the actions 902 that should be taken, dependant upon the value of a source timer. 904 5.2.4 IGMPv3 Source Specific Forwarding Rules 906 When a router receives a datagram from a source destined to a particular 907 group, a decision has to be made whether to forward the datagram onto 908 the subnetwork or not. This decision is first dependent on any multicast 909 routing protocols present. Assuming that there are no other routers 910 downstream (or that downstream routers support source-specific pruning/ 911 grafting), the forwarding decision depends on the presence of a group 912 record and/or a source-specific record. If no group record exists, the 913 datagram is not forwarded on the subnetwork. Even if a group record exists, 914 a source-specific record may or may not exist for the particular source. 916 To summarize, the following table details the actions to be performed 917 for traffic originating from a source destined to a group, and upon 918 the expiry of a source-specific timer, based on the group mode and the 919 value of the source-specific timer, if it exists: 921 Group 922 Filter-Mode Source Timer Value Action 923 ----------- ------------------ ------ 925 INCLUDE TIMER > 0 Forward source 927 INCLUDE TIMER == 0 Stop forwarding source and 928 remove source record 930 INCLUDE None Don't forward source 932 EXCLUDE TIMER > 0 Don't forward source 934 EXCLUDE TIMER == 0 Start forwarding source 936 EXCLUDE None Forward source 938 5.2.5 Actions upon Reception of Reports 940 5.2.5.1 Reception of Current-State reports 942 When receiving Current-State Reports, routers update both group timers and 943 source timers. Depending on the routers current filter-mode for a group and 944 the filter-mode of a Current-State Report received for that group, a router 945 may change to a different filter-mode per group. The table below details the 946 actions, with respect to state and timers, that occur at a router when 947 receiving Current-State Reports. 949 The following notation is used to describe the updating of source timers. 950 The notation ( A, B ) will be used to represent the total number of sources 951 for a particular group, where 953 A = set of sources whose timers > 0 (being forwarded) 954 B = set of sources whose timers = 0 (not being forwarded) 956 The variable TQ is one query period plus the time to report field of the 957 last General Query. The variable RI is the time to report field of the 958 last send Query. 960 Router State Report Rec'd New Router State Actions 961 ------------ ------------ ---------------- ------- 963 INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B) = TQ 964 Group Timer = TQ 966 INCLUDE (A) IS_EX (B) EXCLUDE (A*B,B-A) (B-A) = 0 967 Group Timer = TQ 969 EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+A,Y-A) (A) = TQ 971 EXCLUDE (X,Y) IS_EX (B) EXCLUDE (X*A,Y-A) Group Timer = TQ 973 5.2.5.2 Reception of Filter-Mode-Change and Source-List-Change Reports 975 When a change in the global state of a group occurs in a host, the host 976 sends either a Source-List-Change Report or a Filter-Mode-Change Report for 977 that group. As with Current-State Reports, routers must act upon these 978 reports and possibly change their state to reflect the new desired 979 membership state. 981 Routers must query any sources that are requested to be deleted from the 982 network. When a router queries a specific set of sources, it sets the 983 source timers to a small interval (5 secs). If host membership reports are 984 received which express interest in receiving traffic from the specific 985 sources, the corresponding timers are updated. Similarly, when a router 986 queries a specific group, it sets the group timer to a small interval 987 (5 secs). If any membership reports expressing interest in the group are 988 received within the interval, the group timer is updated and traffic is 989 forwarded without any interruption. During the interval, the router continues 990 to forward traffic from the sources that were requested to be deleted to 991 prevent traffic from being interrupted to other interested hosts. 993 The following table details the change in state and actions that are taken 994 when receiving either Filter-Mode-Change or Source-List-Change Reports 995 dependent upon the current state of the group. 997 Router State Report Rec'd New Router State Actions 998 ------------ ------------ ---------------- ------- 1000 INCLUDE (A) ALLOW (B) INCLUDE (A+B) (B)=TQ 1001 Group Timer=TQ 1003 INCLUDE (A) BLOCK (B) INCLUDE (A) (A*B)=RI 1004 Send Q(G,A*B) 1006 INCLUDE (A) ALLOW (B), INCLUDE (A+B) (B)=TQ 1007 BLOCK (C) (A*C)=RI 1008 Send Q(G,A*C) 1009 Group Timer=TQ 1011 INCLUDE (A) TO_EX (B) EXCLUDE (A*B,B-A) (A*B)=RI 1012 Send Q(G,A*B ) 1013 Group Timer=TQ 1015 INCLUDE (A) TO_IN (B) INCLUDE (A+B) (B)=TQ 1016 (A-B)=RI 1017 Send Q(G,A-B) 1018 Group Timer=TQ 1020 EXCLUDE (X,Y) ALLOW (A) EXCLUDE (X+A,Y-A) (A)=TQ 1022 EXCLUDE (X,Y) BLOCK (A) EXCLUDE (X+(A-Y),Y) (A-Y)=RI 1023 Send Q(G,A-Y) 1025 EXCLUDE (X,Y) ALLOW (A), EXCLUDE (X+A+(B-Y),Y-A) (A)=TQ 1026 BLOCK (B) (B-Y)=RI 1027 Send Q(G,B-Y) 1029 EXCLUDE (X,Y) TO_EX (A) EXCLUDE (X*A,Y*A) (A-Y)=RI 1030 Send Q(G,A-Y) 1031 Group Timer=TQ 1033 EXCLUDE (X,Y) TO_IN (A) EXCLUDE (X+A,Y-A) (A)=TQ 1034 (X-A)=RI 1035 Send Q(G,*) 1037 5.2.6 Switching Filter-Modes 1039 The IGMPv3 group timer is used as a mechanism for transitioning from 1040 EXCLUSION filter-mode to INCLUSION filter-mode. When a group timer 1041 expires with the group in INCLUSION filter-mode, a router concludes that 1042 there are no group members present on the locally attached interface and 1043 deletes the group record and the associated source records. 1045 When a group timer expires with the group in EXCLUSION filter-mode, a router 1046 assumes that there are no hosts in EXCLUSION filter-mode are present on the 1047 attached subnetwork, and switches to INCLUSION filter-mode. In addition, 1048 all source-element records with zero timer values are deleted and the group 1049 timer assumes the maximum value among all the remaining source-element 1050 records corresponding to that group. A Group-Specific Query is then sent 1051 for the group to determine the desired group and source state for that group. 1053 5.2.7 Action of Reception of Queries 1055 IGMPv3 uses the same querier election method as previous versions. Upon 1056 receiving an IGMPv3 General Query from another router, the querier ceases to 1057 send General Queries and sets the OTHER_QUERIER_PRESENT timer. Upon expiry 1058 of OTHER_QUERIER_PRESENT timer, a router becomes the querier. Routers who 1059 are not the acting querier reset OTHER_QUERIER_PRESENT timer upon reception 1060 of a IGMPv3 General Query. For details of compatibility between versions 1061 see section 6. 1063 6. INTEROPERATION WITH OLDER VERSIONS OF IGMP 1065 IGMP version 3 hosts and routers interoperate with hosts and routers that 1066 have not yet been upgraded to IGMPv3. This compatibility is maintained by 1067 hosts and routers taking appropriate actions depending on the versions of 1068 IGMP operating on hosts and routers within a network. 1070 6.1 Query Version Distinctions 1072 The IGMP version of a Host Membership Query message is determined as 1073 follows: 1075 IGMPv1 Query: length = 8 octets AND Max Response Time field is zero 1077 IGMPv2 Query: length = 8 octets AND Max Response Time field is non-zero 1079 IGMPv3 Query: length >= 12 octets AND Reserved field is zero 1081 Query messages that do not match any of the above conditions (e.g., a 1082 Query of length 10 octets) must be silently ignored. 1084 6.2 Group Member Behavior 1086 IGMPv3 hosts can operate in version 1 and version 2 compatibility modes. 1087 The mode in which a host operates is governed by the version of the querier 1088 router on an interface. The version of the querier can be determined 1089 from a Host Membership Query. 1091 IGMPv3 hosts keep state per local interface regarding the version of querier 1092 on the attached network. Hosts can be in one of three states depending on 1093 the version of querier on their attached networks. This state is reflected 1094 by Querier Version, a state variable kept per interface describing the 1095 version of querier on the attached network. This state variable can have 1096 only one of three values: IGMPv3, IGMPv2, IGMPv1. When Querier Version is 1097 IGMPv3, a host acts using the IGMPv3 protocol. When Querier Version 1098 is IGMPv2, a host acts in IGMPv2 compatibility mode, using only the IGMPv2 1099 protocol. When Querier Version is IGMPv1, a host acts in IGMPv1 1100 compatibility mode, using the IGMPv1 protocol. 1102 If a lower version query (as compared to Querier Version) is received on 1103 an interface, this state will change immediately to reflect the older 1104 version querier and the host will operate in that lower version 1105 compatibility mode. However, if a higher version query (as compared to 1106 Querier Version) is received, it will not immediately change it's state. 1107 This is to prevent the problem when newer version queries are sent by a 1108 router restarting and having not yet yielded to an older version querier. 1110 Each time a non-version 3 query is received, a host sets a timer: Older 1111 Version Querier Present Timeout. The state variable, Querier Version, 1112 reflecting the version of querier on an interface will be based on this 1113 timer. If a host hears a newer version query (as compared to Querier 1114 Version), it will not change its operating state until after the timer 1115 expires. 1117 6.2.1 In the Presence of Older Version Queriers 1119 An IGMPv3 host may be placed on a network where the Querier router has 1120 not yet been upgraded to IGMPv3. The following requirements apply: 1122 An older version router expects older version Membership Reports in 1123 response to its Queries, and will not pay attention to Version 3 1124 Membership Reports. Therefore, a state variable MUST be kept for each 1125 interface, describing whether the multicast Querier on that 1126 interface is running IGMPv1, IGMPv2, or IGMPv3. This variable MUST be 1127 based upon whether or not the older version query was heard in the 1128 last [Older Version Querier Present Timeout] seconds, and MUST NOT be 1129 based upon the type of the last Query heard. This state variable MUST 1130 be used to decide what type of Membership Reports to send for unsolicited 1131 Membership Reports as well as Membership Reports in response to Queries. 1133 Version 1 Querier 1135 An IGMPv1 router will send General Queries with the Max Response 1136 Time set to 0. This MUST be interpreted as a value of 100 (10 1137 seconds). 1139 An IGMPv3 host MAY suppress Leave Group messages and Filter-Mode- 1140 Change Reports on a network where the Querier is using IGMPv1. 1142 Version 2 Querier 1144 An IGMPv3 host MAY suppress Filter-Mode-Change Reports on a network 1145 where the Querier is using IGMPv2. 1147 The following table summarizes an IGMPv3 host response to different types 1148 of queries: 1150 Querier 1151 Version Query Type Host Response 1152 ------- ---------- ------------- 1153 IGMPv1 Host Membership Query IGMPv1 Membership Report 1154 IGMPv2 Host Membership Query IGMPv2 Membership Report 1155 IGMPv2 Group-Specific Membership Query IGMPv2 Membership Report 1156 IGMPv3 Host Membership Query IGMPv3 Membership Report 1157 IGMPv3 Group-Specific Membership Query IGMPv3 Membership Report 1158 IGMPv3 Source-Specific Membership Query IGMPv3 Membership Report 1160 6.2.2 In the Presence of Older Version Group Members 1162 An IGMPv3 host may be placed on a network where there are hosts that have 1163 not yet been upgraded to IGMPv3. The following requirement applies: 1165 The host MUST allow its Membership Report to be suppressed by 1166 either a Version 1 Membership Report, or a Version 2 Membership 1167 Report. 1169 An IGMPv3 host or router MUST internally map older version reports 1170 to version 3 reports in the following way: 1172 Type of IGMP Message Mapping 1173 -------------------- ------- 1174 IGMPv1 Membership Report: IS_EX(0) Report 1176 IGMPv2 Membership Report: IS_EX(0) Report 1178 IGMPv2 Group Specific Query: Q(G,*) for group being queried 1180 IGMPv2 Leave Message: TO_IN(NULL) for group in leave 1181 message 1183 6.2.3 Group Member Compatibility State Transition Diagram 1185 RQ3 1186 ----------- 1187 | | 1188 | V 1189 RQ1/ST ------------------- RQ2/ST 1190 ---------------| |---------------- 1191 | | V3 Mode | | 1192 | ------->| |<------- | 1193 | | ------------------- | | 1194 | | | | 1195 | |TE/DT TE/DT| | 1196 | | | | 1197 V | | V 1198 ------------------- ------------------- 1199 ----| | | |---- 1200 RQ3| | V1 Mode |<-------------------| V2 Mode | |RQ3 1201 --->| | RQ1/RT | |<--- 1202 ------------------- ------------------- 1203 | ^ | ^ | ^ 1204 | | | | | | 1205 ------ ------ ----------- 1206 RQ1/RT RQ2 RQ2/RT 1208 Actions 1209 ------- 1210 ST : start Older Version Querier Present Timer 1211 DT : delete Older Version Querier Present Timer 1212 TE : Older Version Querier Present Timer expires 1213 RT : reset Older Version Querier Present Timer 1215 Events 1216 ------ 1217 RQ1 : Receive IGMPv1 Host Membership Query 1218 RQ2 : Receive IGMPv2 Host Membership Query 1219 RQ3 : Receive IGMPv3 Host Membership Query 1221 States 1222 ------ 1223 V3 Mode : An IGMPv3 router is the present querier on an interface. The 1224 host uses IGMPv3 Membership Reports 1226 V2 Mode : An IGMPv2 router is the present querier on an interface. The 1227 host uses IGMPv2 Membership Reports and IGMPv2 Leave Group 1228 messages. 1230 V1 Mode : An IGMPv1 router is the present querier on an interface. The 1231 host uses IGMPv1 Membership Reports. 1233 6.3 Multicast Router Behavior 1235 6.3.1 In the Presence of Older Version Queriers 1237 IGMPv3 routers may be placed on a network where at least one router on the 1238 network has not not yet been upgraded to IGMPv3. The following requirements 1239 apply: 1241 If any older versions of IGMP are present on routers, the querier MUST 1242 use the lowest version of IGMP present on the network. 1243 This must be administratively assured; routers that desire to be 1244 compatible with IGMPv1 and IGMPv2 MUST have a configuration option to 1245 send IGMPv1 and IGMPv2 queries. When in IGMPv1 mode, routers MUST 1246 send Periodic Queries with a Max Response Time of 0, and MUST ignore 1247 Leave Group messages. They SHOULD also warn about receiving an 1248 IGMPv2 or IGMPv3 query, although such warnings MUST be rate-limited. 1250 If a router is not explicitly configured to use IGMPv1 and hears an 1251 IGMPv1 Query or IGMPv2 Query, it SHOULD log a warning. These warnings 1252 MUST be rate-limited. 1254 6.3.2 In the Presence of Older Version Group Members 1256 IGMPv3 routers may be placed on a network where there are hosts that have not 1257 yet been upgraded to IGMPv3. The following requirements apply: 1259 IGMPv3 routers MUST keep state per group being forwarded per interface 1260 regarding the lowest version of IGMP heard. For each group being 1261 forwarded per interface, the state variable Oldest Host Present is 1262 kept. Groups can be in one of three states reflected by the state 1263 variable: Oldest Host Present. 1265 Routers MUST act in a compatibility mode on a per group per interface. 1266 The following table summarizes the types of messages to be used 1267 dependent on the value of Oldest Host Present. 1269 Oldest Host Present Messages Utilized 1270 ------------------- ----------------- 1271 IGMPv1 Version 1 Host Membership Queries 1272 IGMPv2 Version 2 Host Membership Queries, 1273 Version 2 Group-Specific Host 1274 Membership Queries 1275 IGMPv3 Version 3 General Membership Queries, 1276 Version 3 Group-Specific Membership 1277 Queries, 1278 Version 3 Group-and-Source Specific 1279 Membership Queries 1281 A router MUST keep a timer per group, Older Host Present Timeout, if 1282 it hears an non-version 3 report for a group. This SHOULD be set to 1283 the value of two query periods. If a router does not hear a lower 1284 version report for the length of two query periods, it assumes that 1285 the older version members have left and reverts to version 3 operation 1286 for that group. 1288 6.3.3 Router Compatibility State Transition Diagram* 1290 RV3MR 1291 ----------- 1292 | | 1293 | V 1294 RV1MR/ST ------------------- RV2MR/ST 1295 ----------------| |---------------- 1296 | | V3 Mode | | 1297 | ------->| |<------- | 1298 | | ------------------- | | 1299 | | | | 1300 | |TE/DT TE/DT| | 1301 | | | | 1302 V | | V 1303 ------------------- ------------------- 1304 ----| | | |---- 1305 RV3MR| | V1 Mode |<-------------------| V2 Mode | |RV3MR 1306 --->| | RV1MR/RT | |<--- 1307 ------------------- ------------------- 1308 | ^ | ^ | ^ 1309 | | | | | | 1310 ------ ------ ----------- 1311 RV1MR/RT RV2MR RV2MR/RT 1313 * with respect to a single multicast group 1315 Actions 1316 ------- 1317 ST : start Older Host Present Timer 1318 DT : delete Older Host Present Timer 1319 TE : Older Host Present Timer expires 1320 RT : reset Older Host Present Timer 1322 Events 1323 ------ 1324 RV1MR : Receive Version 1 Membership Report 1325 RV2MR : Receive Version 2 Membership Report 1326 RV3MR : Receive Version 3 Membership Report 1328 States 1329 ------ 1330 V3 Mode : A router operates using only IGMPv3 messages for this group. 1332 V2 Mode : An IGMPv2 Membership Report has been heard for this group 1333 within the last Older Host Present Timeout seconds. A router 1334 operates using only IGMPv2 messages for this group. 1336 V1 Mode : An IGMPv1 Membership Report has been heard for this group 1337 within the last Older Host Present Timeout seconds. A router 1338 operates using only IGMPv1 messages for this group. 1340 Note: In V1 Mode and V2 Mode, the Host Membership Query is still a 1341 version 3 query. 1343 7. LIST OF TIMERS, COUNTERS, AND THEIR DEFAULT VALUES 1345 Most of these timers are configurable. If non-default settings are 1346 used, they MUST be consistent among all systems on a single link. Note 1347 that parentheses are used to group expressions to make the algebra 1348 clear. 1350 7.1. Robustness Variable 1352 The Robustness Variable allows tuning for the expected packet loss on a 1353 network. If a network is expected to be lossy, the Robustness Variable 1354 may be increased. IGMP is robust to (Robustness Variable - 1) packet 1355 losses. The Robustness Variable MUST NOT be zero, and SHOULD NOT be 1356 one. Default: 2 1358 7.2. Query Interval 1360 The Query Interval is the interval between General Queries sent by the 1361 Querier. Default: 125 seconds. 1363 By varying the [Query Interval], an administrator may tune the number of 1364 IGMP messages on the network; larger values cause IGMP Queries to be sent 1365 less often. 1367 7.3. Query Response Interval 1369 The Max Response Time inserted into the periodic General Queries. 1370 Default: 100 (10 seconds) 1372 By varying the [Query Response Interval], an administrator may tune the 1373 burstiness of IGMP messages on the network; larger values make the 1374 traffic lest bursty, as host responses are spread out over a larger 1375 interval. The number of seconds represented by the [Query Response 1376 Interval] must me less than the [Query Interval]. 1378 7.4. Group Membership Interval 1380 The Group Membership Interval is the amount of time that must pass 1381 before a multicast router decides there are no more members of a group 1382 on a network. This value MUST be ((the Robustness Variable) times (the 1383 Query Interval)) plus (one Query Response Interval). 1385 7.5. Other Querier Present Interval 1387 The Other Querier Present Interval is the length of time that must pass 1388 before a multicast router decides that there is no longer another 1389 multicast router which should be the querier. This value MUST be ((the 1390 Robustness Variable) times (the Query Interval)) plus (one half of one 1391 Query Response Interval). 1393 7.6. Startup Query Interval 1395 The Startup Query Interval is the interval between General Queries sent 1396 by a Querier on startup. Default: 1/4 the Query Interval. 1398 7.7. Startup Query Count 1400 The Startup Query Count is the number of Queries sent out on startup, 1401 separated by the Startup Query Interval. Default: the Robustness 1402 Variable. 1404 7.8. Last Member Query Interval 1406 The Last Member Query Interval is the Max Response Time inserted into 1407 Group-Specific Queries sent in response to Leave Group messages, and is 1408 also the amount of time between Group-Specific Query messages. Default: 1409 10 (1 second) 1411 This value may be tuned to modify the "leave latency" of the network. A 1412 reduced value results in reduced time to detect the loss of the last 1413 member of a group. 1415 7.9. Last Member Query Count 1417 The Last Member Query Count is the number of Group-Specific Queries sent 1418 before the router assumes there are no local members. Default: the 1419 Robustness Variable. 1421 7.10. Unsolicited Report Interval 1423 The Unsolicited Report Interval is the time between repetitions of a 1424 host's initial report of membership in a group. Default: 10 seconds. 1426 7.11. Version 1 Router Present Timeout 1428 The Version 1 Router Present Timeout is how long a host must wait after 1429 hearing a Version 1 Query before it may send any IGMPv2 messages. 1430 Value: 400 seconds. 1432 9. SECURITY CONSIDERATIONS 1434 We consider the ramifications of a forged message of each type. 1436 Query Message: 1438 A forged Query message from a machine with a lower IP address than 1439 the current Querier will cause Querier duties to be assigned to the 1440 forger. If the forger then sends no more Query messages, other 1441 routers' Other Querier Present timer will time out and one will 1442 resume the role of Querier. During this time, if the forger 1443 ignores Leave Messages, traffic might flow to groups with no 1444 members for up to [Group Membership Interval]. 1446 Report messages: 1448 A forged Report message may cause multicast routers to think there 1449 are members of a group on a network when there are not. Forged 1450 Report messages from the local network are meaningless, since 1451 joining a group on a host is generally an unprivileged operation, 1452 so a local user may trivially gain the same result without forging 1453 any messages. Forged Report messages from external sources are 1454 more troublesome; there are two defenses against externally forged 1455 Reports: 1456 - Ignore the Report if you cannot identify the source address of 1457 the packet as belonging to a network assigned to the interface on 1458 which the packet was received. This solution means that Reports 1459 sent by mobile hosts without addresses on the local network will 1460 be ignored. 1461 - Ignore Report messages without Router Alert options [RFC2113], and 1462 require that routers not forward Report messages. (The 1463 requirement is not a requirement of generalized filtering in the 1464 forwarding path, since the packets already have Router Alert 1465 options in them). This solution breaks backwards compatibility 1466 with implementations of earlier versions of this specification 1467 which did not require Router Alert. 1469 A forged Version 1 Report Message may put a router into "version 1 1470 members present" state for a particular group, meaning that the 1471 router will ignore Leave messages. This can cause traffic to flow 1472 to groups with no members for up to [Group Membership Interval]. 1473 This can be solved by providing routers with a configuration switch 1474 to ignore Version 1 messages completely. This breaks automatic 1475 compatibility with Version 1 hosts, so should only be used in 1476 situations where "fast leave" is critical. 1478 Leave messages: 1480 A forged Leave message will cause the Querier to send out Group- 1481 Specific Queries for the group in question. This causes extra 1482 processing on each router and on each member of the group, but can 1483 not cause loss of desired traffic. 1485 10. ACKNOWLEDGMENTS 1487 Some of the text of this document was copied from [RFC1112] and [IGMPv2]. 1489 11. REFERENCES 1491 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 1492 August 1989. 1494 [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2", 1495 Internet-Draft, October 1996. 1497 [RFC2113] Katz, D., "IP Router Alert Option," RFC 2113, April 1996. 1499 12.0 APPENDIX A. 1501 This section elaborates on the need for the various types of Group Records 1502 described in Section 4.2.9 by considering an alternate approach in sending 1503 Group Membership Report messages. 1505 In this approach, the Group Records included within each Group Membership 1506 Report consist of the filter mode (either MODE_IS_INCLUDE or MODE_IS_EXCLUDE) 1507 and the complete list of sources specified for that address. In other words, 1508 each Report conveys the "Full State" of the Group Record on an interface. 1509 There are only two types of Group Records in this approach, and they follow 1510 the filter mode of the interface multicast address state. 1512 While this approach reduces the number of types of Group Records along with 1513 the processing required to "compute" the membership report by a system, it 1514 unfortunately requires additional processing by the router. Since the Group 1515 Records are only of two types, it is not possible to distinguish Reports that 1516 were sent in response to Queries from those that were sent by a change of 1517 interface state. Membership reports which are sent in response to Membership 1518 Queries are only used to refresh the existing state and typically do not 1519 modify the multicast address state on the router. Reports that are sent in 1520 response to changes in interface state of a multicast address require that the 1521 router take some action in response to the received report (see Section 1522 5.2.5). The inability to distinguish between the two types of reports would 1523 force a router to treat all Membership Reports as potential changes in state 1524 and could result in unnecessary queries from the router. 1526 13. AUTHORS' ADDRESSES 1528 Brad Cain 1529 Bay Networks, Inc. 1530 3 Federal Street 1531 Billerica, MA 01821 1532 phone: +1-978-916-1316 1533 email: bcain@baynetworks.com 1535 Steve Deering 1536 Cisco Systems, Inc. 1537 170 Tasman Drive 1538 San Jose, CA 95134-1706 1539 phone: +1-408-527-8213 1540 email: deering@cisco.com 1542 Ajit Thyagarajan 1543 Torrent Networking Technologies 1544 8181 Professional Place 1545 Landover, MD 20785 1546 phone: +1-301-429-0246 1547 email: ajit@torrentnet.com