<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="bcp" docName="draft-ietf-pim-3228bis-07" number="9778" consensus="true" ipr="pre5378trust200902" obsoletes="3228"> obsoletes="3228" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <front>

<title abbrev="IGMP IANA">IANA abbrev="IANA Considerations for IGMP">IANA Considerations for Internet Group Management Protocols</title>

    <seriesInfo name="RFC" value="9778"/>
    <seriesInfo name="BCP" value="57" />

    <author fullname="Brian Haberman" initials="B." surname="Haberman" role="editor">
      <organization abbrev="JHU APL">Johns Hopkins University Applied Physics Lab</organization>
      <address>
        <email>brian@innovationslab.net</email>
      </address>
    </author>
    <date year="2025" month="March"/>

    <area>RTG</area>
    <workgroup>pim</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

    <abstract>
      <t>This document specifies revised IANA Considerations considerations for the Internet Group Management
   Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. This document specifies the
   guidance provided to IANA to manage values associated with various fields within the
   protocol headers of the group management protocols.</t>
      <t>This document obsoletes RFC 3228 and unifies guidelines for IPv4 and IPv6 group management protocols.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The following sections that follow describe the allocation guidelines associated with
   the specified fields within the Internet Group Management Protocol (IGMP) <xref target="I-D.ietf-pim-3376bis"/> target="RFC9776" format="default"/>
   and the Multicast Listener Discovery (MLD) <xref target="I-D.ietf-pim-3810bis"/> target="RFC9777" format="default"/> headers. Some of these registries
   were created previously, while others are created by this document.</t>
      <t>This document obsoletes <xref target="RFC3228"/> target="RFC3228" format="default"/> and unifies guidelines for IPv4 and IPv6 group
   management protocols.</t>
      <section title="Conventions numbered="true" toc="default">
        <name>Conventions Used in This Document">
   <t>The 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> here.
        </t>

      </section>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>The registration procedures used in this document are defined in <xref target="RFC8126"/>.</t> target="RFC8126" format="default"/>.</t>
      <section title="Type numbered="true" toc="default">
        <name>Type and Code Fields"> Fields</name>
        <section title="Internet numbered="true" toc="default">
          <name>Internet Group Management Protocol"> Protocol</name>
          <t> The IGMP header contains the following fields that carry values assigned from IANA-managed name
	   spaces: Type and Code.  Code field values are defined relative to a specific Type value.</t>
          <t><xref target="RFC3228"/> target="RFC3228" format="default"/> created an IANA the "IGMP Type Numbers" registry for the IGMP Type field. This document updates that
   registry in two ways:
   <list style="hanging">
	   <t>The
          </t>
          <ul spacing="normal">
            <li>The registration procedure is has been changed to Standards Action.</t>
	   <t>The Action.</li>
            <li>The references to <xref target="RFC3228"/>, including the reference for the registry is registry, have been changed to this document.</t>
   </list></t> document.</li>
          </ul>
          <t><xref target="RFC3228"/> target="RFC3228" format="default"/> created an IANA the '"Code" Fields' registry for Code values for existing IGMP Type fields.
   The This document updates that registry in two ways:</t>
 <ul spacing="normal">
            <li>The registration procedure has been changed to Standards Action.</li>
            <li>The reference for the existing registries is registry has been changed to Standards Action. The this document.</li>
          </ul>
<t>
	 Note that the policy for assigning Code values for new IGMP Types MUST <bcp14>MUST</bcp14> be defined in the document defining the new Type value.</t>
        </section>
        <section title="Multicast numbered="true" toc="default">
          <name>Multicast Listener Discovery"> Discovery</name>

          <t>As with IGMP, the MLD header also contains Type and Code fields. Assignment of those fields within the MLD header is defined in <xref target="RFC4443"/> target="RFC4443" format="default"/> with a registration policy of IETF Review.</t> Review; see &lt;<eref target="https://www.iana.org/assignments/icmpv6-parameters"/>&gt;.</t>
        </section>
      </section>
      <section title="IGMP/MLD numbered="true" toc="default">
        <name>IGMP/MLD Query Message Flags">

   <t>The IANA is requested to create a single Flags</name>
        <t>IANA has created the "IGMP/MLD Query Message Flags" registry for the bits in the Flags
   field of the MLDv2 Query Message <xref target="I-D.ietf-pim-3810bis"/> target="RFC9777" format="default"/>
   and the IGMPv3 Query Message <xref target="I-D.ietf-pim-3376bis"/>. The format for the registry is:</t>

   <figure>
      <artwork><![CDATA[
   +-----------+------------+-------------+-----------+
   | target="RFC9776" format="default"/>.  It has been populated as follows: </t>

  <table align="left">
  <name>IGMP/MLD Query Message Flags Bit | Short Name | Description | Reference |
   +-----------+------------+-------------+-----------+
   | 0         |     E      | Extension   | RFC 9279  |
   | 1         |            |             |           |
   | 2         |            |             |           |
   | 3         |            |             |           |
   +-----------+------------+-------------+-----------+
      ]]></artwork>
   </figure> Registry</name>
  <thead>
    <tr>
      <th>Flags Bit</th>
      <th>Short Name</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>E</td>
      <td>Extension</td>
      <td><xref target="RFC9279" format="default"/></td>
    </tr>
    <tr>
      <td>1-3</td>
      <td colspan="3">Unassigned</td>
    </tr>
  </tbody>
</table>

        <t>The Flags Bit value in the registry above corresponds to the column header in the packet format diagrams
   in Sections <xref target="I-D.ietf-pim-3810bis"/> target="RFC9776" sectionFormat="bare" section="4.1"/> and <xref target="I-D.ietf-pim-3376bis"/>.</t>

   <t>The initial contents target="RFC9776" sectionFormat="bare" section="4.2"/> of this requested registry should contain the E-bit defined in <xref target="RFC9279" />.</t> target="RFC9776" format="default"/> and Sections <xref target="RFC9777" sectionFormat="bare" section="5.1"/> and <xref target="RFC9777" sectionFormat="bare" section="5.2"/> of <xref target="RFC9777" format="default"/>.</t>
        <t>The assignment of new bit flags within the Flags field
   requires Standards Action.</t>
      </section>
      <section title="IGMP/MLD numbered="true" toc="default">
        <name>IGMP/MLD Report Message Flags">
   <t>The IANA is requested to create a single Flags</name>
        <t>IANA has created the "IGMP/MLD Report Message Flags" registry for the bits in the Flags
   field of the MLDv2 Report Message and the IGMPv3 Report Message. The format for the registry is:</t>

   <figure>
      <artwork><![CDATA[
   +-----------+------------+-------------+-----------+
   | It has been populated as follows:</t>

   <table align="left">
     <name>IGMP/MLD Report Message Flags Bit | Short Name | Description | Reference |
   +-----------+------------+-------------+-----------+
   | 0         |     E      | Extension   | RFC 9279  |
   | 1         |            |             |           |
   | 2         |            |             |           |
   | 3         |            |             |           |
   | 4         |            |             |           |
   | 5         |            |             |           |
   | 6         |            |             |           |
   | 7         |            |             |           |
   | 8         |            |             |           |
   | 9         |            |             |           |
   | 10        |            |             |           |
   | 11        |            |             |           |
   | 12        |            |             |           |
   | 13        |            |             |           |
   | 14        |            |             |           |
   | 15        |            |             |           |
   +-----------+------------+-------------+-----------+
      ]]></artwork>
   </figure> Registry</name>
  <thead>
    <tr>
      <th>Flags Bit</th>
      <th>Short Name</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>E</td>
      <td>Extension</td>
      <td><xref target="RFC9279" format="default"/></td>
    </tr>
    <tr>
      <td>1-15</td>
      <td colspan="3">Unassigned</td>
    </tr>
  </tbody>
   </table>

        <t>The Flags Bit value in the registry above corresponds to the column header in the packet format diagrams in <xref target="I-D.ietf-pim-3810bis"/> target="RFC9777" format="default"/> and <xref target="I-D.ietf-pim-3376bis"/>.</t>

   <t>The initial contents of this requested registry should contain the E-bit defined in <xref target="RFC9279" />.</t> target="RFC9776" format="default"/>.</t>

        <t>The assignment of new bit flags within the Flags field
   require
   requires Standards Action.</t>
      </section>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Security analyzers such as firewalls and network intrusion detection
   monitors often rely on unambiguous interpretations of the fields
   described in this memo.  As new values for the fields are assigned,
   existing security analyzers that do not understand the new values may
   fail, resulting in either loss of connectivity if the analyzer
   declines to forward the unrecognized traffic, traffic or loss of security if
   it does forward the traffic and the new values are used as part of an
   attack.  This vulnerability argues for high visibility (which the
   Standards Action process ensures) for the assignments whenever possible.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>

<!-- [rfced] As RFCs 9776 and 9777 are being with this document, please consider whether the references should be to the individual RFCs or the STDs instead.

rfced: author would like to point to the STDs
-->

<!-- [I-D.ietf-pim-3376bis] companion document RFC 9776 -->
	<reference anchor="RFC9776" target="https://www.rfc-editor.org/info/rfc9776">
	  <front>
	    <title>Internet Group Management Protocol, Version 3</title>
	    <author initials="B." surname="Haberman" fullname="Brian Haberman" role="editor">
	      <organization>Johns Hopkins University Applied Physics Lab</organization>
	    </author>
	    <date month="March" year="2025"/>
	  </front>
	  <seriesInfo name="STD" value="100"/>
	  <seriesInfo name="RFC" value="9776"/>
	  <seriesInfo name="DOI" value="10.17487/RFC9776"/>
	</reference>

<!-- [I-D.ietf-pim-3810bis] companion document RFC 9777-->
	<reference anchor="RFC9777" target="https://www.rfc-editor.org/info/rfc9777">
	  <front>
	    <title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</title>
	    <author initials="B." surname="Haberman" fullname="Brian Haberman" role="editor">
	      <organization>Johns Hopkins University Applied Physics Lab</organization>
	    </author>
	    <date month="March" year="2025"/>
	  </front>
	  <seriesInfo name="STD" value="101"/>
	  <seriesInfo name="RFC" value="9777"/>
	  <seriesInfo name="DOI" value="10.17487/RFC9777"/>
	</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3228.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9279.xml"/>
      </references>
    </references>
       <section title="Contributors">
   <t>Bill Fenner was numbered="false" toc="default">
      <name>Contributors</name>
      <t><contact fullname="Bill Fenner"/> is the author of RFC 3228, <xref
      target="RFC3228" format="default"/>, which provided a portion of the
      content contained herein.</t>
       </section>

 </middle>

 <back>
   <references title="Normative References">
      <?rfc include="reference.RFC.2119" ?>
      <?rfc include="reference.I-D.ietf-pim-3376bis" ?>
      <?rfc include="reference.I-D.ietf-pim-3810bis" ?>
      <?rfc include="reference.RFC.8126" ?>
      <?rfc include="reference.RFC.8174" ?>
   </references>

   <references title="Informative References">
      <?rfc include="reference.RFC.3228" ?>
      <?rfc include="reference.RFC.4443" ?>
      <?rfc include="reference.RFC.9279" ?>
   </references>

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

  </back>
</rfc>