RFC 2236
Internet Group Management Protocol, Version 2
Internet Group Management Protocol, Version 2 🎀
okay bestie, this is RFC 2236 🦋 and it's from the Network Working Group, written by W. Fenner at Xerox PARC. It's a Standards Track doc dated November 1997, and it updates RFC 1112 (that's Category: Standards Track, Updates: 1112). Its header doesn't list any RFC it obsoletes, so this is an upgrade to an existing thing, not a replacement 💅
Status of This Memo ✨
this doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 for the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited, so share it with everyone 🌈
Copyright Notice 💜
Copyright (C) The Internet Society (1997). All Rights Reserved.
Abstract 🌸
this memo documents IGMPv2, the thing IP hosts use to report their multicast group memberships to routers 📡 it updates STD 5, RFC 1112.
IGMPv2 lets group membership termination get reported to the routing protocol really fast, and that's a huge deal for high-bandwidth multicast groups and/or subnets where membership is super volatile 😭🔥
this document is a product of the Inter-Domain Multicast Routing working group within the Internet Engineering Task Force. comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the author(s) 💖
1. Definitions 💅
okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get read exactly the way RFC 2119 [RFC 2119] describes. these are the strict-vibes words, so pay attention 👑
2. Introduction 🧚
so IGMP is how IP hosts tell their immediately-neighboring multicast routers which multicast groups they belong to 🦋 this memo only covers IGMP between hosts and routers for figuring out group membership. routers that are members of multicast groups are expected to act like hosts too (as well as routers), and they may even answer their own queries 🙈 IGMP may also be used between routers, but that's not specified here.
ICMP is kind of a vibe match here: IGMP is an integral part of IP 💜 every host that wants to receive IP multicasts is required to implement it. IGMP messages ride inside IP datagrams with IP protocol number 2. every IGMP message in this doc gets sent with IP TTL 1 and carries the IP Router Alert option [RFC 2113] in its IP header ✨ every IGMP message that concerns hosts has this format:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Max Resp Time | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2.1. Type 🎀
there are three types of IGMP messages that matter for the host-router interaction:
0x11 = Membership Query- there are two sub-types of Membership Query messages:
- General Query, used to learn which groups have members on an attached network.
- Group-Specific Query, used to learn if a particular group has any members on an attached network.
- these two get told apart by the Group Address, as described in section 1.4 . Membership Query messages are referred to simply as "Query" messages.
- there are two sub-types of Membership Query messages:
0x16 = Version 2 Membership Report0x17 = Leave Group
there's one more type of message, for backwards-compatibility with IGMPv1 🥹
0x12 = Version 1 Membership Report
this document refers to Membership Reports simply as "Reports". when no version is specified, the statement applies equally to both versions 🦋
unrecognized message types should be silently ignored 🙈 new message types may be used by newer versions of IGMP, by multicast routing protocols, or other uses. no drama, just vibes ✨
2.2. Max Response Time ⏱️
the Max Response Time field is only meaningful in Membership Query messages, and it specifies the maximum allowed time before sending a responding report, in units of 1/10 second. in all other messages, the sender sets it to zero and receivers ignore it 💅
varying this setting lets IGMPv2 routers tune the "leave latency" (the time between the moment the last host leaves a group and when the routing protocol is notified that there are no more members), as discussed in section 7.8. it also lets you tune how bursty IGMP traffic is on a subnet, as discussed in section 7.3 🔥
2.3. Checksum 🔐
the checksum is the 16-bit one's complement of the one's complement sum of the whole IGMP message (the entire IP payload) 🧮 for computing it, the checksum field is set to zero. when transmitting packets, the checksum MUST be computed and inserted into this field. when receiving packets, the checksum MUST be verified before processing a packet. no skipping this, bestie 💀
2.4. Group Address 🌈
in a Membership Query message, the group address field is set to zero when sending a General Query, and set to the group address being queried when sending a Group-Specific Query ✨
in a Membership Report or Leave Group message, the group address field holds the IP multicast group address of the group being reported or left 💖
2.5. Other fields 🧚
okay so IGMP messages may be longer than 8 octets, especially in future backwards-compatible versions of IGMP 👀 as long as the Type is one that's recognized, an IGMPv2 implementation MUST ignore anything past the first 8 octets while processing the packet. HOWEVER, the IGMP checksum is always computed over the whole IP payload, not just the first 8 octets. main character energy for the checksum 👑
3. Protocol Description ✨
okay so heads up 🧚 the default timer values come later in the doc, and timer and counter names are wrapped in [square brackets] so you can spot them easily 💖
the word "interface" gets used a lot here to mean "the primary interface on an attached network" 🦋 so if a router has multiple physical interfaces on one network, this protocol only needs to run on one of them. hosts are different though 💅 they need to do their thing on all interfaces that have memberships attached to them
multicast routers use IGMP to figure out which groups have members on each of their attached physical networks 👑 each router keeps a list of multicast group memberships for every attached network, plus a timer for each membership. and "multicast group memberships" just means at least one member of a group exists on that network. it does NOT mean a full list of every member. the router isn't keeping a guest list, it just needs to know someone's there 🫶
for each attached network, a multicast router can be one of two roles: Querier or Non-Querier 🎀 there's normally only ONE Querier per physical network. all multicast routers start out as a Querier on each attached network 🌸 but if a multicast router hears a Query message from a router with a lower IP address, it MUST become a Non-Querier on that network. 😭 if a router hasn't heard a Query message from another router for [Other Querier Present Interval], it goes back to being the Querier 🔥
routers that are the Querier send a General Query on each attached network every [Query Interval] to ask for membership info 🍓 on startup, a router SHOULD send [Startup Query Count] General Queries, spaced closely together [Startup Query Interval], so it can quickly and reliably figure out membership 🧚 a General Query is addressed to the all-systems multicast group (224.0.0.1), has a Group Address field of 0, and has a Max Response Time of [Query Response Interval] ✨
when a host gets a General Query, it sets delay timers for each group it's a member of (except the all-systems group) on the interface where the query came in 🦋 each timer gets a different random value, using the highest clock granularity the host has, picked from the range (0, Max Response Time] with the Max Response Time from the Query packet. no cap, that randomness is the whole point 💅 when a host gets a Group-Specific Query, it sets a delay timer to a random value from that same (0, Max Response Time] range for the group being queried, but only if it's a member on the interface where the query came in 💜 if a timer for that group is already running, it only gets reset to the new random value if the requested Max Response Time is less than the timer's remaining value 🙈
when a group's timer expires, the host multicasts a Version 2 Membership Report to the group, with IP TTL of 1 🎀 and if the host hears another host's Report (version 1 or 2) while its timer is running, it stops its timer for that group and does NOT send its own Report 🫶 this is how duplicate Reports get suppressed. main character energy for the host that stays quiet, lol 🌈
when a router gets a Report, it adds the group being reported to its list of multicast group memberships on the network where it received the Report, and sets that membership's timer to the [Group Membership Interval] ⭐ repeated Reports refresh the timer. and if no Reports come in for a group before the timer runs out, the router assumes the group has no local members, and that it doesn't need to forward remotely-originated multicasts for that group onto the attached network 💀
when a host joins a multicast group, it should immediately send an unsolicited Version 2 Membership Report for that group 🌸 that way, if it's the first member of that group on the network, the router finds out right away. to cover the chance that the first Membership Report gets lost or damaged, it is recommended that it be repeated once or twice after short delays [Unsolicited Report Interval] 🍓 (a simple way to do this is to send the initial Version 2 Membership Report, then act as if a Group-Specific Query was received for that group, and set a timer appropriately) 🧚
now leaving a group 👋 when a host leaves a multicast group, if it was the last host to reply to a Query with a Membership Report for that group, it SHOULD send a Leave Group message to the all-routers multicast group (224.0.0.2) 💖 if it was NOT the last host to reply to a Query, it MAY send nothing, because there must be another member on the subnet 🦋 this is just an optimization to cut down on traffic. a host without enough storage to remember whether it was the last host to reply MAY always send a Leave Group message when it leaves a group 🫶 routers SHOULD accept a Leave Group message addressed to the group being left, so they can work with implementations of an earlier version of this standard 💅 Leave Group messages go to the all-routers group because other group members don't need to know a host left, but it doesn't hurt to address the message to the group 🌈
when a Querier gets a Leave Group message for a group that has group members on the reception interface, it sends [Last Member Query Count] Group-Specific Queries every [Last Member Query Interval] to the group being left ✨ these Group-Specific Queries have their Max Response time set to [Last Member Query Interval] 🎀 if no Reports come in after the response time of the last query expires, the routers assume the group has no local members, same as before 🔥 and any Querier to non-Querier transition gets ignored during this time, so the same router keeps sending the Group-Specific Queries 👑
Non-Queriers MUST ignore Leave Group messages 🙈 and Queriers SHOULD ignore Leave Group messages for groups that have no members on the reception interface 💀
when a non-Querier gets a Group-Specific Query message, and its existing group membership timer is greater than [Last Member Query Count] times the Max Response Time in the message, it sets its group membership timer to that value 🧚
4. Compatibility with IGMPv1 Routers 💅
okay this section is all about how an IGMPv2 host can live on a subnet where the Querier router hasn't been upgraded to IGMPv2 yet 🌸 the following requirements apply:
- the IGMPv1 router will send General Queries with the Max Response Time set to 0. this MUST be interpreted as a value of 100 (10 seconds) 🦋
- the IGMPv1 router expects Version 1 Membership Reports in response to its Queries, and it won't pay attention to Version 2 Membership Reports 😭 so a state variable MUST be kept for each interface, describing whether the multicast Querier on that interface is running IGMPv1 or IGMPv2 🫶 this variable MUST be based upon whether or not an IGMPv1 query was heard in the last [Version 1 Router Present Timeout] seconds, and MUST NOT be based upon the type of the last Query heard 🔥 this state variable MUST be used to decide what type of Membership Reports to send, both for unsolicited Membership Reports and for Membership Reports in response to Queries 👑
- an IGMPv2 host MAY suppress Leave Group messages on a network where the Querier is using IGMPv1 🍓
now flipping it around 🔄 an IGMPv2 router may be placed on a subnet where at least one router on the subnet hasn't been upgraded to IGMPv2 yet. the following requirements apply:
- if any IGMPv1 routers are present, the querier MUST use IGMPv1. the use of IGMPv1 must be administratively configured, because there's no reliable way to dynamically tell whether IGMPv1 routers are on a network 💀 implementations MAY provide a way for system administrators to enable IGMPv1 on their routers. in the absence of explicit configuration, the configuration MUST default to IGMPv2 🧚 when in IGMPv1 mode, routers MUST send Periodic Queries with a Max Response Time of 0, and MUST ignore Leave Group messages 🌈 they SHOULD also warn about receiving an IGMPv2 query, although such warnings MUST be rate-limited 🎀
- if a router is not explicitly configured to use IGMPv1 and hears an IGMPv1 Query, it SHOULD log a warning ✨ these warnings MUST be rate-limited 💖
5. Compatibility with IGMPv1 Hosts 🎀
last one of the compatibility bits 🫶 an IGMPv2 host may be placed on a subnet where there are hosts that haven't been upgraded to IGMPv2 yet. the following requirement applies:
- the host MUST allow its Membership Report to be suppressed by either a Version 1 Membership Report or a Version 2 Membership Report 🦋
and an IGMPv2 router may be placed on a subnet where there are hosts that haven't been upgraded to IGMPv2 yet. the following requirements apply:
- if a router receives a Version 1 Membership Report, it MUST set a timer to note that there are version 1 hosts present which are members of the group the report was for 🍓 this timer should be the same as the [Group Membership Interval] 🧚
- if there are version 1 hosts present for a particular group, a router MUST ignore any Leave Group messages it receives for that group 💅
6. Host State Diagram ✨
okay so the host behavior gets the formal treatment here, with a state transition diagram 🦋 A host can be in one of three possible states for any single IP multicast group on any single network interface:
- "Non-Member" state, when the host does not belong to the group on the interface. This is the starting point for all memberships on all network interfaces, and it needs no storage in the host 💅
- "Delaying Member" state, when the host belongs to the group on the interface and has a report delay timer running for that membership ⏰
- "Idle Member" state, when the host belongs to the group on the interface and does not have a report delay timer running for that membership 🌸
There are five significant events that can cause IGMP state transitions 🔥
- "join group" happens when the host decides to join the group on the interface. It may occur only in the Non-Member state.
- "leave group" happens when the host decides to leave the group on the interface. It may occur only in the Delaying Member and Idle Member states.
- "query received" happens when the host receives either a valid General Membership Query message, or a valid Group-Specific Membership Query message. To be valid, the Query message must be at least 8 octets long, and have a correct IGMP checksum. The group address in the IGMP header must either be zero (a General Query) or a valid multicast group address (a Group-Specific Query). A General Query applies to all memberships on the interface from which the Query is received. A Group-Specific Query applies to membership in a single group on the interface from which the Query is received. Queries are ignored for memberships in the Non-Member state 🙈
- "report received" happens when the host receives a valid IGMP Membership Report message (Version 1 or Version 2). To be valid, the Report message must be at least 8 octets long and have a correct IGMP checksum. A Membership Report applies only to the membership in the group identified by the Membership Report, on the interface from which the Membership Report is received. It is ignored for memberships in the Non-Member or Idle Member state 🧚
- "timer expired" happens when the report delay timer for the group on the interface expires. It may occur only in the Delaying Member state ⭐
All other events, such as receiving invalid IGMP messages, or IGMP messages other than Query or Report, are ignored in all states. Not me ignoring the junk 💀
There are seven possible actions that may be taken in response to the above events 💜
- "send report" for the group on the interface. The type of report is determined by the state of the interface. The Report Message is sent to the group being reported.
- "send leave" for the group on the interface. If the interface state says the Querier is running IGMPv1, this action SHOULD be skipped. If the flag saying we were the last host to report is cleared, this action MAY be skipped. The Leave Message is sent to the ALL-ROUTERS group (224.0.0.2) 🎀
- "set flag" that we were the last host to send a report for this group 🍓
- "clear flag" since we were not the last host to send a report for this group 🌈
- "start timer" for the group on the interface, using a delay value chosen uniformly from the interval (0, Max Response Time], where Max Response time is specified in the Query. If this is an unsolicited Report, the timer is set to a delay value chosen uniformly from the interval (0, [Unsolicited Report Interval] ].
- "reset timer" for the group on the interface to a new value, using a delay value chosen uniformly from the interval (0, Max Response Time], as described in "start timer" 🦋
- "stop timer" for the group on the interface 🛑
In all of the following state diagrams, each state transition arc is labeled with the event that causes the transition, and, in parentheses, any actions taken during the transition. Note that the transition is always triggered by the event. Even if the action is conditional, the transition still occurs 👑
________________
| |
| |
| |
| |
--------->| Non-Member |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| leave group | join group | leave group
| (stop timer, |(send report, | (send leave
| send leave if | set flag, | if flag set)
| flag set) | start timer) |
________|________ | ________|________
| |<--------- | |
| | | |
| |<-------------------| |
| | query received | |
| Delaying Member | (start timer) | Idle Member |
---->| |------------------->| |
| | | report received | |
| | | (stop timer, | |
| | | clear flag) | |
| |_________________|------------------->|_________________|
| query received | timer expired
| (reset timer if | (send report,
| Max Resp Time | set flag)
| < current timer) |
-------------------The all-systems group (address 224.0.0.1) is handled as a special case. The host starts in Idle Member state for that group on every interface, never transitions to another state, and never sends a report for that group 🌟
In addition, a host may be in one of two possible states with respect to any single network interface 🌙
- "No IGMPv1 Router Present", when the host has not heard an IGMPv1 style query for the [Version 1 Router Present Timeout]. This is the initial state.
- "IGMPv1 Router Present", when the host has heard an IGMPv1 style query within the [Version 1 Router Present Timeout].
There are two events that can cause state transitions 💖
- "IGMPv1 query received", when the host receives a query with the Max Response Time field set to 0.
- "timer expires", when the timer set to note the presence of an IGMPv1 router expires.
And a single action that can be triggered by an event 🫶
- "set timer", setting the timer to its maximum value [Version 1 Router Present Timeout] and (re)starting it.
________________
| |
| |
| No IGMPv1 |
| Router |
| Present |
| |
---->| |----
| | | |
| |________________| |
timer expires | | IGMPv1 query
| ________________ | received
| | | | (set timer)
| | | |
| | | |
-----| IGMPv1 |<---
| Router |
| Present |
| |
---->| |----
| |________________| |
| |
| IGMPv1 query received |
| (set timer) |
---------------------------7. Router State Diagram 🦋
okay so routers are basically little state machines, and this section draws out the formal version of all their moves 🧚 the diagrams are the main event, so bestie take your time with them 💅
A router may be in one of two possible states with respect to any single attached network:
- "Querier", when this router is designated to transmit IGMP Membership Queries on this network. 👑
- "Non-Querier", when there is another router designated to transmit IGMP membership Queries on this network. 🌸
The following three events can cause the router to change states:
- "query timer expired" happens when the timer set for query transmission runs out. ⏰
- "query received from a router with a lower IP address" happens when an IGMP Membership Query shows up from a router on the same network with a lower IP address. 👀
- "other querier present timer expired" happens when the timer that tracks another querier with a lower IP address on the network runs out. 💀
There are three actions the router can take in response to those events:
- "start general query timer" for the attached network. ✨
- "start other querier present timer" for the attached network [Other Querier Present Interval]. 🎀
- "send general query" on the attached network. The General Query goes to the all-systems group (224.0.0.1) and has a Max Response Time of [Query Response Interval]. 📣
--------------------------------
_______|________ gen. query timer |
--------- | | expired |
| Initial |------------>| | (send general query, |
--------- (send gen. q.,| | set gen. q. timer) |
set initial gen. q. | |<----------------------
timer) | Querier |
| |
-----| |<---
| | | |
| |________________| |
query received from a | | other querier
router with a lower | | present timer
IP address | | expired
(set other querier | ________________ | (send general
present timer) | | | | query,set gen.
| | | | q. timer)
| | | |
---->| Non |----
| Querier |
| |
| |
---->| |----
| |________________| |
| query received from a |
| router with a lower IP |
| address |
| (set other querier |
| present timer) |
---------------------------A router should start in the Initial state on all attached networks, and immediately move to Querier state. 🚀
In addition, to keep track of which groups have members, a router may be in one of four possible states with respect to any single IP multicast group on any single attached network:
- "No Members Present" state, when there are no hosts on the network which have sent reports for this multicast group. This is the initial state for all groups on the router, and it requires no storage in the router. 🫧
- "Members Present" state, when there is a host on the network which has sent a Membership Report for this multicast group. 🙋♀️
- "Version 1 Members Present" state, when there is an IGMPv1 host on the network which has sent a Version 1 Membership Report for this multicast group. 🕰️
- "Checking Membership" state, when the router has received a Leave Group message but has not yet heard a Membership Report for the multicast group. 🤔
There are six significant events that can cause router state transitions:
- "v2 report received" happens when the router receives a Version 2 Membership Report for the group on the interface. To be valid, the Report message must be at least 8 octets long and must have a correct IGMP checksum. ✅
- "v1 report received" happens when the router receives a Version 1 Membership report for the group on the interface. The same validity requirements apply. 🔁
- "leave received" happens when the router receives an IGMP Group Leave message for the group on the interface. To be valid, the Leave message must be at least 8 octets long and must have a correct IGMP checksum. 👋
- "timer expired" happens when the timer set for a group membership expires. ⌛
- "retransmit timer expired" happens when the timer set to retransmit a group-specific Membership Query expires. 🔄
- "v1 host timer expired" happens when the timer set to note the presence of version 1 hosts as group members expires. 🧓
There are six possible actions the router can take in response to those events:
- "start timer" for the group membership on the interface. This also resets the timer to its initial value [Group Membership Interval] if the timer is currently running. ⏱️
- "start timer*" for the group membership on the interface. This alternate action sets the timer to [Last Member Query Interval] * [Last Member Query Count] if this router is a Querier, or the [Max Response Time] in the packet * [Last Member Query Count] if this router is a non-Querier. 🧮
- "start retransmit timer" for the group membership on the interface [Last Member Query Interval]. 🔂
- "start v1 host timer" for the group membership on the interface. This also resets the timer to its initial value [Group Membership Interval] if the timer is currently running. 🕓
- "send group-specific query" for the group on the attached network. The Group-Specific Query is sent to the group being queried and has a Max Response Time of [Last Member Query Interval]. 🎯
- "notify routing +" tells the routing protocol that there are members of this group on this connected network. 🟢
- "notify routing -" tells the routing protocol that there are no longer any members of this group on this connected network. 🔴
The state diagram for a router in Querier state is below. Read it slowly, it's lowkey a lot 🫠
________________
----------------------------| |<-----------------------
| | |timer expired |
| timer expired| |(notify routing -, |
| (notify routing -)| No Members |clear rxmt tmr) |
| ------->| Present |<------- |
| | | | | |
|v1 report rec'd | | | | ------------ |
|(notify routing +, | |________________| | | rexmt timer| |
| start timer, | | | | expired | |
| start v1 host | v2 report received| | | (send g-s | |
| timer) | (notify routing +,| | | query, | |
| | start timer)| | | st rxmt | |
| __________|______ | _____|_|______ tmr)| |
| | |<------------ | | | |
| | | | |<----- |
| | | v2 report received | | |
| | | (start timer) | | |
| | Members Present |<-------------------| Checking | |
| ----->| | leave received | Membership | |
| | | | (start timer*, | | |
| | | | start rexmt timer,| | |
| | | | send g-s query) | | |
| | --->| |------------------->| | |
| | | |_________________| |______________| |
| | |v2 report rec'd | | | |
| | |(start timer) | |v1 report rec'd |v1 report rec'd |
| | ---------------- |(start timer, |(start timer, |
| |v1 host | start v1 host timer) | start v1 host |
| |tmr ______________V__ | timer) |
| |exp'd | |<---------------------- |
| ------| | |
| | Version 1 |timer expired |
| | Members Present |(notify routing -) |
------->| |-------------------------------------------
| |<--------------------
------->|_________________| v1 report rec'd |
| v2 report rec'd | | (start timer, |
| (start timer) | | start v1 host timer) |
----------------- --------------------------The state diagram for a router in Non-Querier state is similar, but it's a chill vibe 🧊 Non-Queriers do not send any messages and are only driven by message reception. Note that non-Queriers do not care whether a Membership Report message is Version 1 or Version 2. 🫶
________________
| |
| |
timer expired| |timer expired
(notify routing -)| No Members |(notify routing -)
--------->| Present |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| |report received |
| |(notify routing +,|
| | start timer) |
________|________ | ________|________
| |<--------- | |
| | report received | |
| | (start timer) | |
| Members Present |<-------------------| Checking |
| | g-s query rec'd | Membership |
| | (start timer*) | |
---->| |------------------->| |
| |_________________| |_________________|
| report received |
| (start timer) |
-----------------8. List of timers and default values ⏲️
okay bestie, the timers are mostly configurable 🎛️ but if somebody changes the defaults, they MUST be consistent among all routers on a single link. no going rogue 🙅♀️ also parentheses are used to group expressions so the algebra stays clean, so don't skip them 🧠
8.1. Robustness Variable 💪
the Robustness Variable lets you tune for the packet loss you expect on a subnet 📡 if a subnet is expected to be lossy, the Robustness Variable may be increased. IGMP is robust to (Robustness Variable-1) packet losses. The Robustness Variable MUST NOT be zero, and SHOULD NOT be one. Default: 2 🎀
8.2. Query Interval ✨
okay so the Query Interval is the gap between General Queries that the Querier sends 🕰️ Default: 125 seconds 💖
bestie, an admin can play with this number to control how many IGMP messages float around the subnet 🦋 bigger values mean IGMP Queries get sent less often, which is lowkey iconic for a quieter network 🤫
8.3. Query Response Interval ✨
This is the Max Response Time that goes into the periodic General Queries 🌸 Default: 100 (10 seconds) 💅
again, admins can tune this one to manage how bursty the IGMP traffic is 🌊 larger values make things less bursty, because hosts get to spread their responses across a bigger window 🫶 the number of seconds this stands for must be less than the Query Interval, no exceptions 🙅♀️
8.4. Group Membership Interval ✨
the Group Membership Interval is how long a multicast router has to wait before it decides nobody on the network is in a group anymore 😭 this value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one Query Response Interval) 🧮 the MUST is doing all the work here, bestie 💜
8.5. Other Querier Present Interval ✨
this is the amount of time a multicast router waits before it decides the other router that should be the querier is no longer around 👀 this value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one half of one Query Response Interval) 🌈 yes, it's a half, not a full one, so don't mix them up 🙈
8.6. Startup Query Interval ✨
the Startup Query Interval is the gap between General Queries that a Querier sends when it first starts up 🚀 Default: 1/4 the Query Interval 🍓
8.7. Startup Query Count ✨
this is how many Queries get sent on startup, with each one spaced out by the Startup Query Interval 🧚 Default: the Robustness Variable 💫
8.8. Last Member Query Interval ✨
the Last Member Query Interval is the Max Response Time that goes into Group-Specific Queries, which get sent when Leave Group messages show up 🚪 it's also how long to wait between Group-Specific Query messages ⏳ Default: 10 (1 second) ⚡
this one is a tuning knob for the "leave latency" of the network 🎛️ a smaller value means the router finds out faster that the last member of a group has left, which is so efficient 🏃♀️💨
8.9. Last Member Query Count ✨
this is how many Group-Specific Queries get sent before the router decides there are no local members left 🤷♀️ Default: the Robustness Variable 💜
8.10. Unsolicited Report Interval ✨
the Unsolicited Report Interval is the time between the repeats of a host's first report saying it joined a group 📣 Default: 10 seconds 🎀
8.11. Version 1 Router Present Timeout ✨
this is how long a host has to wait after hearing a Version 1 Query before it's allowed to send any IGMPv2 messages 🙃 Value: 400 seconds ⏰
9. Message destinations 📮
this info lives elsewhere in the document too, but here's a quick recap so you don't have to dig around 🫶
Message Type Destination Group
------------ -----------------
General Query ALL-SYSTEMS (224.0.0.1)
Group-Specific Query The group being queried
Membership Report The group being reported
Leave Message ALL-ROUTERS (224.0.0.2)okay, a little side-eye moment 👀 older, non-standard, now-obsolete versions of IGMPv2 had hosts send Leave Messages to the group being left 💀 so a router SHOULD accept Leave Messages addressed to the group being left, purely for backwards compatibility with those hosts 🫠 but no matter what, hosts MUST send to the ALL-ROUTERS address to be compliant with this spec 💅
10. Security Considerations 🔐
this section is serious business, bestie 😤 we go through what happens when someone forges a message of each type 👀
Query Message:
a forged Query message from a machine with a LOWER IP address than the current Querier hands Querier duties over to the forger 😱 if the forger then stops sending Query messages, the other routers' Other Querier Present timers will run out, and one of them will take over as Querier again 🔄 in the meantime, if the forger ignores Leave Messages, traffic might keep flowing to groups with no members for up to [Group Membership Interval] 🌊
a forged Query message sent to a group with members makes those member hosts report their memberships 📢 that adds a small amount of extra traffic on the LAN, but it doesn't cause any protocol problems 🫶
Report messages:
a forged Report message can make multicast routers think there are members of a group on a subnet when there really aren't 🙃 forged Reports from the local subnet are kinda meaningless, though, since joining a group on a host is generally an unprivileged operation 🤷♀️ so a local user can get the same result without forging anything at all 💀 forged Report messages from external sources are more troublesome, so there are two defenses against externally forged Reports 🛡️
- ignore the Report if you cannot identify the source address of the packet as belonging to a subnet assigned to the interface on which the packet was received 🚫 this means Reports sent by mobile hosts without addresses on the local subnet will be ignored too, which is a bummer for them 🥲
- ignore Report messages without Router Alert options [RFC 2113], and require that routers not forward Report messages 🛑 (the requirement is not a requirement of generalized filtering in the forwarding path, since the packets already have Router Alert options in them) 🧐 this solution breaks backwards compatibility with implementations of earlier versions of this specification which did not require Router Alert 💔
a forged Version 1 Report Message can push a router into the "version 1 members present" state for a particular group 😬 that means the router will ignore Leave messages, and traffic can keep flowing to groups with no members for up to [Group Membership Interval] 🌊 there are two defenses against forged v1 Reports 🛡️
- to defend against externally sourced v1 Reports, ignore the Report if you cannot identify the source address of the packet as belonging to a subnet assigned to the interface on which the packet was received 🚫 this means v1 Reports sent by mobile hosts without addresses on the local subnet will be ignored 🥲
- provide routers with a configuration switch to ignore Version 1 messages completely 🎛️ this breaks automatic compatibility with Version 1 hosts, so it should only be used in situations where "fast leave" is critical ⚡ this solution also protects against forged version 1 reports from the local subnet 🙌
Leave message:
a forged Leave message will make the Querier send out Group-Specific Queries for the group in question 🔍 this causes extra processing on each router and on each member of the group, but it can not cause loss of desired traffic 🫶 there are two defenses against externally forged Leave messages 🛡️
- ignore the Leave message if you cannot identify the source address of the packet as belonging to a subnet assigned to the interface on which the packet was received 🚫 this means Leave messages sent by mobile hosts without addresses on the local subnet will be ignored 🥲
- ignore Leave messages without Router Alert options [RFC 2113], and require that routers not forward Leave messages 🛑 (the requirement is not a requirement of generalized filtering in the forwarding path, since the packets already have Router Alert options in them) 🧐 this solution breaks backwards compatibility with implementations of earlier versions of this specification which did not require Router Alert 💔
11. Acknowledgments 💐
IGMPv2 was designed by Rosen Sharma and Steve Deering 👑 the real MVPs 🥹
12. References 📚
RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2113 Katz, D., "IP Router Alert Option," RFC 2113,
February 1997.
RFC 1112 Deering, S., "Host Extensions for IP Multicasting",
STD 5, RFC 1112, August 1989.13. Appendix I - Changes from IGMPv1 🦋
the IGMPv1 "Version" and "Type" fields got squished together into a single "Type" field 🫠
a new IGMP Type is assigned to Version 2 Membership Report messages, so a router can tell the difference between an IGMPv1 and an IGMPv2 host report 🔎
a new IGMP Type is created for the IGMPv2 Leave Group message 🚪
the Membership Query message is changed so that a field that used to sit unused now holds a new value, the Max Response Time ⏱️
the IGMPv2 spec now specifies a querier election mechanism 🗳️ in IGMPv1, the querier election was left up to the multicast routing protocol, and different protocols used different mechanisms 🌀 that could lead to more than one querier per network, so the election mechanism got standardized in IGMPv2 👏 however, this means care must be taken when an IGMPv2 router is trying to coexist with an IGMPv1 router that uses a different querier election mechanism 🤝 in particular, it means that an IGMPv2 router must be able to act as an IGMPv1 router on a particular network if configured to do so 🫶 the actions required include:
- set the Max Response Time field to 0 in all queries 0️⃣
- ignore Leave Group messages 🙈
the IGMPv2 spec relaxes the requirements on validity-checking for Membership Queries and Membership Reports 🧹 when upgrading an implementation, be sure to remove any checks that do not belong 🗑️
the IGMPv2 spec requires the presence of the IP Router Alert option [RFC 2113] in all packets described in this memo 🚨
14. Author's Address 🖊️
William C. Fenner
Xerox PARC
3333 Coyote Hill Road
Palo Alto, CA 94304
Phone: +1 650 812 4816
EMail: fenner@parc.xerox.com15. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (1997). All Rights Reserved. 🌈
this document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind 🎉 provided that the above copyright notice and this paragraph are included on all such copies and derivative works 📄 however, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations 🚫 except as needed for the purpose of developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English 🌍
the limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns ♾️💜
this document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🫶
📦 where this page comes from
- ietf: rfc2236 1997-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms