<?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>

<!--[rfced] The short title that spans the header of the PDF file has
been updated as follows to more closely align with the document
title. Please let us know of any objections.

Original:
   IGMP IANA

Current:
   IANA Considerations for IGMP
-->

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

<!--[rfced] This document obsoletes RFC 3228, which was BCP 57.  As such, we have assigned BCP 57 to this document.  Please let us know any changes are needed.

See the complete list of BCPs here:
https://www.rfc-editor.org/bcps
-->

    <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. -->
<keyword>example</keyword>

    <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</name>
<!-- [rfced] For ease of the reader, we suggest including the IANA registry name.  Do the types and codes get registered in the Internet Control Message Protocol (ICMP) Parameters registry <https://www.iana.org/assignments/icmp-parameters>?  However, we don't see "IETF Review" listed as the registration procedure for any of the registries on that page.

Perhaps this refers to the "IGMP/MLD Extension Types" registry, which lists IETF Review and includes a range for Experimental Use?

Original:
2.1.2.  Multicast Listener Discovery"> Discovery

   As with IGMP, the MLD header also contains Type and Code fields.
   Assignment of those fields within the MLD header is defined in
   [RFC4443] with a registration policy of IETF Review.
-->

          <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>
        </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"/>. target="RFC9776" format="default"/>.  It has been populated as follows: </t>

  <table align="left">
  <name>IGMP/MLD Query Message Flags 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>

<!--[rfced] For easy reference, would you like to add section numbers
to the following text? If so, please confirm that Sections 5.1
and 5.2 of [RFC9777] and Sections 4.1 and 4.2 of [RFC9776] are
correct. Note that there are two instances in the text.

Original:
   The format for Flags Bit value in the registry is:</t>

   <figure>
      <artwork><![CDATA[
   +-----------+------------+-------------+-----------+
   | above corresponds to the column header
   in the packet format diagrams in [I-D.ietf-pim-3810bis] and
   [I-D.ietf-pim-3376bis].

Perhaps:
   The Flags Bit | Short Name | Description | Reference |
   +-----------+------------+-------------+-----------+
   | 0         |     E      | Extension   | RFC 9279  |
   | 1         |            |             |           |
   | 2         |            |             |           |
   | 3         |            |             |           |
   +-----------+------------+-------------+-----------+
      ]]></artwork>
   </figure> value in the registry above corresponds to the column header
   in the packet format diagrams in Sections 5.1 and 5.2 of [RFC9777] and
   Sections 4.1 and 4.2 of [RFC9776].
-->

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

<!-- [rfced] Because the E-bit appears in both tables with a reference, the text that follows seems redundant.  Perhaps "The initial contents..." text can be removed?

      | 0         |     E      | Extension   | RFC 9279  |

   ...
   The initial contents of this requested registry should contain the
   E-bit defined in [RFC9279].

      | 0         |     E      | Extension   | RFC 9279  |

   ...
   The initial contents of this requested registry should contain the
   E-bit defined in [RFC9279].
-->

        <t>The initial contents of this registry includes the E-bit defined in <xref target="RFC9279" />.</t> 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.
-->

<!-- [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>