RFC 5790
Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols
Lightweight IGMPv3 and MLDv2 Protocols ✨
Okay bestie, this RFC is RFC 5790 and it's titled Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols 🦋. It's a Standards Track document from the IETF, dated February 2010, with ISSN 2070-1721. The authors are H. Liu and W. Cao from Huawei Technologies, and H. Asaeda from Keio University 🌸. The header doesn't list anything it obsoletes or updates, so it's standing on its own.
Abstract 💖
Here's the vibe: this doc describes lightweight IGMPv3 and MLDv2 protocols, called LW-IGMPv3 and LW-MLDv2, which make the standard (full) versions of IGMPv3 and MLDv2 simpler 🧚. It also makes sure they play nicely with the full versions and with the older versions of IGMP and MLD. Very considerate of them, honestly 🫶.
Status of This Memo 📜
This is an Internet Standards Track document 🔥.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741 💅.
For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc5790 🔗.
Copyright Notice ⭐
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because 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 they are provided without warranty as described in the Simplified BSD License 🎀.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without getting an adequate license from the person(s) controlling the copyright in those materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🙈.
Table of Contents 📚
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Simplification Method Overview ..................................4
3.1. Behavior of Group Members ..................................5
3.2. Behavior of Multicast Routers ..............................5
4. LW-IGMPv3 Protocol for Group Members ............................6
4.1. Query and Report Messages ..................................6
4.2. Action on Change of Interface State ........................6
4.3. Action on Reception of a Query .............................7
4.4. LW-IGMPv3 Group Record Types ...............................7
5. LW-IGMPv3 Protocol for Multicast Routers ........................9
5.1. Group Timers and Source Timers in the Lightweight Version ..9
5.2. Source-Specific Forwarding Rules ..........................10
5.3. Reception of Current-State Records ........................10
5.4. Reception of Source-List-Change and
Filter-Mode-Change Records ................................12
6. Interoperability ...............................................13
6.1. Interoperation with the Full Version of IGMPv3/MLDv2 ......13
6.1.1. Behavior of Group Members ..........................13
6.1.2. Behavior of Multicast Routers ......................13
6.2. Interoperation with IGMPv1/IGMPv2 .........................14
6.2.1. Behavior of Group Members ..........................14
6.2.2. Behavior of Multicast Routers ......................14
6.3. Interoperation with MLDv1 .................................15
7. Implementation Considerations ..................................15
7.1. Implementation of Source-Specific Multicast ...............15
7.2. Implementation of Multicast Source Filter (MSF) APIs ......16
8. Security Considerations ........................................16
9. Acknowledgements ...............................................16
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................171. Introduction 🌸
Okay so IGMP version 3 [2] and MLD version 2 [3] bring source filtering, which the older versions IGMPv1 [4], IGMPv2 [5], and MLDv1 [6] just don't have 😭. An IGMPv3- or MLDv2-capable host can tell its upstream router which group it wants to join by saying which sources it does or doesn't want multicast traffic from. IGMPv3 and MLDv2 also let a multicast router learn which sources are of interest, or not of interest, for a particular multicast address. The router then uses that info when it forwards multicast data packets 💅.
INCLUDE and EXCLUDE filter-modes are how this source filtering works 🦋. If a host wants to receive from specific sources, it sends an IGMPv3 or MLDv2 report with filter-mode set to INCLUDE. If it doesn't want to receive from some sources, it sends a report with filter-mode set to EXCLUDE. A source-list for the given sources shall be included in the Report message.
Routers use INCLUDE and EXCLUDE too, to process those reports 👑. When a multicast router gets Report messages from its downstream hosts, it forwards the matching multicast traffic by keeping track of the requested group and source addresses. Group timers and source timers keep the forwarding state of the wanted groups and sources going under certain filter-modes ⏰. When a group report arrives or a timer expires, a multicast router may update the desired or undesired source-lists, reset timer values, change the filter-mode, or trigger group queries. All of these factors depend on each other, so the rules get really complicated, and the interface states can change a lot 🙈.
The multicast filter-mode helps a receiver say what it wants much more clearly 💜. It's useful for Source-Specific Multicast (SSM) [7], where you name the sources you're interested in using INCLUDE mode. Real applications don't use EXCLUDE mode to block sources very often, though, because people usually want to name the sources they want, not the ones they don't. Even if one user refuses traffic from some sources in a group, the multicast traffic will still be forwarded onto the shared network if other users there want it 😤. So a filter that blocks sources is generally unnecessary.
This document proposes simplified versions of IGMPv3 and MLDv2, called Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and LW-MLDv2) ✨. LW-IGMPv3 and LW-MLDv2 are subsets of the standard IGMPv3 and MLDv2.
They support both Any-Source Multicast (ASM) and SSM communications without a filtering function that blocks sources 🎀. They're compatible with the standard IGMPv3 and MLDv2, and the protocol operations done by hosts and routers (or switches doing IGMPv3/MLDv2 snooping) are simplified so the complicated stuff goes away 🧚. Since LW-IGMPv3 and LW-MLDv2 are fully compatible with IGMPv3 and MLDv2, hosts or routers that already implement the full version don't need to implement or change anything to work with LW-IGMPv3/LW-MLDv2 hosts or routers 🫶.
2. Terminology 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1] 📖.
Here are some more terms used in this document 🔍:
(*,G) join: An operation triggered by a host that wants to join a group G. In this case, the host receives from all sources sending to group G. This is typical in ASM communication.
(S,G) join: An operation triggered by a host that wants to join a group G, specifying a desired source S. In this case, the host receives traffic only from source S sending to group G.
INCLUDE (S,G) join: An operation triggered by a host that wants to join a group G under INCLUDE filter-mode, specifying a desired source S. It has the same meaning as (S,G) join.
EXCLUDE (*,G) join: An operation triggered by a host that wants to join a group G under EXCLUDE filter-mode. It has the same meaning as (*,G) join.
EXCLUDE (S,G) join: An operation triggered by a host that wants to join a group G under EXCLUDE filter-mode, specifying an undesired source S. This operation is not supported by LW-IGMPv3/LW-MLDv2 🚫.
3. Simplification Method Overview 🍓
The principle is to simplify the host's and router's behavior as much as possible to improve efficiency. The whole point is to keep interoperability with the full versions while introducing no side effects on applications 💖.
For convenience, this document mainly talks about IGMPv3, since MLDv2 inherits the same source filtering mechanism. It still shows MLDv2's unique specifications whenever they're needed 🌈.
3.1. Behavior of Group Members 🎀
LW-IGMPv3 inherits the service interface model of IGMPv3 👑:
IPMulticastListen ( socket, interface, multicast-address,
filter-mode, source-list )In the lightweight protocol, INCLUDE mode on the host side works exactly like the full version does for INCLUDE (S,G) join 🦋. EXCLUDE mode on the host side is kept only for excluding null source-lists, which denotes a (*,G) join as used by IGMPv2/IGMPv1/MLDv1 ✨. The detailed host operation of LW-IGMPv3/LW-MLDv2 is described in Section 4 💜.
3.2. Behavior of Multicast Routers 🛣️
Okay so, in IGMPv3 the router has a filter-mode for each group, and that's what keeps the state of a group membership nice and tidy [2]. As a rule, once a member report is in EXCLUDE mode, the router's filter-mode for that group gets set to EXCLUDE. When every system stops sending EXCLUDE mode reports, the filter-mode for that group may flip back to INCLUDE mode. The group timer is what tells the router when that flip should happen. ⏲️
In LW-IGMPv3, hosts mostly send INCLUDE requests, but they can also request an EXCLUDE (*,G) join, which the router reads as "hey, include all sources" 🙌. Without the full, more general form of EXCLUDE requests, the router doesn't need to keep the EXCLUDE filter-mode at all. That means the state model for multicast routers can be simplified like this:
(multicast address, group timer, (source records))So here a group timer stands in for a (,G) join. Its basic behavior: when a router receives a (,G) join, it sets its group timer and keeps the source-list for the sources listed in the source records it got earlier. When the group timer expires, the router may switch to receiving only the listed sources. The definition of a source record is the same as in the full version 💜.
Getting rid of the filter-mode is a huge win because it makes the router's behavior way simpler 💅. You can find the nitty-gritty router operation details in Section 5.
4. LW-IGMPv3 Protocol for Group Members ✨
4.1. Query and Report Messages
LW-IGMPv3 uses the same two message types, Query and Report messages, as the full version protocols 🎀. Queries work exactly the same way in both, with no difference in how they're defined or used. The report types in the lightweight protocol are reduced, though, because the operation that triggers an EXCLUDE (S,G) join just gets left out 🙈.
The full IGMPv3 defines three Group Record Types. First there's the Current-State Record, written as MODE_IS_INCLUDE (called IS_IN) or MODE_IS_EXCLUDE (called IS_EX). Then there's the Filter-Mode-Change Record, written as CHANGE_TO_INCLUDE_MODE (TO_IN) or CHANGE_TO_EXCLUDE_MODE (TO_EX). Last, the Source-List-Change Record, written as ALLOW_NEW_SOURCES (ALLOW) or BLOCK_OLD_SOURCES (BLOCK). LW-IGMPv3 keeps the actions for a change in interface state and for receiving a query, but IS_IN and IS_EX get eliminated, and Current-State Records get swapped out for other records. The next sections dig into the details 🦋.
4.2. Action on Change of Interface State
When the state of a group member host's interface changes, a State-Change Report gets sent out of that interface right away ⚡. The type and contents of the Group Record(s) in that report come from comparing the filter-mode and source-list for the affected multicast address before and after the change. The rules for this computation are the same as in the full version, but the lightweight host gets a simpler set of interface state change rules because there are fewer message types 💖. The contents of the new report are worked out like this (Group Record Types are described in Section 4.4):
Old State New State State-Change Report Sent
----------- ----------- ------------------------
INCLUDE (A) INCLUDE (B) ALLOW(B-A), BLOCK(A-B)
INCLUDE (A) EXCLUDE ({}) TO_EX({})
INCLUDE ({}) EXCLUDE ({}) TO_EX({})
EXCLUDE ({}) INCLUDE (B) TO_IN(B)Just like in the full version, a State-Change Report could get missed by one or more multicast routers, so it gets retransmitted [Robustness Variable]-1 more times. Those retransmissions happen at random intervals picked from the range (0, [Unsolicited Report Interval]). (These values are defined in [2][3].) 🔁
4.3. Action on Reception of a Query
Same as the full version: when a lightweight host gets a query, it doesn't respond right away 🙅♀️. Instead it waits a random amount of time, capped by the Max Resp Time value that comes from the Max Resp Code in the received Query message [2][3]. The system could get a bunch of different queries on different interfaces, and of different kinds (for example General Queries, Group-Specific Queries, and Group-and-Source-Specific Queries). Each of those might need its own delayed response 🌈.
Before scheduling a response to a query, the system must first look at any previously scheduled pending responses, and in lots of cases it'll schedule one combined response. So the lightweight version host has to be able to maintain this state:
- A timer per interface for scheduling responses to General Queries.
- A per-group and interface timer for scheduling responses to Group-Specific and Group-and-Source-Specific Queries.
- A per-group and interface list of sources to be reported in the response to a Group-and-Source-Specific Query.
LW-IGMPv3 inherits the full version's rules for deciding whether a report needs to be scheduled. The difference is in the simplified EXCLUDE filter-mode and the type of report, which Section 4.4 covers in detail 🫶.
4.4. LW-IGMPv3 Group Record Types
Several Group Record Types from the full IGMPv3 aren't used in LW-IGMPv3 🙃. That's because some of the processes tied to changing the filter-mode to EXCLUDE mode are gone, and some Report messages got folded into a record with a null source address list. Here's every record type used in Report messages by the full and lightweight protocols:
IGMPv3 LW-IGMPv3 Comments
--------- --------- -------------------------------------
IS_EX({}) TO_EX({}) Query response for (*,G) join
IS_EX(x) N/A Query response for EXCLUDE (x,G) join
IS_IN(x) ALLOW(x) Query response for INCLUDE (x,G) join
ALLOW(x) ALLOW(x) INCLUDE (x,G) join
BLOCK(x) BLOCK(x) INCLUDE (x,G) leave
TO_IN(x) TO_IN(x) Change to INCLUDE (x,G) join
TO_IN({}) TO_IN({}) (*,G) leave
TO_EX(x) N/A Change to EXCLUDE (x,G) join
TO_EX({}) TO_EX({}) (*,G) joinHere "x" stands for a non-null source address list, and "({})" stands for a null source address list. So IS_EX({}) means a report whose record type is IS_EX with a null source address list. "N/A" means not applicable (or no use), because that operation should never happen in the lightweight protocols 🚫.
LW-IGMPv3 doesn't use EXCLUDE filter-mode with a non-null source address list 🙅. When a multicast router gets a Report message with either an IS_EX({}) or a TO_EX({}) record type, it ends up with the exact same state. So LW-IGMPv3 merges the IS_EX({}) operation into the TO_EX({}) operation 🧠.
When an LW-IGMPv3 host needs to respond to a query about an INCLUDE (x,G) join state, it uses an ALLOW(x) message type instead of the IS_IN record type 🎯. The router handles both messages in exactly the same way, so IS_IN(x) gets eliminated to keep things simple.
An LW-IGMPv3 host doesn't use EXCLUDE mode, but TO_IN and TO_EX records still show up, for example, in this situation: the host first launches an application (AP1) that requests an INCLUDE (x,G) join and sends ALLOW(x). Then the host launches a second application (AP2) that joins (*,G) and sends TO_EX({}). Now, when AP2 terminates but AP1 is still running on the lightweight host, the host sends a report with the TO_IN(x) record type for [Robustness Variable] times 🍓.
Even though an LW-IGMPv3 host adopts just four message types (ALLOW, BLOCK, TO_IN, and TO_EX) for simplicity, it's still fine to use IS_EX({}) and IS_IN(x) (instead of TO_EX({}) and ALLOW(x), respectively) when responding to queries ✨. This won't cause an interoperation problem, because the router processes each of those two message sets the same way, as long as the router implementation follows the rules given by the full IGMPv3 👑.
5. LW-IGMPv3 Protocol for Multicast Routers 🛣️
The biggest difference between the full and lightweight protocols on the router side is that the lightweight version throws out the filter-mode and redefines what the group timer does 🔥. Because of that, the states a lightweight router keeps are reduced, and the protocol operation is way simpler.
5.1. Group Timers and Source Timers in the Lightweight Version
In both lightweight and full IGMPv3 routers, a source timer is kept for each source record, and it gets updated whenever that source shows up in a received report ⏰. It tells the router whether the source is still valid, and the router has to check it when making its forwarding decision 🦋.
In the full version of IGMPv3, the group timer is used to move the router's filter-mode from EXCLUDE back to INCLUDE. The lightweight protocols redefine it so it tracks the non-source-specific receiving state kept for a (,G) join 💜. Once a group record of TO_EX({}) arrives, the group timer gets set to represent this (,G) group join. When the group timer expires, that means there are no more listeners on the attached network for this (*,G) group 😢. If there are still unexpired sources at that moment (sources whose source timers are greater than zero), the router switches to receiving traffic for those sources only. The role of the group timer breaks down like this:
Group Timer Value Actions/Comments
------------------ --------------------------------------
G_Timer > 0 All members in this group.
G_Timer == 0 No more listeners to this (*,G) group.
If all source timers have expired, then
delete group record. If there are
still source record timers running,
use those source records with running
timers as the source record state.The group and source timer operation in the lightweight version is a bit different from the full IGMPv3. In the full version, if a source timer expires while the router is in EXCLUDE filter-mode, its source record doesn't get deleted until the group timer expires, because it's still being used to indicate undesired sources 🧐. In the lightweight version, there's no need to keep those records around for blocking specific sources. So if a source timer expires, its source record should be deleted immediately, without waiting for the group timer to time out 🗑️✨
5.2. Source-Specific Forwarding Rules ✨
Okay bestie, so a full version multicast router has to check its IGMPv3 state before it decides whether to forward a datagram from a source. It looks at the router filter-mode and the source timer. LW-IGMPv3 doesn't have a router filter-mode, so the group timer and the source timer have to do that job 🎀. Here's the forwarding suggestion LW-IGMPv3 gives the routing protocols 💅:
Group Timer Source Timer Action
------------ ------------------ -----------------------
G_Timer == 0 S_Timer > 0 Suggest forwarding
traffic from source
G_Timer == 0 S_Timer == 0 Suggest stopping
forwarding traffic from
source and remove
source record. If there
are no more source
records for the group,
delete group record
G_Timer == 0 No Source Elements Suggest not forwarding
traffic from source
G_Timer > 0 S_Timer >= 0 Suggest forwarding
traffic from source
G_Timer > 0 No Source Elements Suggest forwarding
traffic from source5.3. Reception of Current-State Records 💖
When a router gets Current-State Records, the LW-IGMPv3 router resets its group or source timers and updates its source-list for the group. For source-specific group reception state (when G_Timer == 0 and S_Timer > 0), the source-list holds the sources whose traffic the router will forward. For non-source-specific group reception (when G_Timer > 0), the source-list remembers the valid sources to receive traffic from once it toggles over to source-specific reception state 🦋.
Now, the LW-IGMPv3 host only sends a subset of the full version's messages, but the LW-IGMPv3 router should be able to process as many messages as it can so it stays compatible with full version hosts 🫶. Heads up: if the report type is IS_EX(x) with a non-empty source-list, the router treats it as the same type of report but with an empty source-list. The notation means exactly what it means in full IGMPv3. Here's what a multicast router does after it receives Current-State Records 👑:
Old New
Source- Source-
Group Timer List Report Rec'd List Actions
------------ ------ ------------ ------ -----------
G_Timer == 0 A IS_IN(B) A+B (B)=GMI
G_Timer == 0 A IS_EX({}) A G_Timer=GMI
G_Timer > 0 A IS_IN(B) A+B (B)=GMI
G_Timer > 0 A IS_EX({}) A G_Timer=GMIYou can simplify that table even more, since the processes are exactly the same for both values of G_Timer 🧚:
Old New
Source- Source-
List Report Rec'd List Actions
------ ------------ ------ -----------
A IS_IN(B) A+B (B)=GMI
A IS_EX({}) A G_Timer=GMIWithout EXCLUDE filter-mode, it's super simple 🌸. When a router gets an IS_IN report, it adds the reported source addresses to the previous source-list and sets their source timers to GMI. When it gets an IS_EX({}) report, it sets the non-source-specific receiving states by resetting the group timer value, and it keeps the previous source-list exactly as it was 🍓.
5.4. Reception of Source-List-Change and Filter-Mode-Change Records 🔥
When an LW-IGMPv3 router gets Source-List-Change and Filter-Mode-Change Records, it needs to reset its group and source timers, update its source-list for the group, or trigger group queries. The router sends those queries for the sources that are asked to stop being forwarded to the group 🙈. Heads up again: if the report type is TO_EX(x) with a non-empty source-list, the router treats it as the same type of report with an empty source-list. The table below shows the state changes and the actions that should be taken 💜.
Old New
Source- Source-
Group Timer List Report Rec'd List Actions
------------ ------ ------------ ------ -------------
G_Timer == 0 A ALLOW(B) A+B (B)=GMI
G_Timer == 0 A BLOCK(B) A Send Q(G,A*B)
G_Timer == 0 A TO_IN(B) A+B (B)=GMI
Send Q(G,A-B)
G_Timer == 0 A TO_EX({}) A G_Timer=GMI
G_Timer > 0 A ALLOW(B) A+B (B)=GMI
G_Timer > 0 A BLOCK(B) A Send Q(G,A*B)
G_Timer > 0 A TO_IN(B) A+B (B)=GMI
SendQ(G,A-B)
Send Q(G)
G_Timer > 0 A TO_EX({}) A G_Timer=GMIAnd here's the merged version, with the duplicate lines combined 🎀:
Old New
Source- Source-
List Report Rec'd List Actions
------ ------------ ------ ----------------------
A ALLOW(B) A+B (B)=GMI
A BLOCK(B) A Send Q(G,A*B)
A TO_IN(B) A+B (B)=GMI
Send Q(G,A-B)
If G_Timer>0 Send Q(G)
A TO_EX({}) A G_Timer=GMI6. Interoperability 🦋
LW-IGMPv3/LW-MLDv2 hosts and routers must interoperate with hosts and routers of the full version [2][3]. They must also interoperate gracefully with hosts and routers running IGMPv1/v2 or MLDv1 💖.
6.1. Interoperation with the Full Version of IGMPv3/MLDv2 ✨
LW-IGMPv3/LW-MLDv2 don't change the message formats of the group Query and Report messages that the full version protocols use. Same vibes, same format 🫶.
6.1.1. Behavior of Group Members 🌈
An LW-IGMPv3 host's compatibility mode comes from the Host Compatibility Mode variable, which can be in one of three states: IGMPv1, IGMPv2, or IGMPv3. When a lightweight host acts as LW-IGMPv3 on its interface, that interface's Host Compatibility Mode is set to IGMPv3, and the host sends a subset of IGMPv3 Report messages. A multicast router running the full or the lightweight IGMPv3 protocol on the same LAN can recognize those 💅.
6.1.2. Behavior of Multicast Routers 👑
An LW-IGMPv3 or LW-MLDv2 router doesn't process IS_EX(x) and TO_EX(x) reports directly. Those are the ones the full version uses. When an LW-IGMPv3/LW-MLDv2 router gets these Report messages from full version hosts, it MUST translate them internally to IS_EX({}) and TO_EX({}) respectively, and then behave accordingly 🔥.
6.2. Interoperation with IGMPv1/IGMPv2 🌸
The lightweight protocols can be treated as a parallel version of the full version of IGMPv3/MLDv2, so their compatibility principle and method with the older versions are generally the same as the full IGMPv3/MLDv2 ones 🧚.
6.2.1. Behavior of Group Members 💜
An interface's Host Compatibility Mode is set to IGMPv2, and its IGMPv2 Querier Present timer is set to Older Version Querier Present Timeout seconds (defined in [2]), whenever an IGMPv2 General Query arrives on that interface. An interface's Host Compatibility Mode is set to IGMPv1, and its IGMPv1 Querier Present timer is set to Older Version Querier Present Timeout seconds, whenever an IGMPv1 Membership Query arrives on that interface 🍓.
When older version group members are around, LW-IGMPv3 hosts may let their Report message be suppressed by either an IGMPv1 or IGMPv2 membership report. But sending IGMPv1 or v2 packets lowers the capability of the LW-IGMPv3 system, so as a potential protection mechanism, the choice to enable or disable backward compatibility may be configurable 🙈.
6.2.2. Behavior of Multicast Routers 🎀
An LW-IGMPv3 router placed on a network with routers that haven't been upgraded to IGMPv3 behaves exactly the same as a full IGMPv3 router in that situation [2] 💖.
A full IGMPv3 router uses Group Compatibility Mode (which is IGMPv1, IGMPv2, or IGMPv3) per group record to show which version of the IGMP protocol it applies to that group. The value gets set based on the version of the IGMP reports it received. When Group Compatibility Mode is IGMPv3, the lightweight router runs the LW-IGMPv3 protocol for that group 🦋.
When Group Compatibility Mode is IGMPv2, an LW-IGMPv3 router inherits this compatibility mechanism under these rules:
IGMP Message LW-IGMPv3 Equivalent
-------------- --------------------
v2 Report TO_EX({})
v2 Leave TO_IN({})When Group Compatibility Mode is IGMPv1, an LW-IGMPv3 router internally translates the following IGMPv1 and IGMPv2 messages for that group into their LW-IGMPv3 equivalents 🌈:
IGMP Message LW-IGMPv3 Equivalent
-------------- --------------------
v1 Report TO_EX({})
v2 Report TO_EX({})6.3. Interoperation with MLDv1 🧚
LW-MLDv2 hosts and routers MUST interoperate with hosts and routers running MLDv1. The method is the same as the one described in Section 6.2. The difference is that when an LW-MLDv2 router has an MLDv1 listener on its network, it translates the following MLDv1 messages into their LW-MLDv2 equivalents 💅:
MLDv1 Message LW-MLDv2 Equivalent
------------- -------------------
Report TO_EX({})
Done TO_IN({})7. Implementation Considerations ⭐
The lightweight protocols don't need any extra procedures for implementing the related protocols or systems, like IGMP/MLD snooping, multicast routing protocols, or operating application sockets. Meanwhile, the processing loads on switches and routers that run IGMPv3/MLDv2 (snooping) and multicast routing protocols may be greatly decreased 🫶💖.
7.1. Implementation of Source-Specific Multicast 🔥
[8] specifies the requirements for implementing Source-Specific Multicast (SSM) on IGMPv3/MLDv2 hosts and routers. The lightweight protocol follows the same rules as given in [8], except for the change of message types that comes with the simplification 👑.
An LW-IGMPv3/LW-MLDv2 host should not invoke (,G) join (i.e., TO_EX({})) and (,G) leave (i.e., TO_IN({})) for applications whose multicast addresses are in the SSM address range 🙈. An upstream LW-IGMPv3/LW-MLDv2 router MUST NOT establish forwarding state, and it MAY log an error when it receives them, as described in [7] 🚨💀.
7.2. Implementation of Multicast Source Filter (MSF) APIs ✨
okay so [9] defines four Multicast Source Filter (MSF) APIs 🎀: (1) IPv4 Basic MSF APIs, (2) IPv4 Advanced MSF APIs, (3) Protocol-Independent Basic MSF APIs, and (4) Protocol-Independent Advanced MSF APIs. ngl that's a lot of API names, bestie 💅
so here's the tea. An LW-IGMPv3 host should implement either the IPv4 Basic MSF API or the Protocol-Independent Basic MSF API 🦋. An LW-MLDv2 host should implement the Protocol-Independent Basic MSF API 💜. The Advanced ones, IPv4 Advanced MSF API and Protocol-Independent Advanced MSF API, are optional to implement in an LW-IGMPv3/LW-MLDv2 host 🌸. So the Advanced APIs are a total bonus, not a must-have ✨
8. Security Considerations 🔒
The security considerations are the same as that of the full version of IGMPv3/MLDv2. 😭 So if you already know the full protocols, you already know the security story. Main character energy, no need to start over 👑
9. Acknowledgements 🫶
The authors would like to thank MBONED and MAGMA working group members. 🌈 Special thanks is given to Marshall Eubanks, Guo Feng, Mark Fine, Alfred Hoenes, Prashant Jhingran, Bharat Joshi, Guo Tao, Wang Wendong, and Gong Xiangyang for their valuable suggestions and comments on this document. These people are literally the reason this doc is so good 💖
10. References 📚
10.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
- [3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
- [4] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
- [5] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
- [6] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
- [7] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
- [8] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
10.2. Informative References
- [9] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.
Authors' Addresses 🧚
Hui Liu
Huawei Technologies Co., Ltd.
Huawei Bld., No.3 Xinxi Rd.
Shang-Di Information Industry Base
Hai-Dian Distinct, Beijing 100085
China
EMail: Liuhui47967@huawei.com
Wei Cao
Huawei Technologies Co., Ltd.
Huawei Bld., No.3 Xinxi Rd.
Shang-Di Information Industry Base
Hai-Dian Distinct, Beijing 100085
China
EMail: caowayne@huawei.com
Hitoshi Asaeda
Keio University
Graduate School of Media and Governance
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
EMail: asaeda@wide.ad.jpThat's the whole RFC, bestie! 🌈💖 Three authors, nine thanks, and a wall of references. We made it, we ate it, and now it's yours to slay 👑✨
📦 where this page comes from
- ietf: rfc5790 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms