Internet Engineering Task Force (IETF) B. Haberman, Ed.
Request for Comments: 9778 JHU APL
BCP: 57 March 2025
Obsoletes: 3228
Category: Best Current Practice
ISSN: 2070-1721
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.
このドキュメントは、インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリー（MLD）プロトコルに関するIANAの考慮事項を改訂します。このドキュメントは、グループ管理プロトコルのプロトコルヘッダー内のさまざまなフィールドに関連する値を管理するためにIANAに提供されたガイダンスを指定します。
This document obsoletes RFC 3228 and unifies guidelines for IPv4 and IPv6 group management protocols.
このドキュメントは、RFC 3228を廃止し、IPv4およびIPv6グループ管理プロトコルのガイドラインを統合します。
This memo documents an Internet Best Current Practice.
このメモは、インターネットの最高の現在の練習を文書化しています。
This document is a product of the Internet Engineering Task Force (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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。BCPSの詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9778.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9778で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。この資料の一部の著作権を管理する人は、IETFの信頼にIETF標準プロセス以外のそのような資料の変更を許可する権利を認めていない可能性があります。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、RFCとして公開したり、英語以外の言語に翻訳する場合を除き、IETF標準プロセスの外で作成されない場合があります。
1. Introduction
1.1. Conventions Used in This Document
2. IANA Considerations
2.1. Type and Code Fields
2.1.1. Internet Group Management Protocol
2.1.2. Multicast Listener Discovery
2.2. IGMP/MLD Query Message Flags
2.3. IGMP/MLD Report Message Flags
3. Security Considerations
4. References
4.1. Normative References
4.2. Informative References
Contributors
Author's Address
The sections that follow describe the allocation guidelines associated with the specified fields within the Internet Group Management Protocol (IGMP) [STD100] and the Multicast Listener Discovery (MLD) [STD101] headers. Some of these registries were created previously, while others are created by this document.
以下のセクションでは、インターネットグループ管理プロトコル（IGMP）[STD100]およびマルチキャストリスナーディスカバリー（MLD）[STD101]ヘッダー内の指定されたフィールドに関連付けられた割り当てガイドラインについて説明します。これらのレジストリの一部は以前に作成されましたが、他のレジストリはこのドキュメントによって作成されます。
This document obsoletes [RFC3228] and unifies guidelines for IPv4 and IPv6 group management protocols.
このドキュメントは、IPv4およびIPv6グループ管理プロトコルのガイドラインを廃止し[RFC3228]統合します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
The registration procedures used in this document are defined in [RFC8126].
このドキュメントで使用される登録手順は、[RFC8126]で定義されています。
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.
IGMPヘッダーには、IANAが管理した名前スペースから割り当てられた値を伝える次のフィールドが含まれています：タイプとコード。コードフィールド値は、特定の型値に対して定義されます。
[RFC3228] created the "IGMP Type Numbers" registry for the IGMP Type field. This document updates that registry in two ways:
[RFC3228]は、IGMPタイプフィールドの「IGMPタイプ番号」レジストリを作成しました。このドキュメントは、そのレジストリを2つの方法で更新します。
* The registration procedure has been changed to Standards Action.
* 登録手順は標準措置に変更されました。
* The references to [RFC3228], including the reference for the registry, have been changed to this document.
* レジストリの参照を含む[RFC3228]への参照は、このドキュメントに変更されました。
[RFC3228] created the '"Code" Fields' registry for Code values for existing IGMP Type fields. This document updates that registry in two ways:
[RFC3228]は、既存のIGMPタイプフィールドのコード値の「「コード」フィールド」レジストリを作成しました。このドキュメントは、そのレジストリを2つの方法で更新します。
* The registration procedure has been changed to Standards Action.
* 登録手順は標準措置に変更されました。
* The reference for the registry has been changed to this document.
* レジストリのリファレンスはこのドキュメントに変更されました。
Note that the policy for assigning Code values for new IGMP Types MUST be defined in the document defining the new Type value.
新しいIGMPタイプのコード値を割り当てるためのポリシーは、新しいタイプ値を定義するドキュメントで定義する必要があることに注意してください。
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; see <https://www.iana.org/assignments/icmpv6-parameters>.
IGMPと同様に、MLDヘッダーにはタイプフィールドとコードフィールドも含まれています。MLDヘッダー内のこれらのフィールドの割り当ては、IETFレビューの登録ポリシーを使用して[RFC4443]で定義されています。<https://www.iana.org/assignments/icmpv6-parameters>を参照してください。
IANA has created the "IGMP/MLD Query Message Flags" registry for the bits in the Flags field of the MLDv2 Query Message [STD101] and the IGMPv3 Query Message [STD100]. It has been populated as follows:
IANAは、MLDV2クエリメッセージ[STD101]およびIGMPV3クエリメッセージ[STD100]のフラグフィールドのビットの「IGMP/MLDクエリメッセージフラグ」レジストリを作成しました。次のように入力されています。
+===========+============+=============+===========+
| Flags Bit | Short Name | Description | Reference |
+===========+============+=============+===========+
| 0 | E | Extension | [RFC9279] |
+-----------+------------+-------------+-----------+
| 1-3 | Unassigned |
+-----------+--------------------------------------+
Table 1: IGMP/MLD Query Message Flags Registry
表1：IGMP/MLDクエリメッセージフラグレジストリ
The Flags Bit value in the registry above corresponds to the column header in the packet format diagrams in Sections 4.1 and 4.2 of [STD100] and Sections 5.1 and 5.2 of [STD101].
上記のレジストリのフラグビット値は、[STD100]のセクション4.1および4.2のパケット形式図の列ヘッダーと[STD101]のセクション5.1および5.2の列ヘッダーに対応しています。
The assignment of new bit flags within the Flags field requires Standards Action.
フラグフィールド内の新しいビットフラグの割り当てには、標準措置が必要です。
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:
IANAは、MLDV2レポートメッセージとIGMPv3レポートメッセージのフラグフィールドのBITSの「IGMP/MLDレポートメッセージフラグ」レジストリを作成しました。次のように入力されています。
+===========+============+=============+===========+
| Flags Bit | Short Name | Description | Reference |
+===========+============+=============+===========+
| 0 | E | Extension | [RFC9279] |
+-----------+------------+-------------+-----------+
| 1-15 | Unassigned |
+-----------+--------------------------------------+
Table 2: IGMP/MLD Report Message Flags Registry
表2：IGMP/MLDレポートメッセージフラグレジストリ
The Flags Bit value in the registry above corresponds to the column header in the packet format diagrams in [STD101] and [STD100].
上記のレジストリのフラグビット値は、[std101]および[std100]のパケット形式図の列ヘッダーに対応しています。
The assignment of new bit flags within the Flags field requires Standards Action.
フラグフィールド内の新しいビットフラグの割り当てには、標準措置が必要です。
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.
ファイアウォールやネットワーク侵入検出モニターなどのセキュリティアナライザーは、このメモに記載されているフィールドの明確な解釈に依存していることがよくあります。フィールドの新しい値が割り当てられると、新しい値が失敗する可能性がある既存のセキュリティアナライザーが失敗する可能性があり、アナライザーが認識されていないトラフィックの転送を拒否した場合、またはトラフィックを転送し、新しい値が攻撃の一部として使用された場合、セキュリティの損失を拒否した場合に、接続の損失をもたらします。この脆弱性は、可能な限り割り当ての高い可視性（標準アクションプロセスが保証する）について主張しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[STD100] Internet Standard 100,
<https://www.rfc-editor.org/info/std100>.
At the time of writing, this STD comprises the following:
Haberman, B., Ed., "Internet Group Management Protocol,
Version 3", STD 100, RFC 9776, DOI 10.17487/RFC9776, March
2025, <https://www.rfc-editor.org/info/rfc9776>.
[STD101] Internet Standard 101,
<https://www.rfc-editor.org/info/std101>.
At the time of writing, this STD comprises the following:
Haberman, B., Ed., "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", STD 101, RFC 9777,
DOI 10.17487/RFC9777, March 2025,
<https://www.rfc-editor.org/info/rfc9777>.
[RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group
Management Protocol (IGMP)", BCP 57, RFC 3228,
DOI 10.17487/RFC3228, February 2002,
<https://www.rfc-editor.org/info/rfc3228>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC9279] Sivakumar, M., Venaas, S., Zhang, Z., and H. Asaeda,
"Internet Group Management Protocol Version 3 (IGMPv3) and
Multicast Listener Discovery Version 2 (MLDv2) Message
Extension", RFC 9279, DOI 10.17487/RFC9279, August 2022,
<https://www.rfc-editor.org/info/rfc9279>.
Bill Fenner is the author of [RFC3228], which provided a portion of the content contained herein.
ビル・フェナーは[RFC3228]の著者であり、ここに含まれるコンテンツの一部を提供しました。
Brian Haberman (editor)
Johns Hopkins University Applied Physics Lab
Email: brian@innovationslab.net