rfc9778xml2.original.xml | rfc9778.xml | |||
---|---|---|---|---|
<?xml version="1.0" encoding="US-ASCII"?> | <?xml version='1.0' encoding='utf-8'?> | |||
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="bcp" docNa | |||
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> | me="draft-ietf-pim-3228bis-07" number="9778" consensus="true" ipr="pre5378trust2 | |||
<?rfc toc="yes"?> | 00902" obsoletes="3228" updates="" submissionType="IETF" xml:lang="en" tocInclud | |||
<?rfc sortrefs="yes"?> | e="true" sortRefs="true" symRefs="true" prepTime="2025-03-28T12:36:04" indexIncl | |||
<?rfc symrefs="yes"?> | ude="true" scripts="Common,Latin" tocDepth="3"> | |||
<?rfc compact="yes"?> | <link href="https://datatracker.ietf.org/doc/draft-ietf-pim-3228bis-07" rel="p | |||
<?rfc comments="yes"?> | rev"/> | |||
<?rfc inline="yes"?> | <link href="https://dx.doi.org/10.17487/rfc9778" rel="alternate"/> | |||
<rfc category="bcp" docName="draft-ietf-pim-3228bis-07" ipr="pre5378trust200902" | <link href="urn:issn:2070-1721" rel="alternate"/> | |||
obsoletes="3228"> | <front> | |||
<front> | <title abbrev="IANA Considerations for IGMP">IANA Considerations for Interne | |||
<title abbrev="IGMP IANA">IANA Considerations for Internet Group Management P | t Group Management Protocols</title> | |||
rotocols</title> | <seriesInfo name="RFC" value="9778" stream="IETF"/> | |||
<seriesInfo name="BCP" value="57" stream="IETF"/> | ||||
<author fullname="Brian Haberman" initials="B." surname="Haberman" role="edit | <author fullname="Brian Haberman" initials="B." surname="Haberman" role="edi | |||
or"> | tor"> | |||
<organization abbrev="JHU APL">Johns Hopkins University Applied Physics La | <organization abbrev="JHU APL" showOnFrontPage="true">Johns Hopkins Univer | |||
b</organization> | sity Applied Physics Lab</organization> | |||
<address> | <address> | |||
<email>brian@innovationslab.net</email> | <email>brian@innovationslab.net</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date month="03" year="2025"/> | ||||
<abstract> | <area>RTG</area> | |||
<t>This document specifies revised IANA Considerations for the Internet Group | <workgroup>pim</workgroup> | |||
Management | <abstract pn="section-abstract"> | |||
Protocol and the Multicast Listener Discovery protocol. This document specifi | <t indent="0" pn="section-abstract-1">This document specifies revised IANA | |||
es the | considerations for the Internet Group Management | |||
Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. This doc | ||||
ument specifies the | ||||
guidance provided to IANA to manage values associated with various fields wit hin the | guidance provided to IANA to manage values associated with various fields wit hin the | |||
protocol headers of the group management protocols.</t> | protocol headers of the group management protocols.</t> | |||
<t indent="0" pn="section-abstract-2">This document obsoletes RFC 3228 and | ||||
<t>This document obsoletes RFC 3228 and unifies guidelines for IPv4 and IPv6 | unifies guidelines for IPv4 and IPv6 group management protocols.</t> | |||
group management protocols.</t> | </abstract> | |||
</abstract> | <boilerplate> | |||
</front> | <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc= | |||
"exclude" pn="section-boilerplate.1"> | ||||
<middle> | <name slugifiedName="name-status-of-this-memo">Status of This Memo</name | |||
<section anchor="intro" title="Introduction"> | > | |||
<t indent="0" pn="section-boilerplate.1-1"> | ||||
<t>The following sections describe the allocation guidelines associated with | This memo documents an Internet Best Current Practice. | |||
the specified fields within the Internet Group Management Protocol (IGMP) <xr | </t> | |||
ef target="I-D.ietf-pim-3376bis"/> | <t indent="0" pn="section-boilerplate.1-2"> | |||
and the Multicast Listener Discovery (MLD) <xref target="I-D.ietf-pim-3810bis | This document is a product of the Internet Engineering Task Force | |||
"/> headers. Some of these registries | (IETF). It represents the consensus of the IETF community. It has | |||
received public review and has been approved for publication by | ||||
the Internet Engineering Steering Group (IESG). Further information | ||||
on BCPs is available in Section 2 of RFC 7841. | ||||
</t> | ||||
<t indent="0" pn="section-boilerplate.1-3"> | ||||
Information about the current status of this document, any | ||||
errata, and how to provide feedback on it may be obtained at | ||||
<eref target="https://www.rfc-editor.org/info/rfc9778" brackets="non | ||||
e"/>. | ||||
</t> | ||||
</section> | ||||
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl | ||||
ude" pn="section-boilerplate.2"> | ||||
<name slugifiedName="name-copyright-notice">Copyright Notice</name> | ||||
<t indent="0" pn="section-boilerplate.2-1"> | ||||
Copyright (c) 2025 IETF Trust and the persons identified as the | ||||
document authors. All rights reserved. | ||||
</t> | ||||
<t indent="0" pn="section-boilerplate.2-2"> | ||||
This document is subject to BCP 78 and the IETF Trust's Legal | ||||
Provisions Relating to IETF Documents | ||||
(<eref target="https://trustee.ietf.org/license-info" brackets="none | ||||
"/>) in effect on the date of | ||||
publication of this document. Please review these documents | ||||
carefully, as they describe your rights and restrictions with | ||||
respect to this document. Code Components extracted from this | ||||
document must include Revised BSD License text as described in | ||||
Section 4.e of the Trust Legal Provisions and are provided without | ||||
warranty as described in the Revised BSD License. | ||||
</t> | ||||
<t indent="0" pn="section-boilerplate.2-3"> | ||||
This document may contain material from IETF Documents or IETF | ||||
Contributions published or made publicly available before November | ||||
10, 2008. The person(s) controlling the copyright in some of this | ||||
material may not have granted the IETF Trust the right to allow | ||||
modifications of such material outside the IETF Standards Process. | ||||
Without obtaining an adequate license from the person(s) | ||||
controlling the copyright in such materials, this document may not | ||||
be modified outside the IETF Standards Process, and derivative | ||||
works of it may not be created outside the IETF Standards Process, | ||||
except to format it for publication as an RFC or to translate it | ||||
into languages other than English. | ||||
</t> | ||||
</section> | ||||
</boilerplate> | ||||
<toc> | ||||
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p | ||||
n="section-toc.1"> | ||||
<name slugifiedName="name-table-of-contents">Table of Contents</name> | ||||
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to | ||||
c.1-1"> | ||||
<li pn="section-toc.1-1.1"> | ||||
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der | ||||
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref | ||||
derivedContent="" format="title" sectionFormat="of" target="name-introduction"> | ||||
Introduction</xref></t> | ||||
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio | ||||
n-toc.1-1.1.2"> | ||||
<li pn="section-toc.1-1.1.2.1"> | ||||
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1">< | ||||
xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1. | ||||
1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-co | ||||
nventions-used-in-this-do">Conventions Used in This Document</xref></t> | ||||
</li> | ||||
</ul> | ||||
</li> | ||||
<li pn="section-toc.1-1.2"> | ||||
<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form | ||||
at="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" f | ||||
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider | ||||
ations</xref></t> | ||||
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio | ||||
n-toc.1-1.2.2"> | ||||
<li pn="section-toc.1-1.2.2.1"> | ||||
<t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent= | ||||
"2.1" format="counter" sectionFormat="of" target="section-2.1"/>. <xref derived | ||||
Content="" format="title" sectionFormat="of" target="name-type-and-code-fields"> | ||||
Type and Code Fields</xref></t> | ||||
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se | ||||
ction-toc.1-1.2.2.1.2"> | ||||
<li pn="section-toc.1-1.2.2.1.2.1"> | ||||
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1. | ||||
2.1.1"><xref derivedContent="2.1.1" format="counter" sectionFormat="of" target=" | ||||
section-2.1.1"/>. <xref derivedContent="" format="title" sectionFormat="of" tar | ||||
get="name-internet-group-management-p">Internet Group Management Protocol</xref> | ||||
</t> | ||||
</li> | ||||
<li pn="section-toc.1-1.2.2.1.2.2"> | ||||
<t indent="0" pn="section-toc.1-1.2.2.1.2.2.1"><xref derived | ||||
Content="2.1.2" format="counter" sectionFormat="of" target="section-2.1.2"/>. < | ||||
xref derivedContent="" format="title" sectionFormat="of" target="name-multicast- | ||||
listener-discover">Multicast Listener Discovery</xref></t> | ||||
</li> | ||||
</ul> | ||||
</li> | ||||
<li pn="section-toc.1-1.2.2.2"> | ||||
<t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent= | ||||
"2.2" format="counter" sectionFormat="of" target="section-2.2"/>. <xref derived | ||||
Content="" format="title" sectionFormat="of" target="name-igmp-mld-query-message | ||||
-flag">IGMP/MLD Query Message Flags</xref></t> | ||||
</li> | ||||
<li pn="section-toc.1-1.2.2.3"> | ||||
<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent= | ||||
"2.3" format="counter" sectionFormat="of" target="section-2.3"/>. <xref derived | ||||
Content="" format="title" sectionFormat="of" target="name-igmp-mld-report-messag | ||||
e-fla">IGMP/MLD Report Message Flags</xref></t> | ||||
</li> | ||||
</ul> | ||||
</li> | ||||
<li pn="section-toc.1-1.3"> | ||||
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form | ||||
at="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" f | ||||
ormat="title" sectionFormat="of" target="name-security-considerations">Security | ||||
Considerations</xref></t> | ||||
</li> | ||||
<li pn="section-toc.1-1.4"> | ||||
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form | ||||
at="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" f | ||||
ormat="title" sectionFormat="of" target="name-references">References</xref></t> | ||||
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio | ||||
n-toc.1-1.4.2"> | ||||
<li pn="section-toc.1-1.4.2.1"> | ||||
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent= | ||||
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>. <xref derived | ||||
Content="" format="title" sectionFormat="of" target="name-normative-references"> | ||||
Normative References</xref></t> | ||||
</li> | ||||
<li pn="section-toc.1-1.4.2.2"> | ||||
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent= | ||||
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>. <xref derived | ||||
Content="" format="title" sectionFormat="of" target="name-informative-references | ||||
">Informative References</xref></t> | ||||
</li> | ||||
</ul> | ||||
</li> | ||||
<li pn="section-toc.1-1.5"> | ||||
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="" forma | ||||
t="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" | ||||
format="title" sectionFormat="of" target="name-contributors">Contributors</xref | ||||
></t> | ||||
</li> | ||||
<li pn="section-toc.1-1.6"> | ||||
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="" forma | ||||
t="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" | ||||
format="title" sectionFormat="of" target="name-authors-address">Author's Addres | ||||
s</xref></t> | ||||
</li> | ||||
</ul> | ||||
</section> | ||||
</toc> | ||||
</front> | ||||
<middle> | ||||
<section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn | ||||
="section-1"> | ||||
<name slugifiedName="name-introduction">Introduction</name> | ||||
<t indent="0" pn="section-1-1">The sections that follow describe the alloc | ||||
ation guidelines associated with | ||||
the specified fields within the Internet Group Management Protocol (IGMP) <xr | ||||
ef target="STD100" format="default" sectionFormat="of" derivedContent="STD100"/> | ||||
and the Multicast Listener Discovery (MLD) <xref target="STD101" format="defa | ||||
ult" sectionFormat="of" derivedContent="STD101"/> headers. Some of these registr | ||||
ies | ||||
were created previously, while others are created by this document.</t> | were created previously, while others are created by this document.</t> | |||
<t indent="0" pn="section-1-2">This document obsoletes <xref target="RFC32 | ||||
<t>This document obsoletes <xref target="RFC3228"/> and unifies guidelines fo | 28" format="default" sectionFormat="of" derivedContent="RFC3228"/> and unifies g | |||
r IPv4 and IPv6 group | uidelines for IPv4 and IPv6 group | |||
management protocols.</t> | management protocols.</t> | |||
<section numbered="true" toc="include" removeInRFC="false" pn="section-1.1 | ||||
<section title="Conventions Used in This Document"> | "> | |||
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | <name slugifiedName="name-conventions-used-in-this-do">Conventions Used | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | in This Document</name> | |||
"OPTIONAL" in this document are to be interpreted as described in | <t indent="0" pn="section-1.1-1"> | |||
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, | The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU | |||
they appear in all | IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL | |||
capitals, as shown here.</t> | D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N | |||
</section> | OT RECOMMENDED</bcp14>", | |||
</section> | "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to | |||
be interpreted as | ||||
<section title="IANA Considerations"> | described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o | |||
<t>The registration procedures used in this document are defined in <xref tar | f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor | |||
get="RFC8126"/>.</t> | mat="of" derivedContent="RFC8174"/> | |||
when, and only when, they appear in all capitals, as shown here. | ||||
<section title="Type and Code Fields"> | </t> | |||
<section title="Internet Group Management Protocol"> | </section> | |||
<t> The IGMP header contains the following fields that carry values assigned | </section> | |||
from IANA-managed name | <section numbered="true" toc="include" removeInRFC="false" pn="section-2"> | |||
<name slugifiedName="name-iana-considerations">IANA Considerations</name> | ||||
<t indent="0" pn="section-2-1">The registration procedures used in this do | ||||
cument are defined in <xref target="RFC8126" format="default" sectionFormat="of" | ||||
derivedContent="RFC8126"/>.</t> | ||||
<section numbered="true" toc="include" removeInRFC="false" pn="section-2.1 | ||||
"> | ||||
<name slugifiedName="name-type-and-code-fields">Type and Code Fields</na | ||||
me> | ||||
<section numbered="true" toc="include" removeInRFC="false" pn="section-2 | ||||
.1.1"> | ||||
<name slugifiedName="name-internet-group-management-p">Internet Group | ||||
Management Protocol</name> | ||||
<t indent="0" pn="section-2.1.1-1"> The IGMP header contains the follo | ||||
wing 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 indent="0" pn="section-2.1.1-2"><xref target="RFC3228" format="defa ult" sectionFormat="of" derivedContent="RFC3228"/> created the "IGMP Type Number s" 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" bare="false" empty="false" indent="3" pn="section | |||
<t>The reference for the registry is changed to this document.</t> | -2.1.1-3"> | |||
</list></t> | <li pn="section-2.1.1-3.1">The registration procedure has been chang | |||
ed to Standards Action.</li> | ||||
<t><xref target="RFC3228"/> created an IANA registry for Code values for exis | <li pn="section-2.1.1-3.2">The references to <xref target="RFC3228" | |||
ting IGMP Type fields. | format="default" sectionFormat="of" derivedContent="RFC3228"/>, including the re | |||
The registration procedure for the existing registries is changed to Standard | ference for the registry, have been changed to this document.</li> | |||
s Action. The policy for | </ul> | |||
assigning Code values for new IGMP Types MUST be defined in the document defi | <t indent="0" pn="section-2.1.1-4"><xref target="RFC3228" format="defa | |||
ning the new Type value.</t> | ult" sectionFormat="of" derivedContent="RFC3228"/> created the '"Code" Fields' r | |||
</section> | egistry for Code values for existing IGMP Type fields. This document updates tha | |||
t registry in two ways:</t> | ||||
<section title="Multicast Listener Discovery"> | <ul spacing="normal" bare="false" empty="false" indent="3" pn="section | |||
<t>As with IGMP, the MLD header also contains Type and Code fields. As | -2.1.1-5"> | |||
signment of those fields within | <li pn="section-2.1.1-5.1">The registration procedure has been chang | |||
the MLD header is defined in <xref target="RFC4443"/> with a r | ed to Standards Action.</li> | |||
egistration policy of IETF Review.</t> | <li pn="section-2.1.1-5.2">The reference for the registry has been c | |||
</section> | hanged to this document.</li> | |||
</ul> | ||||
</section> | <t indent="0" pn="section-2.1.1-6"> | |||
Note that the policy for assigning Code values for new IGMP Types <bcp14 | ||||
<section title="IGMP/MLD Query Message Flags"> | >MUST</bcp14> be defined in the document defining the new Type value.</t> | |||
</section> | ||||
<t>The IANA is requested to create a single registry for the bits in the Flag | <section numbered="true" toc="include" removeInRFC="false" pn="section-2 | |||
s | .1.2"> | |||
field of the MLDv2 Query Message <xref target="I-D.ietf-pim-3810bis"/> | <name slugifiedName="name-multicast-listener-discover">Multicast Liste | |||
and the IGMPv3 Query Message <xref target="I-D.ietf-pim-3376bis"/>. The forma | ner Discovery</name> | |||
t for the registry is:</t> | <t indent="0" pn="section-2.1.2-1">As with IGMP, the MLD header also c | |||
ontains Type and Code fields. Assignment of those fields within the MLD header i | ||||
<figure> | s defined in <xref target="RFC4443" format="default" sectionFormat="of" derivedC | |||
<artwork><![CDATA[ | ontent="RFC4443"/> with a registration policy of IETF Review; see <<eref targ | |||
+-----------+------------+-------------+-----------+ | et="https://www.iana.org/assignments/icmpv6-parameters" brackets="none"/>>.</ | |||
| Flags Bit | Short Name | Description | Reference | | t> | |||
+-----------+------------+-------------+-----------+ | </section> | |||
| 0 | E | Extension | RFC 9279 | | </section> | |||
| 1 | | | | | <section numbered="true" toc="include" removeInRFC="false" pn="section-2.2 | |||
| 2 | | | | | "> | |||
| 3 | | | | | <name slugifiedName="name-igmp-mld-query-message-flag">IGMP/MLD Query Me | |||
+-----------+------------+-------------+-----------+ | ssage Flags</name> | |||
]]></artwork> | <t indent="0" pn="section-2.2-1">IANA has created the "IGMP/MLD Query Me | |||
</figure> | ssage Flags" registry for the bits in the Flags | |||
field of the MLDv2 Query Message <xref target="STD101" format="default" secti | ||||
<t>The Flags Bit value in the registry above corresponds to the column header | onFormat="of" derivedContent="STD101"/> | |||
in the packet format diagrams | and the IGMPv3 Query Message <xref target="STD100" format="default" sectionFo | |||
in <xref target="I-D.ietf-pim-3810bis"/> and <xref target="I-D.ietf-pim-3376b | rmat="of" derivedContent="STD100"/>. It has been populated as follows: </t> | |||
is"/>.</t> | <table align="left" pn="table-1"> | |||
<name slugifiedName="name-igmp-mld-query-message-flags">IGMP/MLD Query | ||||
<t>The initial contents of this requested registry should contain the E-bit d | Message Flags Registry</name> | |||
efined in <xref target="RFC9279" />.</t> | <thead> | |||
<tr> | ||||
<t>The assignment of new bit flags within the Flags field | <th align="left" colspan="1" rowspan="1">Flags Bit</th> | |||
<th align="left" colspan="1" rowspan="1">Short Name</th> | ||||
<th align="left" colspan="1" rowspan="1">Description</th> | ||||
<th align="left" colspan="1" rowspan="1">Reference</th> | ||||
</tr> | ||||
</thead> | ||||
<tbody> | ||||
<tr> | ||||
<td align="left" colspan="1" rowspan="1">0</td> | ||||
<td align="left" colspan="1" rowspan="1">E</td> | ||||
<td align="left" colspan="1" rowspan="1">Extension</td> | ||||
<td align="left" colspan="1" rowspan="1"> | ||||
<xref target="RFC9279" format="default" sectionFormat="of" deriv | ||||
edContent="RFC9279"/></td> | ||||
</tr> | ||||
<tr> | ||||
<td align="left" colspan="1" rowspan="1">1-3</td> | ||||
<td colspan="3" align="left" rowspan="1">Unassigned</td> | ||||
</tr> | ||||
</tbody> | ||||
</table> | ||||
<t indent="0" pn="section-2.2-3">The Flags Bit value in the registry abo | ||||
ve corresponds to the column header in the packet format diagrams | ||||
in Sections <xref target="RFC9776" sectionFormat="bare" section="4.1" format= | ||||
"default" derivedLink="https://rfc-editor.org/rfc/rfc9776#section-4.1" derivedCo | ||||
ntent="RFC9776"/> and <xref target="RFC9776" sectionFormat="bare" section="4.2" | ||||
format="default" derivedLink="https://rfc-editor.org/rfc/rfc9776#section-4.2" de | ||||
rivedContent="RFC9776"/> of <xref target="STD100" format="default" sectionFormat | ||||
="of" derivedContent="STD100"/> and Sections <xref target="RFC9777" sectionForma | ||||
t="bare" section="5.1" format="default" derivedLink="https://rfc-editor.org/rfc/ | ||||
rfc9777#section-5.1" derivedContent="RFC9777"/> and <xref target="RFC9777" secti | ||||
onFormat="bare" section="5.2" format="default" derivedLink="https://rfc-editor.o | ||||
rg/rfc/rfc9777#section-5.2" derivedContent="RFC9777"/> of <xref target="STD101" | ||||
format="default" sectionFormat="of" derivedContent="STD101"/>.</t> | ||||
<t indent="0" pn="section-2.2-4">The assignment of new bit flags within | ||||
the Flags field | ||||
requires Standards Action.</t> | requires Standards Action.</t> | |||
</section> | </section> | |||
<section numbered="true" toc="include" removeInRFC="false" pn="section-2.3 | ||||
<section title="IGMP/MLD Report Message Flags"> | "> | |||
<t>The IANA is requested to create a single registry for the bits in the Flag | <name slugifiedName="name-igmp-mld-report-message-fla">IGMP/MLD Report M | |||
s | essage Flags</name> | |||
field of the MLDv2 Report Message and the IGMPv3 Report Message. The format f | <t indent="0" pn="section-2.3-1">IANA has created the "IGMP/MLD Report M | |||
or the registry is:</t> | essage Flags" registry for the bits in the Flags | |||
field of the MLDv2 Report Message and the IGMPv3 Report Message. It has been | ||||
<figure> | populated as follows:</t> | |||
<artwork><![CDATA[ | <table align="left" pn="table-2"> | |||
+-----------+------------+-------------+-----------+ | <name slugifiedName="name-igmp-mld-report-message-flag">IGMP/MLD Repor | |||
| Flags Bit | Short Name | Description | Reference | | t Message Flags Registry</name> | |||
+-----------+------------+-------------+-----------+ | <thead> | |||
| 0 | E | Extension | RFC 9279 | | <tr> | |||
| 1 | | | | | <th align="left" colspan="1" rowspan="1">Flags Bit</th> | |||
| 2 | | | | | <th align="left" colspan="1" rowspan="1">Short Name</th> | |||
| 3 | | | | | <th align="left" colspan="1" rowspan="1">Description</th> | |||
| 4 | | | | | <th align="left" colspan="1" rowspan="1">Reference</th> | |||
| 5 | | | | | </tr> | |||
| 6 | | | | | </thead> | |||
| 7 | | | | | <tbody> | |||
| 8 | | | | | <tr> | |||
| 9 | | | | | <td align="left" colspan="1" rowspan="1">0</td> | |||
| 10 | | | | | <td align="left" colspan="1" rowspan="1">E</td> | |||
| 11 | | | | | <td align="left" colspan="1" rowspan="1">Extension</td> | |||
| 12 | | | | | <td align="left" colspan="1" rowspan="1"> | |||
| 13 | | | | | <xref target="RFC9279" format="default" sectionFormat="of" deriv | |||
| 14 | | | | | edContent="RFC9279"/></td> | |||
| 15 | | | | | </tr> | |||
+-----------+------------+-------------+-----------+ | <tr> | |||
]]></artwork> | <td align="left" colspan="1" rowspan="1">1-15</td> | |||
</figure> | <td colspan="3" align="left" rowspan="1">Unassigned</td> | |||
</tr> | ||||
<t>The Flags Bit value in the registry above corresponds to the column header | </tbody> | |||
in the packet format diagrams | </table> | |||
in <xref target="I-D.ietf-pim-3810bis"/> and <xref target="I-D.ietf-pim-3376b | <t indent="0" pn="section-2.3-3">The Flags Bit value in the registry abo | |||
is"/>.</t> | ve corresponds to the column header in the packet format diagrams in <xref targe | |||
t="STD101" format="default" sectionFormat="of" derivedContent="STD101"/> and <xr | ||||
<t>The initial contents of this requested registry should contain the E-bit d | ef target="STD100" format="default" sectionFormat="of" derivedContent="STD100"/> | |||
efined in <xref target="RFC9279" />.</t> | .</t> | |||
<t indent="0" pn="section-2.3-4">The assignment of new bit flags within | ||||
<t>The assignment of new bit flags within the Flags field | the Flags field | |||
require Standards Action.</t> | requires Standards Action.</t> | |||
</section> | </section> | |||
</section> | ||||
</section> | <section numbered="true" toc="include" removeInRFC="false" pn="section-3"> | |||
<name slugifiedName="name-security-considerations">Security Considerations | ||||
<section title="Security Considerations"> | </name> | |||
<t>Security analyzers such as firewalls and network intrusion detection | <t indent="0" pn="section-3-1">Security analyzers such as firewalls and ne | |||
twork 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> | ||||
<section title="Contributors"> | <back> | |||
<t>Bill Fenner was the author of RFC 3228, which provided a portion of the co | <references pn="section-4"> | |||
ntent contained herein.</t> | <name slugifiedName="name-references">References</name> | |||
</section> | <references pn="section-4.1"> | |||
<name slugifiedName="name-normative-references">Normative References</na | ||||
</middle> | me> | |||
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 | ||||
<back> | 119" quoteTitle="true" derivedAnchor="RFC2119"> | |||
<references title="Normative References"> | <front> | |||
<?rfc include="reference.RFC.2119" ?> | <title>Key words for use in RFCs to Indicate Requirement Levels</tit | |||
<?rfc include="reference.I-D.ietf-pim-3376bis" ?> | le> | |||
<?rfc include="reference.I-D.ietf-pim-3810bis" ?> | <author fullname="S. Bradner" initials="S." surname="Bradner"/> | |||
<?rfc include="reference.RFC.8126" ?> | <date month="March" year="1997"/> | |||
<?rfc include="reference.RFC.8174" ?> | <abstract> | |||
</references> | <t indent="0">In many standards track documents several words are | |||
used to signify the requirements in the specification. These words are often cap | ||||
<references title="Informative References"> | italized. This document defines these words as they should be interpreted in IET | |||
<?rfc include="reference.RFC.3228" ?> | F documents. This document specifies an Internet Best Current Practices for the | |||
<?rfc include="reference.RFC.4443" ?> | Internet Community, and requests discussion and suggestions for improvements.</t | |||
<?rfc include="reference.RFC.9279" ?> | > | |||
</references> | </abstract> | |||
</front> | ||||
</back> | <seriesInfo name="BCP" value="14"/> | |||
<seriesInfo name="RFC" value="2119"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC2119"/> | ||||
</reference> | ||||
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8 | ||||
126" quoteTitle="true" derivedAnchor="RFC8126"> | ||||
<front> | ||||
<title>Guidelines for Writing an IANA Considerations Section in RFCs | ||||
</title> | ||||
<author fullname="M. Cotton" initials="M." surname="Cotton"/> | ||||
<author fullname="B. Leiba" initials="B." surname="Leiba"/> | ||||
<author fullname="T. Narten" initials="T." surname="Narten"/> | ||||
<date month="June" year="2017"/> | ||||
<abstract> | ||||
<t indent="0">Many protocols make use of points of extensibility t | ||||
hat use constants to identify various protocol parameters. To ensure that the va | ||||
lues in these fields do not have conflicting uses and to promote interoperabilit | ||||
y, their allocations are often coordinated by a central record keeper. For IETF | ||||
protocols, that role is filled by the Internet Assigned Numbers Authority (IANA) | ||||
.</t> | ||||
<t indent="0">To make assignments in a given registry prudently, g | ||||
uidance describing the conditions under which new values should be assigned, as | ||||
well as when and how modifications to existing values can be made, is needed. Th | ||||
is document defines a framework for the documentation of these guidelines by spe | ||||
cification authors, in order to assure that the provided guidance for the IANA C | ||||
onsiderations is clear and addresses the various issues that are likely in the o | ||||
peration of a registry.</t> | ||||
<t indent="0">This is the third edition of this document; it obsol | ||||
etes RFC 5226.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="26"/> | ||||
<seriesInfo name="RFC" value="8126"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8126"/> | ||||
</reference> | ||||
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8 | ||||
174" quoteTitle="true" derivedAnchor="RFC8174"> | ||||
<front> | ||||
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti | ||||
tle> | ||||
<author fullname="B. Leiba" initials="B." surname="Leiba"/> | ||||
<date month="May" year="2017"/> | ||||
<abstract> | ||||
<t indent="0">RFC 2119 specifies common key words that may be used | ||||
in protocol specifications. This document aims to reduce the ambiguity by clari | ||||
fying that only UPPERCASE usage of the key words have the defined special meanin | ||||
gs.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="14"/> | ||||
<seriesInfo name="RFC" value="8174"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8174"/> | ||||
</reference> | ||||
<referencegroup anchor="STD100" target="https://www.rfc-editor.org/info/ | ||||
std100" derivedAnchor="STD100"> | ||||
<reference anchor="RFC9776" target="https://www.rfc-editor.org/info/rf | ||||
c9776" quoteTitle="true"> | ||||
<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> | ||||
<referencegroup anchor="STD101" target="https://www.rfc-editor.org/info/ | ||||
std101" derivedAnchor="STD101"> | ||||
<reference anchor="RFC9777" target="https://www.rfc-editor.org/info/rf | ||||
c9777" quoteTitle="true"> | ||||
<front> | ||||
<title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</ti | ||||
tle> | ||||
<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> | ||||
</references> | ||||
<references pn="section-4.2"> | ||||
<name slugifiedName="name-informative-references">Informative References | ||||
</name> | ||||
<reference anchor="RFC3228" target="https://www.rfc-editor.org/info/rfc3 | ||||
228" quoteTitle="true" derivedAnchor="RFC3228"> | ||||
<front> | ||||
<title>IANA Considerations for IPv4 Internet Group Management Protoc | ||||
ol (IGMP)</title> | ||||
<author fullname="B. Fenner" initials="B." surname="Fenner"/> | ||||
<date month="February" year="2002"/> | ||||
<abstract> | ||||
<t indent="0">This memo requests that the IANA create a registry f | ||||
or fields in the IGMP (Internet Group Management Protocol) protocol header, and | ||||
provides guidance for the IANA to use in assigning parameters for those fields. | ||||
This document specifies an Internet Best Current Practices for the Internet Comm | ||||
unity, and requests discussion and suggestions for improvements.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="57"/> | ||||
<seriesInfo name="RFC" value="3228"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC3228"/> | ||||
</reference> | ||||
<reference anchor="RFC4443" target="https://www.rfc-editor.org/info/rfc4 | ||||
443" quoteTitle="true" derivedAnchor="RFC4443"> | ||||
<front> | ||||
<title>Internet Control Message Protocol (ICMPv6) for the Internet P | ||||
rotocol Version 6 (IPv6) Specification</title> | ||||
<author fullname="A. Conta" initials="A." surname="Conta"/> | ||||
<author fullname="S. Deering" initials="S." surname="Deering"/> | ||||
<author fullname="M. Gupta" initials="M." role="editor" surname="Gup | ||||
ta"/> | ||||
<date month="March" year="2006"/> | ||||
<abstract> | ||||
<t indent="0">This document describes the format of a set of contr | ||||
ol messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the In | ||||
ternet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDAR | ||||
DS-TRACK]</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="STD" value="89"/> | ||||
<seriesInfo name="RFC" value="4443"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC4443"/> | ||||
</reference> | ||||
<reference anchor="RFC9279" target="https://www.rfc-editor.org/info/rfc9 | ||||
279" quoteTitle="true" derivedAnchor="RFC9279"> | ||||
<front> | ||||
<title>Internet Group Management Protocol Version 3 (IGMPv3) and Mul | ||||
ticast Listener Discovery Version 2 (MLDv2) Message Extension</title> | ||||
<author fullname="M. Sivakumar" initials="M." surname="Sivakumar"/> | ||||
<author fullname="S. Venaas" initials="S." surname="Venaas"/> | ||||
<author fullname="Z. Zhang" initials="Z." surname="Zhang"/> | ||||
<author fullname="H. Asaeda" initials="H." surname="Asaeda"/> | ||||
<date month="August" year="2022"/> | ||||
<abstract> | ||||
<t indent="0">This document specifies a generic mechanism to exten | ||||
d IGMPv3 and Multicast Listener Discovery Version 2 (MLDv2) by using a list of T | ||||
LVs (Type, Length, and Value).</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="9279"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9279"/> | ||||
</reference> | ||||
</references> | ||||
</references> | ||||
<section numbered="false" toc="include" removeInRFC="false" pn="section-appe | ||||
ndix.a"> | ||||
<name slugifiedName="name-contributors">Contributors</name> | ||||
<t indent="0" pn="section-appendix.a-1"><contact fullname="Bill Fenner"/> | ||||
is the author of <xref target="RFC3228" format="default" sectionFormat="of" deri | ||||
vedContent="RFC3228"/>, which provided a portion of the | ||||
content contained herein.</t> | ||||
</section> | ||||
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc | ||||
="include" pn="section-appendix.b"> | ||||
<name slugifiedName="name-authors-address">Author's Address</name> | ||||
<author fullname="Brian Haberman" initials="B." surname="Haberman" role="e | ||||
ditor"> | ||||
<organization abbrev="JHU APL" showOnFrontPage="true">Johns Hopkins Univ | ||||
ersity Applied Physics Lab</organization> | ||||
<address> | ||||
<email>brian@innovationslab.net</email> | ||||
</address> | ||||
</author> | ||||
</section> | ||||
</back> | ||||
</rfc> | </rfc> | |||
End of changes. 10 change blocks. | ||||
190 lines changed or deleted | 573 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |