[要約] RFC 4605は、IGMP/MLDプロキシングに関する仕様であり、マルチキャストリスナーの発見と転送をサポートします。目的は、ネットワーク上のマルチキャストトラフィックの効率的な転送を可能にすることです。
Network Working Group B. Fenner
Request for Comments: 4605 AT&T Research
Category: Standards Track H. He
Nortel
B. Haberman
JHU-APL
H. Sandick
Little River Elementary School
August 2006
Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")
インターネットグループ管理プロトコル（IGMP） /マルチキャストリスナーディスカバリー（MLD）ベースのマルチキャスト転送（「IGMP / MLDプロキシ」）
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
概要
In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient for a device to learn and proxy group membership information and simply forward multicast packets based upon that information. This document describes a mechanism for forwarding based solely upon Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) membership information.
特定のトポロジでは、マルチキャストルーティングプロトコルを実行する必要はありません。デバイスがグループメンバーシップ情報を学習およびプロキシし、その情報に基づいてマルチキャストパケットを単純に転送するだけで十分です。このドキュメントでは、インターネットグループ管理プロトコル（IGMP）またはマルチキャストリスナーディスカバリー（MLD）メンバーシップ情報のみに基づいて転送のメカニズムについて説明します。
This document applies spanning tree multicast routing [MCAST] to an Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD)-only environment. The topology is limited to a tree, since we specify no protocol to build a spanning tree over a more complex topology. The root of the tree is assumed to be connected to a wider multicast infrastructure.
このドキュメントは、スパニングツリーマルチキャストルーティング[MCAST]をインターネットグループ管理プロトコル（IGMP）またはマルチキャストリスナーディスカバリー（MLD）の環境に適用します。トポロジーは、より複雑なトポロジの上にスパニングツリーを構築するプロトコルを指定していないため、ツリーに限定されています。ツリーのルートは、より広いマルチキャストインフラストラクチャに接続されていると想定されています。
In a simple tree topology, it is not necessary to run a multicast routing protocol. It is sufficient to learn and proxy group membership information and simply forward multicast packets based upon that information. One typical example of such a tree topology can be found on an edge aggregation box such as a Digital Subscriber Line Access Multiplexer (DSLAM). In most deployment scenarios, an edge box has only one connection to the core network side and has many connections to the customer side.
単純なツリートポロジでは、マルチキャストルーティングプロトコルを実行する必要はありません。グループメンバーシップ情報を学習およびプロキシし、その情報に基づいてマルチキャストパケットを転送するだけで十分です。このようなツリートポロジの典型的な例の1つは、デジタルサブスクライバーラインアクセスマルチプレクサ（DSLAM）などのエッジ集約ボックスにあります。ほとんどの展開シナリオでは、エッジボックスにはコアネットワーク側への接続が1つしかなく、顧客側に多くの接続があります。
Using IGMP/MLD-based forwarding to replicate multicast traffic on devices such as the edge boxes can greatly simplify the design and implementation of those devices. By not supporting more complicated multicast routing protocols such as Protocol Independent Multicast (PIM) or Distance Vector Multicast Routing Protocol (DVMRP), it reduces not only the cost of the devices but also the operational overhead. Another advantage is that it makes the proxy devices independent of the multicast routing protocol used by the core network routers. Hence, proxy devices can be easily deployed in any multicast network.
IGMP/MLDベースの転送を使用して、エッジボックスなどのデバイスでマルチキャストトラフィックを複製すると、これらのデバイスの設計と実装を大幅に簡素化できます。プロトコル独立マルチキャスト（PIM）や距離ベクトルマルチキャストルーティングプロトコル（DVMRP）などのより複雑なマルチキャストルーティングプロトコルをサポートしないことにより、デバイスのコストだけでなく、運用オーバーヘッドも削減します。もう1つの利点は、コアネットワークルーターが使用するマルチキャストルーティングプロトコルとは独立してプロキシデバイスを作ることです。したがって、プロキシデバイスは、マルチキャストネットワークに簡単に展開できます。
Robustness in an edge box is usually achieved by using a hot spare connection to the core network. When the first connection fails, the edge box fails over to the second connection. IGMP/MLD-based forwarding can benefit from such a mechanism and use the spare connection for its redundant or backup connection to multicast routers. When an edge box fails over to the second connection, the proxy upstream connection can also be updated to the new connection.
エッジボックスの堅牢性は、通常、コアネットワークへのホットスペア接続を使用することで実現されます。最初の接続が失敗すると、エッジボックスが2番目の接続に失敗します。IGMP/MLDベースの転送は、このようなメカニズムの恩恵を受け、マルチキャストルーターへの冗長またはバックアップ接続に予備接続を使用できます。エッジボックスが2番目の接続に失敗すると、プロキシアップストリーム接続を新しい接続に更新することもできます。
The IGMP/MLD-based forwarding only works in a simple tree topology. The tree must be manually configured by designating upstream and downstream interfaces on each proxy device. In addition, the IP addressing scheme applied to the proxying tree topology SHOULD be configured to ensure that a proxy device can win the IGMP/MLD Querier election to be able to forward multicast traffic. There are no other multicast routers except the proxy devices within the tree, and the root of the tree is expected to be connected to a wider multicast infrastructure. This protocol is limited to a single administrative domain.
IGMP/MLDベースの転送は、単純なツリートポロジでのみ機能します。ツリーは、各プロキシデバイスに上流および下流のインターフェイスを指定して手動で構成する必要があります。さらに、プロキシツリートポロジに適用されるIPアドレス指定スキームは、プロキシデバイスがIGMP/MLDクエリエの選挙に勝ち、マルチキャストトラフィックを転送できるように設定する必要があります。ツリー内のプロキシデバイスを除いて、他のマルチキャストルーターはありません。ツリーのルートは、より広いマルチキャストインフラストラクチャに接続されると予想されます。このプロトコルは、単一の管理ドメインに限定されています。
In more complicated scenarios where the topology is not a tree, a more robust failover mechanism is desired, or more than one administrative domain is involved, a multicast routing protocol should be used.
トポロジがツリーではない、より堅牢なフェイルオーバーメカニズムが望まれる、または複数の管理ドメインが関与する、より複雑なシナリオでは、マルチキャストルーティングプロトコルを使用する必要があります。
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]で説明されているように解釈されます。
This document is a product of the Multicast & Anycast Group Membership (MAGMA) working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at magma@ietf.org and/or the authors.
このドキュメントは、インターネットエンジニアリングタスクフォース内のマルチキャスト＆Anycastグループメンバーシップ（MAGMA）ワーキンググループの製品です。コメントが求められており、Magma@ietf.orgおよび/または著者のワーキンググループのメーリングリストに宛ててください。
A proxy device's interface in the direction of the root of the tree. Also called the "Host interface".
ツリーのルートの方向にあるプロキシデバイスのインターフェイス。「ホストインターフェイス」とも呼ばれます。
Each of a proxy device's interfaces that is not in the direction of the root of the tree. Also called the "Router interfaces".
ツリーのルートの方向にないプロキシデバイスの各インターフェイス。「ルーターインターフェイス」とも呼ばれます。
In IPv4 environments, for each multicast group, a group is in IGMP version 1 (IGMPv1) [RFC1112] mode if an IGMPv1 report is heard. A group is in IGMP version 2 (IGMPv2) [RFC2236] mode if an IGMPv2 report is heard but no IGMPv1 report is heard. A group is in IGMP version 3 (IGMPv3) [RFC3376] mode if an IGMPv3 report is heard but no IGMPv1 or IGMPv2 report is heard.
IPv4環境では、各マルチキャストグループについて、グループはIGMPV1レポートが聞こえる場合、IGMPバージョン1（IGMPV1）[RFC1112]モードにあります。グループはIGMPバージョン2（IGMPV2）[RFC2236]モードIGMPV2レポートが聞こえますが、IGMPV1レポートが聞こえない場合。グループはIGMPバージョン3（IGMPV3）[RFC3376]モードIGMPV3レポートが聞こえますが、IGMPV1またはIGMPV2レポートが聞こえない場合。
In IPv6 environments, for each multicast group, a group is in MLD version 1 (MLDv1) [RFC2710] mode if an MLDv1 report is heard. MLDv1 is equivalent to IGMPv2. A group is in MLD version 2 (MLDv2) [MLDv2] mode if an MLDv2 report is heard but no MLDv1 report is heard. MLDv2 is equivalent to IGMPv3.
IPv6環境では、各マルチキャストグループについて、MLDV1レポートが聞こえる場合、グループはMLDバージョン1（MLDV1）[RFC2710]モードにあります。MLDV1はIgMPv2に相当します。グループは、MLDV2レポートが聞こえますが、MLDV1レポートが聞こえない場合、MLDバージョン2（MLDV2）[MLDV2]モードにあります。MLDV2はIgMPv3と同等です。
When a group is in IGMPv1 or IGMPv2/MLDv1 mode, the subscription is a group membership on an interface. When a group is in IGMPv3/MLDv2 mode, the subscription is an IGMPv3/MLDv2 state entry, i.e., a (multicast address, group timer, filter-mode, source-element list) tuple, on an interface.
グループがIGMPV1またはIGMPV2/MLDV1モードにある場合、サブスクリプションはインターフェイスのグループメンバーシップです。グループがIGMPV3/MLDV2モードにある場合、サブスクリプションはIGMPV3/MLDV2状態のエントリ、つまり（マルチキャストアドレス、グループタイマー、フィルターモード、ソースエレメントリスト）インターフェイス上のTupleです。
The database maintained at each proxy device into which the membership information of each of its downstream interfaces is merged. The membership database is a set of membership records of the form:
データベースは、下流の各インターフェイスのメンバーシップ情報がマージされる各プロキシデバイスで維持されます。メンバーシップデータベースは、フォームのメンバーシップレコードのセットです。
(multicast-address, filter-mode, source-list)
（マルチキャストアドレス、フィルターモード、ソースリスト）
Please refer to IGMPv3/MLDv2 [RFC3376, MLDv2] specifications for the definition of the fields "filter-mode" and "source-list". The operational behaviors of the membership database is defined in section 4.1.
IGMPV3/MLDV2 [RFC3376、MLDV2]を参照してください。フィールド「フィルターモード」および「ソースリスト」の定義の仕様を参照してください。メンバーシップデータベースの運用行動は、セクション4.1で定義されています。
A proxy device performing IGMP/MLD-based forwarding has a single upstream interface and one or more downstream interfaces. These designations are explicitly configured; there is no protocol to determine what type each interface is. It performs the router portion of the IGMP [RFC1112, RFC2236, RFC3376] or MLD [RFC2710, MLDv2] protocol on its downstream interfaces, and the host portion of IGMP/MLD on its upstream interface. The proxy device MUST NOT perform the router portion of IGMP/MLD on its upstream interface.
IGMP/MLDベースの転送を実行するプロキシデバイスには、単一のアップストリームインターフェイスと1つ以上の下流インターフェイスがあります。これらの指定は明示的に構成されています。各インターフェイスのタイプを決定するプロトコルはありません。IGMP [RFC1112、RFC2236、RFC3376]またはMLD [RFC2710、MLDV2]プロトコルの下流インターフェイスのルーター部分、および上流インターフェイスでIGMP/MLDのホスト部分を実行します。プロキシデバイスは、上流インターフェイスでIGMP/MLDのルーター部分を実行してはなりません。
The proxy device maintains a database consisting of the merger of all subscriptions on any downstream interface. Refer to Section 4 for the details about the construction and maintenance of the membership database.
プロキシデバイスは、ダウンストリームインターフェイス上のすべてのサブスクリプションの合併で構成されるデータベースを維持しています。メンバーシップデータベースの構築とメンテナンスの詳細については、セクション4を参照してください。
The proxy device sends IGMP/MLD membership reports on the upstream interface when queried and sends unsolicited reports or leaves when the database changes.
プロキシデバイスは、Queried時に上流インターフェイスにIGMP/MLDメンバーシップレポートを送信し、データベースが変更されたときに未承諾レポートまたは去ることを送信します。
When the proxy device receives a packet destined for a multicast group (channel in Source-Specific Multicast (SSM)), it uses a list consisting of the upstream interface and any downstream interface that has a subscription pertaining to this packet and on which it is the IGMP/MLD Querier. This list may be built dynamically or cached. It removes the interface on which this packet arrived from the list and forwards the packet to the remaining interfaces (this may include the upstream interface).
プロキシデバイスがマルチキャストグループ（ソース固有のマルチキャスト（SSM）のチャネル）専用のパケットを受信すると、アップストリームインターフェイスと、このパケットに関するサブスクリプションを持つ下流インターフェイスで構成されるリストを使用します。IGMP/MLDクエリエ。このリストは、動的に構築されたり、キャッシュされたりできます。このパケットがリストから到着したインターフェイスを削除し、パケットを残りのインターフェイスに転送します（これにはアップストリームインターフェイスが含まれる場合があります）。
Note that the rule that a proxy device must be the querier in order to forward packets restricts the IP addressing scheme used; in particular, the IGMP/MLD-based forwarding devices must be given the lowest IP addresses of any potential IGMP/MLD Querier on the link, in order to win the IGMP/MLD Querier election. IGMP/MLD Querier election rule defines that the Querier that has the lowest IP address wins the election. (The IGMP/MLD Querier election rule is defined in IGMP/MLD specifications as part of the IGMP/MLD behavior.) So in an IGMP/MLD-based forwarding-only environment, if non-proxy device wins the IGMP/MLD Querier election, no packets will flow.
パケットを転送するためにプロキシデバイスがクエリエでなければならないというルールは、使用されるIPアドレス指定スキームを制限することに注意してください。特に、IGMP/MLDクエリエの選挙に勝つために、IGMP/MLDベースの転送デバイスには、リンク上の潜在的なIGMP/MLDクエリエの最低IPアドレスをリンク上の最低のIPアドレスに与えなければなりません。IGMP/MLDクエリエの選挙規則は、最低のIPアドレスを持っているクエリエが選挙に勝つことを定義しています。（IGMP/MLD Querier選挙規則は、IGMP/MLDの動作の一部としてIGMP/MLD仕様で定義されています。）IGMP/MLDベースの転送のみの環境では、非プロキシデバイスがIGMP/MLDクエリエの選挙で勝つ場合、パケットが流れません。
For example, the figure below shows an IGMP/MLD-based forwarding-only environment:
たとえば、以下の図は、IGMP/MLDベースの転送のみの環境を示しています。
LAN 1 --------------------------------------
Upstream | | Upstream
A(non-proxy) B(proxy)
Downstream |(lowest IP) | Downstream
LAN 2 --------------------------------------
Device A has the lowest IP address on LAN 2, but it is not a proxy device. According to IGMP/MLD Querier election rule, A will win the election on LAN 2 since it has the lowest IP address. Device B will not forward traffic to LAN 2 since it is not the querier on LAN 2.
デバイスAはLAN 2で最も低いIPアドレスを持っていますが、プロキシデバイスではありません。IGMP/MLD Querierの選挙規則によると、IPアドレスが最も低いため、LAN 2での選挙に勝ちます。デバイスBは、LAN 2のクエリエではないため、トラフィックをLAN 2に転送しません。
The election of a single forwarding proxy is necessary to avoid local loops and redundant traffic for links that are considered downstream links by multiple IGMP/MLD-based forwarders. This rule "piggy-backs" forwarder election on IGMP/MLD Querier election. The use of the IGMP/MLD Querier election process to choose the forwarding proxy delivers similar functionality on the local link as the PIM Assert mechanism. On a link with only one IGMP/MLD-based forwarding device, this rule MAY be disabled (i.e., the device MAY be configured to forward packets to an interface on which it is not the querier). However, the default configuration MUST include the querier rule, for example, for redundancy purposes, as shown in the figure below:
単一の転送プロキシの選出は、複数のIGMP/MLDベースのフォワーダーによって下流のリンクと見なされるリンクのローカルループと冗長トラフィックを回避するために必要です。この規則は、IGMP/MLD Querier選挙に関する「Piggy-Backs」フォワーダー選挙。IGMP/MLDクエリエの選挙プロセスを使用して、PIMアサートメカニズムとしてローカルリンク上で同様の機能を提供する転送プロキシを選択します。IGMP/MLDベースの転送デバイスが1つだけのリンクで、このルールは無効になる場合があります（つまり、デバイスは、クエリエではないインターフェイスに転送するように設定されます）。ただし、デフォルトの構成には、以下の図に示すように、冗長性の目的など、クエリエルールを含める必要があります。
LAN 1 --------------------------------------
Upstream | | Upstream
A B
Downstream | | Downstream
LAN 2 --------------------------------------
LAN 2 can have two proxy devices, A and B. In such a configuration, one proxy device must be elected to forward the packets. This document requires that the forwarder must be the IGMP/MLD querier. So proxy device A will forward packets to LAN 2 only if A is the querier. In the above figure, if A is the only proxy device, A can be configured to forward packets even though B is the querier.
LAN 2には、AとBの2つのプロキシデバイスを持つことができます。このような構成では、パケットを転送するために1つのプロキシデバイスを選択する必要があります。このドキュメントでは、フォワーダーがIGMP/MLDクエリエである必要があります。したがって、プロキシデバイスAは、Aがクエリエである場合にのみ、LAN 2にパケットを転送します。上記の図では、Aが唯一のプロキシデバイスである場合、Bはクエリエであるにもかかわらず、Aを転送するように構成できます。
Note that this does not protect against an "upstream loop". For example, see the figure below:
これは「上流のループ」から保護しないことに注意してください。たとえば、以下の図を参照してください。
LAN 1 --------------------------------------
Upstream | | Downstream
A B
Downstream | | Upstream
LAN 2 --------------------------------------
B will unconditionally forward packets from LAN 1 to LAN 2, and A will unconditionally forward packets from LAN 2 to LAN 1. This will cause an upstream loop. A multicast routing protocol that employs a tree building algorithm is required to resolve loops like this.
Bは、LAN 1からLAN 2に無条件にパケットを転送し、AはLAN 2からLAN 1に無条件にパケットを転送します。これにより、上流のループが発生します。このようなループを解決するには、ツリービルディングアルゴリズムを使用するマルチキャストルーティングプロトコルが必要です。
This specification describes a protocol that works only in a simple tree topology. The tree must be manually configured by designating upstream and downstream interfaces on each proxy device, and the root of the tree is expected to be connected to a wider multicast infrastructure.
この仕様は、単純なツリートポロジでのみ機能するプロトコルについて説明します。ツリーは、各プロキシデバイスに上流と下流のインターフェイスを指定して手動で構成する必要があり、ツリーのルートはより広いマルチキャストインフラストラクチャに接続されると予想されます。
In order for senders to send from inside the proxy tree, all traffic is forwarded towards the root. The multicast router(s) connected to the wider multicast infrastructure should be configured to treat all systems inside the proxy tree as though they were directly connected; e.g., for Protocol Independent Multicast - Sparse Mode (PIM-SM) [PIM-SM], these routers should Register-encapsulate traffic from new sources within the proxy tree just as they would directly-connected sources.
送信者がプロキシツリー内から送信するために、すべてのトラフィックがルートに向かって転送されます。より広いマルチキャストインフラストラクチャに接続されたマルチキャストルーターは、プロキシツリー内のすべてのシステムを直接接続されているかのように構成するように構成する必要があります。たとえば、プロトコル独立マルチキャスト - スパースモード（PIM-SM）[PIM-SM]の場合、これらのルーターは、直接接続されたソースと同様に、プロキシツリー内の新しいソースからトラフィックを登録する必要があります。
This information is likely to be manually configured; IGMP/MLD-based multicast forwarding provides no way for the routers upstream of the proxy tree to know what networks are connected to the proxy tree. If the proxy topology is congruent with some routing topology, this information MAY be learned from the routing protocol running on the topology; e.g., a router may be configured to treat multicast packets from all prefixes learned from routing protocol X via interface Y as though they were from a directly connected system.
この情報は手動で構成される可能性があります。IGMP/MLDベースのマルチキャスト転送は、プロキシツリーの上流のルーターがどのネットワークがプロキシツリーに接続されているかを知る方法を提供しません。プロキシトポロジがいくつかのルーティングトポロジーと一致している場合、この情報はトポロジで実行されているルーティングプロトコルから学ぶことができます。たとえば、ルーティングプロトコルXから学習したすべてのプレフィックスから、直接接続されたシステムからのように、ルーティングプロトコルXから学習したすべてのプレフィックスからマルチキャストパケットを処理するようにルーターを構成することができます。
This section describes an IGMP/MLD-based multicast forwarding device's actions in more detail.
このセクションでは、IGMP/MLDベースのマルチキャスト転送デバイスのアクションについて詳しく説明します。
The proxy device performs the router portion of the IGMP/MLD protocol on each downstream interface. For each interface, the version of IGMP/MLD used is explicitly configured and defaults to the highest version supported by the system.
プロキシデバイスは、各下流インターフェイスでIGMP/MLDプロトコルのルーター部分を実行します。各インターフェイスについて、使用されているIGMP/MLDのバージョンは明示的に構成され、デフォルトはシステムでサポートされている最高バージョンになります。
The output of this protocol is a set of subscriptions; this set is maintained separately on each downstream interface. In addition, the subscriptions on each downstream interface are merged into the membership database.
このプロトコルの出力は、サブスクリプションのセットです。このセットは、各ダウンストリームインターフェイスで個別に維持されます。さらに、各下流インターフェイスのサブスクリプションは、メンバーシップデータベースにマージされます。
The membership database is a set of membership records of the form:
メンバーシップデータベースは、フォームのメンバーシップレコードのセットです。
(multicast-address, filter-mode, source-list)
（マルチキャストアドレス、フィルターモード、ソースリスト）
Each record is the result of the merge of all subscriptions for that record's multicast-address on downstream interfaces. If some subscriptions are IGMPv1 or IGMPv2/MLDv1 subscriptions, these subscriptions are converted to IGMPv3/MLDv2 subscriptions. The IGMPv3/MLDv2 and the converted subscriptions are first preprocessed to remove the timers in the subscriptions and, if the filter mode is EXCLUDE, to remove every source whose source timer > 0. Then the preprocessed subscriptions are merged using the merging rules for multiple memberships on a single interface (specified in Section 3.2 of the IGMPv3 specification [RFC3376] and in Section 4.2 of the MLDv2 specification [MLDv2]) to create the membership record. For example, there are two downstream interfaces, I1 and I2, that have subscriptions for multicast address G. I1 has an IGMPv2/MLDv1 subscription that is (G). I2 has an IGMPv3/MLDv2 subscription that has membership information (G, INCLUDE, (S1, S2)). The I1's subscription is converted to an IGMPv3/MLDv2 subscription that has membership information (G, EXCLUDE, NULL). Then the subscriptions are preprocessed and merged, and the final membership record is (G, EXCLUDE, NULL).
各レコードは、そのレコードの下流インターフェイスでのマルチキャストアドレスのすべてのサブスクリプションのマージの結果です。一部のサブスクリプションがIGMPV1またはIGMPV2/MLDV1サブスクリプションの場合、これらのサブスクリプションはIGMPV3/MLDV2サブスクリプションに変換されます。IGMPV3/MLDV2および変換されたサブスクリプションは、最初にサブスクリプションのタイマーを除去するために前処理され、フィルターモードが除外されている場合、ソースタイマー> 0を除去するすべてのソースを削除します。単一のインターフェイス（IGMPV3仕様[RFC3376]のセクション3.2およびMLDV2仕様[MLDV2]のセクション4.2で指定）でメンバーシップレコードを作成します。たとえば、マルチキャストアドレスGのサブスクリプションを備えた2つの下流インターフェイス、I1とI2があります。I1にはIgMPv2/MLDV1サブスクリプションがあります（g）。I2には、メンバーシップ情報を持つIGMPV3/MLDV2サブスクリプションがあります（g、include、（s1、s2））。I1のサブスクリプションは、メンバーシップ情報（G、除外、ヌル）を持つIGMPV3/MLDV2サブスクリプションに変換されます。次に、サブスクリプションは前処理されてマージされ、最終メンバーシップレコードは（g、除外、null）です。
The proxy device performs the host portion of the IGMP/MLD protocol on the upstream interface. If there is an IGMPv1 or IGMPv2/MLDv1 querier on the upstream network, then the proxy device will perform IGMPv1 or IGMPv2/MLDv1 on the upstream interface accordingly. Otherwise, it will perform IGMPv3/MLDv2.
プロキシデバイスは、上流インターフェイスでIGMP/MLDプロトコルのホスト部分を実行します。アップストリームネットワークにIgMPV1またはIgMPv2/MLDV1 Querierがある場合、プロキシデバイスは、それに応じてアップストリームインターフェイスでIGMPV1またはIGMPV2/MLDV1を実行します。それ以外の場合は、IGMPV3/MLDV2を実行します。
If the proxy device performs IGMPv3/MLDv2 on the upstream interface, then when the composition of the membership database changes, the change in the database is reported on the upstream interface as though this proxy device were a host performing the action. If the proxy device performs IGMPv1 or IGMPv2/MLDv1 on the upstream interface, then when the membership records are created or deleted, the changes are reported on the upstream interface. All other changes are ignored. When the proxy device reports using IGMPv1 or IGMPv2/MLDv1, only the multicast address field in the membership record is used.
プロキシデバイスがアップストリームインターフェイスでIGMPV3/MLDV2を実行する場合、メンバーシップデータベースの構成が変更されると、このプロキシデバイスがアクションを実行するホストであるかのように、上流インターフェイスでデータベースの変更が報告されます。プロキシデバイスがアップストリームインターフェイスでIGMPV1またはIGMPV2/MLDV1を実行する場合、メンバーシップレコードが作成または削除されると、アップストリームインターフェイスで変更が報告されます。他のすべての変更は無視されます。プロキシデバイスがIGMPV1またはIGMPV2/MLDV1を使用して報告する場合、メンバーシップレコードのマルチキャストアドレスフィールドのみが使用されます。
A proxy device forwards packets received on its upstream interface to each downstream interface based upon the downstream interface's subscriptions and whether or not this proxy device is the IGMP/MLD Querier on each interface. A proxy device forwards packets received on any downstream interface to the upstream interface, and to each downstream interface other than the incoming interface based upon the downstream interfaces' subscriptions and whether or not this proxy device is the IGMP/MLD Querier on each interface. A proxy device MAY use a forwarding cache in order not to make this decision for each packet, but MUST update the cache using these rules any time any of the information used to build it changes.
プロキシデバイスは、ダウンストリームインターフェイスのサブスクリプションに基づいて、上流インターフェイスで受信したパケットを各ダウンストリームインターフェイスに転送し、このプロキシデバイスが各インターフェイスのIGMP/MLDクエリエであるかどうか。プロキシデバイスは、下流インターフェイスで受信したパケットを、上流インターフェイスに、および下流インターフェイスのサブスクリプションに基づいて着信インターフェイス以外の各ダウンストリームインターフェイスに転送し、このプロキシデバイスが各インターフェイスのIGMP/MLDクエリエであるかどうかに基づいています。プロキシデバイスは、各パケットに対してこの決定を下さないように転送キャッシュを使用する場合がありますが、変更を構築するために使用される情報のいずれかを使用してこれらのルールを使用してキャッシュを更新する必要があります。
To support Source-Specific Multicast (SSM), the proxy device should be compliant with the specification about using IGMPv3 for SSM [SSM]. Note that the proxy device should be compliant with both the IGMP Host Requirement and the IGMP Router Requirement for SSM since it performs IGMP Host Portion on the upstream interface and IGMP Router Portion on each downstream interface.
ソース固有のマルチキャスト（SSM）をサポートするために、プロキシデバイスは、SSM [SSM]にIGMPV3を使用することに関する仕様に準拠する必要があります。プロキシデバイスは、上流インターフェイスでIGMPホスト部分と各下流インターフェイスでIGMPルーター部分を実行するため、SSMのIGMPホスト要件とIGMPルーター要件の両方に準拠する必要があることに注意してください。
An interface can be configured to perform IGMPv1 or IGMPv2. In this scenario, the SSM semantic will not be maintained for that interface. However, a proxy device that supports this document should ignore those IGMPv1 or IGMPv2 subscriptions sent to SSM addresses. And more importantly, the packets with source-specific addresses SHOULD NOT be forwarded to interfaces with IGMPv2 or IGMPv1 subscriptions for these addresses.
インターフェイスは、IGMPV1またはIGMPV2を実行するように構成できます。このシナリオでは、SSMセマンティックはそのインターフェイスに対して維持されません。ただし、このドキュメントをサポートするプロキシデバイスは、SSMアドレスに送信されるIGMPV1またはIGMPV2サブスクリプションを無視する必要があります。さらに重要なことは、ソース固有のアドレスを備えたパケットを、これらのアドレスのIGMPv2またはIGMPV1サブスクリプションとのインターフェイスに転送しないでください。
Since only the Querier forwards packets, the IGMP/MLD Querier election process may lead to black holes if a non-forwarder is elected Querier. An attacker on a downstream LAN can cause itself to be elected Querier, and as a result, no packets would be forwarded.
Querierのみがパケットを転送するため、IGMP/MLDクエリエの選挙プロセスは、非フォーカーがクエリエに選出された場合、ブラックホールにつながる可能性があります。下流のLANの攻撃者は、それ自体がクエリエに選出される可能性があり、その結果、パケットは転送されません。
However, there are some operational ways to avoid this problem. It is fairly common for an operator to number the routers starting from the bottom of the subnet. So an operator SHOULD assign the subnet's lowest IP address(es) to a proxy (proxies) in order for the proxy (proxies) to win the querier election.
ただし、この問題を回避するための運用方法はいくつかあります。オペレーターがサブネットの下部から始まるルーターに番号を付けることはかなり一般的です。したがって、オペレーターは、プロキシ（プロキシ）がクエリエの選挙に勝つために、サブネットの最低IPアドレス（ES）をプロキシ（プロキシ）に割り当てる必要があります。
IGMP/MLD-based forwarding does not provide the "upstream loop" detection mechanism described in Section 3. Hence, to avoid the problems caused by an "upstream loop", it MUST be administratively assured that such loops don't exist when deploying IGMP/MLD Proxying.
IGMP/MLDベースの転送は、セクション3で説明されている「上流のループ」検出メカニズムを提供しません。したがって、「アップストリームループ」によって引き起こされる問題を回避するには、IGMPを展開するときにそのようなループが存在しないことを管理上保証する必要があります。/MLDプロキシ。
The IGMP/MLD information presented by the proxy to its upstream routers is the aggregation of all its downstream group membership information. Any access control applied on the group membership protocol at the upstream router cannot be performed on a single subscriber. That is, the access control will apply equally to all the interested hosts reachable via the proxy device.
上流のルーターにプロキシによって提示されたIGMP/MLD情報は、すべての下流のグループメンバーシップ情報の集約です。アップストリームルーターのグループメンバーシッププロトコルに適用されるアクセス制御は、単一のサブスクライバーで実行することはできません。つまり、アクセス制御は、プロキシデバイスを介して到達可能なすべての関心のあるホストに等しく適用されます。
The authors would like to thank Erik Nordmark, Dave Thaler, Pekka Savola, Karen Kimball, and others for reviewing the specification and providing their comments.
著者は、仕様を確認し、コメントを提供してくれたErik Nordmark、Dave Thaler、Pekka Savola、Karen Kimballなどに感謝したいと思います。
[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月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、1997年11月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[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月。
[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月。
[SSM] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[SSM] Holbrook、H.、Cain、B。、およびB. Haberman、「インターネットグループ管理プロトコルバージョン3（IGMPV3）およびマルチキャストリスナーディスカバリープロトコルバージョン2（MLDV2）を使用して、ソース固有のマルチキャスト、RFC 4604、8月2006年。
[MCAST] Deering, S., "Multicast Routing in a Datagram Internetwork", Ph.D. Thesis, Stanford University, December 1991.
[Mcast] Deering、S。、「データグラムインターネットワークのマルチキャストルーティング」、Ph.D。論文、スタンフォード大学、1991年12月。
[PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[PIM-SM] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、 "Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）、RFC 4601、2006年8月。
Authors' Addresses
著者のアドレス
Bill Fenner AT&T Labs - Research 1 River Oaks Place San Jose, CA 95134
ビル・フェナーAT＆Tラボ - リサーチ1リバーオークスプレイスサンノゼ、カリフォルニア95134
Phone: +1 408 493-8505
EMail: fenner@research.att.com
Haixiang He Nortel 600 Technology Park Drive Billerica, MA 01821
haixiang彼はノルテル600テクノロジーパークドライブビレリカ、マサチューセッツ州01821
EMail: haixiang@nortel.com
Brian Haberman Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099
ブライアンハーバーマンジョンズホプキンス大学応用物理学ラボ11100ジョンズホプキンスロードローレル、メリーランド20723-6099
EMail: brian@innovationslab.net
Hal Sandick Little River Elementary School 2315 Snow Hill Road Durham, NC 27712
ハルサンディックリトルリバー小学校2315スノーヒルロードダーラム、ノースカロライナ27712
EMail: sandick@nc.rr.com
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）によって提供されます。