rfc9279xml2.original.xml   rfc9279.xml 
<?xml version='1.0'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'> <!DOCTYPE rfc [
<rfc category="std" docName="draft-ietf-pim-igmp-mld-extension-08" <!ENTITY nbsp "&#160;">
ipr="trust200902"> <!ENTITY zwsp "&#8203;">
<?rfc toc="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc compact="yes"?> <!ENTITY wj "&#8288;">
<?rfc subcompact="no"?> ]>
<?rfc symrefs="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="9279" category="std" con
<front> sensus="true" docName="draft-ietf-pim-igmp-mld-extension-08" ipr="trust200902" o
<title abbrev="IGMPv3/MLDv2 message extension"> bsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sor
Internet Group Management Protocol version 3 (IGMPv3) and tRefs="true" symRefs="true" version="3">
Multicast Listener Discovery version 2 (MLDv2) Message Extension
</title>
<author fullname="Mahesh Sivakumar" initials="M." surname="Sivakumar">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>64 Butler St</street>
<city>Milpitas</city>
<code>CA 95035</code>
<country>USA</country>
</postal>
<email>sivakumar.mahesh@gmail.com</email>
</address>
</author>
<author fullname="Stig Venaas" initials="S." surname="Venaas">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Tasman Drive</street>
<city>San Jose</city>
<code>CA 95134</code>
<country>USA</country>
</postal>
<email>stig@cisco.com</email>
</address>
</author>
<author fullname="Zheng(Sandy) Zhang" initials="Z." surname="Zhang">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>No. 50 Software Ave, Yuhuatai District</street>
<city>Nanjing</city>
<region/>
<code>210000</code>
<country>China</country>
</postal>
<email>zhang.zheng@zte.com.cn</email>
</address>
</author>
<author fullname="Hitoshi Asaeda" initials="H." surname="Asaeda">
<organization abbrev="NICT">National Institute of Information and
Communications Technology</organization>
<address>
<postal>
<street>4-2-1 Nukui-Kitamachi</street>
<city>Koganei, Tokyo</city>
<region/>
<code>184-8795</code>
<country>Japan</country>
</postal>
<email>asaeda@nict.go.jp</email>
</address>
</author>
<date/>
<area>Routing</area>
<keyword>Multicast</keyword>
<abstract> <front>
<t>This document specifies a generic mechanism to extend IGMPv3 and <title abbrev="IGMPv3/MLDv2 Message Extension">
MLDv2 by using a list of TLVs (Type, Length and Value). Internet Group Management Protocol Version 3 (IGMPv3) and
</t> Multicast Listener Discovery Version 2 (MLDv2) Message Extension
</abstract> </title>
</front>
<middle> <seriesInfo name="RFC" value="9279"/>
<section title="Introduction"> <author fullname="Mahesh Sivakumar" initials="M." surname="Sivakumar">
<t>This document defines a generic method to extend <organization>Juniper Networks</organization>
IGMPv3 <xref target="RFC3376"/> and MLDv2 <xref target="RFC3810"/> <address>
messages to accommodate information other than <postal>
what is contained in the current message formats. This is done by <street>64 Butler St</street>
allowing a list of TLVs (Type, Length and Value) to be used in the <city>Milpitas</city>
Additional Data section of IGMPv3 and MLDv2 messages. <region>CA</region>
This document defines <code>95035</code>
a registry for such TLVs, while other documents will define the specific <country>United States of America</country>
types and their values, and their semantics. The extension would only be </postal>
used when at least one TLV is to be added to the message. This extension <email>sivakumar.mahesh@gmail.com</email>
also applies to the lightweight versions of IGMPv3 and MLDv2 as defined </address>
in <xref target="RFC5790"/>. </author>
</t> <author fullname="Stig Venaas" initials="S." surname="Venaas">
<t> <organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>United States of America</country>
</postal>
<email>stig@cisco.com</email>
</address>
</author>
<author fullname="Zheng(Sandy) Zhang" initials="Z." surname="Zhang">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>No. 50 Software Ave, Yuhuatai District</street>
<city>Nanjing</city>
<code>210000</code>
<country>China</country>
</postal>
<email>zhang.zheng@zte.com.cn</email>
</address>
</author>
<author fullname="Hitoshi Asaeda" initials="H." surname="Asaeda">
<organization abbrev="NICT">National Institute of Information and
Communications Technology</organization>
<address>
<postal>
<street>4-2-1 Nukui-Kitamachi, Koganei</street>
<region>Tokyo</region>
<code>184-8795</code>
<country>Japan</country>
</postal>
<email>asaeda@nict.go.jp</email>
</address>
</author>
<date month="July" year="2022"/>
<area>Routing</area>
<workgroup>pim</workgroup>
<keyword>Multicast</keyword>
<abstract>
<t>This document specifies a generic mechanism to extend IGMPv3 and Multic
ast Listener Discovery Version 2
(MLDv2) by using a list of TLVs (Type, Length, and Value).
</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>This document defines a generic method to extend IGMPv3 <xref
target="RFC3376" format="default"/> and MLDv2 <xref target="RFC3810"
format="default"/> messages to accommodate information other than what
is contained in the current message formats. This is done by allowing a
list of TLVs to be used in the Additional Data
section of IGMPv3 and MLDv2 messages. This document defines a registry
for such TLVs. Other documents will define their specific types, and
their values and semantics. The extension would only be used when
at least one TLV is to be added to the message. This extension also
applies to the lightweight versions of IGMPv3 and MLDv2 as defined in
<xref target="RFC5790" format="default"/>.
</t>
<t>
When this extension mechanism is used, it replaces the Additional Data When this extension mechanism is used, it replaces the Additional Data
section defined in IGMPv3/MLDv2 with TLVs. section defined in IGMPv3/MLDv2 with TLVs.
</t> </t>
<t> <t>
Additional Data is defined for Query messages in IGMPv3 Additional Data is defined for Query messages in IGMPv3 (<xref target="RFC
<xref target="RFC3376"/> Section 4.1.10 3376" sectionFormat="of" section="4.1.10"/>)
and MLDv2 <xref target="RFC3810"/> Section 5.1.12, and for Report and MLDv2 (<xref target="RFC3810" sectionFormat="of" section="5.1.12"/>),
messages in IGMPv3 <xref target="RFC3376"/> Section 4.2.11 and MLDv2 and for Report
<xref target="RFC3810"/> Section 5.2.11. messages in IGMPv3 (<xref target="RFC3376" sectionFormat="of" section="4.2
</t> .11"/>) and MLDv2 (<xref target="RFC3810" sectionFormat="of" section="5.2.11"/>
</section> ).
</t>
<section title="Conventions used in this document"> </section>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <section numbered="true" toc="default">
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <name>Conventions Used in This Document</name>
"OPTIONAL" in this document are to be interpreted as described in BCP 14 <t>
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
they appear in all capitals, as shown here. IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
</t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
</section> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<section title="Extension Format"> be interpreted as
<t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section numbered="true" toc="default">
<name>Extension Format</name>
<t>
For each of the IGMPv3 and MLDv2 headers, a previously reserved bit For each of the IGMPv3 and MLDv2 headers, a previously reserved bit
is used to indicate the presence of this extension. is used to indicate the presence of this extension.
When this extension is used, When this extension is used,
the Additional Data of IGMPv3 and MLDv2 messages is formatted as the Additional Data of IGMPv3 and MLDv2 messages is formatted as
follows. Note that this format contains a variable number of TLVs. follows. Note that this format contains a variable number of TLVs.
It MUST contain at least one TLV. It <bcp14>MUST</bcp14> contain at least one TLV.
</t> </t>
<figure title="Figure 1: Extension Format"> <figure>
<artwork> <name>Extension Format</name>
<![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 Type 1 | Extension Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Value 1 | | Extension Value 1 |
. . . . . .
. . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type 2 | Extension Length 2 | | Extension Type 2 | Extension Length 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Value 2 | | Extension Value 2 |
. . . . . .
. . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type n | Extension Length n | | Extension Type n | Extension Length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Value n | | Extension Value n |
. . . . . .
. . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork> </figure>
</figure>
<t> <dl newline="false" spacing="normal">
<list style="empty"> <dt>Extension Type:</dt>
<t>Extension Type: 2 octets. This identifies a particular Extension <dd>2 octets. This identifies a particular Extension Type as defined in the "IGM
Type as defined in the IGMP/MLD Extension Type Registry. If this is P/MLD Extension Types" registry. If this is not the first TLV, it will follow im
not the first TLV, it will follow immediately after the mediately after the end of the previous one. There is no alignment or padding.<
end of the previous one. There is no alignment or padding. /dd>
</t> <dt>Extension Length:</dt>
<t>Extension Length: 2 octets. This specifies the length in octets of <dd>2 octets. This specifies the length in octets of the following Extension Val
the following Extension Value field. The length may be zero if no ue field. The length may be zero if no value is needed.</dd>
value is needed. <dt>Extension Value:</dt>
</t> <dd>This field contains the value. The specification defining the Extension Type
<t>Extension Value: This field contains the value. The length and the describes the length and contents of this field. </dd>
contents of this field is according to the specification of the </dl>
Extension Type.
</t> <t>
</list> IGMPv3 and MLDv2 messages are defined so they can fit within the
</t> network MTU in order to avoid fragmentation. An IGMPv3/MLDv2 Report
<t>
IGMPv3 and MLDv2 messages are defined so that they can fit within the
network MTU, in order to avoid fragmentation. An IGMPv3/MLDv2 report
message contains a number of records. The records are called message contains a number of records. The records are called
Group Records for IGMPv3, and Address Records for MLDv2. Group Records for IGMPv3 and Address Records for MLDv2.
When this extension When this extension
mechanism is used, the number of records in each Report message mechanism is used, the number of records in each Report message
SHOULD be kept small enough that the entire message, including any <bcp14>SHOULD</bcp14> be kept small enough so that the entire message, inc
extension TLVs can fit within the network MTU. luding any
</t> extension TLVs, can fit within the network MTU.
<section title="Multicast Listener Query Extension">
<t>The MLDv2 Query Message format <xref target="RFC3810"/> with extension
is shown below. The E-bit MUST be set to 1 to indicate that the extension
is present. Otherwise, it MUST be 0.
</t> </t>
<figure title="Figure 2: MLD Query Extension"> <section numbered="true" toc="default">
<artwork> <name>Multicast Listener Query Extension</name>
<![CDATA[ <t>The MLDv2 Query message format <xref target="RFC3810" format="default
"/> with extension
is shown below. The E-bit <bcp14>MUST</bcp14> be set to 1 to indicate that
the extension
is present. Otherwise, it <bcp14>MUST</bcp14> be 0.
</t>
<figure>
<name>MLD Query Extension</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type = 130 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Response Code | Reserved | | Maximum Response Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
* * * *
| | | |
skipping to change at line 230 skipping to change at line 223
| | | |
* * * *
| | | |
* Source Address [N] * * Source Address [N] *
| | | |
* * * *
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension | | Extension |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwor
]]></artwork> k>
</figure> </figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Version 2 Multicast Listener Report Extension"> <name>Version 2 Multicast Listener Report Extension</name>
<t>The MLDv2 Report Message format <xref target="RFC3810"/> with <t>The MLDv2 Report message format <xref target="RFC3810" format="defaul
extension is shown below. The E-bit MUST be set to 1 to indicate that t"/> with
the extension is present. Otherwise, it MUST be 0. extension is shown below. The E-bit <bcp14>MUST</bcp14> be set to 1 to ind
</t> icate that
the extension is present. Otherwise, it <bcp14>MUST</bcp14> be 0.
<figure title="Figure 3: MLD Report Extension"> </t>
<artwork> <figure>
<![CDATA[ <name>MLD Report Extension</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type = 143 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Reserved |Nr of Mcast Address Records (M)| |E| Reserved |Nr of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Multicast Address Record [1] . . Multicast Address Record [1] .
skipping to change at line 275 skipping to change at line 266
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Multicast Address Record [M] . . Multicast Address Record [M] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension | | Extension |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwor
]]> k>
</artwork> </figure>
</figure> </section>
</section> <section numbered="true" toc="default">
<name>IGMP Membership Query Extension</name>
<section title="IGMP Membership Query Extension"> <t>The IGMPv3 Query message format <xref target="RFC3376" format="defaul
<t>The IGMPv3 Query Message format <xref target="RFC3376"/> with the t"/> with the
extension is shown below. The E-bit MUST be set to 1 to indicate that extension is shown below. The E-bit <bcp14>MUST</bcp14> be set to 1 to ind
the extension is present. Otherwise, it MUST be 0. icate that
</t> the extension is present. Otherwise, it <bcp14>MUST</bcp14> be 0.
<figure title="Figure 4: IGMP Query Extension"> </t>
<artwork> <figure>
<![CDATA[ <name>IGMP Query Extension</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type = 0x11 | Max Resp Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address | | Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Resv|S| QRV | QQIC | Number of Sources (N) | |E| Resv|S| QRV | QQIC | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address [1] | | Source Address [1] |
+- -+ +- -+
| Source Address [2] | | Source Address [2] |
+- . -+ +- . -+
. . . . . .
. . . . . .
+- -+ +- -+
| Source Address [N] | | Source Address [N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension | | Extension |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwor
]]> k>
</artwork> </figure>
</figure> </section>
</section> <section numbered="true" toc="default">
<name>IGMP Version 3 Membership Report Extension</name>
<section title="IGMP Version 3 Membership Report Extension"> <t>The IGMPv3 Report message format <xref target="RFC3376" format="defau
<t>The IGMPv3 Report Message format <xref target="RFC3376"/> with the lt"/> with the
extension is shown below. The E-bit MUST be set to 1 to indicate that extension is shown below. The E-bit <bcp14>MUST</bcp14> be set to 1 to ind
the extension is present. Otherwise, it MUST be 0. icate that
</t> the extension is present. Otherwise, it <bcp14>MUST</bcp14> be 0.
<figure title="Figure 5: IGMP Report Extension"> </t>
<artwork> <figure>
<![CDATA[ <name>IGMP Report Extension</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type = 0x22 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Reserved | Number of Group Records (M) | |E| Reserved | Number of Group Records (M) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Group Record [1] . . Group Record [1] .
skipping to change at line 354 skipping to change at line 341
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Group Record [M] . . Group Record [M] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension | | Extension |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwor
]]> k>
</artwork> </figure>
</figure> </section>
</section> </section>
</section> <section numbered="true" toc="default">
<section title="No-op TLV"> <name>No-op TLV</name>
<t> <t>
The no-op TLV is a No-Operation TLV that MUST be ignored during The No-op TLV is a No-Operation TLV that <bcp14>MUST</bcp14> be ignored du
processing. This TLV may be useful for verifying that implementations ring
correctly implement this extension mechanism. Note that there is processing. This TLV may be used to verify that the extension mechanism ha
s been implemented correctly. Note that there is
no alignment requirement, so there is no need to use this Extension Type no alignment requirement, so there is no need to use this Extension Type
to provide alignment. to provide alignment.
</t> </t>
<figure title="Figure 6: No-op TLV Format"> <figure>
<artwork> <name>No-op TLV Format</name>
<![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | No-op Type = 0 | No-op Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
. . . . . .
. . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwor
]]></artwork> k>
</figure> </figure>
<t>
<list style="empty">
<t>No-op Type: 2 octets. The type of the No-op TLV extension is the
value 0.
</t>
<t>Extension Length: 2 octets. This specifies the length in octets of
the following Value field. The length may be zero if no
value is needed.
</t>
<t>Value: This field contains the value. As this Extension Type is
always ignored, the value can be arbitrary data. The number of octets
used MUST match the specified length.
contents of this field is according to the specification of the
Extension Type.
</t>
</list>
</t>
</section>
<section title="Processing the extension"> <dl newline="false" spacing="normal">
<t> <dt>No-op Type:</dt> <dd>2 octets. The type of the No-op TLV extension is 0.</dd
The procedure specified in this document applies only when the E-bit >
<dt>Extension Length:</dt>
<dd>2 octets. This specifies the length in
octets of the following Value field. The length may be zero if no value is need
ed.</dd>
<dt> Value:</dt>
<dd>This field contains the value. As this Extension Type is always ignored, the
value can be arbitrary data. The number of octets used <bcp14>MUST</bcp14> matc
h the specified length. </dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>Processing the Extension</name>
<t>
The procedure specified in this document only applies when the E-bit
is set. is set.
</t> </t>
<t> <t>
If the validation of the TLVs fails, the entire Additional Data field If the validation of the TLVs fails, the entire Additional Data field
MUST be ignored as specified in IGMPv3 [RFC3376] and MLDv2 [RFC3810]. <bcp14>MUST</bcp14> be ignored as specified in IGMPv3 <xref target="RFC337 6"/> and MLDv2 <xref target="RFC3810"/>.
The following checks must pass for the validation of the TLVs not to The following checks must pass for the validation of the TLVs not to
fail: fail:
<list style="empty"> </t>
<t> <ul empty="false" spacing="normal">
At least one TLV MUST be present.</t> <li>
<t> At least one TLV <bcp14>MUST</bcp14> be present.</li>
There MUST NOT be any data in the IP payload after the last TLV. <li>
There <bcp14>MUST NOT</bcp14> be any data in the IP payload after the las
t TLV.
To check this, the parser needs to walk through each of the TLVs until To check this, the parser needs to walk through each of the TLVs until
there are less than four octets left in the IP payload. If there are there are less than four octets left in the IP payload. If there are
any octets left, validation fails. any octets left, validation fails.
</t> </li>
<t> <li>
The total length of the Extension MUST NOT exceed the remainder of The total length of the Extension <bcp14>MUST NOT</bcp14> exceed the rema
the IP payload length. For this validation, one only examines the inder of
content of the Extension Length fields. the IP payload length. For this validation, only the
</t> content of the Extension Length fields is examined.
</list> </li>
</t> </ul>
<t> <t>
Future documents defining a new Extension Type MUST specify any Future documents defining a new Extension Type <bcp14>MUST</bcp14> specify
any
additional processing and validation. These rules, if any, will additional processing and validation. These rules, if any, will
be examined only after the general validation (above) succeeds. be examined only after the general validation succeeds.
</t> </t>
<t> <t>
TLVs with unsupported Extension Types MUST be ignored. TLVs with unsupported Extension Types <bcp14>MUST</bcp14> be ignored.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Applicability and backwards compatibility"> <name>Applicability and Backwards Compatibility</name>
<t>IGMP and MLD implementations, particularly implementations on hosts, <t>IGMP and MLD implementations, particularly implementations on hosts,
rarely change, and the adoption process of this extension mechanism is rarely change. The adoption process of this extension mechanism is
expected to be slow. expected to be slow. As new extension TLVs are defined, it may
Also, as new extension TLVs are defined, it may take a long time for them to be supported. Due to this, defining
take a long time before they are supported. Due to this, defining
new extension TLVs should not be taken lightly, and it is crucial new extension TLVs should not be taken lightly, and it is crucial
to consider backwards compatibility.</t> to consider backwards compatibility.</t>
<t>Implementations that do not support this extension mechanism will <t>Implementations that do not support this extension mechanism will
ignore it, as specified in [RFC3376] and [RFC3810]. Also, as mentioned ignore it, as specified in <xref target="RFC3376"/> and <xref target="RFC381
0"/>. As mentioned
in the previous section, unsupported extension TLVs are ignored. in the previous section, unsupported extension TLVs are ignored.
</t> </t>
<t>It is possible that a new extension TLV only applies to queries, or <t>It is possible that a new extension TLV will only apply to queries or
only to reports, or there may be other specific conditions for when it is to only to reports, or that there may be other specific conditions for when it
be used. A document defining a new Extension Type MUST specify under what is to
conditions the new Extension Type should be used, including for which be used. A document defining a new Extension Type <bcp14>MUST</bcp14> specif
y the
conditions under which the new Extension Type should be used, including whic
h
message types. message types.
It MUST also be specified what the behavior should be if a message is not It <bcp14>MUST</bcp14> also be specified what the behavior should be if a me
used in the defined manner, e.g., if it is present in a query message, ssage is not
used in the defined manner, e.g., if it is present in a Query message,
when it was only expected to be used in reports. when it was only expected to be used in reports.
</t> </t>
<t>When defining new Extension Types, care should be taken to consider the <t>When defining new Extension Types, the effect of partial support for th
effect of partial support for the new TLV, by either the hosts or routers, e new TLV, by either the hosts or routers, on the same link should be carefully
on the same link. Further, it must be considered whether there are any considered. Further, whether there are any
dependencies or restrictions on combinations between the new Extension dependencies or restrictions on combinations between the new Extension
Types and any pre-existing Extension Types. Types and any preexisting Extension Types must be considered.
</t> </t>
<t>This document defines an extension mechanism only for IGMPv3 and MLDv2.
<t>This document defines an extension mechanism only for IGMPv3 and MLDv2.
Hence, this mechanism does not apply if hosts or routers send older version Hence, this mechanism does not apply if hosts or routers send older version
messages.</t> messages.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t>The Security Considerations of [RFC3376] and [RFC3810] also apply here. <t>The Security Considerations of <xref target="RFC3376"/> and <xref targe
</t> t="RFC3810"/> also apply here.
<t>This document extends the IGMP and MLD message formats, allowing for a </t>
variable number of TLVs. Implementations must take care when parsing <t>This document extends the IGMP and MLD message formats, allowing for a
the TLVs to not exceed the packet boundary, an attacker could variable number of TLVs. Implementations must take care not to exceed the pa
cket boundary when parsing
the TLVs, because an attacker could
intentionally specify a TLV with a length exceeding the boundary. intentionally specify a TLV with a length exceeding the boundary.
</t> </t>
<t>An implementation could add a large number of minimal TLVs in a <t>An implementation could add a large number of minimal TLVs in a
message to increase the cost of processing the message to magnify message to increase the cost of processing the message. This would magnify
a Denial of Service attack. a denial-of-service attack.
</t> </t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>IANA is asked to create a new registry called "IGMP/MLD Extension Types" <t>IANA has created a new registry called "IGMP/MLD Extension Types"
in the "Internet Group Management Protocol (IGMP) Type Numbers" section, in the "Internet Group Management Protocol (IGMP) Type Numbers" section and
with registration procedure "IETF Review" <xref target="RFC8126"/>, and lists this document as the reference.
with this document as a reference. The registry is common for IGMP and MLD. The registration procedure is "IETF Review" <xref target="RFC8126" format="d
</t><t> efault"/>.
Two Extension Types are provided for "Experimental Use" The registry is common for IGMP and MLD.
<xref target="RFC8126"/>. Any experiments should be confined to closed </t>
<t>
Two Extension Types (65534 and 65535) are provided for "Experimental Use"
<xref target="RFC8126" format="default"/>. Any experiments should be confine
d to closed
environments where it is unlikely that they may conflict with other environments where it is unlikely that they may conflict with other
experiments, see <xref target="RFC3692"/>. experiments; see <xref target="RFC3692" format="default"/>.
</t><t> </t>
The initial content of the registry should be as below.</t> <t>
<t><figure> IANA has initially populated the registry as shown in <xref target="extensio
<artwork><![CDATA[ n_type_table"/></t>
Extension Type Length Name Reference
0 variable No-op [this document]
1-65533 Unassigned
65534 variable Experimental use
65535 variable Experimental use
]]></artwork>
</figure></t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>The authors thank Ron Bonica, Ian Duncan, Wesley Eddy, Leonard Giuliano,
Jake Holland, Tommy Pauly, Pete Resnick,
Alvaro Retana and Zhaohui Zhang for reviewing the document
and providing valuable feedback.
</t>
</section>
</middle>
<back>
<references title="Normative References"> <table anchor="extension_type_table">
<?rfc include='reference.RFC.2119'?> <name>IGMP/MLD Extension Types</name>
<?rfc include='reference.RFC.3376'?> <thead>
<?rfc include='reference.RFC.3810'?> <tr>
<?rfc include='reference.RFC.8126'?> <th>Extension Type</th>
<?rfc include='reference.RFC.8174'?> <th>Length</th>
</references> <th>Name</th>
<references title="Informative References"> <th>Reference</th>
<?rfc include='reference.RFC.3692'?> </tr>
<?rfc include='reference.RFC.5790'?> </thead>
</references> <tbody>
<tr>
<td>0</td>
<td>variable</td>
<td>No-op</td>
<td>RFC 9279</td>
</tr>
<tr>
<td>1-65533</td>
<td></td>
<td>Unassigned</td>
<td></td>
</tr>
<tr>
<td>65534-65535</td>
<td>variable</td>
<td>Reserved for Experimental Use</td>
<td></td>
</tr>
</tbody>
</table>
</section>
</back> </middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3376.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3810.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3692.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5790.xml"/>
</references>
</references>
<section anchor="ack" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors thank <contact fullname="Ron Bonica"/>, <contact fullname="
Ian Duncan"/>, <contact fullname="Wesley Eddy"/>, <contact fullname="Leonard Giu
liano"/>, <contact fullname="Jake Holland"/>, <contact fullname="Tommy Pauly"/>,
<contact fullname="Pete Resnick"/>, <contact fullname="Alvaro Retana"/>, and <c
ontact fullname="Zhaohui Zhang"/>
for reviewing the document and providing valuable feedback.
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 31 change blocks. 
356 lines changed or deleted 420 lines changed or added

This html diff was produced by rfcdiff 1.48.