[要約] RFC 4604は、IGMPv3とMLDv2を使用して、ソース特定マルチキャストを実現するための標準を定めています。このRFCの目的は、ネットワーク上での効率的なソース特定マルチキャスト通信を可能にすることです。
Network Working Group H. Holbrook
Request for Comments: 4604 Arastra, Inc.
Updates: 3376, 3810 B. Cain
Category: Standards Track Acopia Networks
B. Haberman
JHU APL
August 2006
Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast
インターネットグループ管理プロトコルバージョン3（IGMPV3）およびマルチキャストリスナーディスカバリープロトコルバージョン2（MLDV2）を使用して、ソース固有のマルチキャスト
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
The Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively. Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission. This document defines the notion of an "SSM-aware" router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast. This document updates the IGMPv3 and MLDv2 specifications.
インターネットグループ管理プロトコルバージョン3（IGMPV3）とマルチキャストリスナーディスカバリープロトコルバージョン2（MLDV2）は、ホストがそれぞれIPv4およびIPv6マルチキャストトランスミッションを受けたいという希望を隣接するルーターに通知できるプロトコルです。ソース固有のマルチキャスト（SSM）は、マルチキャスト送信を受信するために、ソースのネットワーク層アドレスとマルチキャスト宛先アドレスの両方を指定するためにレシーバーが必要なマルチキャストの形式です。このドキュメントでは、「SSMにアウェアする」ルーターとホストの概念を定義し、SSMにアウェアのルーターとホストでのIGMPV3およびMLDV2の動作を明確にし、（場合によっては）修正します。このドキュメントは、IGMPV3およびMLDV2の仕様を更新します。
The Internet Group Management Protocol (IGMP) [RFC1112, IGMPv2, IGMPv3] allows an IPv4 host to communicate IP multicast group membership information to its neighboring routers. IGMP version 3 (IGMPv3) [IGMPv3] provides the ability for a host to selectively request or filter traffic from individual sources within a multicast group.
インターネットグループ管理プロトコル（IGMP）[RFC1112、IGMPV2、IGMPV3]により、IPv4ホストはIPマルチキャストグループメンバーシップ情報を隣接するルーターに通信できます。IGMPバージョン3（IGMPV3）[IGMPV3]は、ホストがマルチキャストグループ内の個々のソースからトラフィックを選択またはフィルタリングする機能を提供します。
The Multicast Listener Discovery Protocol (MLD) [RFC2710, MLDv2] offers similar functionality for IPv6 hosts. MLD version 2 (MLDv2) provides the analogous "source filtering" functionality of IGMPv3 for IPv6.
マルチキャストリスナーディスカバリープロトコル（MLD）[RFC2710、MLDV2]は、IPv6ホストに同様の機能を提供します。MLDバージョン2（MLDV2）は、IPv6のIGMPv3の類似の「ソースフィルタリング」機能を提供します。
Due to the commonality of function, the term "Group Management Protocol", or "GMP", will be used to refer to both IGMP and MLD. The term "Source Filtering GMP", or "SFGMP", will be used to refer jointly to the IGMPv3 and MLDv2 group management protocols.
関数の共通性により、「グループ管理プロトコル」または「GMP」という用語は、IGMPとMLDの両方を参照するために使用されます。「ソースフィルタリングGMP」または「SFGMP」という用語は、IGMPV3およびMLDV2グループ管理プロトコルを共同で参照するために使用されます。
The use of source-specific multicast is facilitated by small changes to the SFGMP protocols on both hosts and routers. [SSM] defines general requirements that must be followed by systems that implement the SSM service model; this document defines the concrete application of those requirements to systems that implement IGMPv3 and MLDv2. In doing so, this document defines modifications to the host and router portions of IGMPv3 and MLDv2 for use with SSM, and presents a number of clarifications to their behavior when used with SSM addresses. This document updates the IGMPv3 and MLDv2 specifications.
ソース固有のマルチキャストの使用は、ホストとルーターの両方でSFGMPプロトコルの小さな変更により促進されます。[SSM]は、SSMサービスモデルを実装するシステムが従わなければならない一般的な要件を定義します。このドキュメントでは、IGMPV3およびMLDV2を実装するシステムへのこれらの要件の具体的な適用を定義しています。そうすることで、このドキュメントでは、SSMで使用するIGMPV3およびMLDV2のホストとルーターの部分の変更を定義し、SSMアドレスで使用する場合の動作に多くの説明を提示します。このドキュメントは、IGMPV3およびMLDV2の仕様を更新します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
In order to emphasize the parts of this document that modify the existing protocol specifications ([RFC2710, MLDv2, IGMPv3]), as opposed to merely clarify them, any protocol modifications are marked with the tag "MODIFICATION".
既存のプロトコル仕様を変更するこのドキュメントの部分を強調するために（[RFC2710、MLDV2、IGMPV3]）、単にそれらを明確にすることとは対照的に、プロトコルの変更にはタグ「変更」がマークされます。
This section defines the notion of an "SSM-aware" host and then goes on to describe the API requirements and the SFGMP protocol requirements of an SSM-aware host. It is important to note that SSM can be used by any host that supports source filtering APIs and whose operating system supports the appropriate SFGMP. The SFGMP modifications described in this section make SSM work better on an SSM-aware host, but they are not strict prerequisites for the use of SSM.
このセクションでは、「SSM-Aware」ホストの概念を定義し、その後、SSM対応ホストのAPI要件とSFGMPプロトコル要件について説明します。SSMは、ソースフィルタリングAPIをサポートし、オペレーティングシステムが適切なSFGMPをサポートするホストが使用できることに注意することが重要です。このセクションで説明したSFGMPの変更により、SSMが認識したホストでSSMの動作が改善されますが、SSMの使用のための厳格な前提条件ではありません。
The 232/8 IPv4 address range is currently allocated for SSM by IANA [IANA-ALLOCATION]. In IPv6, the FF3x::/32 range (where 'x' is a valid IPv6 multicast scope value) is reserved for SSM semantics [RFC3306], although today SSM allocations are restricted to FF3x::/96. ([SSM] has a more thorough discussion of this topic.) A host that knows the SSM address range and is capable of applying SSM semantics to it is described as an "SSM-aware" host.
232/8 IPv4アドレス範囲は現在、IANA [IANA-Allocation]によってSSMに割り当てられています。IPv6では、FF3X ::/32範囲（「X」は有効なIPv6マルチキャストスコープ値です）はSSMセマンティクス[RFC3306]に予約されていますが、今日のSSM割り当てはFF3X ::/96に制限されています。（[SSM]は、このトピックについてより徹底的な議論をしています。）SSMアドレス範囲を知っており、SSMセマンティクスを適用できるホストは、「SSMを認識する」ホストとして説明されています。
A host or router may be configured to apply SSM semantics to addresses other than those in the IANA-allocated range. The GMP module on a host or router SHOULD have a configuration option to set the SSM address range(s). If this configuration option exists, it MUST default to the IANA-allocated SSM range. The mechanism for setting this configuration option MUST at least allow for manual configuration. Protocol mechanisms to set this option may be defined in the future.
ホストまたはルーターは、IANAに割り当てられた範囲のアドレス以外のアドレスにSSMセマンティクスを適用するように構成できます。ホストまたはルーターのGMPモジュールには、SSMアドレス範囲を設定する構成オプションが必要です。この構成オプションが存在する場合、IANAに割り当てられたSSM範囲にデフォルトする必要があります。この構成オプションを設定するメカニズムは、少なくとも手動構成を可能にする必要があります。このオプションを設定するプロトコルメカニズムは、将来定義される場合があります。
If the host IP module of an SSM-aware host receives a non-source-specific request to receive multicast traffic sent to an SSM destination address, it SHOULD return an error to the application, as specified in [MSFAPI] (MODIFICATION). On a non-SSM-aware host, an application that uses the wrong API (e.g., "join(G)", "IPMulticastListen(G,EXCLUDE(S1))" for IGMPv3, or "IPv6MulticastListen(G,EXCLUDE(S2))" for MLDv2) to request delivery of packets sent to an SSM address will not receive the requested service, because an SSM-aware router (following the rules of this document) will refuse to process the request, and the application will receive no indication other than a failure to receive the requested traffic.
SSMを認識しているホストのホストIPモジュールが、SSM宛先アドレスに送信されたマルチキャストトラフィックを受信するための非ソース固有のリクエストを受信した場合、[MSFAPI]（修正）で指定されているように、アプリケーションにエラーを返す必要があります。非SSMに認識されているホストでは、間違ったAPIを使用するアプリケーション（例： "Join（g）"、 "ipmulticastlisten（g、exclude（s1））" "" ipv6multicastlisten（g、exclude（s2））の場合）「MLDV2の場合）SSMアドレスに送信されたパケットの配信をリクエストするには、SSMを認識したルーター（このドキュメントのルールに従う）がリクエストの処理を拒否し、アプリケーションが兆候を受け取らないため、要求されたサービスを受信しません。要求されたトラフィックを受け取らなかった以外。
This section defines the behavior of the SFGMP protocol module on an SSM-aware host, including two modifications to the protocols as described in [IGMPv3, MLDv2]. It also includes a number of clarifications of protocol operations. In doing so, it documents the behavior of an SSM-aware host with respect to sending and receiving the following GMP message types:
このセクションでは、[IGMPV3、MLDV2]で説明されているように、プロトコルの2つの変更を含む、SSMに認識されたホスト上のSFGMPプロトコルモジュールの動作を定義します。また、プロトコル操作の多くの説明も含まれています。そうすることで、次のGMPメッセージタイプを送信および受信することに関して、SSMを意識したホストの動作を文書化します。
- IGMPv1/v2 and MLDv1 Reports (2.2.1) - IGMPv3 and MLDv2 Reports (2.2.2) - IGMPv1 Queries, IGMPv2 and MLDv1 General Queries (2.2.3)
- IGMPV1/V2およびMLDV1レポート（2.2.1） - IgMPV3およびMLDV2レポート（2.2.2） - IGMPV1クエリ、IGMPV2およびMLDV1一般クエリ（2.2.3）
- IGMPv2 Leave and MLDv1 Done (2.2.4) - IGMPv2 and MLDv1 Group Specific Query (2.2.5) - IGMPv3 and MLDv2 Group Specific Query (2.2.6) - IGMPv3 and MLDv2 Group-and-Source Specific Query (2.2.7)
- IGMPV2休暇およびMLDV1 DONE（2.2.4）-IGMPV2およびMLDV1グループ固有のクエリ（2.2.5） - IGMPV3およびMLDV2群特定クエリ（2.2.6） - IGMPV3およびMLDV2グループおよびソース固有のクエリ（2.2.7）
An SSM-aware host operating according to [IGMPv3, MLDv2] could send an IGMPv1, IGMPv2, or MLDv1 report for an SSM address when it is operating in "older-version compatibility mode." This is an exceptional (error) condition, indicating that the router(s) cannot provide the SFGMP support needed for SSM, and an error is logged when the host enters compatibility mode for an SSM address, as described below. In this situation, it is likely that traffic sent to a channel (S,G) will not be delivered to a receiving host that has requested to receive channel (S,G).
[Igmpv3、MLDV2]に従って動作するSSM対応ホストは、「古いバージョン互換性モード」で動作しているときにSSMアドレスのIgMPv1、IgMPv2、またはMLDV1レポートを送信できます。これは例外的な（エラー）条件であり、ルーターがSSMに必要なSFGMPサポートを提供できないことを示し、以下に説明するように、ホストがSSMアドレスの互換性モードに入るとエラーが記録されます。この状況では、チャネル（s、g）に送信されるトラフィックは、チャネル（s、g）の受信を要求した受信ホストに配信されない可能性があります。
[IGMPv3] and [MLDv2] specify that a host MAY allow an older-version report to suppress its own IGMPv3 or MLDv2 Membership Record. An SSM-aware host, however, MUST NOT allow its report to be suppressed in this situation (MODIFICATION). Suppressing reports in this scenario would provide an avenue for an attacker to deny SSM service to other hosts on the link.
[IGMPV3]および[MLDV2]は、ホストが古いバージョンレポートで独自のIGMPV3またはMLDV2メンバーシップレコードを抑制できるようにすることを指定しています。ただし、SSMを認識しているホストは、この状況でレポートを抑制することを許可してはなりません（変更）。このシナリオでレポートを抑制すると、攻撃者がリンク上の他のホストへのSSMサービスを拒否する道が提供されます。
A host implementation may report more than one SSM channel in a single report either by including multiple sources within a group record or by including multiple group records.
ホストの実装は、グループレコード内に複数のソースを含めるか、複数のグループレコードを含めることにより、単一のレポートで複数のSSMチャネルをレポートする場合があります。
A Group Record for a source-specific destination address may (under normal operation) be any of the following types:
ソース固有の宛先アドレスのグループレコードは、（通常の操作中）次のタイプのいずれかである場合があります。
- MODE_IS_INCLUDE as part of a Current-State Record
- MODE_IS_INCLUDE現在の状態レコードの一部として
- ALLOW_NEW_SOURCES as part of a State-Change Record
- 状態変化レコードの一部としてlow_new_sources
- BLOCK_OLD_SOURCES as part of a State-Change Record
- State-Change Recordの一部としてBlock_old_Sources
A report may include both SSM destination addresses and non-source-specific, i.e., Any-Source Multicast (ASM) destination addresses, in the same message.
レポートには、SSM宛先アドレスと非ソース固有の、つまり、同じメッセージに任意のソースマルチキャスト（ASM）宛先アドレスの両方が含まれる場合があります。
Additionally, a CHANGE_TO_INCLUDE_MODE record may be sent by a host in some cases, for instance, when the SSM address range is changed through configuration. A router should process such a record according to the normal SFGMP rules.
さらに、SSMアドレス範囲が構成によって変更された場合、場合によっては、HostによってChange_To_include_modeレコードが送信される場合があります。ルーターは、通常のSFGMPルールに従ってそのようなレコードを処理する必要があります。
An SSM-aware host SHOULD NOT send any of the following record types for an SSM address.
SSM対応ホストは、SSMアドレスの次のレコードタイプのいずれかを送信しないでください。
- MODE_IS_EXCLUDE as part of a Current-State Record
- MODE_IS_EXCLUDE現在の状態レコードの一部として
- CHANGE_TO_EXCLUDE_MODE as part of a Filter-Mode-Change Record
- Filter-Mode-Changeレコードの一部として、Change_TO_EXCLUDE_MODE
This is a MODIFICATION to [IGMPv3, MLDv2], imposing a restriction on its use for SSM destination addresses. The rationale is that EXCLUDE mode does not apply to SSM addresses, and an SSM-aware router will ignore MODE_IS_EXCLUDE and CHANGE_TO_EXCLUDE_MODE requests in the SSM range, as described below.
これは[Igmpv3、MLDV2]の変更であり、SSM宛先アドレスへの使用に制限を課しています。理論的根拠は、除外モードがSSMアドレスに適用されず、SSMを意識したルーターは、以下に説明するように、SSM範囲でMODE_IS_EXCLUDEおよびCHANGE_TO_EXCLUDE_MODEリクエストを無視するということです。
If an IGMPv1 Query, or an IGMPv2 or MLDv1 General Query is received, the SFGMP protocol specifications require the host to revert to the older (IGMPv1, IGMPv2, or MLDv1) mode of operation on that interface. If this occurs, the host will stop reporting source-specific subscriptions on that interface and will start using IGMPv1, IGMPv2, or MLDv1 to report interest in all SSM destination addresses, unqualified by a source address. As a result, SSM semantics will no longer be applied to the multicast group address by the router.
IGMPV1クエリ、またはIGMPV2またはMLDV1一般クエリを受信した場合、SFGMPプロトコルの仕様では、そのインターフェイスの操作モードの操作モード（IGMPV1、IGMPV2、またはMLDV1）に戻る必要があります。これが発生した場合、ホストはそのインターフェイス上のソース固有のサブスクリプションの報告を停止し、IGMPV1、IGMPV2、またはMLDV1の使用を開始して、ソースアドレスによって資格のないすべてのSSM宛先アドレスの関心を報告します。その結果、SSMセマンティクスは、ルーターによるマルチキャストグループアドレスに適用されなくなります。
A router compliant with this document would never generate an IGMPv1, IGMPv2, or MLDv1 query for an address in the SSM range; thus, this situation only occurs either if the router is not SSM-aware, or if the host and the router disagree about the SSM address range (for instance, if they have inconsistent manual configurations).
このドキュメントに準拠したルーターは、SSM範囲のアドレスのIgMPv1、IgMPv2、またはMLDV1クエリを生成することはありません。したがって、この状況は、ルーターがSSMを認識していない場合、またはホストとルーターがSSMアドレス範囲について同意しない場合にのみ発生します（たとえば、一貫性のない手動構成がある場合）。
A host SHOULD log an error if it receives an IGMPv1, IGMPv2, or MLDv1 query for an SSM address (MODIFICATION).
SSMアドレスのIGMPV1、IGMPV2、またはMLDV1クエリを受信した場合、ホストはエラーを記録する必要があります（変更）。
In order to mitigate this problem, it must be administratively assured that all routers on a given shared-medium network are compliant with this document and are in agreement about the SSM address range.
この問題を軽減するには、特定の共有メディアネットワーク上のすべてのルーターがこのドキュメントに準拠しており、SSMアドレス範囲に同意していることが管理上保証されなければなりません。
IGMP Leave and MLD Done messages are not processed by hosts. IGMPv2 Leave and MLDv1 Done messages should not be sent for an SSM address, unless the sending host has reverted to older-version compatibility mode, with all the caveats described above.
IGMP休暇とMLD完了メッセージは、ホストによって処理されません。IGMPV2の残りおよびMLDV1 DONEメッセージは、上記のすべての警告を使用して、送信ホストが古いバージョン互換モードに戻っていない限り、SSMアドレスに対して送信されないでください。
If a host receives an IGMPv2 or MLDv1 Group Specific Query for an address in any configured source-specific range, it should process the query normally, as per [IGMPv3, MLDv2], even if the group queried is a source-specific destination address. The transmission of such a query likely indicates either that the sending router is not compliant with this document or that it is not configured with the same SSM address range(s) as the receiving host. A host SHOULD log an error in this case (MODIFICATION).
ホストが、構成されたソース固有の範囲のアドレスに対してIGMPV2またはMLDV1グループ固有のクエリを受信した場合、[IGMPV3、MLDV2]に従ってクエリを通常のように処理する必要があります。このようなクエリの送信は、送信ルーターがこのドキュメントに準拠していないか、受信ホストと同じSSMアドレス範囲で構成されていないことを示している可能性があります。ホストは、この場合にエラーを記録する必要があります（変更）。
If an SSM-aware host receives an SFGMP Group-Specific Query for an SSM address, it must respond with a report if the group matches the source-specific destination address of any of its subscribed source-specific channels, as specified in [IGMPv3, MLDv2].
SSMを認識しているホストがSSMアドレスのSFGMPグループ固有のクエリを受け取った場合、[IGMPV3、SOURCED固有のチャネルのソース固有の宛先アドレスとグループが[IGMPv3、]で指定されている場合、レポートで応答する必要があります。MLDV2]。
The rationale for this is that, although in the current SFGMP protocol specifications a router would have no reason to send one, the semantics of such a query are well-defined in this range and future implementations may have reason to send such a query. Be liberal in what you accept.
これの理論的根拠は、現在のSFGMPプロトコル仕様ではルーターが1つを送信する理由がないが、このようなクエリのセマンティクスはこの範囲で明確に定義されており、将来の実装にはそのようなクエリを送信する理由があるということです。あなたが受け入れるものでリベラルになりなさい。
An SFGMP router typically uses a Group-and-Source-Specific Query to query an SSM channel that a host has requested to leave via a BLOCK_OLD_SOURCES record. A host must respond to a Group-and-Source-Specific Query for which the group and source in the query match any channel for which the host has a subscription, as required by [IGMPv3, MLDv2]. The use of an SSM address does not change this behavior.
SFGMPルーターは通常、グループアンドソース固有のクエリを使用して、ホストがBlock_old_Sourcesレコードを介して出発するように要求したSSMチャネルを照会します。ホストは、[IGMPV3、MLDV2]で要求されるように、ホストのグループとソースがホストがサブスクリプションを持っているチャネルと一致するグループとソース固有のクエリに応答する必要があります。SSMアドレスを使用しても、この動作は変更されません。
A host must be able to process a query with multiple sources listed per group, again as required by [IGMPv3, MLDv2]. The use of an SSM address does not modify the behavior of the SFGMPs in this regard.
ホストは、[Igmpv3、MLDV2]で要求されているように、グループごとにリストされている複数のソースを使用してクエリを処理できる必要があります。SSMアドレスを使用しても、この点でSFGMPの動作は変更されません。
Routers must be aware of the SSM address range in order to provide the SSM service model. A router that knows the SSM address range and is capable of applying SSM semantics to it as described in this section is described as an "SSM-aware" router. An SSM-aware router MAY have a configuration option to apply SSM semantics to addresses other than the IANA-allocated range, but if such an option exists, it MUST default to the IANA-allocated range.
ルーターは、SSMサービスモデルを提供するために、SSMアドレス範囲を認識する必要があります。このセクションで説明されているように、SSMアドレスの範囲を知っており、SSMセマンティクスを適用できるルーターは、「SSM認識」ルーターとして説明されています。SSMを認識したルーターには、IANAに割り当てられた範囲以外のアドレスにSSMセマンティクスを適用する構成オプションがある場合がありますが、そのようなオプションが存在する場合は、IANAに割り当てられた範囲にデフォルトする必要があります。
This section documents the behavior of routers with respect to the following types of SFGMP messages for source-specific destination addresses:
このセクションでは、ソース固有の宛先アドレスの次のタイプのSFGMPメッセージに関するルーターの動作を文書化します。
- IGMPv3 and MLDv2 Reports (3.1) - IGMPv3 and MLDv2 General Query (3.2) - IGMPv3 and MLDv2 Group-Specific Query (3.3) - IGMPv3 and MLDv2 Group-and-Source Specific Query (3.4) - IGMPv1/v2 and MLDv1 Reports (3.5) - IGMPv1/v2 and MLDv1 Queries (3.6) - IGMPv2 Leave and MLDv1 Done (3.7)
- IgMPV3およびMLDV2レポート（3.1） - IgMPV3およびMLDV2一般クエリ（3.2） - IGMPV3およびMLDV2グループ特異的クエリ（3.3） - IGMPV3およびMLDV2グループおよびソース固有のクエリ（3.4）-IGMPV1/V2およびMLDV1レポート（3.5レポート（3.5））-IGMPV1/V2およびMLDV1クエリ（3.6）-IGMPV2のleaveおよびMLDV1 DONE（3.7）
SFGMP Reports are used to report source-specific subscriptions in the SSM address range. A router SHOULD ignore a group record of either of the following types if it refers to an SSM destination address:
SFGMPレポートは、SSMアドレス範囲のソース固有のサブスクリプションを報告するために使用されます。ルーターは、SSM宛先アドレスを参照する場合、次のタイプのいずれかのグループ記録を無視する必要があります。
- MODE_IS_EXCLUDE Current-State Record
- MODE_IS_EXCLUDE Current-Stateレコード
- CHANGE_TO_EXCLUDE_MODE Filter-Mode-Change Record
- change_to_exclude_modeフィルターモードチェンジレコード
A router MAY choose to log an error in either case. It MUST process any other group records within the same report. These behaviors are MODIFICATIONS to [IGMPv3, MLDv2] to prevent non-source-specific semantics from being applied to SSM addresses, and to avoid reverting to older-version compatibility mode.
ルーターは、どちらの場合でもエラーを記録することを選択できます。同じレポート内の他のグループレコードを処理する必要があります。これらの動作は、[IGMPV3、MLDV2]の修正であり、非ソース固有のセマンティクスがSSMアドレスに適用されるのを防ぎ、高齢化の互換性モードに戻ることを避けるためです。
A CHANGE_TO_INCLUDE_MODE Filter-Mode-Change Record is processed per the normal SFGMP rules; Section 2.2.2 describes a legitimate scenario when this could occur.
change_to_include_modeフィルター - モード変更レコードは、通常のSFGMPルールに従って処理されます。セクション2.2.2では、これが発生する可能性がある正当なシナリオについて説明します。
An SSM router sends periodic SFGMP General Queries as per the IGMPv3 and MLDv2 specifications. No change in behavior is required for SSM.
SSMルーターは、IGMPV3およびMLDV2の仕様に従って、定期的なSFGMP一般クエリを送信します。SSMには動作の変更は必要ありません。
SFGMP routers that support source-specific multicast may send group-specific queries for addresses in the source-specific range. This specification does not explicitly prohibit such a message, although, at the time of this writing, a router conformant to [IGMPv3, MLDv2] would not send one.
ソース固有のマルチキャストをサポートするSFGMPルーターは、ソース固有の範囲のアドレスのグループ固有のクエリを送信する場合があります。この仕様はそのようなメッセージを明示的に禁止していませんが、この執筆時点では、[Igmpv3、MLDV2]に適合するルーターは送信しません。
SFGMP Group-and-Source-Specific Queries are used when a receiver has indicated that it is no longer interested in receiving traffic from a particular (S,G) pair to determine if there are any remaining directly-attached hosts with interest in that (S,G) pair. Group-and-Source-Specific Queries are used within the source-specific address range when a router receives a BLOCK_OLD_SOURCES Record for one or more source-specific groups. These queries are sent normally, as per [IGMPv3, MLDv2].
SFGMPグループおよびソース固有のクエリは、受信者が特定の（s、g）ペアからトラフィックを受信することに関心がなくなったことを示している場合に使用されます。S、g）ペア。ルーターが1つ以上のソース固有のグループに対してblock_old_sourcesレコードを受信した場合、グループおよびソース固有のクエリは、ソース固有のアドレス範囲内で使用されます。これらのクエリは、[Igmpv3、MLDV2]に従って正常に送信されます。
An IGMPv1/v2 or MLDv1 report for an address in the source-specific range could be sent by a non-SSM-aware host. A router SHOULD ignore all such reports and specifically SHOULD NOT use them to establish IP forwarding state. This is a MODIFICATION to [IGMPv3, MLDv2]. A router MAY log an error if it receives such a report (also a MODIFICATION).
ソース固有の範囲のアドレスのIGMPV1/V2またはMLDV1レポートは、非SSM認識ホストによって送信できます。ルーターはそのようなすべてのレポートを無視する必要があり、具体的にはIP転送状態を確立するためにそれらを使用しないでください。これは[Igmpv3、MLDV2]の変更です。ルーターは、そのようなレポートを受信した場合にエラーを記録する場合があります（変更も変更されます）。
An SFGMP router that loses the querier election to a lower version router must log an error, as specified by [IGMPv3, MLDv2].
[igmpv3、mldv2]で指定されているように、より低いバージョンのルーターにクエリエの選挙を失うSFGMPルーターは、エラーを記録する必要があります。
An IGMPv2 Leave or MLDv1 Done message may be sent by a non-SSM-aware host. A router SHOULD ignore all such messages in the source-specific address range and MAY log an error (MODIFICATION).
IGMPV2の去り、またはMLDV1完了したメッセージは、非SSMに認識されたホストから送信される場合があります。ルーターは、ソース固有のアドレス範囲内のそのようなすべてのメッセージを無視し、エラー（変更）を記録する場合があります。
The specific protocol modifications described in this document are not known to create any security concerns that are not already present when IGMPv3 or MLDv2 is used with ASM-style multicast. The reader is referred to [SSM] for an analysis of SSM-specific security issues.
このドキュメントで説明されている特定のプロトコルの変更は、ASMスタイルのマルチキャストでIGMPV3またはMLDV2が使用されている場合、まだ存在しないセキュリティ上の懸念を作成することは知られていません。読者は、SSM固有のセキュリティ問題の分析のために[SSM]に紹介されます。
It is important that a router not accept non-source-specific reception requests for an SSM destination address. The rules of [IGMPv3] and [MLDv2] require a router, upon receiving such a membership report, to revert to earlier version compatibility mode for the group in question. If the router were to revert in this situation, it would prevent an IGMPv3-capable host from receiving SSM service for that destination address, thus creating a potential for an attacker to deny SSM service to other hosts on the same link.
ルーターがSSM宛先アドレスの非ソース固有の受信要求を受け入れないことが重要です。[IGMPV3]と[MLDV2]のルールは、そのようなメンバーシップレポートを受信する際に、問題のグループの以前のバージョン互換モードに戻るためにルーターを必要とします。この状況でルーターが戻る場合、IGMPV3対応のホストがその宛先アドレスのSSMサービスを受信することを防ぎ、攻撃者が同じリンクの他のホストにSSMサービスを拒否する可能性を生み出します。
The authors would like to thank Vince Laviano, Nidhi Bhaskar, Steve Deering, Toerless Eckert, and Pekka Savola for their input and careful review.
著者は、Vince Laviano、Nidhi Bhaskar、Steve Deering、Toerless Eckert、Pekka Savolaの入力と慎重なレビューに感謝します。
[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[Igmpv2] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、1997年11月。
[IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[Igmpv3] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[MSFAPI] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.
[MSFAPI] Thaler、D.、Fenner、B。、およびB. Quinn、「マルチキャストソースフィルターのソケットインターフェイス拡張機能」、RFC 3678、2004年1月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[SSM] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[SSM] Holbrook、H。およびB. Cain、「IPのソース固有のマルチキャスト」、RFC 4607、2006年8月。
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[MLDV2] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[IANA-ALLOC] Internet Assigned Numbers Authority, http://www.iana.org/assignments/multicast-addresses.
[IANA-Alloc]インターネットは、http://www.iana.org/assignments/multicast-addressesを割り当てました。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306] Haberman、B。およびD. Thaler、「Unicast-PrefixベースのIPv6マルチキャストアドレス」、RFC 3306、2002年8月。
Authors' Addresses
著者のアドレス
Hugh Holbrook Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303
Hugh Holbrook Arastra、Inc。P.O.Box 10905 Palo Alto、CA 94303
Phone: +1 650 331-1620
EMail: holbrook@arastra.com
Brad Cain Acopia Networks
Brad Cain Acopia Networks
EMail: bcain99@gmail.com
Brian Haberman Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099
ブライアンハーバーマンジョンズホプキンス大学応用物理学ラボ11100ジョンズホプキンスロードローレル、メリーランド20723-6099
EMail: brian@innovationslab.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。