rfc-9776

Internet Group Management Protocol, Version 3

B. Haberman (Editor)
date2025-03 streamIETF areartg wgpim statusINTERNET STANDARD pages48 canonicalhttps://www.rfc-editor.org/rfc/rfc9776 doi10.17487/RFC9776
The Internet Group Management Protocol (IGMP) is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP (IGMPv3) adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document specifies IGMPv3. It is a revised version of RFC 3376 that includes clarifications and fixes for errata, and it is backward compatible with RFC 3376. This document updates RFC 2236 and obsoletes RFC 3376.

obsoletes

updates

also

Extracted elements (30)

design-rationale §A.2

IGMPv3 removes the host-suppression mechanism from IGMPv2, where hosts that heard another host's report would suppress their own. Suppression was removed because it prevented routers from receiving complete membership information needed for source-specific multicast and because the savings were deemed insufficient to justify the complexity and the loss of robustness.

multicast

design-rationale §A.1

State-Change Records (Filter-Mode-Change and Source-List-Change) were added so that hosts can immediately report changes in multicast reception interest without waiting for the next periodic Query, reducing join and leave latency. Without state-change messages, a host leaving a group would not be reflected until the Group Membership Interval expired.

multicast

interoperability-note §7.1

IGMP Query version is determined by message length and Max Resp Code: IGMPv1 Query has length 8 and Max Resp Code = 0; IGMPv2 Query has length 8 and Max Resp Code != 0; IGMPv3 Query has length >= 12. Queries not matching any condition MUST be silently ignored.

multicast

normative-requirement §6 MUST

A multicast router MUST enable reception of multicast address 224.0.0.22 from all sources on each interface over which IGMPv3 is run, and MUST perform the group member part of IGMPv3 for that address. IGMPv3 Membership Reports are sent to 224.0.0.22.

multicast, ip

normative-requirement §5.1 SHOULD

A State-Change Report triggered by an interface state change is retransmitted [Robustness Variable] - 1 additional times at random intervals within (0, [Unsolicited Report Interval]) to cover the possibility of the report being missed by one or more multicast routers.

multicast

normative-requirement §4.1.12 MUST

A system MUST accept and process any Query whose IP Destination Address field contains any of the addresses (unicast or multicast) assigned to the interface on which the Query arrives, not just the expected multicast destination.

multicast

normative-requirement §4 MUST

An IGMPv3 implementation MUST also support IGMPv1 Membership Report (0x12), IGMPv2 Membership Report (0x16), and IGMPv2 Leave Group (0x17) message types for interoperation with previous versions of IGMP.

multicast

normative-requirement §4.2.11 MUST NOT

An IGMPv3 implementation MUST NOT include any auxiliary data in transmitted Group Records (Aux Data Len MUST be set to zero) and MUST ignore any auxiliary data present in received Group Records, as IGMPv3 defines no auxiliary data semantics.

multicast

normative-requirement §2 MUST NOT

An implementation MAY impose a limit on source-list size, but that limit MUST NOT be less than 64 addresses per list. When an operation causes the source-list size limit to be exceeded, the service interface MUST return an error.

multicast

normative-requirement §3.2 MUST NOT

An implementation MUST NOT use an EXCLUDE interface record to represent a group when all sockets for that group are in INCLUDE state. If system resource limits are reached when calculating interface state, an error MUST be returned to the requesting application.

multicast

normative-requirement §4 MUST

Every IGMP message MUST be sent with an IP TTL of 1, IP Precedence of Internetwork Control (ToS 0xc0), and an IP Router Alert option in the IP header.

multicast, ip

normative-requirement §7.2.1 MUST

IGMPv3 hosts MUST operate in v1 and v2 compatibility modes and MUST keep per-interface state regarding the compatibility mode of each attached network via the Host Compatibility Mode variable and version-specific Querier-Present Timers.

multicast

normative-requirement §4.2.14 MUST

Routers MUST accept a Membership Report with a source address of 0.0.0.0, which may be used by a system that has not yet acquired an IP address. Multiple systems on a LAN may simultaneously use 0.0.0.0 as a source address.

multicast

normative-requirement §6.4 SHOULD

SSM-aware routers SHOULD ignore records with multicast addresses in the SSM range if the record type is MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE, and SHOULD ignore IGMPv1/IGMPv2 reports for SSM addresses. SSM-aware hosts SHOULD NOT send MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE records for SSM addresses.

multicast

normative-requirement §4 MUST

Unrecognized IGMP message types MUST be silently ignored. Similarly, unrecognized Group Record Type values MUST be silently ignored.

multicast

normative-requirement §4.1.10 MUST

When a received Query or Report contains additional octets beyond the defined fields, implementations MUST include those octets in checksum verification but MUST otherwise ignore them. When sending, implementations MUST NOT include additional octets beyond the defined fields.

multicast

normative-requirement §4.1.2 MUST

