RFC 4604 - Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast 日本語訳

URL : https://tools.ietf.org/html/rfc4604
タイトル : RFC 4604 - 使用するインターネットグループ管理プロトコルバージョン3（IGMPv3の）およびマルチキャストリスナ発見プロトコルバージョン2（MLDv2の）ソース固有のマルチキャストのための
翻訳編集 : 自動生成

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

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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（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の仕様を更新します。

1. Introduction

1. はじめに

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の仕様を更新します。

1.1. Terminology

1.1. 用語

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の]）を変更し、この文書の一部を強調するために、任意のプロトコルの変更は、タグ「修飾」とマークされています。

2. Host Requirements for Source-Specific Multicast

ソース固有のマルチキャスト2.ホスト要件

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対応の」ホストの概念を定義し、APIの要件とSSM対応のホストのSFGMPプロトコル要件を記述するために行きます。 SSMは、オペレーティングシステムの適切なSFGMPをサポートしているソースフィルタリングAPIとをサポートする任意のホストで使用できることに注目することが重要です。このセクションで説明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割り当て]でSSMに割り当てられます。今日SSM配分をFF3x :: / 96に制限されているがIPv6では、（X '' は有効なIPv6マルチキャストスコープ値である）FF3x :: / 32の範囲は、SSM意味論[RFC3306]のために予約されています。（[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アドレスの範囲（複数可）を設定するための設定オプションを持つべきである（SHOULD）。この設定オプションが存在する場合は、IANA割り当てSSM範囲をデフォルトとしなければなりません。この設定オプションを設定するためのメカニズムは、少なくとも手動構成を考慮しなければなりません。このオプションを設定するためのプロトコルメカニズムは、将来的に定義されてもよいです。

2.1. API Requirements

2.1. APIの要件

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を使用するアプリケーション（オン例えば、 "参加（G）"、 "IPMulticastListen（Gは、EXCLUDE（S1））" IGMPv3のために、または「IPv6MulticastListen（Gは、EXCLUDE（S2））」のMLDv2用）（）この文書のルール以下のSSM対応のルータが要求を処理することを拒否し、アプリケーションが兆候を受信しませんので、SSMアドレスに送信されたパケットの配信は、要求されたサービスを受信しません要求します故障以外は、要求されたトラフィックを受信します。

2.2. GMP Requirements

2.2. GMPの要件

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 LeaveとのMLDv1（2.2.4） - IGMPv2のとのMLDv1グループ固有のクエリー（2.2.5） - のIGMPv3およびMLDv2のグループ固有のクエリー（2.2.6） - のIGMPv3およびMLDv2のグループおよびソース特定照会（2.2.7 ）

2.2.1. IGMPv1/v2 and MLDv1 Reports

2.2.1. IGMPv1 / v2とのMLDv1レポート

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サービスを拒否するための手段を提供することになります。

2.2.2. IGMPv3 and MLDv2 Reports

2.2.2. IGMPv3およびMLDv2のレポート

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

- 状態変化記録の一部としてALLOW_NEW_SOURCES

- BLOCK_OLD_SOURCES as part of a 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.

また、CHANGE_TO_INCLUDE_MODEレコードは、SSMアドレス範囲を構成によって変更された場合、例えば、いくつかのケースでは、ホストによって送信されてもよいです。ルータは、通常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

- フィルタ - モード変更レコードの一部として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.

これは、SSM宛先アドレスのためのその使用に制限を課し、[IGMPv3の、MLDv2の]の変形です。根拠は、モードがSSMアドレスには適用されませんEXCLUDE、下記のようにSSM対応のルータは、SSM範囲でMODE_IS_EXCLUDEとCHANGE_TO_EXCLUDE_MODE要求を無視することです。

2.2.3. IGMPv1 Queries, IGMPv2 and MLDv1 General Queries

2.2.3. IGMPv1レポートクエリ、IGMPv2のとのMLDv1一般的なクエリ

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）モードに戻すためにホストが必要です。この問題が発生した場合、ホストは送信元アドレスによって修飾されていない、そのインターフェイス上でソース固有のサブスクリプションを報告停止し、すべてのSSMの宛先アドレスへの関心を報告するのIGMPv1、IGMPv2の、またはのMLDv1の使用を開始します。その結果、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アドレスの範囲について合意していることを保証しなければなりません。

2.2.4. IGMPv2 Leave and MLDv1 Done

2.2.4. IGMPv2のままとのMLDv1が完了します

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を実行されたメッセージは、SSMアドレスに送るべきではありません。

2.2.5. IGMPv2 and MLDv1 Group Specific Query

2.2.5. IGMPv2のとのMLDv1グループ固有のクエリー

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アドレス範囲（S）で構成されていないこと。ホストは、この場合（変形例）でエラーをログに記録します。

2.2.6. IGMPv3 and MLDv2 Group-Specific Query

2.2.6. IGMPv3およびMLDv2のグループ固有のクエリー

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の中に指定されているように、報告書に応答しなければなりません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つを送信する理由がないであろうが、このようなクエリの意味論がこの範囲内に明確に定義されており、将来の実装は、このようなクエリを送信する理由を有していてもよい、ということです。あなたが受け入れるものにリベラルう。

2.2.7. IGMPv3 and MLDv2 Group-and-Source-Specific Query

2.2.7. IGMPv3およびMLDv2のグループと-ソース固有のクエリ

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アドレスの使用は、この点でSFGMPsの動作を変更しません。

3. Router Requirements for Source-Specific Multicast

ソース固有のマルチキャストのための3ルータの要件

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） - のIGMPv1 / v2とのMLDv1クエリー（3.6） - IGMPv2の脱退とのMLDv1完了（3.7）

3.1. IGMPv3 and MLDv2 Reports

3.1. IGMPv3およびMLDv2のレポート

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現在のステートを記録

- 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.

ルータは、いずれの場合にエラーをログに記録するように選ぶかもしれません。これは、同じレポート内の他のグループのレコードを処理しなければなりません。これらの動作は、SSMアドレスに適用されることから、非ソース固有のセマンティクスを防ぐために、より古いバージョンの互換性モードに戻ることを避けるために[IGMPv3の、MLDv2の]への変更です。

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項では、これが発生する可能性が合法的なシナリオについて説明します。

3.2. IGMPv3 and MLDv2 General Queries

3.2. IGMPv3およびMLDv2の一般的なクエリ

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のために必要とされません。

3.3. IGMPv3 and MLDv2 Group-Specific Queries

3.3. IGMPv3およびMLDv2のグループ固有のクエリー

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の]に準拠ルータが1を送信しません、が、この仕様は、明示的に、そのようなメッセージを禁止するものではありません。

3.4. IGMPv3 and MLDv2 Group-and-Source-Specific Queries

3.4. 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の]ごとに、正常に送信されます。

3.5. IGMPv1/v2 and MLDv1 Reports

3.5. IGMPv1 / v2とのMLDv1レポート

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の]の変形です。それは、このような報告書（も修正を）受信した場合、ルータはエラーを記録することがあります。

3.6. IGMPv1/v2 and MLDv1 Queries

3.6. IGMPv1 / v2とのMLDv1クエリー

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ルータは、エラーを記録しなければなりません。

3.7. IGMPv2 Leave and MLDv1 Done

3.7. IGMPv2のままとのMLDv1が完了します

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 Doneメッセージは、非SSM対応のホストによって送信することができます。ルータは、送信元固有のアドレス範囲内のすべてのそのようなメッセージを無視するべきであり、エラー（変形例）をログインすることができます。

4. Security Considerations

4.セキュリティについての考慮事項

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.

この文書に記載された特定のプロトコルの変更はのIGMPv3またはMLDv2のがASM形式のマルチキャストで使用する場合、既に存在していない任意のセキュリティ上の問題を作成するために知られていません。読者は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]のルールは、問題の基のために、以前のバージョンの互換性モードに戻すには、そのようなメンバシップレポートを受信すると、ルータを必要とします。ルータがこのような状況に戻すとしたら、それはこのように同じリンク上の他のホストにSSMサービスを否定する攻撃の可能性を作成し、その宛先アドレスのSSMサービスを受けてからのIGMPv3対応のホストを防止するであろう。

5. Acknowledgements

5.謝辞

The authors would like to thank Vince Laviano, Nidhi Bhaskar, Steve Deering, Toerless Eckert, and Pekka Savola for their input and careful review.

作者は彼らの入力と慎重な審査のためヴィンスLaviano、Nidhi Bhaskar、スティーブデアリング、Toerlessエッカート、およびペッカSavolaに感謝したいと思います。

6. Normative References

6.引用規格

[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.

[IGMPv2の]フェナー、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の]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、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]ターラー、D.、フェナー、B.、およびB.クイン、 "マルチキャストソースフィルタのためのソケットインタフェース拡張"、RFC 3678、2004年1月。

[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.

[RFC1112]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、1989年8月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[SSM] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.

[SSM]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有のマルチキャスト"、RFC 4607、2006年8月。

[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

[のMLDv2]ヴィーダ、R.とL.コスタ、 "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]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "IPv6のためのマルチキャストリスナー発見（MLD）"、RFC 2710、1999年10月。

8. Informative References

8.参考文献

[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]ハーバーマン、B.とD.ターラー、 "ユニキャストプレフィックスベースのIPv6マルチキャストアドレス"、RFC 3306、2002年8月。

Authors' Addresses

著者のアドレス

Hugh Holbrook Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303

ヒュー・ホルブルックArastra、株式会社私書箱ボックス10905パロアルト、CA 94303

Phone: +1 650 331-1620 EMail: holbrook@arastra.com

電話：+1 650 331-1620 Eメール：holbrook@arastra.com

Brad Cain Acopia Networks

ブラッドカインAcopia Networksの

EMail: bcain99@gmail.com

メールアドレス：bcain99@gmail.com

Brian Haberman Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099

ブライアンハーバーマンジョンズ・ホプキンス大学応用物理研究所11100ジョンズホプキンスロードローレル、MD 20723から6099

EMail: brian@innovationslab.net

メールアドレス：brian@innovationslab.net

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。