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>
			<!--[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="IANA Considerations for IGMP">IANA Considerations for Internet Gr
			oup Management Protocols</title>
			<!--[rfced] This document obsoletes RFC 3228, which was BCP 57. As such, we hav
			e 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="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. -->
			<keyword>example</keyword>
	<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
			nce for the registry, have been changed to this document.</li>
			</ul>
			<t><xref target="RFC3228" format="default"/> created the '"Code" Field
			s' 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>
			<!-- [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 Protoco
			l (ICMP) Parameters registry <https://www.iana.org/assignments/icmp-parameters>?
			However, we don't see "IETF Review" listed as the registration procedure for a
			ny of the registries on that page.
	<t><xref target="RFC3228"/> created an IANA registry for Code values for exis		Perhaps this refers to the "IGMP/MLD Extension Types" registry, which lists IETF
	ting IGMP Type fields.		Review and includes a range for Experimental Use?
	The registration procedure for the existing registries is changed to Standard
	s Action. The policy for
	assigning Code values for new IGMP Types MUST be defined in the document defi
	ning the new Type value.</t>
	</section>
	<section title="Multicast Listener Discovery">		Original:
	<t>As with IGMP, the MLD header also contains Type and Code fields. As		2.1.2. Multicast Listener Discovery
	signment of those fields within
	the MLD header is defined in <xref target="RFC4443"/> with a r
	egistration policy of IETF Review.</t>
	</section>
	</section>		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.
			-->
	<section title="IGMP/MLD Query Message Flags">		<t>As with IGMP, the MLD header also contains Type and Code fields. As
			signment of those fields within
			the MLD header is defined in <xref target="RFC4443" format="de
			fault"/> with a registration policy of IETF Review.</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 IANA is requested to create a single registry for the bits in the Flag		<table align="left">
	s		<name>IGMP/MLD Query Message Flags Registry</name>
	field of the MLDv2 Query Message <xref target="I-D.ietf-pim-3810bis"/>		<thead>
	and the IGMPv3 Query Message <xref target="I-D.ietf-pim-3376bis"/>. The forma		<tr>
	t for the registry is:</t>		<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>
	<figure>		<!--[rfced] For easy reference, would you like to add section numbers
	<artwork><![CDATA[		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
	| Flags Bit | Short Name | Description | Reference |		correct. Note that there are two instances in the text.
	+-----------+------------+-------------+-----------+
	| 0 | E | Extension | RFC 9279 |
	| 1 | | | |
	| 2 | | | |
	| 3 | | | |
	+-----------+------------+-------------+-----------+
	]]></artwork>
	</figure>
	<t>The Flags Bit value in the registry above corresponds to the column header		Original:
	in the packet format diagrams		The Flags Bit value in the registry above corresponds to the column header
	in <xref target="I-D.ietf-pim-3810bis"/> and <xref target="I-D.ietf-pim-3376b		in the packet format diagrams in [I-D.ietf-pim-3810bis] and
	is"/>.</t>		[I-D.ietf-pim-3376bis].
	<t>The initial contents of this requested registry should contain the E-bit d		Perhaps:
	efined in <xref target="RFC9279" />.</t>		The Flags Bit 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 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 <xref target="RFC9777" format="default"/> and <xref target="RFC9776" forma
			t="default"/>.</t>
			<t>The initial contents of this registry contain the E-bit defined in <x
			ref target="RFC9279" 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">
			<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>
	<section title="IGMP/MLD Report Message Flags">		<table align="left">
	<t>The IANA is requested to create a single registry for the bits in the Flag		<name>IGMP/MLD Report Message Flags Registry</name>
	s		<thead>
	field of the MLDv2 Report Message and the IGMPv3 Report Message. The format f		<tr>
	or the registry is:</t>		<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>
	<figure>		<t>The Flags Bit value in the registry above corresponds to the column h
	<artwork><![CDATA[		eader in the packet format diagrams in <xref target="RFC9777" format="default"/>
	+-----------+------------+-------------+-----------+		and <xref target="RFC9776" format="default"/>.</t>
	| 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		<!-- [rfced] Because the E-bit appears in both tables with a reference, the text
	in the packet format diagrams		that follows seems redundant. Perhaps "The initial contents..." text can be re
	in <xref target="I-D.ietf-pim-3810bis"/> and <xref target="I-D.ietf-pim-3376b		moved?
	is"/>.</t>
	<t>The initial contents of this requested registry should contain the E-bit d efined in <xref target="RFC9279" />.</t>		| 0 | E | Extension | RFC 9279 |
	<t>The assignment of new bit flags within the Flags field		...
	require Standards Action.</t>		The initial contents of this requested registry should contain the
	</section>		E-bit defined in [RFC9279].
	</section>		| 0 | E | Extension | RFC 9279 |
	<section title="Security Considerations">		...
	<t>Security analyzers such as firewalls and network intrusion detection		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" 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		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>		<!-- [I-D.ietf-pim-3376bis] companion document RFC 9776 -->
			<reference anchor="RFC9776" target="https://www.rfc-editor.org/info/rfc97
			76">
			<front>
			<title>Internet Group Management Protocol, Version 3</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="100"/>
			<seriesInfo name="RFC" value="9776"/>
			<seriesInfo name="DOI" value="10.17487/RFC9776"/>
			</reference>
	<back>		<!-- [I-D.ietf-pim-3810bis] companion document RFC 9777-->
	<references title="Normative References">		<reference anchor="RFC9777" target="https://www.rfc-editor.org/info/rfc97
	<?rfc include="reference.RFC.2119" ?>		77">
	<?rfc include="reference.I-D.ietf-pim-3376bis" ?>		<front>
	<?rfc include="reference.I-D.ietf-pim-3810bis" ?>		<title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</title
	<?rfc include="reference.RFC.8126" ?>		>
	<?rfc include="reference.RFC.8174" ?>		<author initials="B." surname="Haberman" fullname="Brian Haberman" ro
	</references>		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>
	<references title="Informative References">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<?rfc include="reference.RFC.3228" ?>		126.xml"/>
	<?rfc include="reference.RFC.4443" ?>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<?rfc include="reference.RFC.9279" ?>		174.xml"/>
	</references>		</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>
	</back>		<!-- [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. 35 change blocks.
	164 lines changed or deleted		319 lines changed or added
This html diff was produced by rfcdiff 1.48.