When receiving packets, the IGMP Checksum MUST be verified before processing. The checksum is the 16-bit one's complement sum of the entire IP payload, with the Checksum field set to zero during computation.

multicast

protocol-element §3.2

Per-interface multicast reception state is derived from per-socket state: if any socket for a (interface, multicast-address) pair is in EXCLUDE mode, the interface record is EXCLUDE with source-list = intersection of all EXCLUDE socket lists minus sources in any INCLUDE socket. If all sockets are in INCLUDE mode, the interface record is INCLUDE with source-list = union of all socket source-lists.

multicast

protocol-element §4.2.13

Six Group Record types are defined: MODE_IS_INCLUDE (1) and MODE_IS_EXCLUDE (2) are Current-State Records sent in response to queries; CHANGE_TO_INCLUDE_MODE (3) and CHANGE_TO_EXCLUDE_MODE (4) are Filter-Mode-Change Records; ALLOW_NEW_SOURCES (5) and BLOCK_OLD_SOURCES (6) are Source-List-Change Records sent when source-list changes without a filter-mode change.

multicast

protocol-element §2

The IPMulticastListen(socket, interface, multicast-address, filter-mode, source-list) service interface allows upper-layer protocols to request reception of packets to a multicast address in either INCLUDE mode (only listed sources) or EXCLUDE mode (all sources except listed). Join is equivalent to EXCLUDE with empty source-list; Leave is equivalent to INCLUDE with empty source-list.

multicast, ip

protocol-element §4.1.6

The QRV (Querier's Robustness Variable) field carries the querier's Robustness Variable; if > 7, QRV is set to zero. Non-querier routers adopt the QRV from the most recently received Query as their own Robustness Variable, unless QRV was zero, in which case they use the default value.

multicast

protocol-element §4.1.5

The S flag (Suppress Router-Side Processing) in a Query, when set to one, instructs receiving multicast routers to suppress normal timer updates upon receiving the Query but does not suppress querier election or host-side Query processing.

multicast

protocol-element §4.1.11

Three query variants exist: (1) General Query—Group Address and Number of Sources both zero, sent to 224.0.0.1; (2) Group Specific Query—Group Address set to the multicast address, Number of Sources zero; (3) Group-and-Source Specific Query—Group Address and one or more Source Addresses set, used to verify interest in specific sources.

multicast

security-consideration §9.3

A malicious host can send forged State-Change Reports to cause routers to join undesired multicast groups (current-state reports) or to trigger spurious queries by sending BLOCK_OLD_SOURCES reports, causing unnecessary query traffic. IPsec authentication headers may be used to provide authentication for IGMP messages where such security is required.

security, multicast, ipsec

security-consideration §9.1

IGMP provides no authentication or authorization, making it susceptible to local network attacks. A malicious host can send forged Membership Queries to manipulate the querier election, force other hosts to suppress responses, or increase leave latency by sending forged Queries with large Max Response Times.

security, multicast

state-machine §7.2.1

Host Compatibility Mode per interface has three states: IGMPv1, IGMPv2, IGMPv3. Receiving an IGMPv1 Query sets the IGMPv1-Querier-Present Timer; receiving an IGMPv2 General Query sets the IGMPv2-Querier-Present Timer. When timers expire, the host steps up to the next newer compatible version, ultimately returning to IGMPv3 mode when both timers have expired.

multicast

state-machine §6.2.1

Router Filter Mode per group transitions between INCLUDE and EXCLUDE. Reception of an IS_EX or TO_EX record transitions the router to EXCLUDE mode, setting the Group Timer to GMI. When the Group Timer expires in EXCLUDE mode, the router transitions back to INCLUDE mode, retaining only sources with running source timers as the new INCLUDE source record state.

multicast

wire-format §4.1

IGMPv3 Membership Query message (type 0x11): 8-bit Type, 8-bit Max Resp Code, 16-bit Checksum, 32-bit Group Address, 4-bit Flags, 1-bit S flag, 3-bit QRV, 8-bit QQIC, 16-bit Number of Sources, followed by N 32-bit Source Address fields. Sent with IP TTL=1, IP Precedence=Internetwork Control, and Router Alert option.

multicast, ip

wire-format §4.2

IGMPv3 Membership Report message (type 0x22): 8-bit Type, 8-bit Reserved, 16-bit Checksum, 16-bit Flags, 16-bit Number of Group Records (M), followed by M Group Records. Each Group Record contains Record Type (8 bits), Aux Data Len (8 bits), Number of Sources N (16 bits), 32-bit Multicast Address, N 32-bit Source Addresses, and optional Auxiliary Data.

multicast, ip

wire-format §4.1.1

Max Resp Code field uses a dual encoding: values < 128 represent Max Response Time directly in 1/10-second units; values >= 128 encode a floating-point value with a 1-bit indicator, 3-bit exponent, and 4-bit mantissa, yielding Max Response Time = (mant | 0x10) << (exp + 3). The same scheme applies to the QQIC field for Query Interval encoding.

multicast