[要約] RFC 4541は、IGMPおよびMLDスヌーピングスイッチに関する考慮事項を提供する。その目的は、マルチキャストトラフィックの効率的な配信を実現するために、スイッチの設計と実装に関するガイドラインを提供することである。
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
インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリー（MLD）スヌーピングスイッチに関する考慮事項
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).
Copyright（c）The Internet Society（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）およびマルチキャストリスナーディスカバリー（MLD）スヌーピングスイッチの推奨事項について説明しています。これらは、IgMPv3-およびMLDV2-Snoopingについてさらに考慮して、IgMPv2の最良の現在のプラクティスに基づいています。リンクレイヤートポロジの変更やイーサネット固有のカプセル化の問題など、関連性のある追加領域も考慮されます。
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 Standard [Bridge]は、LANパケットが「ブリッジ」されている方法、またはより一般的に使用されているように、LANセグメント間に切り替えられている方法を指定しています。マルチキャストパケットに関するスイッチの操作は、次のように要約できます。宛先MACアドレスがマルチキャストアドレスであるパケットを処理する場合、スイッチは[ブリッジ]に従って転送状態にある残りの各ネットワークインターフェイスにパケットのコピーを転送します。Spanningツリーアルゴリズムにより、ネットワーク内のすべてのスイッチでこのルールを適用すると、ネットワークに接続されたすべてのノードがパケットにアクセスできるようになります。
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]、ベンダーがサポートした技術文書[シスコ]、バグは[MSOFT]、[MSOFT]、関係者との議論を報告します。IGMPスヌーピングスイッチ、マグマメーリングリストのディスカッション、およびスイッチベンダーによる実装アンケートへの返信。
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.
このドキュメントの提案は、IGMPに基づいており、IPv4にのみ適用されます。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スヌーピングスイッチは、IPv6トラフィックから学んだトポロジ情報を使用して、IPv4マルチキャストパケットの転送を変更することを思いとどまらせます。
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]で説明されているように、マルチキャストルーター勧誘メッセージを送信するスヌーピングスイッチによって構築する必要があります。また、他のノードから送信されたマルチキャストルーター広告メッセージをSnoopする場合があります。
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アドレスを使用していません（たとえ存在していても）。0.0.0.0アドレスは、クエリパケットがマルチキャストルーターからのものではないことを示すために使用されます。
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ソースアドレスを使用する場合があります。このため、Snooping Switchで受信したIGMPメンバーシップレポートは、ソースIPアドレスが0.0.0.0に設定されているため、拒否されてはなりません。
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クエリメッセージに過負荷になっているが、ヘッダーが拡張されているからです。したがって、IGMPV3クエリは、たとえばIGMPV2スヌーピングスイッチによって古いバージョンクエリとして解釈される可能性があるリスクがあります。これはすでに報告されており[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スヌーピングスイッチは、スパニングツリー操作によって引き起こされるリンクレイヤートポロジの変更に注意する必要があります。スパニングツリーによってポートが有効または無効になっている場合、ネットワークの収束時間を短縮するために、すべてのアクティブな非ルーターポートで一般的なクエリを送信できます。querierがquerierがIgmpv3モードであるかどうかを認識する必要があります。その場合、スイッチは、真のクエリエが送信した最新の情報を順守するIGMPV3クエリを送信できない限り、一般的なクエリをスプーフィングしてはなりません。いかなる場合でも、スイッチがスプーフィングされたIGMPV2クエリをIGMPV3ネットワークに導入する必要があります。これにより、過剰なネットワークの破壊が生じる可能性があります。
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.
スイッチがクエリエでない場合は、これらのプロキシクエリで「全ゼロ」IPソースアドレスを使用する必要があります（一部のホストは0.0.0.0 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パケットで情報を使用してはなりません。スイッチはそのようなパケットをflood濫させるべきではありませんが、もしそうなら、イベントのメモ（つまり、カウンターを増やす）も取得する必要があります。これらのエラーとその処理については、[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スヌーピング機能です。実装が実行できるアプローチの1つは、ソフトウェア内の個別のメンバーシップとマルチキャストルーターテーブルを維持し、これらのテーブルを転送キャッシュに「マージ」することです。
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.
2) IGMPではない224.0.0.x範囲の宛先IP（DIP）アドレスを備えたパケットは、すべてのポートに転送する必要があります。
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バージョンをサポートする環境では、未登録のストリームに浸水する可能性があります。グループ。
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ホストで構成されるグループが完全に個別のグループであるという事実の結果です。その結果、IPv4グループのメンバー間でトポロジーを形成する場合、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.
7) IGMPV3「含まれるソース」および「除外ソース」メンバーシップレポートを共有セグメントで受信する場合、スイッチは、受け取ったすべてのメンバーシップレポートのスーパーセットを共有セグメントに転送する必要があります。特定のソースSからグループGへのトラフィックの転送は、共有セグメントの少なくとも1つのホストが、タイプのIGMPV3メンバーシップに（g、slist1）または除外（g、slist2）が含まれる場合、Sはの要素です。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、...）ベースのデータ転送表の実際の実装は、このドキュメントの範囲内ではありません。ただし、1つの可能性は、2つの（g、s）転送リストを維持することです。1つは、転送が発生する前に特定の（g、s）の一致が必要なフィルターを含む1つ、もう1つは、aの一致が一致するフィルターを除外するために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ルーターとIgMPv2およびIgMPV3ホストからなるネットワークでは、最近報告されたIGMPV2スヌーピングスイッチによって相互接続されたホスト[IETF56]で構成されるネットワークで特別な問題が発生します。ルーターは、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.
IPv6では、MLDはScope 2（Link-Scope）以上のアドレスに義務付けられているため、データ転送ルールはより単純です。唯一の例外は、MLDメッセージが送信されないすべてのホストリンクスコープアドレスであるアドレスFF02 :: 1です。すべてのホストリンクスコープアドレスを備えたパケットは、すべてのポートに転送する必要があります。
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.
NULL IPソースアドレスに関するIPv4の動作に相当すると、MLDメンバーシップレポートは、不特定のIPソースアドレス（：:)のためにMLDスヌーピングスイッチによって拒否されてはなりません。さらに、非queierスイッチが一般的なクエリをスプーフィングする場合（上記のセクション2.1で説明されているように、スパニングツリートポロジの変更について）、スイッチは、そのクエリを送信するときにnull 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.
- RFCS [IPV6-ETHER]および[IPv6-FDDI]は、128ビットDIPアドレスのうち32がマルチキャストグループの48ビットDMACアドレスを形成する方法を説明し、[IPv6-Token]はトークンリング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.
MLDV2がICMPV6を使用しているという事実は、ICMPV6にはMLD以外の複数の用途があるため、スヌーピングスイッチに新しい要件を追加します。これは、MLDスヌーピングに関連するパケットを識別するために、IPヘッダーの次のヘッダーフィールドがICMPv6であることを検出するだけでは不十分であることを意味します。すべてのICMPV6パケットをMLDスヌーピングの候補として扱うソフトウェアベースの実装は、受信キューを簡単に埋め、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 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.
解決策は、スヌーピングスイッチがパケットをさらに覗くことを要求するか、ICMPv6と併せてマルチキャストDMACアドレスを検出できることを要求することです。最初のソリューションは、構成オプションを使用すると、管理者がどのICMPV6メッセージタイプがCPUリダイレクトをトリガーするかを指定できる場合に望ましいものです。その理由は、メッセージタイプのハードコードが新しいメッセージタイプの導入に柔軟性がないためです。2番目のソリューションは、ICMPV6およびマルチキャスト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.
IPマルチキャストアドレスからマルチキャストDMACアドレスまでのマッピングは、潜在的に大きなオーバーラップを導入します。IPv6マルチキャストアドレスの構造を下の図に示します。その結果、2 **（112-32）、つまり1.2E24を超える一意のDIPアドレスがあり、イーサネットとFDDIの単一のDMACアドレスにマッピングされます。これは、IPv4の場合は2 ** 5と比較する必要があります。
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.
この作業の一環として、次の質問がマグマディスカッションリストで尋ねられ、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は結合され、ハードウェア/ソフトウェアに吸収され、1つの結合のみがクエリエに転送されるように結合されていますか？
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.1から224.0.0.255の範囲内のマルチキャストデータグラムですか？
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?
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 Switchは、IGMP結合が受信されたポートに加えて、IPマルチキャストルーターが取り付けられているポートへの転送をサポートしていますか？
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] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、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] Fujisawa、K。およびA. Onoe、「IEEE 1394ネットワーク上のIPv6パケットの送信」、RFC 3146、2001年10月。
[IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[IPv6-Ether] Crawford、M。、「イーサネットネットワーク上のIPv6パケットの送信」、RFC 2464、1998年12月。
[IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, December 1998.
[IPv6-Fddi] Crawford、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] Crawford、M.、Narten、T。、およびS. Thomas、「トークンリングネットワーク上のIPv6パケットの送信」、RFC 2470、1998年12月。
[MLD] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[MLD] 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月。
[MRDISC] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005.
[Mrdisc] Haberman、B。and J. Martin、「マルチキャストルーターディスカバリー」、RFC 4286、2005年12月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、1997年11月。
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[RFC3307] Haberman、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] Cisco Techノート、「キャンパスネットワークのマルチキャスト：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] MicrosoftのDave Thalerによるブリーフィングは、サンフランシスコでの56'th IETF会議でマグマ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、「IGMPスヌーピングを備えたいくつかのLANスイッチRRASスタートアップでマルチキャストパケットを転送する停止」、http://support.microsoft.com/サポート/記事/Q223/1/36.asp
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.
- ローカルネットワーク上のホストが、SwitchがForgedメッセージの発信者と同じネットワークセグメントにマルチキャストリスナーがいると誤って信じている現在の状態レポートメッセージを生成することが可能です。これにより、レイズされていないマルチキャストパケットがソースとルーターの間のネットワークセグメントに転送されます。[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セグメント（ハブ）またはネットワークとは対照的です。
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 Cai、Ben Carter、Paul Congdon、Toerless Eckert、Bill Fenner、Brian Haberman、Edward Hilquist、Hugh Holbrook、Kevin Humphries、Isidor Kouvelas、Pekka Savola、Suzuki shinsuke、Jaff ThomasRolland VidaとMargaret Wassermanは、この文書に関するコメントと提案について。
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、Alcatel、Cisco Systems、Enterasys Networks、Hewlett-Packard、Vitesse Semiconductor Corporation、Thrane＆Thraneの貢献について、以下の企業が貢献について認められています。これらの名前の順序付けは、応答表の列番号に必ずしも対応するものではありません。
Authors' Addresses
著者のアドレス
Morten Jagd Christensen Thrane & Thrane Lundtoftegaardsvej 93 D 2800 Lyngby DENMARK
Morten Jagd Christensen Thrane＆Thrane Lundtoftegaardsvej 93 D 2800 Lyngby Denmark
EMail: mjc@tt.dk
Karen Kimball Hewlett-Packard 8000 Foothills Blvd. Roseville, CA 95747 USA
Karen Kimball Hewlett-Packard 8000 Foothills Blvd.カリフォルニア州ローズビル95747米国
EMail: karen.kimball@hp.com
Frank Solensky Calix 43 Nanog Park Acton, MA 01720 USA
フランク・ソレンスキー・カリックス43ナノグ・パーク・アクトン、マサチューセッツ州01720 USA
EMail: frank.solensky@calix.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）によって提供されます。