idnits 2.17.1 draft-ietf-idmr-igmp-v2-07.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-26) 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 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 43 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 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...t other group...' == Line 14 has weird spacing: '...cuments as In...' == Line 17 has weird spacing: '... may be updat...' == Line 18 has weird spacing: '...other documen...' == Line 19 has weird spacing: '...afts as refer...' == (8 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 (October 23, 1997) is 9682 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 section? 'Bradner97' on line 49 looks like a reference -- Missing reference section? 'Katz97' on line 945 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 4 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 W. Fenner 3 draft-ietf-idmr-igmp-v2-07.txt Xerox PARC 4 Obsoletes: Appendix I of RFC1112 October 23, 1997 5 Expires April 1997 7 Internet Group Management Protocol, Version 2 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts). 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a 20 "working draft" or "work in progress." 22 Please check the I-D abstract listing contained in each Internet 23 Draft directory to learn the current status of this or any other 24 Internet Draft. 26 Distribution of this document is unlimited. 28 Abstract 30 This draft documents IGMPv2, used by IP hosts to report their 31 multicast group memberships to routers. It replaces Appendix I of 32 RFC1112. 34 IGMPv2 allows group membership termination to be quickly reported 35 to the routing protocol, which is important for high-bandwidth 36 multicast groups and/or subnets with highly volatile group 37 membership. 39 This document is a product of the Inter-Domain Multicast Routing working 40 group within the Internet Engineering Task Force. Comments are 41 solicited and should be addressed to the working group's mailing list at 42 idmr@cs.ucl.ac.uk and/or the author(s). 44 1. Definitions 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119 [Bradner97]. 50 2. Introduction 52 The Internet Group Management Protocol (IGMP) is used by IP hosts to 53 report their multicast group memberships to any immediately-neighboring 54 multicast routers. This memo describes only the use of IGMP between 55 hosts and routers to determine group membership. Routers that are 56 members of multicast groups are expected to behave as hosts as well as 57 routers, and may even respond to their own queries. IGMP may also be 58 used between routers, but such use is not specified here. 60 Like ICMP, IGMP is a integral part of IP. It is required to be 61 implemented by all hosts wishing to receive IP multicasts. IGMP 62 messages are encapsulated in IP datagrams, with an IP protocol number of 63 2. All IGMP messages described in this document are sent with IP TTL 1, 64 and contain the IP Router Alert option [Katz97] in their IP header. All 65 IGMP messages of concern to hosts have the following format: 67 0 1 2 3 68 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 69 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 70 | Type | Max Resp Time | Checksum | 71 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 72 | Group Address | 73 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 75 2.1. Type 77 There are three types of IGMP messages of concern to the host- 78 router interaction: 80 0x11 = Membership Query 81 There are two sub-types of Membership Query messages: 82 - General Query, used to learn which groups have members on an 83 attached network. 84 - Group-Specific Query, used to learn if a particular group 85 has any members on an attached network. 86 These two messages are differentiated by the Group Address, as 87 described in section 1.4 . Membership Query messages are 88 referred to simply as "Query" messages. 90 0x16 = Version 2 Membership Report 91 0x17 = Leave Group 93 There is an additional type of message, for backwards-compatibility 94 with IGMPv1: 96 0x12 = Version 1 Membership Report 98 This document refers to Membership Reports simply as "Reports". 99 When no version is specified, the statement applies equally to both 100 versions. 102 Unrecognized message types should be silently ignored. New message 103 types may be used by newer versions of IGMP, by multicast routing 104 protocols, or other uses. 106 2.2. Max Response Time 108 The Max Response Time field is meaningful only in Membership Query 109 messages, and specifies the maximum allowed time before sending a 110 responding report in units of 1/10 second. In all other messages, 111 it is set to zero by the sender and ignored by receivers. 113 Varying this setting allows IGMPv2 routers to tune the "leave 114 latency" (the time between the moment the last host leaves a group 115 and when the routing protocol is notified that there are no more 116 members), as discussed in section 7.8. It also allows tuning of 117 the burstiness of IGMP traffic on a subnet, as discussed in section 118 7.3. 120 2.3. Checksum 122 The checksum is the 16-bit one's complement of the one's complement 123 sum of the whole IGMP message (the entire IP payload). For 124 computing the checksum, the checksum field is set to zero. When 125 receiving packets, the checksum MUST be verified before processing 126 a packet. 128 2.4. Group Address 130 In a Membership Query message, the group address field is set to 131 zero when sending a General Query, and set to the group address 132 being queried when sending a Group-Specific Query. 134 In a Membership Report or Leave Group message, the group address 135 field holds the IP multicast group address of the group being 136 reported or left. 138 2.5. Other fields 140 Note that IGMP messages may be longer than 8 octets, especially 141 future backwards-compatible versions of IGMP. As long as the Type 142 is one that is recognized, an IGMPv2 implementation MUST ignore 143 anything past the first 8 octets while processing the packet. 144 However, the IGMP checksum is always computed over the whole IP 145 payload, not just over the first 8 octets. 147 3. Protocol Description 149 Note that defaults for timer values are described later in this 150 document. Timer and counter names appear in square brackets. 152 The term "interface" is sometimes used in this document to mean "the 153 primary interface on an attached network"; if a router has multiple 154 physical interfaces on a single network this protocol need only run on 155 one of them. Hosts, on the other hand, need to perform their actions on 156 all interfaces that have memberships associated with them. 158 Multicast routers use IGMP to learn which groups have members on each of 159 their attached physical networks. A multicast router keeps a list of 160 multicast group memberships for each attached network, and a timer for 161 each membership. "Multicast group memberships" means the presence of at 162 least one member of a multicast group on a given attached network, not a 163 list of all of the members. With respect to each of its attached 164 networks, a multicast router may assume one of two roles: Querier or 165 Non-Querier. There is normally only one Querier per physical network. 166 All multicast routers start up as a Querier on each attached network. 167 If a multicast router hears a Query message from a router with a lower 168 IP address, it MUST become a Non-Querier on that network. If a router 169 has not heard a Query message from another router for [Other Querier 170 Present Interval], it resumes the role of Querier. Routers periodically 171 [Query Interval] send a General Query on each attached network for which 172 this router is the Querier, to solicit membership information. On 173 startup, a router SHOULD send [Startup Query Count] General Queries 174 spaced closely together [Startup Query Interval] in order to quickly and 175 reliably determine membership information. A General Query is addressed 176 to the all-systems multicast group (224.0.0.1), has a Group Address 177 field of 0, and has a Max Response Time of [Query Response Interval]. 179 When a host receives a General Query, it sets delay timers for each 180 group (excluding the all-systems group) of which it is a member on the 181 interface from which it received the query. Each timer is set to a 182 different random value, using the highest clock granularity available on 183 the host, selected from the range (0, Max Response Time] with Max 184 Response Time as specified in the Query packet. When a host receives a 185 Group-Specific Query, it sets a delay timer to a random value selected 186 from the range (0, Max Response Time] as above for the group being 187 queried if it is a member on the interface from which it received the 188 query. If a timer for the group is already running, it is reset to the 189 random value only if the requested Max Response Time is less than the 190 remaining value of the running timer. When a group's timer expires, the 191 host multicasts a Version 2 Membership Report to the group, with IP TTL 192 of 1. If the host receives another host's Report (version 1 or 2) while 193 it has a timer running, it stops its timer for the specified group and 194 does not send a Report, in order to suppress duplicate Reports. 196 When a router receives a Report, it adds the group being reported to the 197 list of multicast group memberships on the network on which it received 198 the Report and sets the timer for the membership to the [Group 199 Membership Interval]. Repeated Reports refresh the timer. If no 200 Reports are received for a particular group before this timer has 201 expired, the router assumes that the group has no local members and that 202 it need not forward remotely-originated multicasts for that group onto 203 the attached network. 205 When a host joins a multicast group, it should immediately transmit an 206 unsolicited Version 2 Membership Report for that group, in case it is 207 the first member of that group on the network. To cover the possibility 208 of the initial Membership Report being lost or damaged, it is 209 recommended that it be repeated once or twice after short delays 210 [Unsolicited Report Interval]. (A simple way to accomplish this is to 211 send the initial Version 2 Membership Report and then act as if a 212 Group-Specific Query was received for that group, and set a timer 213 appropriately). 215 When a host leaves a multicast group, if it was the last host to reply 216 to a Query with a Membership Report for that group, it SHOULD send a 217 Leave Group message to the all-routers multicast group (224.0.0.2). If 218 it was not the last host to reply to a Query, it MAY send nothing as 219 there must be another member on the subnet. This is an optimization to 220 reduce traffic; a host without sufficient storage to remember whether or 221 not it was the last host to reply MAY always send a Leave Group message 222 when it leaves a group. Routers SHOULD accept a Leave Group message 223 addressed to the group being left, in order to accommodate 224 implementations of an earlier version of this standard. Leave Group 225 messages are addressed to the all-routers group because other group 226 members have no need to know that a host has left the group, but it does 227 no harm to address the message to the group. 229 When a Querier receives a Leave Group message for a group that has group 230 members on the reception interface, it sends [Last Member Query Count] 231 Group-Specific Queries every [Last Member Query Interval] to the group 232 being left. These Group-Specific Queries have their Max Response time 233 set to [Last Member Query Interval]. If no Reports are received after 234 the response time of the last query expires, the routers assume that the 235 group has no local members, as above. Any Querier to non-Querier 236 transition is ignored during this time; the same router keeps sending 237 the Group-Specific Queries. 239 Non-Queriers MUST ignore Leave Group messages, and Queriers SHOULD 240 ignore Leave Group messages for which there are no group members on the 241 reception interface. 243 When a non-Querier receives a Group-Specific Query message, if its 244 existing group membership timer is greater than [Last Member Query 245 Count] times the Max Response Time specified in the message, it sets its 246 group membership timer to that value. 248 4. Compatibility with IGMPv1 Routers 250 An IGMPv2 host may be placed on a subnet where the Querier router has 251 not yet been upgraded to IGMPv2. The following requirements apply: 253 The IGMPv1 router will send General Queries with the Max Response 254 Time set to 0. This MUST be interpreted as a value of 100 (10 255 seconds). 257 The IGMPv1 router expects Version 1 Membership Reports in response 258 to its Queries, and will not pay attention to Version 2 Membership 259 Reports. Therefore, a state variable MUST be kept for each 260 interface, describing whether the multicast Querier on that 261 interface is running IGMPv1 or IGMPv2. This variable MUST be based 262 upon whether or not an IGMPv1 query was heard in the last [Version 263 1 Router Present Timeout] seconds, and MUST NOT be based upon the 264 type of the last Query heard. This state variable MUST be used to 265 decide what type of Membership Reports to send for unsolicited 266 Membership Reports as well as Membership Reports in response to 267 Queries. 269 An IGMPv2 host MAY suppress Leave Group messages on a network where 270 the Querier is using IGMPv1. 272 An IGMPv2 router may be placed on a subnet where at least one router on 273 the subnet has not yet been upgraded to IGMPv2. The following 274 requirements apply: 276 If any IGMPv1 routers are present, the querier MUST use IGMPv1. 277 The use of IGMPv1 must be administratively configured, as there is 278 no reliable way of dynamically determining whether IGMPv1 routers 279 are present on a network. Implementations MAY provide a way for 280 system administrators to enable the use of IGMPv1 on their routers; 281 in the absence of explicit configuration, the configuration MUST 282 default to IGMPv2. When in IGMPv1 mode, routers MUST send Periodic 283 Queries with a Max Response Time of 0, and MUST ignore Leave Group 284 messages. They SHOULD also warn about receiving an IGMPv2 query, 285 although such warnings MUST be rate-limited. 287 If a router is not explicitly configured to use IGMPv1 and hears an 288 IGMPv1 Query, it SHOULD log a warning. These warnings MUST be 289 rate-limited. 291 5. Compatibility with IGMPv1 Hosts 293 An IGMPv2 host may be placed on a subnet where there are hosts that have 294 not yet been upgraded to IGMPv2. The following requirement applies: 296 The host MUST allow its Membership Report to be suppressed by 297 either a Version 1 Membership Report or a Version 2 Membership 298 Report. 300 An IGMPv2 router may be placed on a subnet where there are hosts that 301 have not yet been upgraded to IGMPv2. The following requirements apply: 303 If a router receives a Version 1 Membership Report, it MUST set a 304 timer to note that there are version 1 hosts present which are 305 members of the group for which it heard the report. This timer 306 should be the same as the [Group Membership Interval]. 308 If there are version 1 hosts present for a particular group, a 309 router MUST ignore any Leave Group messages that it receives for 310 that group. 312 6. Host State Diagram 314 Host behavior is more formally specified by the state transition diagram 315 below. A host may be in one of three possible states with respect to 316 any single IP multicast group on any single network interface: 318 - "Non-Member" state, when the host does not belong to the group on the 319 interface. This is the initial state for all memberships on all 320 network interfaces; it requires no storage in the host. 322 - "Delaying Member" state, when the host belongs to the group on the 323 interface and has a report delay timer running for that membership. 325 - "Idle Member" state, when the host belongs to the group on the 326 interface and does not have a report delay timer running for that 327 membership. 329 There are five significant events that can cause IGMP state transitions: 331 - "join group" occurs when the host decides to join the group on the 332 interface. It may occur only in the Non-Member state. 334 - "leave group" occurs when the host decides to leave the group on the 335 interface. It may occur only in the Delaying Member and Idle Member 336 states. 338 - "query received" occurs when the host receives either a valid General 339 Membership Query message, or a valid Group-Specific Membership Query 340 message. To be valid, the Query message must be at least 8 octets 341 long, and have a correct IGMP checksum. The group address in the IGMP 342 header must either be zero (a General Query) or a valid multicast 343 group address (a Group-Specific Query). A General Query applies to 344 all memberships on the interface from which the Query is received. A 345 Group-Specific Query applies to membership in a single group on the 346 interface from which the Query is received. Queries are ignored for 347 memberships in the Non-Member state. 349 - "report received" occurs when the host receives a valid IGMP 350 Membership Report message (Version 1 or Version 2). To be valid, the 351 Report message must be at least 8 octets long and have a correct IGMP 352 checksum. A Membership Report applies only to the membership in the 353 group identified by the Membership Report, on the interface from which 354 the Membership Report is received. It is ignored for memberships in 355 the Non-Member or Idle Member state. 357 - "timer expired" occurs when the report delay timer for the group on 358 the interface expires. It may occur only in the Delaying Member 359 state. 361 All other events, such as receiving invalid IGMP messages, or IGMP 362 messages other than Query or Report, are ignored in all states. 364 There are seven possible actions that may be taken in response to the 365 above events: 367 - "send report" for the group on the interface. The type of report is 368 determined by the state of the interface. The Report Message is sent 369 to the group being reported. 371 - "send leave" for the group on the interface. If the interface state 372 says the Querier is running IGMPv1, this action SHOULD be skipped. If 373 the flag saying we were the last host to report is cleared, this 374 action MAY be skipped. The Leave Message is sent to the ALL-ROUTERS 375 group (224.0.0.2). 377 - "set flag" that we were the last host to send a report for this group. 379 - "clear flag" since we were not the last host to send a report for this 380 group. 382 - "start timer" for the group on the interface, using a delay value 383 chosen uniformly from the interval (0, Max Response Time], where Max 384 Response time is specified in the Query. If this is an unsolicited 385 Report, the timer is set to a delay value chosen uniformly from the 386 interval (0, [Unsolicited Report Interval] ]. 388 - "reset timer" for the group on the interface to a new value, using a 389 delay value chosen uniformly from the interval (0, Max Response Time], 390 as described in "start timer". 392 - "stop timer" for the group on the interface. 394 In all of the following state diagrams, each state transition arc is 395 labeled with the event that causes the transition, and, in parentheses, 396 any actions taken during the transition. Note that the transition is 397 always triggered by the event; even if the action is conditional, the 398 transition still occurs. 400 ________________ 401 | | 402 | | 403 | | 404 | | 405 --------->| Non-Member |<--------- 406 | | | | 407 | | | | 408 | | | | 409 | |________________| | 410 | | | 411 | leave group | join group | leave group 412 | (stop timer, |(send report, | (send leave if 413 | send leave if | set flag, | flag set) 414 | flag set) | start timer) | 415 ________|________ | ________|________ 416 | |<--------- | | 417 | | | | 418 | |<-------------------| | 419 | | query received | | 420 | Delaying Member | (start timer) | Idle Member | 421 ---->| |------------------->| | 422 | | | report received | | 423 | | | (stop timer, | | 424 | | | clear flag) | | 425 | |_________________|------------------->|_________________| 426 | query received | timer expired 427 | (reset timer if | (send report, 428 | Max Resp Time | set flag) 429 | < current timer) | 430 ------------------- 432 The all-systems group (address 224.0.0.1) is handled as a special case. 433 The host starts in Idle Member state for that group on every interface, 434 never transitions to another state, and never sends a report for that 435 group. 437 In addition, a host may be in one of two possible states with respect to 438 any single network interface: 440 - "No IGMPv1 Router Present", when the host has not heard an IGMPv1 441 style query for the [Version 1 Router Present Timeout]. This is the 442 initial state. 444 - "IGMPv1 Router Present", when the host has heard an IGMPv1 style query 445 within the [Version 1 Router Present Timeout]. 447 There are two events that can cause state transitions: 449 - "IGMPv1 query received", when the host receives a query with the Max 450 Response Time field set to 0. 452 - "timer expires", when the timer set to note the presence of an IGMPv1 453 router expires. 455 And a single action that can be triggered by an event: 457 - "set timer", setting the timer to its maximum value [Version 1 Router 458 Present Timeout] and (re)starting it. 460 ________________ 461 | | 462 | | 463 | No IGMPv1 | 464 | Router | 465 | Present | 466 | | 467 ---->| |---- 468 | | | | 469 | |________________| | 470 timer expires | | IGMPv1 query received 471 | ________________ | (set timer) 472 | | | | 473 | | | | 474 | | | | 475 -----| IGMPv1 |<--- 476 | Router | 477 | Present | 478 | | 479 ---->| |---- 480 | |________________| | 481 | | 482 | IGMPv1 query received | 483 | (set timer) | 484 --------------------------- 486 7. Router State Diagram 488 Router behavior is more formally specified by the state transition 489 diagrams below. 491 A router may be in one of two possible states with respect to any single 492 attached network: 494 - "Querier", when this router is designated to transmit IGMP Membership 495 Queries on this network. 497 - "Non-Querier", when there is another router designated to transmit 498 IGMP membership Queries on this network. 500 The following three events can cause the router to change states: 502 - "query timer expired" occurs when the timer set for query transmission 503 expires. 505 - "query received from a router with a lower IP address" occurs when an 506 IGMP Membership Query is received from a router on the same network 507 with a lower IP address. 509 - "other querier present timer expired" occurs when the timer set to 510 note the presence of another querier with a lower IP address on the 511 network expires. 513 There are three actions that may be taken in response to the above 514 events: 516 - "start general query timer" for the attached network. 518 - "start other querier present timer" for the attached network [Other 519 Querier Present Interval]. 521 - "send general query" on the attached network. The General Query is 522 sent to the all-systems group (224.0.0.1), and has a Max Response Time 523 of [Query Response Interval]. 525 -------------------------------- 526 _______|________ gen. query timer | 527 --------- | | expired | 528 | Initial |---------------->| | (send general query, | 529 --------- (send gen. q., | | set gen. q. timer) | 530 set initial gen. q. | |<---------------------- 531 timer) | Querier | 532 | | 533 -----| |<--- 534 | | | | 535 | |________________| | 536 query received from a | | other querier 537 router with a lower | | present timer expired 538 IP address | | (send general query, 539 (set other querier | ________________ | set gen. q. timer) 540 present timer) | | | | 541 | | | | 542 | | | | 543 ---->| Non |---- 544 | Querier | 545 | | 546 | | 547 ---->| |---- 548 | |________________| | 549 | query received from a | 550 | router with a lower IP | 551 | address | 552 | (set other querier | 553 | present timer) | 554 --------------------------- 556 A router should start in the Initial state on all attached networks, and 557 immediately move to Querier state. 559 In addition, to keep track of which groups have members, a router may be 560 in one of four possible states with respect to any single IP multicast 561 group on any single attached network: 563 - "No Members Present" state, when there are no hosts on the network 564 which have sent reports for this multicast group. This is the initial 565 state for all groups on the router; it requires no storage in the 566 router. 568 - "Members Present" state, when there is a host on the network which has 569 sent a Membership Report for this multicast group. 571 - "Version 1 Members Present" state, when there is an IGMPv1 host on the 572 network which has sent a Version 1 Membership Report for this 573 multicast group. 575 - "Checking Membership" state, when the router has received a Leave 576 Group message but has not yet heard a Membership Report for the 577 multicast group. 579 There are six significant events that can cause router state 580 transitions: 582 - "v2 report received" occurs when the router receives a Version 2 583 Membership Report for the group on the interface. To be valid, the 584 Report message must be at least 8 octets long and must have a correct 585 IGMP checksum. 587 - "v1 report received" occurs when the router receives a Version 1 588 Membership report for the group on the interface. The same validity 589 requirements apply. 591 - "leave received" occurs when the router receives an IGMP Group Leave 592 message for the group on the interface. To be valid, the Leave 593 message must be at least 8 octets long and must have a correct IGMP 594 checksum. 596 - "timer expired" occurs when the timer set for a group membership 597 expires. 599 - "retransmit timer expired" occurs when the timer set to retransmit a 600 group-specific Membership Query expires. 602 - "v1 host timer expired" occurs when the timer set to note the presence 603 of version 1 hosts as group members expires. 605 There are six possible actions that may be taken in response to the 606 above events: 608 - "start timer" for the group membership on the interface - also resets 609 the timer to its initial value [Group Membership Interval] if the 610 timer is currently running. 612 - "start timer*" for the group membership on the interface - this 613 alternate action sets the timer to [Last Member Query Interval] * 614 [Last Member Query Count] if this router is a Querier, or the [Max 615 Response Time] in the packet * [Last Member Query Count] if this 616 router is a non-Querier. 618 - "start retransmit timer" for the group membership on the interface 620 [Last Member Query Interval]. 622 - "start v1 host timer" for the group membership on the interface - also 623 resets the timer to its initial value [Group Membership Interval] if 624 the timer is currently running. 626 - "send group-specific query" for the group on the attached network. 627 The Group-Specific Query is sent to the group being queried, and has a 628 Max Response Time of [Last Member Query Interval]. 630 - "notify routing +" notify the routing protocol that there are members 631 of this group on this connected network. 633 - "notify routing -" notify the routing protocol that there are no 634 longer any members of this group on this connected network. 636 The state diagram for a router in Querier state follows: 638 ________________ 639 ----------------------------| |<----------------------------- 640 | | | | 641 | timer expired| |timer expired | 642 | (notify routing -)| No Members |(notify routing -, | 643 | ------->| Present |<--------- clear rxmt tmr) | 644 | | | | | | 645 |v1 report rec'd | | | | | 646 |(notify routing +, | |________________| | --------------- | 647 | start timer, | | | | rexmt timer | | 648 | start v1 host | v2 report received| | | expired | | 649 | timer) | (notify routing +,| | | (send g-s | | 650 | | start timer)| | | query, | | 651 | __________|______ | ________|_|______ st rxmt | | 652 | | |<------------ | | tmr) | | 653 | | | | |<------- | 654 | | | v2 report received | | | 655 | | | (start timer) | | | 656 | | Members Present |<-------------------| Checking | | 657 | ----->| | leave received | Membership | | 658 | | | | (start timer*, | | | 659 | | | | start rexmt timer,| | | 660 | | | | send g-s query) | | | 661 | | --->| |------------------->| | | 662 | | | |_________________| |_________________| | 663 | | |v2 report rec'd | | | | 664 | | |(start timer) | |v1 report rec'd |v1 report rec'd | 665 | | ---------------- |(start timer, |(start timer, | 666 | |v1 host | start v1 host timer) | start v1 host timer) | 667 | |tmr ______________V__ | | 668 | |exp'd | |<---------------------- | 669 | ------| | | 670 | | Version 1 |timer expired | 671 | | Members Present |(notify routing -) | 672 ------->| |------------------------------------------------- 673 | |<-------------------- 674 ------->|_________________| v1 report rec'd | 675 | v2 report rec'd | | (start timer, | 676 | (start timer) | | start v1 host timer) | 677 ----------------- -------------------------- 679 The state diagram for a router in Non-Querier state is similar, but 680 non-Queriers do not send any messages and are only driven by message re- 681 ception. Note that non-Queriers do not care whether a Membership Report 682 message is Version 1 or Version 2. 684 ________________ 685 | | 686 | | 687 timer expired| |timer expired 688 (notify routing -)| No Members |(notify routing -) 689 --------->| Present |<--------- 690 | | | | 691 | | | | 692 | | | | 693 | |________________| | 694 | | | 695 | |report received | 696 | |(notify routing +,| 697 | | start timer) | 698 ________|________ | ________|________ 699 | |<--------- | | 700 | | report received | | 701 | | (start timer) | | 702 | Members Present |<-------------------| Checking | 703 | | g-s query rec'd | Membership | 704 | | (start timer*) | | 705 ---->| |------------------->| | 706 | |_________________| |_________________| 707 | report received | 708 | (start timer) | 709 ----------------- 711 8. List of timers and default values 713 Most of these timers are configurable. If non-default settings are 714 used, they MUST be consistent among all routers on a single link. Note 715 that parentheses are used to group expressions to make the algebra 716 clear. 718 8.1. Robustness Variable 720 The Robustness Variable allows tuning for the expected packet loss on a 721 subnet. If a subnet is expected to be lossy, the Robustness Variable 722 may be increased. IGMP is robust to (Robustness Variable - 1) packet 723 losses. The Robustness Variable MUST NOT be zero, and SHOULD NOT be 724 one. Default: 2 726 8.2. Query Interval 728 The Query Interval is the interval between General Queries sent by the 729 Querier. Default: 125 seconds. 731 By varying the [Query Interval], an administrator may tune the number of 732 IGMP messages on the subnet; larger values cause IGMP Queries to be sent 733 less often. 735 8.3. Query Response Interval 737 The Max Response Time inserted into the periodic General Queries. 738 Default: 100 (10 seconds) 740 By varying the [Query Response Interval], an administrator may tune the 741 burstiness of IGMP messages on the subnet; larger values make the 742 traffic less bursty, as host responses are spread out over a larger 743 interval. The number of seconds represented by the [Query Response 744 Interval] must be less than the [Query Interval]. 746 8.4. Group Membership Interval 748 The Group Membership Interval is the amount of time that must pass 749 before a multicast router decides there are no more members of a group 750 on a network. This value MUST be ((the Robustness Variable) times (the 751 Query Interval)) plus (one Query Response Interval). 753 8.5. Other Querier Present Interval 755 The Other Querier Present Interval is the length of time that must pass 756 before a multicast router decides that there is no longer another 757 multicast router which should be the querier. This value MUST be ((the 758 Robustness Variable) times (the Query Interval)) plus (one half of one 759 Query Response Interval). 761 8.6. Startup Query Interval 763 The Startup Query Interval is the interval between General Queries sent 764 by a Querier on startup. Default: 1/4 the Query Interval. 766 8.7. Startup Query Count 768 The Startup Query Count is the number of Queries sent out on startup, 769 separated by the Startup Query Interval. Default: the Robustness 770 Variable. 772 8.8. Last Member Query Interval 774 The Last Member Query Interval is the Max Response Time inserted into 775 Group-Specific Queries sent in response to Leave Group messages, and is 776 also the amount of time between Group-Specific Query messages. Default: 777 10 (1 second) 779 This value may be tuned to modify the "leave latency" of the network. A 780 reduced value results in reduced time to detect the loss of the last 781 member of a group. 783 8.9. Last Member Query Count 785 The Last Member Query Count is the number of Group-Specific Queries sent 786 before the router assumes there are no local members. Default: the 787 Robustness Variable. 789 8.10. Unsolicited Report Interval 791 The Unsolicited Report Interval is the time between repetitions of a 792 host's initial report of membership in a group. Default: 10 seconds. 794 8.11. Version 1 Router Present Timeout 796 The Version 1 Router Present Timeout is how long a host must wait after 797 hearing a Version 1 Query before it may send any IGMPv2 messages. 798 Value: 400 seconds. 800 9. Message destinations 802 This information is provided elsewhere in the document, but is 803 summarized here for convenience. 805 Message Type Destination Group 806 ------------ ----------------- 807 General Query ALL-SYSTEMS (224.0.0.1) 808 Group-Specific Query The group being queried 809 Membership Report The group being reported 810 Leave Message ALL-ROUTERS (224.0.0.2) 812 Note: in older (i.e., non-standard and now obsolete) versions of 813 IGMPv2, hosts send Leave Messages to the group being left. A 814 router SHOULD accept Leave Messages addressed to the group being 815 left in the interests of backwards compatability with such hosts. 816 In all cases, however, hosts MUST send to the ALL-ROUTERS address 817 to be compliant with this specification. 819 10. Security Considerations 821 We consider the ramifications of a forged message of each type. 823 Query Message: 825 A forged Query message from a machine with a lower IP address than 826 the current Querier will cause Querier duties to be assigned to the 827 forger. If the forger then sends no more Query messages, other 828 routers' Other Querier Present timer will time out and one will 829 resume the role of Querier. During this time, if the forger 830 ignores Leave Messages, traffic might flow to groups with no 831 members for up to [Group Membership Interval]. 833 A forged Query message sent to a group with members will cause the 834 hosts which are members of the group to report their memberships. 835 This causes a small amount of extra traffic on the LAN, but causes 836 no protocol problems. 838 Report messages: 840 A forged Report message may cause multicast routers to think there 841 are members of a group on a subnet when there are not. Forged 842 Report messages from the local subnet are meaningless, since 843 joining a group on a host is generally an unprivileged operation, 844 so a local user may trivially gain the same result without forging 845 any messages. Forged Report messages from external sources are 846 more troublesome; there are two defenses against externally forged 847 Reports: 848 - Ignore the Report if you cannot identify the source address of 849 the packet as belonging to a subnet assigned to the interface on 850 which the packet was received. This solution means that Reports 851 sent by mobile hosts without addresses on the local subnet will 852 be ignored. 853 - Ignore Report messages without Router Alert options [Katz97], and 854 require that routers not forward Report messages. (The 855 requirement is not a requirement of generalized filtering in the 856 forwarding path, since the packets already have Router Alert 857 options in them). This solution breaks backwards compatibility 858 with implementations of earlier versions of this specification 859 which did not require Router Alert. 861 A forged Version 1 Report Message may put a router into "version 1 862 members present" state for a particular group, meaning that the 863 router will ignore Leave messages. This can cause traffic to flow 864 to groups with no members for up to [Group Membership Interval]. 865 There are two defenses against forged v1 Reports: 866 - To defend against externally sourced v1 Reports, ignore the 867 Report if you cannot identify the source address of the packet as 868 belonging to a subnet assigned to the interface on which the 869 packet was received. This solution means that v1 Reports sent by 870 mobile hosts without addresses on the local subnet will be 871 ignored. 872 - Provide routers with a configuration switch to ignore Version 1 873 messages completely. This breaks automatic compatibility with 874 Version 1 hosts, so should only be used in situations where "fast 875 leave" is critical. This solution protects against forged 876 version 1 reports from the local subnet as well. 878 Leave message: 880 A forged Leave message will cause the Querier to send out Group- 881 Specific Queries for the group in question. This causes extra 882 processing on each router and on each member of the group, but can 883 not cause loss of desired traffic. There are two defenses against 884 externally forged Leave messages: 885 - Ignore the Leave message if you cannot identify the source 886 address of the packet as belonging to a subnet assigned to the 887 interface on which the packet was received. This solution means 888 that Leave messages sent by mobile hosts without addresses on the 889 local subnet will be ignored. 890 - Ignore Leave messages without Router Alert options [Katz97], and 891 require that routers not forward Leave messages. (The 892 requirement is not a requirement of generalized filtering in the 893 forwarding path, since the packets already have Router Alert 894 options in them). This solution breaks backwards compatibility 895 with implementations of earlier versions of this specification 896 which did not require Router Alert. 898 11. Acknowledgments 900 IGMPv2 was designed by Rosen Sharma and Steve Deering. 902 12. References 904 Bradner97 Bradner, S., "Key words for use in RFCs to Indicate 905 Requirement Levels", RFC 2119/BCP 14, Harvard University, 906 March 1997. 908 Katz97 Katz, D., "IP Router Alert Option," RFC 2113, Cisco 909 Systems, February 1997. 911 13. Appendix I - Changes from IGMPv1 913 The IGMPv1 "Version" and "Type" fields are combined into a single "Type" 914 field. 916 A new IGMP Type is assigned to Version 2 Membership Report messages, so 917 a router may tell the difference between an IGMPv1 and IGMPv2 host 918 report. 920 A new IGMP Type is created for the IGMPv2 Leave Group message. 922 The Membership Query message is changed so that a previously unused 923 field contains a new value, the Max Response Time. 925 The IGMPv2 spec now specifies a querier election mechanism. In IGMPv1, 926 the querier election was left up to the multicast routing protocol, and 927 different protocols used different mechanisms. This could result in 928 more than one querier per network, so the election mechanism has been 929 standardized in IGMPv2. However, this means that care must be taken 930 when an IGMPv2 router is trying to coexist with an IGMPv1 router that 931 uses a different querier election mechanism. In particular, it means 932 that an IGMPv2 router must be able to act as an IGMPv1 router on a 933 particular network if configured to do so. The actions required 934 include: 936 - Set the Max Response Time field to 0 in all queries. 938 - Ignore Leave Group messages. 940 The IGMPv2 spec relaxes the requirements on validity-checking for 941 Membership Queries and Membership Reports. When upgrading an 942 implementation, be sure to remove any checks that do not belong. 944 The IGMPv2 spec requires the presence of the IP Router Alert option 945 [Katz97] in all packets described in this memo. 947 14. Author's Address 949 William C. Fenner 950 Xerox PARC 951 3333 Coyote Hill Road 952 Palo Alto, CA 94304 953 Phone: +1 650 812 4816 954 Email: fenner@parc.xerox.com