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")
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).
著作権（C）インターネット協会（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.
この文書は、インターネットグループ管理プロトコル（IGMP）またはマルチキャストリスナ発見（MLD）のみの環境に[MCAST]ルーティングツリーマルチキャストをまたがる適用されます。私たちは、より複雑なトポロジー上でスパニングツリーを構築するために何のプロトコルを指定しないためのトポロジーは、ツリーに限定されています。ツリーのルートは、より広いマルチキャストインフラストラクチャに接続されているものとします。
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.
シンプルなツリートポロジでは、マルチキャストルーティングプロトコルを実行する必要はありません。学び、プロキシグループメンバーシップ情報と、その情報に基づいて単純にマルチキャストパケットを転送するのに十分です。このようなツリートポロジーの典型的な一例は、デジタル加入者線アクセスマルチプレクサ（DSLAM）などのエッジ・アグリゲーション・ボックスで見つけることができます。ほとんどの展開シナリオでは、エッジボックスは、コアネットワーク側に一つだけの接続を持っており、顧客の側に多くの接続を持っています。
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）などのより複雑なマルチキャストルーティングプロトコルをサポートしていないことで、デバイスのコストだけでなく、運用のオーバーヘッドだけでなく、減少します。別の利点は、コアネットワークルータによって使用されるマルチキャストルーティングプロトコルのプロキシデバイスが独立させることです。したがって、プロキシデバイスは、簡単にマルチキャストネットワークに配備することができます。
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.
エッジボックスのロバスト性は、通常、コアネットワークへホットスペア接続を使用することによって達成されます。最初の接続が失敗した場合、エッジボックスは、第二の接続にフェイルオーバー。 IGMP / MLDベースの転送は、このようなメカニズムから恩恵を受けるとマルチキャストルータへの冗長またはバックアップ接続のための予備接続を使用することができます。エッジボックスは、第二の接続にフェールオーバーする場合は、接続のアップストリームプロキシは、新しい接続に更新することができます。
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.
このドキュメントはインターネットエンジニアリングタスクフォース内でのマルチキャスト＆エニーキャストグループメンバーシップ（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.
IGMPv1レポートが聞こえる場合のIPv4環境では、各マルチキャストグループについて、グループは、IGMPバージョン1（IGMPv1レポート）[RFC1112]モードにあります。 IGMPv2レポートを聞いているが、何のIGMPv1レポートが聞こえない場合、グループは、IGMPバージョン2（IGMPv2の）[RFC2236]モードにあります。 IGMPv3レポートを聞いているが、何のIGMPv1またはIGMPv2レポートが聞こえない場合、グループは、IGMPバージョン3（IGMPv3の）[RFC3376]モードにあります。
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環境では、各マルチキャストグループについて、グループは、MLDバージョン1（のMLDv1）である[RFC2710]モードのMLDv1レポートが聞かれている場合。 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の状態エントリ、すなわち、（マルチキャストアドレス、グループタイマー、フィルタモード、ソース要素のリスト）タプルです。
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.
プロキシデバイスは、照会時にアップストリームインターフェイス上の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アドレスを指定する必要があります。 IGMP / MLDクエリアの選挙規則は最低のIPアドレスを持つクエリアが選挙に勝つことが規定されています。 （IGMP / MLDクエリアの選挙ルールが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アドレスを持っていますが、それは、プロキシデバイスではありません。それは最低のIPアドレスを持っているため、IGMP / MLDクエリアの選挙規則によると、Aは、LAN上の2選挙に勝つだろう。それはLAN 2にクエリアではないので、デバイスBは、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クエリアの選挙でこのルール「ピギーバック」フォワーダ選挙。転送プロキシを選択するIGMP / MLDクエリア選出プロセスの使用は、PIMアサートメカニズムとしてローカルリンク上で同様の機能を提供します。唯一のIGMP / MLDベースの転送装置とのリンク上で、このルールは（即ち、デバイスがクエリアされていないインターフェイスにパケットを転送するように構成することができる）ディセーブルされます。ただし、デフォルト設定は以下の図に示すように、冗長性のために、例えば、クエリアルールを含める必要があります。
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は、このような構成では、2つのプロキシ装置、AおよびBを有することができ、あるプロキシ装置は、パケットを転送することを選択しなければなりません。この文書では、フォワーダがIGMP / MLDクエリアでなければならないことが必要です。だから、プロキシ装置Aは、Aがクエリアである場合にのみ、LAN 2にパケットを転送します。 Aのみプロキシデバイスである場合、上記の図では、Aは、Bがクエリアであってもパケットを転送するように構成することができます。
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からLAN 1 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ベースのマルチキャスト転送が代理ツリーの上流のルータはネットワークがプロキシツリーに接続されているかを知るための方法を提供していません。プロキシ・トポロジーは、いくつかのルーティングトポロジと合同である場合、この情報は、トポロジ上で実行されているルーティングプロトコルから学ぶことができます。例えば、ルータはすべてのプレフィックスからのマルチキャストパケットは、それらが直接接続されたシステムからのものであったかのようにインターフェースを介して、Yプロトコル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の変換後のサブスクリプションは、第1のフィルタモードは、EXCLUDEソースがタイマー> 0は、次に前処理サブスクリプションは、複数のメンバーシップのためにマージルールを使用してマージされ、すべてのソースを削除する場合、サブスクリプションにタイマーを除去するために前処理されていますメンバーシップ・レコードを作成する（[RFC3376]とのMLDv2仕様のセクション4.2に【のMLDv2] IGMPv3の仕様のセクション3.2で指定された）単一のインターフェイス上で。例えば、マルチキャストアドレスG. I1のサブスクリプションを持っている2つのダウンストリームインターフェース、I1及びI2は、ある（G）であり、IGMPv2の/のMLDv1サブスクリプションを持っています。 I2は、会員情報を持っているのIGMPv3 / MLDv2のサブスクリプション（G、INCLUDE、（S1、S2））を有しています。 I1のサブスクリプションは、会員情報有するのIGMPv3 / MLDv2のサブスクリプション（G、EXCLUDEを、NULL）に変換されます。次いで、サブスクリプションは、前処理およびマージし、最終メンバーシップ・レコードは、（G、EXCLUDE、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クエリアが存在する場合には、プロキシデバイスは、それに応じてアップストリームインターフェイス上の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ホスト部分を実行するためのプロキシデバイスがIGMPホスト要件とSSMのための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.
唯一クエリアがパケットを転送するための非フォワーダがクエリア選出された場合、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アドレスを割り当てる必要があります。
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.
著者は、仕様を見直し、彼らのコメントを提供するためのエリックNordmarkと、デーブターラー、ペッカSavola、カレン・キンボール、そして他の人に感謝したいと思います。
[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月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236]フェナー、W.、 "インターネットグループ管理プロトコル、バージョン2"、RFC 2236、1997年11月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、1989年8月。
[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月。
[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月。
[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]ホルブルック、H.、カイン、B.、およびB.ハーバーマン、 "ソース固有マルチキャストのためにインターネットグループ管理プロトコルバージョン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]デアリング、S.、「データグラムインターネットワークにおけるマルチキャストルーティング」、博士論文、スタンフォード大学、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]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月。
Authors' Addresses
著者のアドレス
Bill Fenner AT&T Labs - Research 1 River Oaks Place San Jose, CA 95134
ビルフェナーAT＆T研究所 - 研究1リバーオークス置き、サンノゼ、CA 95134
Phone: +1 408 493-8505 EMail: fenner@research.att.com
電話：+1 408 493-8505 Eメール：fenner@research.att.com
Haixiang He Nortel 600 Technology Park Drive Billerica, MA 01821
Haixiang彼ノーテル600テクノロジーパークドライブビレリカ、MA 01821
EMail: haixiang@nortel.com
メールアドレス：haixiang@nortel.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
Hal Sandick Little River Elementary School 2315 Snow Hill Road Durham, NC 27712
ハルSandickリトルリバー小学校2315雪の丘の道ダーラム、ノースカロライナ27712
EMail: sandick@nc.rr.com
メールアドレス：sandick@nc.rr.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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）によって提供されます。