RFC 9279
Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Message Extension
RFC 9279 💖 Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Message Extension
The title block tea 🫶
- RFC number: 9279 🎀
- Category: Standards Track ✨
- Date: August 2022 📅
- ISSN: 2070-1721
- Obsoletes / Updates: nothing listed here, so this doc doesn't replace or update any earlier RFCs 🌸
- Authors:
- M. Sivakumar, Juniper Networks 🦋
- S. Venaas, Cisco Systems, Inc. 🦋
- Z. Zhang, ZTE Corporation 🦋
- H. Asaeda, NICT 🦋
Abstract 🌈
okay so this doc gives you a generic mechanism to extend IGMPv3 and Multicast Listener Discovery Version 2 (MLDv2) by using a list of TLVs (Type, Length, and Value) 🧚
Status of This Memo 💅
This is an Internet Standards Track document. It's giving official ✨
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 7841 📚
You can find the current status of this document, any errata, and info on how to send feedback at https://www.rfc-editor.org/info/rfc9279 🔗
Copyright Notice 🔒
Copyright (c) 2022 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 (https://trustee.ietf.org/license-info) as they stand on the date this document is published. Please read these carefully because they lay out your rights and restrictions for this document 📜 Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Revised BSD License.
Table of Contents 🗺️
1. Introduction
2. Conventions Used in This Document
3. Extension Format
3.1. Multicast Listener Query Extension
3.2. Version 2 Multicast Listener Report Extension
3.3. IGMP Membership Query Extension
3.4. IGMP Version 3 Membership Report Extension
4. No-op TLV
5. Processing the Extension
6. Applicability and Backwards Compatibility
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction ✨
Okay, so this doc defines a generic way to extend IGMPv3 [RFC3376] and MLDv2 [RFC3810] messages so they can carry info that doesn't fit in the current message formats 🎀 The move is to allow a list of TLVs in the Additional Data section of IGMPv3 and MLDv2 messages. This doc defines a registry for those TLVs, and other docs will define their specific types and their values and semantics 💜 The extension only gets used when at least one TLV needs to be added to the message. It also applies to the lightweight versions of IGMPv3 and MLDv2 defined in [RFC5790] 🦋
When this extension mechanism is used, it replaces the Additional Data section defined in IGMPv3/MLDv2 with TLVs 🍓
Additional Data is defined for Query messages in IGMPv3 (Section 4.1.10 of [RFC3376]) and MLDv2 (Section 5.1.12 of [RFC3810]). It's also defined for Report messages in IGMPv3 (Section 4.2.11 of [RFC3376]) and MLDv2 (Section 5.2.11 of [RFC3810]) 🌸
2. Conventions Used in This Document 📖
Here's the key word situation 🔑 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document get read the way BCP 14 [RFC2119] [RFC8174] describes. That only happens when, and only when, they show up in all capitals, exactly like this 💅
3. Extension Format 🎀
For each of the IGMPv3 and MLDv2 headers, a bit that was previously reserved gets used to signal that this extension is present 🦋 When the extension is used, the Additional Data of IGMPv3 and MLDv2 messages follows the format below. Heads up: this format holds a variable number of TLVs. It MUST contain at least one TLV. 😭
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type 1 | Extension Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Value 1 |
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type 2 | Extension Length 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Value 2 |
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type n | Extension Length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Value n |
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: Extension Format 🌈
Here's what each field does:
Extension Type: 2 octets. This identifies a particular Extension Type as defined in the "IGMP/MLD Extension Types" registry. If this isn't the first TLV, it comes right after the end of the previous one. There's no alignment or padding, so it's all packed in tight 🧚Extension Length: 2 octets. This is the length in octets of theExtension Valuefield that follows. It can be zero if no value is needed 🍓Extension Value: This field holds the value. The spec that defines the Extension Type describes the length and contents of this field 💜
IGMPv3 and MLDv2 messages are defined so they fit within the network MTU, which avoids fragmentation 🦋 An IGMPv3/MLDv2 Report message holds a number of records. They're called Group Records for IGMPv3 and Address Records for MLDv2. When this extension mechanism is used, the number of records in each Report message SHOULD be kept small enough that the entire message, extension TLVs included, can fit within the network MTU 💖
3.1. Multicast Listener Query Extension ✨
The MLDv2 Query message format [RFC3810] with the extension looks like this. The E-bit MUST be set to 1 to show the extension is present. Otherwise, it MUST be 0. 🎀
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 = 130 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Response Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Multicast Address *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Resv|S| QRV | QQIC | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Source Address [1] *
| |
* *
| |
+- -+
| |
* *
| |
* Source Address [2] *
| |
* *
| |
+- . -+
. . .
. . .
+- -+
| |
* *
| |
* Source Address [N] *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: MLD Query Extension 🦋
3.2. Version 2 Multicast Listener Report Extension 💖
okay so the MLDv2 Report message format [RFC3810] gets an extension tacked on, and honestly it's giving main character energy 💅. The E-bit MUST be set to 1 to indicate that the extension is present. Otherwise, it MUST be 0.
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 = 143 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Reserved |Nr of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: MLD Report Extension 🧚
3.3. IGMP Membership Query Extension 🦋
bestie, this one is the IGMPv3 Query message format [RFC3376] with the extension tacked on. Same deal as before: the E-bit MUST be set to 1 to indicate that the extension is present. Otherwise, it MUST be 0.
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 = 0x11 | Max Resp Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Resv|S| QRV | QQIC | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address [1] |
+- -+
| Source Address [2] |
+- . -+
. . .
. . .
+- -+
| Source Address [N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: IGMP Query Extension 🌈
3.4. IGMP Version 3 Membership Report Extension 🌸
the IGMPv3 Report message format [RFC3376] with the extension is up next 💅. The E-bit MUST be set to 1 to indicate that the extension is present. Otherwise, it MUST be 0.
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 = 0x22 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Reserved | Number of Group Records (M) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: IGMP Report Extension ✨
4. No-op TLV 🫶
the No-op TLV is a No-Operation TLV that MUST be ignored during processing 🙈. It's handy for checking that the extension mechanism has been implemented correctly. Also, there's no alignment requirement, so you don't need this Extension Type just to get things aligned.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No-op Type = 0 | No-op Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: No-op TLV Format 🧚
- No-op Type: 2 octets. The type of the No-op TLV extension is
0. - Extension Length: 2 octets. This tells you the length in octets of the Value field that follows. The length may be zero if no value is needed.
- Value: This field holds the value. Since this Extension Type is always ignored, the value can be arbitrary data. The number of octets used MUST match the specified length.
5. Processing the Extension 💜
the procedure in this document only applies when the E-bit is set 🎀.
If validation of the TLVs fails, the entire Additional Data field MUST be ignored, as specified in IGMPv3 [RFC3376] and MLDv2 [RFC3810] 😭. The following checks must pass for TLV validation not to fail:
- At least one TLV MUST be present.
- There MUST NOT be any data in the IP payload after the last TLV. To check this, the parser walks through each of the TLVs until fewer than four octets are left in the IP payload. If any octets are left, validation fails.
- The total length of the Extension MUST NOT exceed the remainder of the IP payload length. For this check, only the content of the Extension Length fields is examined.
Future documents defining a new Extension Type MUST specify any additional processing and validation. These rules, if any, are only examined after the general validation succeeds 👑.
TLVs with unsupported Extension Types MUST be ignored.
6. Applicability and Backwards Compatibility 🌈
IGMP and MLD implementations, especially the ones on hosts, rarely change 🙈. Adoption of this extension mechanism is expected to be slow. As new extension TLVs get defined, it may take a long time before they're supported. So defining new extension TLVs should not be taken lightly, and it is crucial to consider backwards compatibility 💀.
Implementations that don't support this extension mechanism will ignore it, as specified in [RFC3376] and [RFC3810]. As mentioned in the previous section, unsupported extension TLVs are ignored 🍓.
A new extension TLV might only apply to queries, or only to reports, or it might have other specific conditions for when it's used. A document defining a new Extension Type MUST specify the conditions under which the new Extension Type should be used, including which message types. It MUST also be specified what the behavior should be if a message is not used in the defined manner, e.g., if it is present in a Query message when it was only expected in reports 🫶.
When defining new Extension Types, the effect of partial support for the new TLV, by either hosts or routers on the same link, should be carefully considered 🔥. It's also worth considering whether there are any dependencies or restrictions on combinations between the new Extension Types and any preexisting Extension Types.
This document only defines an extension mechanism for IGMPv3 and MLDv2. So this mechanism does not apply if hosts or routers send older version messages 🦋.
7. Security Considerations 💀
The Security Considerations of [RFC3376] and [RFC3810] also apply here 🔐.
This document extends the IGMP and MLD message formats, allowing for a variable number of TLVs. Implementations must take care not to exceed the packet boundary when parsing the TLVs, because an attacker could intentionally specify a TLV with a length exceeding the boundary 😱.
An implementation could add a large number of minimal TLVs in a message to increase the cost of processing the message. This would magnify a denial-of-service attack 🚨.
8. IANA Considerations ✨
okay so IANA made a brand new registry called "IGMP/MLD Extension Types" 📋 It lives under the "Internet Group Management Protocol (IGMP) Type Numbers" section, and this doc is listed as the reference. The registration procedure is "IETF Review" [RFC8126]. The registry is shared by IGMP and MLD, so both protocols use the same list 🫶
Extension Types 65534 and 65535 are set aside for "Experimental Use" [RFC8126] 🧪 Experiments should stay in closed environments where they're unlikely to clash with other experiments. See [RFC3692] for the details 💅
IANA filled in the registry with the starting entries shown in Table 1:
+================+==========+==================+===========+
| Extension Type | Length | Name | Reference |
+================+==========+==================+===========+
| 0 | variable | No-op | RFC 9279 |
+----------------+----------+------------------+-----------+
| 1-65533 | | Unassigned | |
+----------------+----------+------------------+-----------+
| 65534-65535 | variable | Reserved for | |
| | | Experimental Use | |
+----------------+----------+------------------+-----------+
Table 1: IGMP/MLD Extension TypesSo basically: type 0 is the No-op one (that's this RFC 🌸), 1 through 65533 are still open, and the last two are for experiments 🧚
9. References 📚
9.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. - [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>. - [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>. - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References
- [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004,
<https://www.rfc-editor.org/info/rfc3692>. - [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, DOI 10.17487/RFC5790, February 2010,
<https://www.rfc-editor.org/info/rfc5790>.
Acknowledgements 💖
Big thank you to Ron Bonica, Ian Duncan, Wesley Eddy, Leonard Giuliano, Jake Holland, Tommy Pauly, Pete Resnick, Alvaro Retana, and Zhaohui Zhang 🫶 They reviewed the document and gave really valuable feedback, and the authors are so grateful ✨
Authors' Addresses 📮
Mahesh Sivakumar
Juniper Networks
64 Butler St
Milpitas, CA 95035
United States of America
Email: sivakumar.mahesh@gmail.comStig Venaas
Cisco Systems, Inc.
Tasman Drive
San Jose, CA 95134
United States of America
Email: stig@cisco.comZheng(Sandy) Zhang
ZTE Corporation
No. 50 Software Ave, Yuhuatai District
Nanjing
210000
China
Email: zhang.zheng@zte.com.cnHitoshi Asaeda
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi, Koganei, Tokyo
184-8795
Japan
Email: asaeda@nict.go.jp📦 where this page comes from
- ietf: rfc9279 2022-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms