rfc9778xml2.original.xml		rfc9778.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml 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"?>
	<rfc category="bcp" docName="draft-ietf-pim-3228bis-07" ipr="pre5378trust200902"
	obsoletes="3228">
	<front>
	<title abbrev="IGMP IANA">IANA Considerations for Internet Group Management P
	rotocols</title>
	<author fullname="Brian Haberman" initials="B." surname="Haberman" role="edit		<!DOCTYPE rfc [
	or">		<!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-ie
			tf-pim-3228bis-07" number="9778" consensus="true" ipr="pre5378trust200902" obsol
			etes="3228" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sor
			tRefs="true" symRefs="true" version="3">
			<front>
			<title abbrev="IANA Considerations for IGMP">IANA Considerations for Internet Gr
			oup Management Protocols</title>
			<seriesInfo name="RFC" value="9778"/>
			<seriesInfo name="BCP" value="57" />
			<author fullname="Brian Haberman" initials="B." surname="Haberman" role="edi
			tor">
	<organization abbrev="JHU APL">Johns Hopkins University Applied Physics La b</organization>		<organization abbrev="JHU APL">Johns Hopkins University Applied Physics La b</organization>
	<address>		<address>
	<email>brian@innovationslab.net</email>		<email>brian@innovationslab.net</email>
	</address>		</address>
	</author>		</author>
			<date year="2025" month="March"/>
	<abstract>
	<t>This document specifies revised IANA Considerations for the Internet Group
	Management
	Protocol and the Multicast Listener Discovery protocol. This document specifi
	es the
	guidance provided to IANA to manage values associated with various fields wit
	hin the
	protocol headers of the group management protocols.</t>
	<t>This document obsoletes RFC 3228 and unifies guidelines for IPv4 and IPv6		<area>RTG</area>
	group management protocols.</t>		<workgroup>pim</workgroup>
	</abstract>
	</front>
	<middle>		<!-- [rfced] Please insert any keywords (beyond those that appear in
	<section anchor="intro" title="Introduction">		the title) for use on https://www.rfc-editor.org/search. -->
	<t>The following sections describe the allocation guidelines associated with		<abstract>
	the specified fields within the Internet Group Management Protocol (IGMP) <xr		<t>This document specifies revised IANA considerations for the Internet Gr
	ef target="I-D.ietf-pim-3376bis"/>		oup Management
	and the Multicast Listener Discovery (MLD) <xref target="I-D.ietf-pim-3810bis		Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. This doc
	"/> headers. Some of these registries		ument specifies the
			guidance provided to IANA to manage values associated with various fields wit
			hin the
			protocol headers of the group management protocols.</t>
			<t>This document obsoletes RFC 3228 and unifies guidelines for IPv4 and IP
			v6 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) <xr
			ef target="RFC9776" format="default"/>
			and the Multicast Listener Discovery (MLD) <xref target="RFC9777" format="def
			ault"/> headers. Some of these registries
	were created previously, while others are created by this document.</t>		were created previously, while others are created by this document.</t>
			<t>This document obsoletes <xref target="RFC3228" format="default"/> and u
	<t>This document obsoletes <xref target="RFC3228"/> and unifies guidelines fo		nifies guidelines for IPv4 and IPv6 group
	r IPv4 and IPv6 group
	management protocols.</t>		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>REQU
			IRED</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 title="Conventions Used in This Document">		</section>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		</section>
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		<section numbered="true" toc="default">
	"OPTIONAL" in this document are to be interpreted as described in		<name>IANA Considerations</name>
	BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,		<t>The registration procedures used in this document are defined in <xref
	they appear in all		target="RFC8126" format="default"/>.</t>
	capitals, as shown here.</t>		<section numbered="true" toc="default">
	</section>		<name>Type and Code Fields</name>
	</section>		<section numbered="true" toc="default">
			<name>Internet Group Management Protocol</name>
	<section title="IANA Considerations">		<t> The IGMP header contains the following fields that carry values as
	<t>The registration procedures used in this document are defined in <xref tar		signed from IANA-managed name
	get="RFC8126"/>.</t>
	<section title="Type and Code Fields">
	<section title="Internet Group Management Protocol">
	<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 sp ecific Type value.</t>		spaces: Type and Code. Code field values are defined relative to a sp ecific Type value.</t>
	<t><xref target="RFC3228"/> created an IANA registry for the IGMP Type field. This document updates that		<t><xref target="RFC3228" format="default"/> created the "IGMP Type Nu mbers" registry for the IGMP Type field. This document updates that
	registry in two ways:		registry in two ways:
	<list style="hanging">		</t>
	<t>The registration procedure is changed to Standards Action.</t>		<ul spacing="normal">
	<t>The reference for the registry is changed to this document.</t>		<li>The registration procedure has been changed to Standards Action.
	</list></t>		</li>
			<li>The references to <xref target="RFC3228"/>, including the refere
	<t><xref target="RFC3228"/> created an IANA registry for Code values for exis		nce for the registry, have been changed to this document.</li>
	ting IGMP Type fields.		</ul>
	The registration procedure for the existing registries is changed to Standard		<t><xref target="RFC3228" format="default"/> created the '"Code" Field
	s Action. The policy for		s' registry for Code values for existing IGMP Type fields. This document updates
	assigning Code values for new IGMP Types MUST be defined in the document defi		that registry in two ways:</t>
	ning the new Type value.</t>		<ul spacing="normal">
	</section>		<li>The registration procedure has been changed to Standards Action.
			</li>
	<section title="Multicast Listener Discovery">		<li>The reference for the registry has been changed to this document
	<t>As with IGMP, the MLD header also contains Type and Code fields. As		.</li>
	signment of those fields within		</ul>
	the MLD header is defined in <xref target="RFC4443"/> with a r		<t>
	egistration policy of IETF Review.</t>		Note that the policy for assigning Code values for new IGMP Types <bcp14
	</section>		>MUST</bcp14> be defined in the document defining the new Type value.</t>
			</section>
	</section>		<section numbered="true" toc="default">
			<name>Multicast Listener Discovery</name>
	<section title="IGMP/MLD Query Message Flags">
	<t>The IANA is requested to create a single registry for the bits in the Flag
	s
	field of the MLDv2 Query Message <xref target="I-D.ietf-pim-3810bis"/>
	and the IGMPv3 Query Message <xref target="I-D.ietf-pim-3376bis"/>. The forma
	t for the registry is:</t>
	<figure>
	<artwork><![CDATA[
	+-----------+------------+-------------+-----------+
	| Flags Bit | Short Name | Description | Reference |
	+-----------+------------+-------------+-----------+
	| 0 | E | Extension | RFC 9279 |
	| 1 | | | |
	| 2 | | | |
	| 3 | | | |
	+-----------+------------+-------------+-----------+
	]]></artwork>
	</figure>
	<t>The Flags Bit value in the registry above corresponds to the column header		<t>As with IGMP, the MLD header also contains Type and Code fields. As
	in the packet format diagrams		signment of those fields within the MLD header is defined in <xref target="RFC44
	in <xref target="I-D.ietf-pim-3810bis"/> and <xref target="I-D.ietf-pim-3376b		43" format="default"/> with a registration policy of IETF Review; see &lt;<eref
	is"/>.</t>		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="RFC9777" format="default"/>
			and the IGMPv3 Query Message <xref target="RFC9776" format="default"/>. It h
			as been populated as follows: </t>
	<t>The initial contents of this requested registry should contain the E-bit d		<table align="left">
	efined in <xref target="RFC9279" />.</t>		<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 assignment of new bit flags within the Flags field		<t>The Flags Bit value in the registry above corresponds to the column h
			eader 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="RFC9
			776" 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>		requires Standards Action.</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="IGMP/MLD Report Message Flags">		<name>IGMP/MLD Report Message Flags</name>
	<t>The IANA is requested to create a single registry for the bits in the Flag		<t>IANA has created the "IGMP/MLD Report Message Flags" registry for the
	s		bits in the Flags
	field of the MLDv2 Report Message and the IGMPv3 Report Message. The format f		field of the MLDv2 Report Message and the IGMPv3 Report Message. It has been
	or the registry is:</t>		populated as follows:</t>
	<figure>
	<artwork><![CDATA[
	+-----------+------------+-------------+-----------+
	| 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>
	<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"/> and <xref target="I-D.ietf-pim-3376b
	is"/>.</t>
	<t>The initial contents of this requested registry should contain the E-bit d
	efined in <xref target="RFC9279" />.</t>
	<t>The assignment of new bit flags within the Flags field		<table align="left">
	require Standards Action.</t>		<name>IGMP/MLD Report Message Flags Registry</name>
	</section>		<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>
	</section>		<t>The Flags Bit value in the registry above corresponds to the column h eader in the packet format diagrams in <xref target="RFC9777" format="default"/> and <xref target="RFC9776" format="default"/>.</t>
	<section title="Security Considerations">		<t>The assignment of new bit flags within the Flags field
	<t>Security analyzers such as firewalls and network intrusion detection		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		monitors often rely on unambiguous interpretations of the fields
	described in this memo. As new values for the fields are assigned,		described in this memo. As new values for the fields are assigned,
	existing security analyzers that do not understand the new values may		existing security analyzers that do not understand the new values may
	fail, resulting in either loss of connectivity if the analyzer		fail, resulting in either loss of connectivity if the analyzer
	declines to forward the unrecognized traffic, or loss of security if		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		it does forward the traffic and the new values are used as part of an
	attack. This vulnerability argues for high visibility (which the		attack. This vulnerability argues for high visibility (which the
	Standards Action process ensures) for the assignments whenever possible.</t>		Standards Action process ensures) for the assignments whenever possible.</t>
	</section>		</section>
			</middle>
			<back>
			<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
			119.xml"/>
	<section title="Contributors">		<!-- [rfced] As RFCs 9776 and 9777 are being with this document, please consider
	<t>Bill Fenner was the author of RFC 3228, which provided a portion of the co		whether the references should be to the individual RFCs or the STDs instead.
	ntent contained herein.</t>
	</section>
	</middle>		rfced: author would like to point to the STDs
			-->
	<back>		<!-- [I-D.ietf-pim-3376bis] companion document RFC 9776 -->
	<references title="Normative References">		<reference anchor="RFC9776" target="https://www.rfc-editor.org/info/rfc97
	<?rfc include="reference.RFC.2119" ?>		76">
	<?rfc include="reference.I-D.ietf-pim-3376bis" ?>		<front>
	<?rfc include="reference.I-D.ietf-pim-3810bis" ?>		<title>Internet Group Management Protocol, Version 3</title>
	<?rfc include="reference.RFC.8126" ?>		<author initials="B." surname="Haberman" fullname="Brian Haberman" ro
	<?rfc include="reference.RFC.8174" ?>		le="editor">
	</references>		<organization>Johns Hopkins University Applied Physics Lab</organiz
			ation>
			</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>
	<references title="Informative References">		<!-- [I-D.ietf-pim-3810bis] companion document RFC 9777-->
	<?rfc include="reference.RFC.3228" ?>		<reference anchor="RFC9777" target="https://www.rfc-editor.org/info/rfc97
	<?rfc include="reference.RFC.4443" ?>		77">
	<?rfc include="reference.RFC.9279" ?>		<front>
	</references>		<title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</title
			>
			<author initials="B." surname="Haberman" fullname="Brian Haberman" ro
			le="editor">
			<organization>Johns Hopkins University Applied Physics Lab</organiz
			ation>
			</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>
	</back>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			126.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			174.xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
			228.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
			443.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			279.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>
			<!-- [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>		</rfc>
End of changes. 25 change blocks.
	175 lines changed or deleted		260 lines changed or added
This html diff was produced by rfcdiff 1.48.