[要約] RFC 9279は、IGMPv3とMLDv2を拡張するためのTLVリストを使用する汎用メカニズムを指定しています。これの目的は、これらのプロトコルを柔軟に拡張し、新しい機能をサポートすることです。
Internet Engineering Task Force (IETF) M. Sivakumar
Request for Comments: 9279 Juniper Networks
Category: Standards Track S. Venaas
ISSN: 2070-1721 Cisco Systems, Inc.
Z. Zhang
ZTE Corporation
H. Asaeda
NICT
August 2022
Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Message Extension
インターネットグループ管理プロトコルバージョン3（IGMPV3）およびマルチキャストリスナーディスカバリーバージョン2（MLDV2）メッセージ拡張
Abstract
概要
This document specifies a generic mechanism to extend IGMPv3 and Multicast Listener Discovery Version 2 (MLDv2) by using a list of TLVs (Type, Length, and Value).
このドキュメントは、TLVのリスト（タイプ、長さ、および値）のリストを使用して、IGMPV3およびマルチキャストリスナーディスカバリーバージョン2（MLDV2）を拡張するための一般的なメカニズムを指定します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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 Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、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/rfc9279.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9279で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Conventions Used in This Document
3. Extension Format
3.1. Multicast Listener Query Extension
3.2. Version 2 Multicast Listener Report Extension
3.3. IGMP Membership Query Extension
3.4. IGMP Version 3 Membership Report Extension
4. No-op TLV
5. Processing the Extension
6. Applicability and Backwards Compatibility
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
This document defines a generic method to extend IGMPv3 [RFC3376] and MLDv2 [RFC3810] messages to accommodate information other than what is contained in the current message formats. This is done by allowing a list of TLVs to be used in the Additional Data section of IGMPv3 and MLDv2 messages. This document defines a registry for such TLVs. Other documents will define their specific types, and their values and semantics. The extension would only be used when at least one TLV is to be added to the message. This extension also applies to the lightweight versions of IGMPv3 and MLDv2 as defined in [RFC5790].
このドキュメントは、現在のメッセージ形式に含まれるもの以外の情報に対応するために、IgMPv3 [RFC3376]およびMLDV2 [RFC3810]メッセージを拡張する一般的な方法を定義します。これは、IGMPV3およびMLDV2メッセージの追加データセクションでTLVのリストを使用できるようにすることによって行われます。このドキュメントは、そのようなTLVのレジストリを定義します。他のドキュメントでは、特定のタイプとその価値とセマンティクスを定義します。拡張機能は、少なくとも1つのTLVがメッセージに追加される場合にのみ使用されます。この拡張は、[RFC5790]で定義されているように、IGMPV3およびMLDV2の軽量バージョンにも適用されます。
When this extension mechanism is used, it replaces the Additional Data section defined in IGMPv3/MLDv2 with TLVs.
この拡張メカニズムを使用すると、IGMPV3/MLDV2で定義された追加のデータセクションをTLVSに置き換えます。
Additional Data is defined for Query messages in IGMPv3 (Section 4.1.10 of [RFC3376]) and MLDv2 (Section 5.1.12 of [RFC3810]), and for Report messages in IGMPv3 (Section 4.2.11 of [RFC3376]) and MLDv2 (Section 5.2.11 of [RFC3810]).
追加データは、IgMPv3（[RFC3376]のセクション4.1.10）およびMLDV2（[RFC3810]のセクション5.1.12）のクエリメッセージと、[RFC3376]のセクション4.2.11）およびMLDV22のレポートメッセージについて定義されています。（[RFC3810]のセクション5.2.11）。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
For each of the IGMPv3 and MLDv2 headers, a previously reserved bit is used to indicate the presence of this extension. When this extension is used, the Additional Data of IGMPv3 and MLDv2 messages is formatted as follows. Note that this format contains a variable number of TLVs. It MUST contain at least one TLV.
IGMPV3およびMLDV2ヘッダーのそれぞれについて、以前に予約されていたビットが使用され、この拡張の存在を示します。この拡張機能を使用すると、IGMPV3およびMLDV2メッセージの追加データが次のようにフォーマットされます。この形式には、可変数のTLVが含まれていることに注意してください。少なくとも1つのTLVを含める必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type 1 | Extension Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Value 1 |
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type 2 | Extension Length 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Value 2 |
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type n | Extension Length n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Value n |
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Extension Format
図1：拡張形式
Extension Type: 2 octets. This identifies a particular Extension Type as defined in the "IGMP/MLD Extension Types" registry. If this is not the first TLV, it will follow immediately after the end of the previous one. There is no alignment or padding.
拡張タイプ：2オクテット。これは、「IGMP/MLD拡張タイプ」レジストリで定義されている特定の拡張タイプを識別します。これが最初のTLVではない場合、前のTLVの終了直後に続きます。アライメントやパディングはありません。
Extension Length: 2 octets. This specifies the length in octets of the following Extension Value field. The length may be zero if no value is needed.
拡張長：2オクテット。これは、次の拡張値フィールドのオクテットの長さを指定します。値が不要な場合、長さはゼロになる場合があります。
Extension Value: This field contains the value. The specification defining the Extension Type describes the length and contents of this field.
拡張値：このフィールドには値が含まれています。拡張タイプを定義する仕様は、このフィールドの長さと内容を記述します。
IGMPv3 and MLDv2 messages are defined so they can fit within the network MTU in order to avoid fragmentation. An IGMPv3/MLDv2 Report message contains a number of records. The records are called Group Records for IGMPv3 and Address Records for MLDv2. When this extension mechanism is used, the number of records in each Report message SHOULD be kept small enough so that the entire message, including any extension TLVs, can fit within the network MTU.
IGMPV3およびMLDV2メッセージは定義されているため、断片化を回避するためにネットワークMTUに収まることができます。IGMPV3/MLDV2レポートメッセージには、多くのレコードが含まれています。レコードは、IGMPV3のグループレコードと呼ばれ、MLDV2のアドレスレコードです。この拡張メカニズムを使用する場合、各レポートメッセージのレコードの数は十分に小さく保ち、拡張TLVを含むメッセージ全体がネットワークMTU内に収まるようにする必要があります。
The MLDv2 Query message format [RFC3810] with extension is shown below. The E-bit MUST be set to 1 to indicate that the extension is present. Otherwise, it MUST be 0.
拡張付きMLDV2クエリメッセージフォーマット[RFC3810]を以下に示します。Extensionが存在することを示すために、eビットを1に設定する必要があります。それ以外の場合は、0でなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 130 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Response Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Multicast Address *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Resv|S| QRV | QQIC | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Source Address [1] *
| |
* *
| |
+- -+
| |
* *
| |
* Source Address [2] *
| |
* *
| |
+- . -+
. . .
. . .
+- -+
| |
* *
| |
* Source Address [N] *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MLD Query Extension
図2：MLDクエリ拡張機能
The MLDv2 Report message format [RFC3810] with extension is shown below. The E-bit MUST be set to 1 to indicate that the extension is present. Otherwise, it MUST be 0.
拡張付きMLDV2レポートメッセージフォーマット[RFC3810]を以下に示します。Extensionが存在することを示すために、eビットを1に設定する必要があります。それ以外の場合は、0でなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 143 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Reserved |Nr of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MLD Report Extension
図3：MLDレポート拡張
The IGMPv3 Query message format [RFC3376] with the extension is shown below. The E-bit MUST be set to 1 to indicate that the extension is present. Otherwise, it MUST be 0.
拡張機能を備えたIGMPV3クエリメッセージフォーマット[RFC3376]を以下に示します。Extensionが存在することを示すために、eビットを1に設定する必要があります。それ以外の場合は、0でなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x11 | Max Resp Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Resv|S| QRV | QQIC | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address [1] |
+- -+
| Source Address [2] |
+- . -+
. . .
. . .
+- -+
| Source Address [N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IGMP Query Extension
図4：IGMPクエリエクステンション
The IGMPv3 Report message format [RFC3376] with the extension is shown below. The E-bit MUST be set to 1 to indicate that the extension is present. Otherwise, it MUST be 0.
拡張機能を備えたIGMPV3レポートメッセージフォーマット[RFC3376]を以下に示します。Extensionが存在することを示すために、eビットを1に設定する必要があります。それ以外の場合は、0でなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x22 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Reserved | Number of Group Records (M) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IGMP Report Extension
図5：IGMPレポート拡張
The No-op TLV is a No-Operation TLV that MUST be ignored during processing. This TLV may be used to verify that the extension mechanism has been implemented correctly. Note that there is no alignment requirement, so there is no need to use this Extension Type to provide alignment.
No-op TLVは、処理中に無視する必要がある非操作TLVです。このTLVは、拡張メカニズムが正しく実装されていることを確認するために使用できます。アラインメント要件はないため、この拡張タイプを使用してアラインメントを提供する必要はないことに注意してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No-op Type = 0 | No-op Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: No-op TLV Format
図6：no-op tlv形式
No-op Type: 2 octets. The type of the No-op TLV extension is 0.
NO-OPタイプ：2オクテット。NO-OP TLV拡張のタイプは0です。
Extension Length: 2 octets. This specifies the length in octets of the following Value field. The length may be zero if no value is needed.
拡張長：2オクテット。これは、次の値フィールドのオクテットの長さを指定します。値が不要な場合、長さはゼロになる場合があります。
Value: This field contains the value. As this Extension Type is always ignored, the value can be arbitrary data. The number of octets used MUST match the specified length.
値：このフィールドには値が含まれています。この拡張タイプは常に無視されるため、値は任意のデータになる可能性があります。使用するオクテットの数は、指定された長さと一致する必要があります。
The procedure specified in this document only applies when the E-bit is set.
このドキュメントで指定された手順は、eビットが設定されている場合にのみ適用されます。
If the validation of the TLVs fails, the entire Additional Data field MUST be ignored as specified in IGMPv3 [RFC3376] and MLDv2 [RFC3810]. The following checks must pass for the validation of the TLVs not to fail:
TLVの検証が失敗した場合、IGMPV3 [RFC3376]およびMLDV2 [RFC3810]で指定されているように、追加のデータフィールド全体を無視する必要があります。TLVの検証に失敗しないようにするには、次のチェックが合格する必要があります。
* At least one TLV MUST be present.
* 少なくとも1つのTLVが存在する必要があります。
* There MUST NOT be any data in the IP payload after the last TLV. To check this, the parser needs to walk through each of the TLVs until there are less than four octets left in the IP payload. If there are any octets left, validation fails.
* 最後のTLVの後、IPペイロードにデータがないはずです。これを確認するには、パーサーは、IPペイロードに残り4オクテットが残るまで、各TLVを通過する必要があります。オクテットが残っている場合、検証は失敗します。
* The total length of the Extension MUST NOT exceed the remainder of the IP payload length. For this validation, only the content of the Extension Length fields is examined.
* 拡張の合計長さは、IPペイロード長の残りを超えてはなりません。この検証では、拡張長フィールドのコンテンツのみが調べられます。
Future documents defining a new Extension Type MUST specify any additional processing and validation. These rules, if any, will be examined only after the general validation succeeds.
新しい拡張機能タイプを定義する将来のドキュメントでは、追加の処理と検証を指定する必要があります。これらの規則は、もしあれば、一般的な検証が成功した後にのみ検討されます。
TLVs with unsupported Extension Types MUST be ignored.
サポートされていない拡張タイプを持つTLVは無視する必要があります。
IGMP and MLD implementations, particularly implementations on hosts, rarely change. The adoption process of this extension mechanism is expected to be slow. As new extension TLVs are defined, it may take a long time for them to be supported. Due to this, defining new extension TLVs should not be taken lightly, and it is crucial to consider backwards compatibility.
IGMPおよびMLDの実装、特にホストの実装はめったに変わりません。この拡張メカニズムの採用プロセスは遅くなると予想されます。新しい拡張TLVが定義されると、それらがサポートされるまでに長い時間がかかる場合があります。このため、新しい拡張TLVを定義することは軽く採取されるべきではなく、逆方向の互換性を考慮することが重要です。
Implementations that do not support this extension mechanism will ignore it, as specified in [RFC3376] and [RFC3810]. As mentioned in the previous section, unsupported extension TLVs are ignored.
[RFC3376]および[RFC3810]で指定されているように、この拡張メカニズムをサポートしない実装はそれを無視します。前のセクションで述べたように、サポートされていない拡張TLVは無視されます。
It is possible that a new extension TLV will only apply to queries or only to reports, or that there may be other specific conditions for when it is to be used. A document defining a new Extension Type MUST specify the conditions under which the new Extension Type should be used, including which message types. It MUST also be specified what the behavior should be if a message is not used in the defined manner, e.g., if it is present in a Query message, when it was only expected to be used in reports.
新しい拡張TLVは、クエリにのみ適用されるか、レポートにのみ適用される可能性があります。また、使用する場合には他の特定の条件がある可能性があります。新しいエクステンションタイプを定義するドキュメントでは、どのメッセージタイプを含む新しい拡張タイプを使用する必要がある条件を指定する必要があります。また、メッセージが定義された方法で使用されていない場合、たとえば、レポートでのみ使用されると予想されるクエリメッセージに存在する場合、動作が何であるかを指定する必要があります。
When defining new Extension Types, the effect of partial support for the new TLV, by either the hosts or routers, on the same link should be carefully considered. Further, whether there are any dependencies or restrictions on combinations between the new Extension Types and any preexisting Extension Types must be considered.
新しい拡張タイプを定義する場合、ホストまたはルーターのいずれかによる新しいTLVに対する部分的なサポートの効果を同じリンクで慎重に考慮する必要があります。さらに、新しい拡張タイプと既存の拡張タイプの間の組み合わせに依存関係または制限があるかどうかを考慮する必要があります。
This document defines an extension mechanism only for IGMPv3 and MLDv2. Hence, this mechanism does not apply if hosts or routers send older version messages.
このドキュメントは、IgMPv3とMLDV2のみの拡張メカニズムを定義します。したがって、ホストまたはルーターが古いバージョンメッセージを送信した場合、このメカニズムは適用されません。
The Security Considerations of [RFC3376] and [RFC3810] also apply here.
[RFC3376]および[RFC3810]のセキュリティ上の考慮事項もここに適用されます。
This document extends the IGMP and MLD message formats, allowing for a variable number of TLVs. Implementations must take care not to exceed the packet boundary when parsing the TLVs, because an attacker could intentionally specify a TLV with a length exceeding the boundary.
このドキュメントは、IGMPおよびMLDメッセージ形式を拡張し、変数数のTLVを可能にします。攻撃者は境界を超える長さのTLVを意図的に指定できるため、実装はTLVを解析するときにパケット境界を超えないように注意する必要があります。
An implementation could add a large number of minimal TLVs in a message to increase the cost of processing the message. This would magnify a denial-of-service attack.
実装により、メッセージに多数の最小TLVを追加して、メッセージの処理コストを増加させる可能性があります。これにより、サービス拒否攻撃が拡大されます。
IANA has created a new registry called "IGMP/MLD Extension Types" in the "Internet Group Management Protocol (IGMP) Type Numbers" section and lists this document as the reference. The registration procedure is "IETF Review" [RFC8126]. The registry is common for IGMP and MLD.
IANAは、「インターネットグループ管理プロトコル（IGMP）タイプ番号」セクションに「IGMP/MLD拡張タイプ」と呼ばれる新しいレジストリを作成し、このドキュメントを参照としてリストしています。登録手順は「IETFレビュー」[RFC8126]です。レジストリは、IGMPおよびMLDで一般的です。
Two Extension Types (65534 and 65535) are provided for "Experimental Use" [RFC8126]. Any experiments should be confined to closed environments where it is unlikely that they may conflict with other experiments; see [RFC3692].
2つの拡張タイプ（65534および65535）が「実験的使用」のために提供されています[RFC8126]。実験は、他の実験と矛盾する可能性が低い閉鎖環境に限定される必要があります。[RFC3692]を参照してください。
IANA has initially populated the registry as shown in Table 1
表1に示すように、IANAが最初にレジストリに登録しています
+================+==========+==================+===========+
| Extension Type | Length | Name | Reference |
+================+==========+==================+===========+
| 0 | variable | No-op | RFC 9279 |
+----------------+----------+------------------+-----------+
| 1-65533 | | Unassigned | |
+----------------+----------+------------------+-----------+
| 65534-65535 | variable | Reserved for | |
| | | Experimental Use | |
+----------------+----------+------------------+-----------+
Table 1: IGMP/MLD Extension Types
表1：IGMP/MLD拡張タイプ
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <https://www.rfc-editor.org/info/rfc3376>.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B.、およびA. Thyagarajan、 "Internet Group Management Protocol、バージョン3"、RFC 3376、DOI 10.17487/RFC3376、2002年10月、<<https://www.rfc-editor.org/info/rfc3376>。
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>.
[RFC3810] Vida、R.、ed。and L. Costa、ed。、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、DOI 10.17487/RFC3810、2004年6月、<https://www.rfc-editor.org/info/rfc3810>。
[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>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, <https://www.rfc-editor.org/info/rfc3692>.
[RFC3692] Narten、T。、「有用と見なされる実験数とテスト数の割り当て」、BCP 82、RFC 3692、DOI 10.17487/RFC3692、2004年1月、<https://www.rfc-editor.org/info/rfc3692>
[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, DOI 10.17487/RFC5790, February 2010, <https://www.rfc-editor.org/info/rfc5790>.
[RFC5790] Liu、H.、Cao、W。、およびH. Asaeda、「軽量インターネットグループ管理プロトコルバージョン3（IGMPV3）およびマルチキャストリスナーディスカバリーバージョン2（MLDV2）プロトコル」、RFC 5790、DOI 10.17487/RFC5790、FEBRUARY2010、<https://www.rfc-editor.org/info/rfc5790>。
Acknowledgements
謝辞
The authors thank Ron Bonica, Ian Duncan, Wesley Eddy, Leonard Giuliano, Jake Holland, Tommy Pauly, Pete Resnick, Alvaro Retana, and Zhaohui Zhang for reviewing the document and providing valuable feedback.
著者は、ロン・ボニャ、イアン・ダンカン、ウェスリー・エディ、レナード・ジュリアーノ、ジェイク・ホランド、トミー・ポーリー、ピート・レストニック、アルバロ・レタナ、Zhaohui Zhangに、文書をレビューし、貴重なフィードバックを提供してくれたことに感謝します。
Authors' Addresses
著者のアドレス
Mahesh Sivakumar Juniper Networks 64 Butler St Milpitas, CA 95035 United States of America Email: sivakumar.mahesh@gmail.com
Mahesh Sivakumar Juniper Networks 64 Butler St Milpitas、CA 95035アメリカ合衆国電子メール：sivakumar.mahesh@gmail.com
Stig Venaas Cisco Systems, Inc. Tasman Drive San Jose, CA 95134 United States of America Email: stig@cisco.com
Stig Venaas Cisco Systems、Inc。Tasman Drive San Jose、CA 95134アメリカ合衆国電子メール：stig@cisco.com
Zheng(Sandy) Zhang ZTE Corporation No. 50 Software Ave, Yuhuatai District Nanjing 210000 China Email: zhang.zheng@zte.com.cn
Zheng（Sandy）Zhang Zte Corporation No. 50 Software Ave、Yuhuatai District Nanjing 210000 China Email：zhang.zheng@zte.com.cn
Hitoshi Asaeda National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi, Koganei, Tokyo 184-8795 Japan Email: asaeda@nict.go.jp
Asaeda National Institute of Information And Communications Technology 4-2-1 Nukui-Kitamachi、Koganei、東京184-8795日本メール：asaeda@nict.go.jp