<?xml version='1.0'?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="9279" category="std" consensus="true" docName="draft-ietf-pim-igmp-mld-extension-08"
     ipr="trust200902">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?> ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

<front>
    <title abbrev="IGMPv3/MLDv2 message extension"> Message Extension">
    Internet Group Management Protocol version Version 3 (IGMPv3) and
    Multicast Listener Discovery version Version 2 (MLDv2) Message Extension
    </title>

    <seriesInfo name="RFC" value="9279"/>
    <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>
	  <region>CA</region>
          <code>95035</code>
          <country>United States of America</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>
	  <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>
        <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/> Nukui-Kitamachi, Koganei</street>
          <region>Tokyo</region>
          <code>184-8795</code>
          <country>Japan</country>
        </postal>
        <email>asaeda@nict.go.jp</email>
      </address>
    </author>
  <date/>
    <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
    MLDv2 Multicast Listener Discovery Version 2
(MLDv2) by using a list of TLVs (Type, Length Length, and Value).
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document defines a generic method to extend IGMPv3 <xref target="RFC3376"/>
      target="RFC3376" format="default"/> and MLDv2 <xref target="RFC3810"/> 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 (Type, Length and Value) to be used in the Additional Data
      section of IGMPv3 and MLDv2 messages.  This document defines a registry
      for such TLVs, while other TLVs.  Other documents will define the their specific
      types types, and
      their values, values and their 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"/>. target="RFC5790" format="default"/>.
      </t>
      <t>
      When this extension mechanism is used, it replaces the Additional Data
      section defined in IGMPv3/MLDv2 with TLVs.
      </t>
      <t>
      Additional Data is defined for Query messages in IGMPv3
      <xref target="RFC3376"/> Section 4.1.10 (<xref target="RFC3376" sectionFormat="of" section="4.1.10"/>)
      and MLDv2 <xref target="RFC3810"/> Section 5.1.12, (<xref target="RFC3810" sectionFormat="of" section="5.1.12"/>), and for Report
      messages in IGMPv3 <xref target="RFC3376"/> Section 4.2.11 (<xref target="RFC3376" sectionFormat="of" section="4.2.11"/>) and  MLDv2
      <xref target="RFC3810"/> Section 5.2.11. (<xref target="RFC3810" sectionFormat="of" section="5.2.11"/>).
      </t>
    </section>
    <section title="Conventions used numbered="true" toc="default">
      <name>Conventions Used in this document">
    <t>The This Document</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
    </section>
    <section title="Extension Format"> numbered="true" toc="default">
      <name>Extension Format</name>
 <t>
      For each of the IGMPv3 and MLDv2 headers, a previously reserved bit
      is used to indicate the presence of this extension.
      When this extension is used,
      the Additional Data of IGMPv3 and MLDv2 messages is formatted as
      follows. Note that this format contains a variable number of TLVs.
      It MUST <bcp14>MUST</bcp14> contain at least one TLV.
      </t>
    <figure title="Figure 1: Extension Format">
      <artwork>
        <![CDATA[
      <figure>
        <name>Extension Format</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 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                       |
.                               .                               .
.                               .                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>
    <t>
      <list style="empty">
        <t>Extension Type: 2

<dl newline="false" spacing="normal">
<dt>Extension Type:</dt>
<dd>2 octets. This identifies a particular Extension Type as defined in the IGMP/MLD "IGMP/MLD Extension Type Registry. Types" registry. If this is not the first TLV, it will follow immediately after the end of the previous one.  There is no alignment or padding.
        </t>
        <t>Extension Length: 2 padding.</dd>
<dt>Extension Length:</dt>
<dd>2 octets. This specifies the length in octets of the following Extension Value field. The length may be zero if no value is needed.
        </t>
        <t>Extension Value: This needed.</dd>
<dt>Extension Value:</dt>
<dd>This field contains the value. The specification defining the Extension Type describes the length and the contents of this field is according to the specification of the
	Extension Type.
        </t>
      </list>
    </t> field. </dd>
</dl>

      <t>
      IGMPv3 and MLDv2 messages are defined so that they can fit within the
      network MTU, MTU in order to avoid fragmentation. An IGMPv3/MLDv2 report Report
      message contains a number of records. The records are called
      Group Records for IGMPv3, IGMPv3 and Address Records for MLDv2.
      When this extension
      mechanism is used, the number of records in each Report message
      SHOULD
      <bcp14>SHOULD</bcp14> be kept small enough so that the entire message, including any
      extension TLVs TLVs, can fit within the network MTU.
      </t>
      <section title="Multicast numbered="true" toc="default">
        <name>Multicast Listener Query Extension"> Extension</name>
        <t>The MLDv2 Query Message message format <xref target="RFC3810"/> target="RFC3810" format="default"/> with extension
      is shown below. The E-bit MUST <bcp14>MUST</bcp14> be set to 1 to indicate that the extension
      is present. Otherwise, it MUST <bcp14>MUST</bcp14> be 0.
        </t>
      <figure title="Figure 2: MLD
        <figure>
          <name>MLD Query Extension">
        <artwork>
        <![CDATA[ Extension</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
     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                          |
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ]]></artwork>
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>
      </section>
      <section title="Version numbered="true" toc="default">
        <name>Version 2 Multicast Listener Report Extension"> Extension</name>
        <t>The MLDv2 Report Message message format <xref target="RFC3810"/> target="RFC3810" format="default"/> with
      extension is shown below. The E-bit MUST <bcp14>MUST</bcp14> be set to 1 to indicate that
      the extension is present. Otherwise, it MUST <bcp14>MUST</bcp14> be 0.
        </t>

      <figure title="Figure 3: MLD
        <figure>
          <name>MLD Report Extension">
        <artwork>
        <![CDATA[ Extension</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
     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                          |
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ]]>
        </artwork>
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>
      </section>
      <section title="IGMP numbered="true" toc="default">
        <name>IGMP Membership Query Extension"> Extension</name>
        <t>The IGMPv3 Query Message message format <xref target="RFC3376"/> target="RFC3376" format="default"/> with the
      extension is shown below. The E-bit MUST <bcp14>MUST</bcp14> be set to 1 to indicate that
      the extension is present. Otherwise, it MUST <bcp14>MUST</bcp14> be 0.
        </t>
      <figure title="Figure 4: IGMP
        <figure>
          <name>IGMP Query Extension">
        <artwork>
        <![CDATA[ Extension</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
     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                          |
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ]]>
        </artwork>
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>
      </section>
      <section title="IGMP numbered="true" toc="default">
        <name>IGMP Version 3 Membership Report Extension"> Extension</name>
        <t>The IGMPv3 Report Message message format <xref target="RFC3376"/> target="RFC3376" format="default"/> with the
      extension is shown below. The E-bit MUST <bcp14>MUST</bcp14> be set to 1 to indicate that
      the extension is present. Otherwise, it MUST <bcp14>MUST</bcp14> be 0.
        </t>
      <figure title="Figure 5: IGMP
        <figure>
          <name>IGMP Report Extension">
        <artwork>
        <![CDATA[ Extension</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
     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                          |
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ]]>
        </artwork>
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>
      </section>
    </section>
    <section title="No-op TLV"> numbered="true" toc="default">
      <name>No-op TLV</name>
      <t>
      The no-op No-op TLV is a No-Operation TLV that MUST <bcp14>MUST</bcp14> be ignored during
      processing. This TLV may be useful for verifying used to verify that implementations
      correctly implement this the extension mechanism. mechanism has been implemented correctly. Note that there is
      no alignment requirement, so there is no need to use this Extension Type
      to provide alignment.
      </t>
    <figure title="Figure 6: No-op
      <figure>
        <name>No-op TLV Format">
      <artwork>
        <![CDATA[ Format</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
     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                             |
    .                               .                               .
    .                               .                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ]]></artwork>
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>
    <t>
      <list style="empty">
        <t>No-op Type: 2

<dl newline="false" spacing="normal">
<dt>No-op Type:</dt> <dd>2 octets. The type of the No-op TLV extension is the
	value 0.
        </t>
        <t>Extension Length: 2 0.</dd>
<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 needed.
        </t>
        <t>Value: This needed.</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 MUST <bcp14>MUST</bcp14> match the specified length.
        contents of this field is according to the specification of the
	Extension Type.
        </t>
      </list>
    </t> </dd>
</dl>

    </section>
    <section title="Processing numbered="true" toc="default">
      <name>Processing the extension"> Extension</name>
      <t>
      The procedure specified in this document applies only applies when the E-bit
      is set.
      </t>
      <t>
      If the validation of the TLVs fails, the entire Additional Data field
      MUST
      <bcp14>MUST</bcp14> be ignored as specified in IGMPv3 [RFC3376] <xref target="RFC3376"/> and MLDv2 [RFC3810]. <xref target="RFC3810"/>.
      The following checks must pass for the validation of the TLVs not to
      fail:
      <list style="empty">
	<t>
      </t>
      <ul empty="false" spacing="normal">
        <li>
        At least one TLV MUST <bcp14>MUST</bcp14> be present.</t>
	<t> present.</li>
        <li>
	There MUST NOT <bcp14>MUST NOT</bcp14> be any data in the IP payload after the last TLV.
	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
	any octets left, validation fails.
	</t>
	<t>
	</li>
        <li>
	The total length of the Extension MUST NOT <bcp14>MUST NOT</bcp14> exceed the remainder of
	the IP payload length.  For this validation, one only examines the
	content of the Extension Length fields.
	</t>
      </list>
    </t> fields is examined.
	</li>
      </ul>
      <t>
      Future documents defining a new Extension Type MUST <bcp14>MUST</bcp14> specify any
      additional processing and validation.  These rules, if any, will
      be examined only after the general validation (above) succeeds.
      </t>
      <t>
      TLVs with unsupported Extension Types MUST <bcp14>MUST</bcp14> be ignored.
      </t>
    </section>
    <section title="Applicability numbered="true" toc="default">
      <name>Applicability and backwards compatibility"> Backwards Compatibility</name>
      <t>IGMP and MLD implementations, particularly implementations on hosts,
    rarely change, and the change. The adoption process of this extension mechanism is
    expected to be slow.
    Also, as As new extension TLVs are defined, it may
    take a long time before they are for them to be supported. Due to this, defining
    new extension TLVs should not be taken lightly, and it is crucial
    to consider backwards compatibility.</t>
      <t>Implementations that do not support this extension mechanism will
    ignore it, as specified in [RFC3376] <xref target="RFC3376"/> and [RFC3810]. Also, as <xref target="RFC3810"/>. As mentioned
    in the previous section, unsupported extension TLVs are ignored.
      </t>
      <t>It is possible that a new extension TLV will only applies apply to queries, queries or
    only to reports, or that there may be other specific conditions for when it is to
    be used. A document defining a new Extension Type MUST <bcp14>MUST</bcp14> specify under what the
    conditions under which the new Extension Type should be used, including for which
    message types.
    It MUST <bcp14>MUST</bcp14> 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 Query message,
    when it was only expected to be used in reports.
      </t>
      <t>When defining new Extension Types, care should be taken to consider the effect of partial support for the new TLV, by either the hosts or routers, on the same link. Further, it must link should be considered carefully considered. Further, whether there are any
    dependencies or restrictions on combinations between the new Extension
    Types and any pre-existing preexisting Extension Types. Types must be considered.
      </t>

      <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
    messages.</t>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The Security Considerations of [RFC3376] <xref target="RFC3376"/> and [RFC3810] <xref target="RFC3810"/> also apply here.
      </t>
      <t>This document extends the IGMP and MLD message formats, allowing for a
    variable number of TLVs. Implementations must take care when parsing
    the TLVs to not to exceed the packet boundary, boundary when parsing
    the TLVs, because an attacker could
    intentionally specify a TLV with a length exceeding the boundary.
      </t>
      <t>An implementation could add a large number of minimal TLVs in a
    message to increase the cost of processing the message to message. This would magnify
    a Denial of Service denial-of-service attack.
      </t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is asked to create has created a new registry called "IGMP/MLD Extension Types"
    in the "Internet Group Management Protocol (IGMP) Type Numbers" section,
    with registration procedure "IETF Review" <xref target="RFC8126"/>, section and
    with lists this document as a the reference.
    The registration procedure is "IETF Review" <xref target="RFC8126" format="default"/>.
    The registry is common for IGMP and MLD.
    </t><t>
      </t>
      <t>
    Two Extension Types (65534 and 65535) are provided for "Experimental Use"
    <xref target="RFC8126"/>. target="RFC8126" format="default"/>. Any experiments should be confined to closed
    environments where it is unlikely that they may conflict with other
    experiments,
    experiments; see <xref target="RFC3692"/>.
    </t><t>
    The initial content of target="RFC3692" format="default"/>.
      </t>
      <t>
    IANA has initially populated the registry should be as below.</t>
      <t><figure>
          <artwork><![CDATA[
Extension Type    Length    Name                        Reference
--------------------------------------------------------------
      0           variable  No-op                       [this document]
1-65533                     Unassigned
  65534           variable  Experimental use
  65535           variable shown in <xref target="extension_type_table"/></t>

<table anchor="extension_type_table">
  <name>IGMP/MLD Extension Types</name>
  <thead>
    <tr>
      <th>Extension Type</th>
      <th>Length</th>
      <th>Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <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
        ]]></artwork>
        </figure></t> Use</td>
      <td></td>
    </tr>
  </tbody>
</table>
    </section>

    </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3376.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3692.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5790.xml"/>
      </references>
    </references>
 <section anchor="ack" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors thank Ron Bonica, Ian Duncan, Wesley Eddy, Leonard Giuliano,
    Jake Holland, Tommy Pauly, Pete Resnick,
    Alvaro Retana and Zhaohui Zhang <contact fullname="Ron Bonica"/>, <contact fullname="Ian Duncan"/>, <contact fullname="Wesley Eddy"/>, <contact fullname="Leonard Giuliano"/>, <contact fullname="Jake Holland"/>, <contact fullname="Tommy Pauly"/>, <contact fullname="Pete Resnick"/>, <contact fullname="Alvaro Retana"/>, and <contact fullname="Zhaohui Zhang"/>
for reviewing the document and providing valuable feedback.
      </t>
    </section>

</middle>
<back>

  <references title="Normative References">
    <?rfc include='reference.RFC.2119'?>
    <?rfc include='reference.RFC.3376'?>
    <?rfc include='reference.RFC.3810'?>
    <?rfc include='reference.RFC.8126'?>
    <?rfc include='reference.RFC.8174'?>
  </references>
  <references title="Informative References">
    <?rfc include='reference.RFC.3692'?>
    <?rfc include='reference.RFC.5790'?>
  </references>
  </back>
</rfc>