Network Working Group M. Christensen
Request for Comments: 4541 Thrane & Thrane
Category: Informational K. Kimball
Hewlett-Packard
F. Solensky
Calix
May 2006
Considerations for Internet Group Management Protocol (IGMP)
and Multicast Listener Discovery (MLD) Snooping Switches
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered.
このメモは、インターネットグループ管理プロトコル（IGMP）とMulticast Listener Discovery（MLD）スヌーピングスイッチの推奨事項について説明します。これらはIGMPv3-とのMLDv2スヌーピングのための更なる配慮したIGMPv2のための最高の現在のプラクティスに基づいています。そのようなリンク層トポロジの変更およびEthernet固有のカプセル化問題など関連性の更なる領域は、も考慮されています。
The IEEE bridge standard [BRIDGE] specifies how LAN packets are 'bridged', or as is more commonly used today, switched between LAN segments. The operation of a switch with respect to multicast packets can be summarized as follows. When processing a packet whose destination MAC address is a multicast address, the switch will forward a copy of the packet into each of the remaining network interfaces that are in the forwarding state in accordance with [BRIDGE]. The spanning tree algorithm ensures that the application of this rule at every switch in the network will make the packet accessible to all nodes connected to the network.
IEEEブリッジ標準[BRIDGE]はLANパケットが「ブリッジ」、またはより一般的に使用される今日のように、LANセグメント間で切り替える方法を指定します。次のようにマルチキャストパケットに対するスイッチの動作を要約することができます。宛先MACアドレスがマルチキャストアドレスであるパケットを処理するとき、スイッチは[BRIDGE]に従ってフォワーディング状態にある残りのネットワークインターフェースのそれぞれにパケットのコピーを転送します。スパニングツリーアルゴリズムは、ネットワーク内のすべてのスイッチで、この規則の適用は、ネットワークに接続されたすべてのノードへパケットがアクセスできるようになることを保証します。
This behaviour works well for broadcast packets that are intended to be seen or processed by all connected nodes. In the case of multicast packets, however, this approach could lead to less efficient use of network bandwidth, particularly when the packet is intended for only a small number of nodes. Packets will be flooded into network segments where no node has any interest in receiving the packet. While nodes will rarely incur any processing overhead to filter packets addressed to unrequested group addresses, they are unable to transmit new packets onto the shared media for the period of time that the multicast packet is flooded. In general, significant bandwidth can be wasted by flooding.
この動作は、接続されたすべてのノードによって見たり処理されることが意図されているブロードキャストパケットに適しています。マルチキャストパケットの場合には、しかしながら、このアプローチは、パケットがノードの数が少ないために意図されている場合は特に、ネットワーク帯域幅の少ない効率的な使用につながる可能性があります。パケットがどのノードがパケットを受信することに興味を持っていないネットワークセグメントにフラッディングされます。要求されていないグループアドレス宛のノードはめったにパケットをフィルタリングするために任意の処理オーバーヘッドが発生しませんが、それらはマルチキャストパケットが殺到していることをしばらくの間、共有メディア上に新しいパケットを送信することはできません。一般的には、かなりの帯域幅は、洪水によって無駄にすることができます。
In recent years, a number of commercial vendors have introduced products described as "IGMP snooping switches" to the market. These devices do not adhere to the conceptual model that provides the strict separation of functionality between different communications layers in the ISO model, and instead utilize information in the upper level protocol headers as factors to be considered in processing at the lower levels. This is analogous to the manner in which a router can act as a firewall by looking into the transport protocol's header before allowing a packet to be forwarded to its destination address.
近年では、商用ベンダーの数が市場に「IGMPスヌーピングスイッチ」として記載されている製品を導入しています。これらのデバイスは、ISOモデルにおける異なる通信層の間の機能の厳密な分離を提供する概念モデルに準拠し、その代わり因子は低いレベルで処理する際に考慮されるように、上位プロトコルヘッダ内の情報を利用しません。これは、ルータがパケットをその宛先アドレスに転送することを許可する前に、トランスポートプロトコルのヘッダを調べて、ファイアウォールとして機能することができる方法に類似しています。
In the case of IP multicast traffic, an IGMP snooping switch provides the benefit of conserving bandwidth on those segments of the network where no node has expressed interest in receiving packets addressed to the group address. This is in contrast to normal switch behavior where multicast traffic is typically forwarded on all interfaces.
IPマルチキャストトラフィックの場合、IGMPスヌーピングスイッチには、ノードがグループアドレス宛てのパケットを受信することに関心を示していないネットワークのこれらのセグメントの帯域幅を節約するという利点を提供します。これは、マルチキャストトラフィックは、典型的にはすべてのインターフェイス上で転送される通常のスイッチの動作とは対照的です。
Many switch datasheets state support for IGMP snooping, but no recommendations for this exist today. It is the authors' hope that the information presented in this document will supply this foundation.
多くのスイッチデータシートIGMPスヌーピングのための国の支援が、これには推奨事項は、今日存在しません。この文書の情報は、この基盤を提供することを作者の希望です。
The recommendations presented here are based on the following information sources: The IGMP specifications [RFC1112], [RFC2236] and [IGMPv3], vendor-supplied technical documents [CISCO], bug reports [MSOFT], discussions with people involved in the design of IGMP snooping switches, MAGMA mailing list discussions, and on replies by switch vendors to an implementation questionnaire.
ここで紹介する推奨事項は、次の情報源に基づいています：IGMPの仕様[RFC1112]、[RFC2236]と[IGMPv3の]、ベンダーが提供する技術文書[CISCO]、バグレポート[MSOFT]、の設計に関わる人たちとの議論IGMPスヌーピングスイッチ、MAGMAメーリングリストでの議論、および実装アンケートへのスイッチ・ベンダーによって回答に。
Interoperability issues that arise between different versions of IGMP are not the focus of this document. Interested readers are directed to [IGMPv3] for a thorough description of problem areas.
IGMPの異なるバージョン間で発生する相互運用性の問題は、この文書の焦点ではありません。興味のある読者は、問題の領域の完全な説明については、[IGMPv3の]に向けられています。
The suggestions in this document are based on IGMP, which applies only to IPv4. For IPv6, Multicast Listener Discovery [MLD] must be used instead. Because MLD is based on IGMP, we do not repeat the entire description and recommendations for MLD snooping switches. Instead, we point out the few cases where there are differences from IGMP.
この文書に記載されている提案は、IPv4のみに適用されるIGMP、に基づいています。 IPv6の場合、マルチキャストリスナ発見は[MLD]の代わりに使用する必要があります。 MLDはIGMPに基づいているので、我々は、MLDスヌーピングスイッチの全体説明と推奨事項を繰り返さないでください。代わりに、私たちは、IGMPからの違いがあるいくつかの例を指摘しています。
Note that the IGMP snooping function should apply only to IPv4 multicasts. Other multicast packets, such as IPv6, might be suppressed by IGMP snooping if additional care is not taken in the implementation as mentioned in the recommendations section. It is desired not to restrict the flow of non-IPv4 multicasts other than to the degree which would happen as a result of regular bridging functions. Likewise, MLD snooping switches are discouraged from using topological information learned from IPv6 traffic to alter the forwarding of IPv4 multicast packets.
IGMPスヌーピング機能は、IPv4マルチキャストにのみ適用されるべきであることに注意してください。勧告の項で述べたように、追加のケアが実装で撮影されていない場合、IPv6など他のマルチキャストパケットは、IGMPスヌーピングによって抑制される可能性があります。定期的なブリッジ機能の結果として起こる度以外の非たIPv4マルチキャストの流れを制限しないことが望まれます。同様に、MLDスヌーピングスイッチは、IPv4マルチキャストパケットの転送を変更するIPv6トラフィックから学んだトポロジ情報を使用してから、落胆しています。
The following sections list the recommendations for an IGMP snooping switch. The recommendation is stated and is supplemented by a description of a possible implementation approach. All implementation discussions are examples only and there may well be other ways to achieve the same functionality.
次のセクションでは、IGMPスヌーピングスイッチのための提言をリストアップ。勧告は記載されている、可能な実装アプローチの説明によって補完されます。すべての実装の議論はあくまで一例であり、よく同じ機能を実現する他の方法があるかもしれません。
The IGMP snooping functionality is separated into a control section (IGMP forwarding) and a data section (Data forwarding).
IGMPスヌーピング機能は、制御部（転送IGMP）とデータ部（データ転送）に分離されます。
1) A snooping switch should forward IGMP Membership Reports only to those ports where multicast routers are attached.
1）スヌーピングスイッチは、マルチキャストルータが接続されているこれらのポートにIGMPメンバシップレポートを転送しなければなりません。
Alternatively stated: a snooping switch should not forward IGMP Membership Reports to ports on which only hosts are attached. An administrative control may be provided to override this restriction, allowing the report messages to be flooded to other ports.
別の言い方をすれば：スヌーピングスイッチは、ホストだけが接続されているポートにIGMPメンバーシップレポートを転送するべきではありません。管理コントロールは、レポートメッセージが他のポートにフラッディングされることを可能にする、この制限を無効にするために提供されてもよいです。
This is the main IGMP snooping functionality for the control path.
これは、制御パスのための主要なIGMPスヌーピング機能です。
Sending membership reports to other hosts can result, for IGMPv1 and IGMPv2, in unintentionally preventing a host from joining a specific multicast group.
他のホストにメンバーシップレポートを送信すると、意図せずに、特定のマルチキャストグループに参加するホストを防止することで、IGMPv1およびIGMPv2のために、可能性があります。
When an IGMPv1 or IGMPv2 host receives a membership report for a group address that it intends to join, the host will suppress its own membership report for the same group. This join or message suppression is a requirement for IGMPv1 and IGMPv2 hosts. However, if a switch does not receive a membership report from the host it will not forward multicast data to it.
IGMPv1またはIGMPv2のホストが加入しようとするグループアドレスのためのメンバーシップレポートを受信した場合、ホストは、同じグループのために、独自のメンバーシップレポートを抑制します。これは、参加したり、メッセージ抑制は、IGMPv1およびIGMPv2のホストのための要件です。スイッチは、ホストからのメンバーシップレポートを受信しない場合は、それにマルチキャストデータを転送しません。
This is not a problem in an IGMPv3-only network because there is no suppression of IGMP Membership reports.
IGMPメンバーシップレポートのない抑制がないので、これはIGMPv3の専用ネットワークの問題ではありません。
The administrative control allows IGMP Membership Report messages to be processed by network monitoring equipment such as packet analyzers or port replicators.
管理制御はIGMPメンバーシップレポートメッセージは、パケットアナライザまたはポートリプリケータなどのネットワーク監視装置によって処理することができます。
The switch supporting IGMP snooping must maintain a list of multicast routers and the ports on which they are attached. This list can be constructed in any combination of the following ways:
IGMPスヌーピングをサポートするスイッチは、マルチキャストルータおよびそれらが結合されているポートのリストを維持する必要があります。このリストは、次の方法の任意の組み合わせで構築することができます。
a) This list should be built by the snooping switch sending Multicast Router Solicitation messages as described in IGMP Multicast Router Discovery [MRDISC]. It may also snoop Multicast Router Advertisement messages sent by and to other nodes.
A）このリストは、IGMPマルチキャストルータ発見[MRDISC]で説明したように、マルチキャストルータ要請メッセージを送信スヌーピングスイッチによって構築されなければなりません。それはまたによって、他のノードに送信されたマルチキャストルータ広告メッセージをスヌープします。
b) The arrival port for IGMP Queries (sent by multicast routers) where the source address is not 0.0.0.0.
b）は、送信元アドレスが0.0.0.0でないマルチキャストルータによって送信されたIGMPクエリ（）のために到着ポート。
The 0.0.0.0 address represents a special case where the switch is proxying IGMP Queries for faster network convergence, but is not itself the Querier. The switch does not use its own IP address (even if it has one), because this would cause the Queries to be seen as coming from a newly elected Querier. The 0.0.0.0 address is used to indicate that the Query packets are NOT from a multicast router.
0.0.0.0アドレスは、スイッチが高速ネットワーク収束にIGMPクエリをプロキシされる特殊な場合を表し、それ自体がクエリアではありません。これは、クエリの原因となるため、スイッチが新たに選出されたクエリアから来ると見られることを、自身のIPアドレスを（それが1を持っている場合でも）を使用していません。 0.0.0.0アドレスは、Queryパケットがマルチキャストルータからされていないことを示すために使用されます。
c) Ports explicitly configured by management to be IGMP-forwarding ports, in addition to or instead of any of the above methods to detect router ports.
C）ポートは、明示的にルータポートを検出することに加え、または代わりに上記の方法のいずれかで、IGMP転送ポートであることを管理することにより構成されています。
2) IGMP networks may also include devices that implement "proxy-reporting", in which reports received from downstream hosts are summarized and used to build internal membership states. Such proxy-reporting devices may use the all-zeros IP Source-Address when forwarding any summarized reports upstream. For this reason, IGMP membership reports received by the snooping switch must not be rejected because the source IP address is set to 0.0.0.0.
2）IGMPネットワークも要約し、内部のメンバーシップ状態を構築するために使用されている下流のホストからの報告を受けている「プロキシレポート機能を」実装するデバイスを含むことができます。上流のいずれかの要約レポートを転送するとき、このようなプロキシレポートデバイスはすべてゼロIPソース・アドレスを使用することができます。送信元IPアドレスが0.0.0.0に設定されているので、このような理由から、詮索スイッチが受信したIGMPメンバーシップレポートを拒否してはいけません。
3) The switch that supports IGMP snooping must flood all unrecognized IGMP messages to all other ports and must not attempt to make use of any information beyond the end of the network layer header.
3）他のすべてのポートへのすべての認識できないIGMPメッセージをあふれさせる必要がありIGMPスヌーピングをサポートし、ネットワーク層ヘッダの終わりを越えた情報を利用しようとしてはならないスイッチ。
In addition, earlier versions of IGMP should interpret IGMP fields as defined for their versions and must not alter these fields when forwarding the message. When generating new messages, a given IGMP version should set fields to the appropriate values for its own version. If any fields are reserved or otherwise undefined for a given IGMP version, the fields should be ignored when parsing the message and must be set to zeroes when new messages are generated by implementations of that IGMP version. An exception may occur if the switch is performing a spoofing function, and is aware of the settings for new or reserved fields that would be required to correctly spoof for a different IGMP version.
また、IGMPの以前のバージョンは、そのバージョン用に定義されているIGMPフィールドを解釈すべきであるとのメッセージを転送するとき、これらのフィールドを変更してはいけません。新しいメッセージを生成する場合、特定のIGMPバージョンは独自のバージョンのために適切な値にフィールドを設定する必要があります。任意のフィールドが与えられたIGMPバージョン用に予約またはそうでなければ、未定義されている場合は、メッセージを解析するとき、フィールドは無視され、新しいメッセージがそのIGMPバージョンの実装によって生成されたときにゼロに設定する必要があります。スイッチがスプーフィング機能を実行し、正しく異なるIGMPバージョンのために偽装するために必要とされるであろう新しいまたは予約フィールドの設定を認識している場合、例外が発生することがあります。
The reason to worry about these trivialities is that IGMPv3 overloads the old IGMP query message using the same type number (0x11) but with an extended header. Therefore there is a risk that IGMPv3 queries may be interpreted as older version queries by, for example, IGMPv2 snooping switches. This has already been reported [IETF56] and is discussed in section 2.2.
これら些事心配する理由は、IGMPv3のは、同じタイプの数（0x11を）が、拡張ヘッダとを使用して、古いIGMPクエリメッセージをオーバーロードすることです。したがって、例えば、IGMPv2のは、スイッチをスヌーピングによってIGMPv3のクエリが古いバージョンのクエリとして解釈されるおそれがあります。これは、すでに[IETF56】報告されており、セクション2.2で議論されています。
4) An IGMP snooping switch should be aware of link layer topology changes caused by Spanning Tree operation. When a port is enabled or disabled by Spanning Tree, a General Query may be sent on all active non-router ports in order to reduce network convergence time. Non-Querier switches should be aware of whether the Querier is in IGMPv3 mode. If so, the switch should not spoof any General Queries unless it is able to send an IGMPv3 Query that adheres to the most recent information sent by the true Querier. In no case should a switch introduce a spoofed IGMPv2 Query into an IGMPv3 network, as this may create excessive network disruption.
4）IGMPスヌーピングスイッチは、スパニングツリー動作によるリンク層トポロジ変更を認識すべきです。ポートがスパニングツリーによって有効または無効になっている場合には、一般的なクエリは、ネットワークのコンバージェンス時間を短縮するために、すべてのアクティブな非ルータポートで送信されてもよいです。非クエリアスイッチがクエリアがIGMPv3のモードであるかどうかに注意する必要があります。もしそうなら、真のクエリアによって送られた最新の情報に準拠してIGMPv3のクエリーを送信することができない限り、スイッチは、任意の一般的なクエリを偽造べきではありません。これは、過剰なネットワークの混乱を作成することができるようにない場合には、スイッチは、IGMPv3のネットワークになりすましIGMPv2のクエリーを導入すべきです。
If the switch is not the Querier, it should use the 'all-zeros' IP Source Address in these proxy queries (even though some hosts may elect to not process queries with a 0.0.0.0 IP Source Address). When such proxy queries are received, they must not be included in the Querier election process.
スイッチがクエリアでない場合は（いくつかのホストは、0.0.0.0のIP送信元アドレスを使用してクエリを処理しないことを選択する場合であっても）、それはこれらのプロキシクエリの「すべてゼロのIP送信元アドレスを使用する必要があります。そのようなプロキシクエリが受信されると、彼らはクエリア選択プロセスに含まれてはいけません。
5) An IGMP snooping switch must not make use of information in IGMP packets where the IP or IGMP headers have checksum or integrity errors. The switch should not flood such packets but if it does, it should also take some note of the event (i.e., increment a counter). These errors and their processing are further discussed in [IGMPv3], [MLD] and [MLDv2].
5）IGMPスヌーピングスイッチは、IPやIGMPヘッダチェックサムまたは整合性エラーがあるIGMPパケット内の情報を利用してはなりません。スイッチは、このようなパケットをあふれさせるべきではありませんが、それがない場合、それはまた、（すなわち、カウンタをインクリメント）イベントのいくつかのノートを取る必要があります。これらのエラーとその処理がさらに【のIGMPv3]で議論されている、[MLD]および[のMLDv2]。
6) The snooping switch must not rely exclusively on the appearance of IGMP Group Leave announcements to determine when entries should be removed from the forwarding table. It should implement a membership timeout mechanism such as the router-side functionality of the IGMP protocol as described in the IGMP and MLD specifications (See Normative Reference section for IGMPv1-3 and MLDv1-2) on all its non-router ports. This timeout value should be configurable.
6）スヌーピングスイッチは、エントリが転送テーブルから削除すべきかを決定するためにIGMPグループ離脱発表の外観だけに頼らないでなければなりません。そのようなすべての非ルータポートにIGMPおよびMLD仕様（IGMPv1-3とMLDv1-2ための引用規格のセクションを参照）に記載されているようにIGMPプロトコルのルータ側の機能として、会員のタイムアウト機構を実装する必要があります。このタイムアウト値は設定する必要があります。
1) Packets with a destination IP address outside 224.0.0.X which are not IGMP should be forwarded according to group-based port membership tables and must also be forwarded on router ports.
1）IGMPない224.0.0.X外部宛先IPアドレスを持つパケットは、グループベースのポートメンバーシップテーブルに従って転送されるべきであり、また、ルータポートに転送されなければなりません。
This is the main IGMP snooping functionality for the data path. One approach that an implementation could take would be to maintain separate membership and multicast router tables in software and then "merge" these tables into a forwarding cache.
これは、データ・パスのための主要なIGMPスヌーピング機能です。実装が取ることができることを一つのアプローチは、ソフトウェアで別々のメンバーシップおよびマルチキャストルータテーブルを維持して、フォワーディングキャッシュにこれらのテーブルを「マージ」することです。
2) Packets with a destination IP (DIP) address in the 224.0.0.X range which are not IGMP must be forwarded on all ports.
IGMPは、すべてのポートで転送されなければならないれる224.0.0.X範囲内の宛先IP（DIP）アドレスを持つ2）パケット。
This recommendation is based on the fact that many host systems do not send Join IP multicast addresses in this range before sending or listening to IP multicast packets. Furthermore, since the 224.0.0.X address range is defined as link-local (not to be routed), it seems unnecessary to keep the state for each address in this range. Additionally, some routers operate in the 224.0.0.X address range without issuing IGMP Joins, and these applications would break if the switch were to prune them due to not having seen a Join Group message from the router.
この勧告は、多くのホストシステムが送信またはIPマルチキャストパケットを聴く前に、この範囲のIPマルチキャストアドレスに参加し送信していないという事実に基づいています。 224.0.0.Xアドレス範囲がリンクローカル（ルーティングされない）として定義されているので、この範囲内の各アドレスの状態を維持するために不要と思われます。さらに、いくつかのルータはIGMP参加を発行せずに224.0.0.Xアドレス範囲で動作し、スイッチが原因ルータからの参加グループのメッセージを見たではないにそれらを剪定した場合、これらのアプリケーションは壊れます。
3) An unregistered packet is defined as an IPv4 multicast packet with a destination address which does not match any of the groups announced in earlier IGMP Membership Reports.
3）登録されていないパケットは、以前のIGMPメンバーシップレポートに発表されたグループのいずれにも一致しない宛先アドレスを持つIPv4マルチキャストパケットとして定義されます。
If a switch receives an unregistered packet, it must forward that packet on all ports to which an IGMP router is attached. A switch may default to forwarding unregistered packets on all ports. Switches that do not forward unregistered packets to all ports must include a configuration option to force the flooding of unregistered packets on specified ports.
スイッチが未登録のパケットを受信した場合、それは、IGMPルーターが接続されているすべてのポートにそのパケットを転送する必要があります。スイッチはすべてのポートに未登録のパケットを転送するために、デフォルトがあります。すべてのポートに未登録のパケットを転送していないスイッチは、指定されたポート上で登録されていないパケットのフラッディングを強制する設定オプションを含める必要があります。
In an environment where IGMPv3 hosts are mixed with snooping switches that do not yet support IGMPv3, the switch's failure to flood unregistered streams could prevent v3 hosts from receiving their traffic. Alternatively, in environments where the snooping switch supports all of the IGMP versions that are present, flooding unregistered streams may cause IGMP hosts to be overwhelmed by multicast traffic, even to the point of not receiving Queries and failing to issue new membership reports for their own groups.
IGMPv3ホストがまだのIGMPv3をサポートしていないスイッチをスヌーピングと混合されている環境では、未登録のストリームをあふれさせるスイッチの失敗は自分のトラフィックを受信v3のホストを防ぐことができます。また、スヌーピングスイッチが存在しているIGMPのバージョンのすべてをサポートしている環境では、未登録のストリームをあふれさせることはIGMPもクエリを受信し、自分自身のための新しいメンバーシップレポートを発行するために失敗しないのポイントに、マルチキャストトラフィックに圧倒されるようにホスト可能性がありグループ。
It is encouraged that snooping switches at least recognize and process IGMPv3 Join Reports, even if this processing is limited to the behavior for IGMPv2 Joins, i.e., is done without considering any additional "include source" or "exclude source" filtering. When IGMPv3 Joins are not recognized, a snooping switch may incorrectly prune off the unregistered data streams for the groups (as noted above); alternatively, it may fail to add in forwarding to any new IGMPv3 hosts if the group has previously been joined as IGMPv2 (because the data stream is seen as already having been registered).
それは、この処理はIGMPv2のための行動参加に制限されている場合でも、少なくとも詮索スイッチが認識し、プロセスがレポートに参加IGMPv3のことを奨励されている、すなわち、任意の追加を考慮せずに行われているか、フィルタリング「ソースを除外する」「ソースを含めます」。 IGMPv3のが認識されない参加するとき（上述のように）、スヌーピングスイッチが誤ってグループに対する未登録データストリームをオフに整理することができます。あるいは、（データストリームが既に登録されていると見られているため）グループは、以前IGMPv2のように接合されている場合、新しいIGMPv3ホストへの転送に追加できない場合があります。
4) All non-IPv4 multicast packets should continue to be flooded out to all remaining ports in the forwarding state as per normal IEEE bridging operations.
4）すべての非IPv4マルチキャストパケットは、通常のIEEEブリッジ操作に従ってフォワーディング状態で残りのすべてのポートにフラッディングされ続けるべきです。
This recommendation is a result of the fact that groups made up of IPv4 hosts and IPv6 hosts are completely separate and distinct groups. As a result, information gleaned from the topology between members of an IPv4 group would not be applicable when forming the topology between members of an IPv6 group.
この勧告は、IPv4ホストとIPv6ホストからなるグループが完全に独立した別個の基であるという事実の結果です。 IPv6のグループのメンバー間のトポロジーを形成する際に結果として、IPv4のグループのメンバー間のトポロジから収集された情報は適用できないであろう。
5) IGMP snooping switches may maintain forwarding tables based on either MAC addresses or IP addresses. If a switch supports both types of forwarding tables then the default behavior should be to use IP addresses. IP address based forwarding is preferred because the mapping between IP multicast addresses and link-layer multicast addresses is ambiguous. In the case of Ethernet, there is a multiplicity of 1 Ethernet address to 32 IP addresses [RFC1112].
5）IGMPスヌーピングスイッチは、MACアドレスまたはIPアドレスのいずれかに基づいて転送テーブルを維持することができます。スイッチが転送テーブルの両方のタイプをサポートしている場合は、デフォルトの動作では、IPアドレスを使用する必要があります。 IPマルチキャストアドレス及びリンク層マルチキャストアドレスの間のマッピングがあいまいであるため、IPアドレスベースの転送が好ましいです。イーサネットの場合、32のIPアドレス[RFC1112]に1つのイーサネットアドレスの多数があります。
6) Switches which rely on information in the IP header should verify that the IP header checksum is correct. If the checksum fails, the information in the packet must not be incorporated into the forwarding table. Further, the packet should be discarded.
6）IPヘッダ内の情報に依存しているスイッチは、IPヘッダチェックサムが正しいことを確認すべきです。チェックサムが失敗した場合、パケット内の情報が転送テーブルに組み込まれてはいけません。さらに、パケットが破棄されなければなりません。
7) When IGMPv3 "include source" and "exclude source" membership reports are received on shared segments, the switch needs to forward the superset of all received membership reports on to the shared segment. Forwarding of traffic from a particular source S to a group G must happen if at least one host on the shared segment reports an IGMPv3 membership of the type INCLUDE(G, Slist1) or EXCLUDE(G, Slist2), where S is an element of Slist1 and not an element of Slist2.
IGMPv3の「含むソース」と「ソースを除外する」メンバーシップレポートが共有セグメント上で受信された場合7）、スイッチは、共有セグメントへのすべての受信されたメンバシップレポートのスーパーセットを転送する必要があります。共有セグメント上の少なくとも1つのホストに報告する場合Gが発生しなければならないグループに特定のソースSからのトラフィックの転送タイプのIGMPv3のメンバーシップは、Sは、の要素である（G、Slist2）、（G、Slist1）を含めるか除外Slist1ないSlist2の要素。
The practical implementation of the (G,S1,S2,...) based data forwarding tables are not within the scope of this document. However, one possibility is to maintain two (G,S) forwarding lists: one for the INCLUDE filter where a match of a specific (G,S) is required before forwarding will happen, and one for the EXCLUDE filter where a match of a specific (G,S) will result in no forwarding.
（G、S1、S2、...）ベースのデータ転送テーブルの実際の実装は、この文書の範囲外です。しかし、一つの可能性は、2つ（G、S）転送リストを維持することである：除外フィルターの転送が起こる前に、特定の（G、S）の一致が必要とされるフィルタを含むための1つ、および1つここでの一致特定（G、S）は、無転送をもたらすであろう。
A special problem arises in networks consisting of IGMPv3 routers as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2 snooping switch as recently reported [IETF56]. The router will continue to maintain IGMPv3 even in the presence of IGMPv2 hosts, and thus the network will not converge on IGMPv2. But it is likely that the IGMPv2 snooping switch will not recognize or process the IGMPv3 membership reports. Groups for these unrecognized reports will then either be flooded (with all of the problems that may create for hosts in a network with a heavy multicast load) or pruned by the snooping switch.
特別な問題は、IGMPv3ルータからなるネットワークならびに最近[IETF56】報告されたようにIGMPv2のスヌーピングスイッチによって相互接続はIGMPv2およびIGMPv3ホストにおいて生じます。ルータでもIGMPv2ホストの存在下でのIGMPv3を維持していきますので、ネットワークは、IGMPv2の上で収束しないでしょう。しかし、IGMPv2のスヌーピングスイッチが認識またはIGMPv3メンバシップレポートを処理しない可能性が高いです。これらの認識されていないレポートのグループが、その後のいずれか（重マルチキャストの負荷とネットワーク内のホストのために作成することが問題のすべてで）浸水や詮索スイッチによって剪定されます。
Therefore, it is recommended that in such a network, the multicast router be configured to use IGMPv2. If this is not possible, and if the snooping switch cannot recognize and process the IGMPv3 membership reports, it is instead recommended that the switch's IGMP snooping functionality be disabled, as there is no clear solution to this problem.
したがって、このようなネットワークでは、マルチキャストルータはIGMPv2を使用するように構成することが推奨されます。これは不可能である、と詮索スイッチが認識し、IGMPv3メンバシップレポートを処理できない場合は、代わりにこの問題に対する明確な解決策がないように、スイッチのIGMPスヌーピング機能は、無効にすることをお勧めします。
In order to avoid confusion, the previous discussions have been based on the IGMP protocol which only applies to IPv4 multicast. In the case of IPv6, most of the above discussions are still valid with a few exceptions that we will describe here.
混乱を避けるために、以前の議論は、IPv4のみのマルチキャストに適用されるIGMPプロトコルに基づいています。 IPv6の場合には、上記の議論のほとんどは、まだ私たちがここで説明しますいくつかの例外を除いて有効です。
The control and data forwarding rules in the IGMP section can, with a few considerations, also be applied to MLD. This means that the basic functionality of intercepting MLD packets, and building membership lists and multicast router lists, is the same as for IGMP.
IGMPセクションの制御とデータ転送ルールは、いくつかの考慮事項でも、MLDに適用することができます。これは、MLDパケット、および建物の会員リストおよびマルチキャストルータリストを傍受の基本的な機能は、IGMPの場合と同じであることを意味しています。
In IPv6, the data forwarding rules are more straight forward because MLD is mandated for addresses with scope 2 (link-scope) or greater. The only exception is the address FF02::1 which is the all hosts link-scope address for which MLD messages are never sent. Packets with the all hosts link-scope address should be forwarded on all ports.
MLDは、スコープ2（リンクスコープ）以上とアドレスについて義務付けられているため、IPv6では、データ転送ルールは、より単純です。唯一の例外は、アドレスFF02 :: 1 MLDメッセージが送信されることはありませんされているすべてのホストリンクスコープのアドレスです。すべてのホストリンクスコープアドレスを持つパケットはすべてのポートで転送する必要があります。
MLD messages are also not sent regarding groups with addresses in the range FF00::/15 (which encompasses both the reserved FF00::/16 and node-local FF01::/16 IPv6 address spaces). These addresses should never appear in packets on the link.
MLDメッセージはまた、範囲FF00にアドレスを持つグループについて送信されない:: / 15（予約FF00 :: / 16とノードローカルFF01 :: / 16のIPv6アドレス空間の両方を包含します）。これらのアドレスは、リンク上のパケットに表示されることはありません。
Equivalent to the IPv4 behaviors regarding the null IP Source address, MLD membership reports must not be rejected by an MLD snooping switch because of an unspecified IP source address (::). Additionally, if a non-Querier switch spoofs any General Queries (as addressed in Section 2.1 above, for Spanning Tree topology changes), the switch should use the null IP source address (::) when sending said queries. When such proxy queries are received, they must not be included in the Querier election process.
ヌルIPソースアドレスについてのIPv4行動に相当、MLDメンバーシップレポートが原因で不特定のIP送信元アドレス（のMLDスヌーピングスイッチによって拒否されてはならない：:)。クエリを言っ送信するとき:)：（スパニングツリートポロジの変更のために、上記の2.1節で取り上げたように）非クエリアスイッチは、任意の一般的なクエリを偽装した場合また、スイッチはヌルIP送信元アドレスを（使用する必要があります。そのようなプロキシクエリが受信されると、彼らはクエリア選択プロセスに含まれてはいけません。
The three major differences between IPv4 and IPv6 in relation to multicast are:
マルチキャストに関連して、IPv4とIPv6の間の3つの主な違いは以下のとおりです。
- The IPv6 protocol for multicast group maintenance is called Multicast Listener Discovery [MLDv2]. MLDv2 uses ICMPv6 message types instead of IGMP message types.
- マルチキャストグループの維持のためのIPv6プロトコルが呼び出されたマルチキャストリスナ発見【のMLDv2]。 MLDv2のではなく、IGMPメッセージタイプのICMPv6メッセージタイプを使用しています。
- The RFCs [IPV6-ETHER] and [IPV6-FDDI] describe how 32 of the 128 bit DIP addresses are used to form the 48 bit DMAC addresses for multicast groups, while [IPV6-TOKEN] describes the mapping for token ring DMAC addresses by using three low-order bits. The specification [IPV6-1394] makes use of a 6 bit channel number.
- のRFC [IPV6 - エーテル]及び[IPV6-FDDI]は[IPV6-TOKEN]は、トークンリングDMACアドレスのマッピングを説明しながら32の128ビットDIPアドレスは、マルチキャストグループのための48ビットDMACアドレスを形成するために使用される方法を説明します下位3ビットを使用することによって。仕様は、[IPV6-1394] 6ビットのチャネル番号を利用します。
- Multicast router discovery is accomplished using the Multicast Router Discovery Protocol (MRDISC) defined in [MRDISC].
- マルチキャストルータ発見は[MRDISC]で定義されたマルチキャストルータ発見プロトコル（MRDISC）を使用して達成されます。
The IPv6 packet header does not include a checksum field. Nevertheless, the switch should detect other packet integrity issues such as address version and payload length consistencies if possible. When the snooping switch detects such an error, it must not include information from the corresponding packet in the MLD forwarding table. The forwarding code should instead drop the packet and take further reasonable actions as advocated above.
IPv6パケットヘッダーは、チェックサムフィールドを含んでいません。可能であればそれにも関わらず、スイッチは、このようなアドレスバージョンとペイロード長の一貫性などの他のパケットの整合性の問題を検出する必要があります。スヌーピングスイッチは、このようなエラーを検出すると、MLD転送テーブル内の対応するパケットからの情報を含んではなりません。転送コードは、代わりにパケットをドロップし、上記の主張のように、さらに合理的な行動を取るべきです。
The fact that MLDv2 is using ICMPv6 adds new requirements to a snooping switch because ICMPv6 has multiple uses aside from MLD. This means that it is no longer sufficient to detect that the next-header field of the IP header is ICMPv6 in order to identify packets relevant for MLD snooping. A software-based implementation which treats all ICMPv6 packets as candidates for MLD snooping could easily fill its receive queue and bog down the CPU with irrelevant packets. This would prevent the snooping functionality from performing its intended purpose and the non-MLD packets destined for other hosts could be lost.
ICMPv6のは、MLDは別に複数の用途を持っているためのMLDv2がICMPv6の使用しているという事実は、スヌーピングスイッチに新しい要件を追加します。 IPヘッダの次ヘッダフィールドは、MLDスヌーピングに関連するパケットを識別するために、ICMPv6のあることを検出することはもはや十分ではないことを意味します。 MLDスヌーピングの候補として、すべてのICMPv6パケットを扱うソフトウェアベースの実装が簡単にその受信キューを記入し、無関係なパケットでCPUを行き詰まらことができます。これは、その意図された目的を実行することからスヌーピング機能を妨げるし、他のホスト宛ての非MLDパケットが失われる可能性があります。
A solution is either to require that the snooping switch looks further into the packets, or to be able to detect a multicast DMAC address in conjunction with ICMPv6. The first solution is desirable when a configuration option allows the administrator to specify which ICMPv6 message types should trigger a CPU redirect and which should not. The reason is that a hardcoding of message types is inflexible for the introduction of new message types. The second solution introduces the risk that new protocols that use ICMPv6 and multicast
溶液スヌーピングスイッチがパケットにさらに見える、またはICMPv6のと併せてマルチキャストDMACアドレスを検出できるようにすることを必要とするかのいずれかです。設定オプションは、ICMPv6メッセージタイプがCPUのリダイレクトをトリガする必要があり、どれがないかを指定するには、管理者が許可する場合に最初の溶液が望ましいです。その理由は、メッセージタイプのハードコーディングは、新しいメッセージタイプの導入のための柔軟性がないことです。第2の解決策は、新しいプロトコルがICMPv6のマルチキャストを使用する危険性を紹介します
DMAC addresses could be incorrectly identified as MLD. It is suggested that solution one is preferred when the configuration option is provided. If this is not the case, then the implementor should seriously consider making it available since Neighbor Discovery messages would be among those that fall into this false positive case and are vital for the operational integrity of IPv6 networks.
DMACアドレスが間違ってMLDとして識別することができます。コンフィギュレーションオプションが提供されたときにソリューションの1が好ましいことが示唆されます。そうでない場合は、実装者は真剣に近隣探索メッセージがこの偽陽性のケースに分類し、IPv6ネットワークの動作の完全性のために不可欠なものの一つであるであろうから、それを利用可能にすることを検討すべきです。
The mapping from IP multicast addresses to multicast DMAC addresses introduces a potentially enormous overlap. The structure of an IPv6 multicast address is shown in the figure below. As a result, there are 2 ** (112 - 32), or more than 1.2e24 unique DIP addresses which map into a single DMAC address in Ethernet and FDDI. This should be compared to 2**5 in the case of IPv4.
DMACアドレスをマルチキャストするIPマルチキャストアドレスからのマッピングは、潜在的に膨大な重複を導入します。 IPv6マルチキャストアドレスの構造は、以下の図に示されています。イーサネットおよびFDDIにおける単一DMACアドレスにマッピング以上1.2e24ユニークDIPアドレスが、又は - 結果として、そこ2 **（32 112）です。これは、IPv4の場合に** 5 2と比較すべきです。
Initial allocation of IPv6 multicast addresses, as described in [RFC3307], however, cover only the lower 32 bits of group ID. While this reduces the problem of address ambiguity to group IDs with different flag and scope values for now, it should be noted that the allocation policy may change in the future. Because of the potential overlap it is recommended that IPv6 address based forwarding is preferred to MAC address based forwarding.
[RFC3307]に記載されているようにIPv6マルチキャストアドレスの初期割り当ては、しかし、グループIDの下位32ビットのみを覆います。これは今のところ、異なるフラグと範囲の値を持つグループIDに対してアドレスの曖昧さの問題を低減しつつ、割当てポリシーが将来変更される可能性があることに留意すべきです。なぜなら潜在的重複はIPv6アドレスベースの転送は、MACアドレスベースの転送に好適であることが推奨されます。
| 8 | 4 | 4 | 112 bits |
+--------+----+----+---------------------------------------+
|11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------+
As part of this work, the following questions were asked on the MAGMA discussion list and were sent to known switch vendors implementing IGMP snooping. The individual contributions have been anonymized upon request and do not necessarily apply to all of the vendors' products.
この作業の一環として、以下の質問は、MAGMAのディスカッションリストに頼まれたとIGMPスヌーピングを実装知られているスイッチ・ベンダーに送られました。個々の寄与は、要求に応じて匿名化されており、必ずしもベンダーの製品のすべてに適用されません。
The questions were:
質問は以下の通りでした。
Q1 Do your switches perform IGMP Join aggregation? In other words, are IGMP joins intercepted, absorbed by the hardware/software so that only one Join is forwarded to the querier?
Q1あなたのスイッチは、IGMPは、集計に参加行いますか？つまり、IGMPは一つだけが参加するようなハードウェア/ソフトウェアで吸収、傍受のジョインは、クエリアに転送されていますか？
Q2 Is multicast forwarding based on MAC addresses? Would datagrams addressed to multicast IP addresses 224.1.2.3 and 239.129.2.3 be forwarded on the same ports-groups?
Q2は、MACアドレスに基づいてマルチキャスト転送ですか？ポート・グループと同じに転送されたデータグラムは、マルチキャストIPアドレスの224.1.2.3と239.129.2.3宛でしょうか？
Q3 Is it possible to forward multicast datagrams based on IP addresses (not routed)? In other words, could 224.1.2.3 and 239.129.2.3 be forwarded on different port-groups with unaltered TTL?
Q3それはIPアドレス（ルーティングされない）に基づいて、マルチキャストデータグラムを転送することは可能ですか？言い換えれば、224.1.2.3ができ、239.129.2.3は変更TTLと異なるポートグループに転送されますか？
Q4 Are multicast datagrams within the range 224.0.0.1 to 224.0.0.255 forwarded on all ports whether or not IGMP Joins have been sent?
Q4 IGMPが送られてきたジョインかどうかに関係なく、すべてのポートに転送さ224.0.0.255に範囲224.0.0.1内マルチキャストデータグラムはありますか？
Q5 Are multicast frames within the MAC address range 01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports whether or not IGMP joins have been sent?
Q5 MACアドレス範囲内のマルチキャストフレームは01です：00：5E：00：00：00：01 01 5E：00：00：FF IGMPが送られてきた参加するかどうかに関係なく、すべてのポートに転送？
Q6 Does your switch support forwarding to ports on which IP multicast routers are attached in addition to the ports where IGMP Joins have been received?
Q6は、IPマルチキャストルータはIGMPが受信されたジョインポートのほかに添付されているポートに、スイッチのサポート転送をしていますか？
Q7 Is your IGMP snooping functionality fully implemented in hardware?
Q7は、完全にハードウェアに実装あなたのIGMPスヌーピング機能ですか？
Q8 Is your IGMP snooping functionality partly software implemented?
Q8あなたのIGMPは、一部のソフトウェアが実装される機能を詮索されていますか？
Q9 Can topology changes (for example spanning tree configuration changes) be detected by the IGMP snooping functionality so that for example new queries can be sent or tables can be updated to ensure robustness?
Q9は、例えば新しいクエリを送信することができますまたはテーブルは堅牢性を確保するために更新することができるようにIGMPスヌーピング機能によって検出される（ツリー構成の変更にまたがるなど）の変更をトポロジすることはできますか？
The answers were:
---------------------------+-----------------------+
| Switch Vendor |
---------------------------+---+---+---+---+---+---+
| 1 | 2 | 3 | 4 | 5 | 6 |
---------------------------+---+---+---+---+---+---+
Q1 Join aggregation | x | x | x | | x | x |
Q2 Layer-2 forwarding | x | x | x | x |(1)| |
Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x |
Q4 224.0.0.X aware |(1)| x |(1)|(2)| x | x |
Q5 01:00:5e:00:00:XX aware | x | x | x |(2)| x | x |
Q6 Mcast router list | x | x | x | x | x | x |
Q7 Hardware implemented | | | | | | |
Q8 Software assisted | x | x | x | x | x | x |
Q9 Topology change aware | x | x | x | x | |(2)|
---------------------------+---+---+---+---+---+---+
x Means that the answer was Yes.
(1) In some products (typically high-end) Yes; in others No.
(2) Not at the time that the questionnaire was received
but expected in the near future.
[BRIDGE] IEEE Std. 802.1D-2004 IEEE Standard for Local and metropolitan area networks, Media Access Control (MAC) Bridges
[ブリッジ] IEEE STD。 802.1D-2004ローカルおよびメトロポリタンエリアネットワークのためのIEEE規格、メディアアクセス制御（MAC）ブリッジ
[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月。
[IPV6-1394] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets over IEEE 1394 Networks", RFC 3146, October 2001.
[IPV6-1394]藤沢、K.とA.尾上、RFC 3146、2001年10月 "1394ネットワークの上のIPv6パケットのトランスミッション"。
[IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[IPV6-ETHER]クロフォード、M.、 "イーサネットネットワークの上のIPv6パケットのトランスミッション"、RFC 2464、1998年12月。
[IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, December 1998.
[IPV6-FDDI]クロフォード、M.、 "FDDIネットワークの上のIPv6パケットの送信"、RFC 2467、1998年12月。
[IPV6-TOKEN] Crawford, M., Narten, T., and S. Thomas, "Transmission of IPv6 Packets over Token Ring Networks", RFC 2470, December 1998.
[IPV6-TOKEN]クロフォード、M.、Narten氏、T.、およびS.トーマス、 "トークンリングネットワークの上のIPv6パケットの送信"、RFC 2470、1998年12月。
[MLD] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
"IPv6のためのマルチキャストリスナー発見（MLD）" [MLD]デアリング、S.、フェナー、W.、およびB.ハーバーマン、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月。
[MRDISC] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005.
【MRDISC]ハーバーマン、B.及びJ.マーチン、 "マルチキャストルータ発見"、RFC 4286、2005年12月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、1989年8月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236]フェナー、W.、 "インターネットグループ管理プロトコル、バージョン2"、RFC 2236、1997年11月。
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[RFC3307]ハーバーマン、B.、 "IPv6マルチキャストアドレスの割り当てに関するガイドライン"、RFC 3307、2002年8月。
[CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP and IGMP snooping", http://www.cisco.com/warp/public/473/22.html
[CISCO]シスコテクニカルノート、 "キャンパスネットワークにおけるマルチキャスト：CGMPとIGMPスヌーピング"、http://www.cisco.com/warp/public/473/22.html
[IETF56] Briefing by Dave Thaler, Microsoft, presented to the MAGMA WG at the 56'th IETF meeting in San Francisco, http://www.ietf.org/proceedings/03mar/index.html
[IETF56]デーブターラー、マイクロソフトによるブリーフィングはhttp://www.ietf.org/proceedings/03mar/index.html、サンフランシスコで56'th IETFミーティングでMAGMA WGに提示します
[MSOFT] Microsoft support article Q223136, "Some LAN Switches with IGMP Snooping Stop Forwarding Multicast Packets on RRAS Startup", http://support.microsoft.com/ support/articles/Q223/1/36.ASP
[MSOFT] Microsoftのサポート記事Q223136、http://support.microsoft.com/サポート/記事/ Q223 / 1 / 36.ASP "いくつかのLANは、RRAS起動時にIGMPスヌーピングストップフォワーディングマルチキャストパケットをスイッチ"
Under normal network operation, the snooping switch is expected to improve overall network performance by limiting the scope of multicast flooding to a smaller portion of the local network. In the event of forged IGMP messages, the benefits of using a snooping switch might be reduced or eliminated.
通常のネットワーク動作の下で、スヌーピングスイッチは、ローカルネットワークの小さな部分にマルチキャストフラッディングの範囲を制限することによって、ネットワーク全体のパフォーマンスを向上することが期待されます。偽造IGMPメッセージのイベントでは、スヌーピングスイッチを使用する利点は、低減または排除される可能性があります。
Security considerations for IGMPv3 at the network layer of the protocol stack are described in [IGMPv3]. The introduction of IGMP snooping functionality does not alter the handling of multicast packets by the router as it does not make use of link layer information.
プロトコルスタックのネットワーク層でのIGMPv3のためのセキュリティ問題は[IGMPv3の]に記載されています。それがリンク層情報を利用しないようIGMPスヌーピング機能の導入は、ルータによってマルチキャストパケットの取り扱いを変更しません。
There are, however, changes in the way that the IGMP snooping switch handles multicast packets within the local network. In particular:
IGMPスヌーピングスイッチは、ローカルネットワーク内のマルチキャストパケットを処理する方法の変更は、しかし、があります。特に：
- A Query message with a forged source address which is less than that of the current Querier could cause snooping switches to forward subsequent Membership reports to the wrong network interface. It is for this reason that IGMP Membership Reports should be sent to all multicast routers as well as the current Querier.
- 現在の質問者のそれよりも低い偽造送信元アドレスを持つクエリメッセージは、誤ったネットワークインタフェースに、後続のメンバーシップレポートを転送するためのスイッチをスヌーピング引き起こす可能性があります。これは、IGMPメンバーシップレポートは、すべてのマルチキャストルータだけでなく、現在の質問者に送信されなければならないのはこのためです。
- It is possible for a host on the local network to generate Current-State Report Messages that would cause the switch to incorrectly believe that there is a multicast listener on the same network segment as the originator of the forged message. This will cause unrequested multicast packets to be forwarded into the network segments between the source and the router. If the router requires that all Multicast Report messages be authenticated as described in section 9.4 of [IGMPv3], it will discard the forged Report message from the host inside the network in the same way that it would discard one which originates from a remote location. It is worth noting that if the router accepts unauthenticated Report messages by virtue of them having arrived over a network interface associated with the internal network, investigating the affected network segments will quickly narrow the search for the source of the forged messages.
- ローカルネットワーク上のホストが誤って偽造メッセージの発信元と同じネットワークセグメント上のマルチキャストリスナーがあることを信じるようにスイッチを引き起こす現在のステートレポート・メッセージを生成することが可能です。これは、非要求マルチキャストパケットが送信元とルータ間のネットワークセグメントに転送されるようになります。ルータは[IGMPv3の]のセクション9.4に記載されているようにすべてのマルチキャスト報告メッセージが認証されることを必要とする場合、それは遠隔地から発信一方を捨てることになるのと同じようにネットワーク内のホストから鍛造報告メッセージを廃棄します。これは、ルータがそれらによって認証されていないレポートメッセージを受け入れるかどうかすぐに偽造されたメッセージのソースの検索が狭くなります影響を受けたネットワークセグメントを調査し、内部ネットワークに関連付けられたネットワーク・インターフェースを介して到着したことは注目に値します。
- As noted in [IGMPv3], there is little motivation for an attacker to forge a Membership report message since joining a group is generally an unprivileged operation. The sender of the forged Membership report will be the only recipient of the multicast traffic to that group. This is in contrast to a shared LAN segment (HUB) or network without snooping switches, where all other hosts on the same segment would be unable to transmit when the network segment is flooding the unwanted traffic.
- 【のIGMPv3]で述べたように、グループに参加することは、一般的に権限のない操作であるので、メンバシップレポートメッセージを偽造する攻撃者のために少し動機があります。偽造メンバーシップレポートの送信者は、そのグループへのマルチキャストトラフィックの受信者のみとなります。これは、同じセグメント上の他のすべてのホストがネットワークセグメントが不要なトラフィックをフラッディングされたときに送信することができないスヌーピングスイッチ、なしの共有LANセグメント（HUB）またはネットワークとは対照的です。
The worst case result for each attack would remove the performance improvements that the snooping functionality would otherwise provide. It would, however, be no worse than that experienced on a network with switches that do not perform multicast snooping.
各攻撃のための最悪の結果は、スヌーピング機能は、それ以外の提供するパフォーマンスの向上を削除します。それは、しかし、それはマルチキャストスヌーピングを実行しないスイッチとネットワーク上で経験したよりも、何も悪いことしないでしょう。
We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben Carter, Paul Congdon, Toerless Eckert, Bill Fenner, Brian Haberman, Edward Hilquist, Hugh Holbrook, Kevin Humphries, Isidor Kouvelas, Pekka Savola, Suzuki Shinsuke, Jaff Thomas, Rolland Vida, and Margaret Wasserman for comments and suggestions on this document.
私たちは、マーティン・バク、レベル、Yiqunカイ、ベン・カーター、ポールコングドン、Toerlessエッカート、ビルフェナー、ブライアンハーバーマン、エドワードHilquist、ヒュー・ホルブルック、ケビン・ハンフリーズ、イジドールKouvelas、ペッカSavola、鈴木伸介、Jaffトーマスに感謝したいと思いますこのドキュメントに関するコメントや提案のためのロランビーダ、およびマーガレットワッサーマン。
Furthermore, the following companies are acknowledged for their contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks, Hewlett-Packard, Vitesse Semiconductor Corporation, Thrane & Thrane. The ordering of these names do not necessarily correspond to the column numbers in the response table.
3Com社、アルカテル、シスコシステムズ、エンテラシスネットワークス、ヒューレット・パッカード、ビテッセセミコンダクターコーポレーション、トラーネ＆トラーネ：さらに、以下の企業は、彼らの貢献のために認められています。これらの名前の順序は、必ずしも応答テーブルの列番号に対応していません。
Authors' Addresses
著者のアドレス
Morten Jagd Christensen Thrane & Thrane Lundtoftegaardsvej 93 D 2800 Lyngby DENMARK
モルテンミノテルヤークト・クリステンセントラーネ＆トラーネLundtoftegårdsvej93 D 2800リンビーデンマーク
EMail: mjc@tt.dk
メールアドレス：mjc@tt.dk
Karen Kimball Hewlett-Packard 8000 Foothills Blvd. Roseville, CA 95747 USA
カレン・キンボールヒューレット・パッカード8000フットヒルズブルバードローズ、CA 95747 USA
EMail: karen.kimball@hp.com
メールアドレス：karen.kimball@hp.com
Frank Solensky Calix 43 Nanog Park Acton, MA 01720 USA
フランクSolenskyカリックス43 Nanogの公園アクトン、MA 01720 USA
EMail: frank.solensky@calix.com
メールアドレス：frank.solensky@calix.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）によって提供されます。