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

<!DOCTYPE rfc [
  <!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" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <front>
    
<title 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>

    <abstract>
      <t>This document specifies revised IANA 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" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The sections that follow describe the allocation guidelines associated with
   the specified fields within the Internet Group Management Protocol (IGMP) <xref target="STD100" format="default"/>
   and the Multicast Listener Discovery (MLD) <xref target="STD101" 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" format="default"/> and unifies guidelines for IPv4 and IPv6 group
   management protocols.</t>
      <section numbered="true" toc="default">
        <name>Conventions Used in This Document</name>
        <t>
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    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>
    <section numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>The registration procedures used in this document are defined in <xref target="RFC8126" format="default"/>.</t>
      <section numbered="true" toc="default">
        <name>Type and Code Fields</name>
        <section numbered="true" toc="default">
          <name>Internet Group Management 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" format="default"/> created the "IGMP Type Numbers" registry for the IGMP Type field. 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 references to <xref target="RFC3228"/>, including the reference for the registry, have been changed to this document.</li>
          </ul>
          <t><xref target="RFC3228" format="default"/> created the '"Code" Fields' registry for Code values for existing IGMP Type fields. 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 registry has been changed to this document.</li>
          </ul>
<t>
	 Note that the policy for assigning Code values for new IGMP Types <bcp14>MUST</bcp14> be defined in the document defining the new Type value.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Multicast Listener 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" format="default"/> with a registration policy of IETF Review; see &lt;<eref target="https://www.iana.org/assignments/icmpv6-parameters"/>&gt;.</t>
        </section>
      </section>
      <section numbered="true" toc="default">
        <name>IGMP/MLD Query Message 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="STD101" format="default"/>
   and the IGMPv3 Query Message <xref target="STD100" 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>

        <t>The Flags Bit value in the registry above corresponds to the column header in the packet format diagrams
   in Sections <xref target="RFC9776" sectionFormat="bare" section="4.1"/> and <xref target="RFC9776" sectionFormat="bare" section="4.2"/> of <xref target="STD100" format="default"/> and Sections <xref target="RFC9777" sectionFormat="bare" section="5.1"/> and <xref target="RFC9777" sectionFormat="bare" section="5.2"/> of <xref target="STD101" format="default"/>.</t>
        <t>The assignment of new bit flags within the Flags field
   requires Standards Action.</t>
      </section>
      <section numbered="true" toc="default">
        <name>IGMP/MLD Report Message 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. It has been populated as follows:</t>

   <table align="left">
     <name>IGMP/MLD Report 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-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="STD101" format="default"/> and <xref target="STD100" format="default"/>.</t>

        <t>The assignment of new bit flags within the Flags field
   requires Standards Action.</t>
      </section>
    </section>
    <section 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 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"/>

	
<!--[I-D.ietf-pim-3376bis] companion document RFC 9776]-->
<referencegroup anchor="STD100" target="https://www.rfc-editor.org/info/std100">
<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"/>
 <date month="March" year="2025"/>
</front>
<seriesInfo name="STD" value="100"/>
<seriesInfo name="RFC" value="9776"/>
<seriesInfo name="DOI" value="10.17487/RFC9776"/>
</reference>
</referencegroup>


<!--[I-D.ietf-pim-3810bis] companion document RFC 9777]-->
<referencegroup anchor="STD101" target="https://www.rfc-editor.org/info/std101">
<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"/>
 <date month="March" year="2025"/>
</front>
<seriesInfo name="STD" value="101"/>
<seriesInfo name="RFC" value="9777"/>
<seriesInfo name="DOI" value="10.17487/RFC9777"/>
</reference>
</referencegroup>


        <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 numbered="false" toc="default">
      <name>Contributors</name>
      <t><contact fullname="Bill Fenner"/> is the author of <xref
      target="RFC3228" format="default"/>, which provided a portion of the
      content contained herein.</t>
       </section> 
  </back>
</rfc>
