メインコンテンツまでスキップ

2. IGMP スヌーピングに関する推奨事項 (IGMP Snooping Recommendations)

以下の各節では、IGMP スヌーピングスイッチに対する推奨事項を列挙する。推奨事項を示したうえで、考えられる実装方法の説明を補足する。実装に関する議論はすべて例示であり、同じ機能を実現する別の方法が存在しうる。

2.1. 転送規則 (Forwarding Rules)​

IGMP スヌーピング機能は、制御部分(IGMP 転送)とデータ部分(データ転送)に分けられる。

2.1.1. IGMP 転送規則 (IGMP Forwarding Rules)​

  1. スヌーピングスイッチは、IGMP メンバーシップレポートを、マルチキャストルータが接続されているポートにのみ転送すべきである (SHOULD)。

別の言い方をすれば、スヌーピングスイッチは、ホストのみが接続されているポートに IGMP メンバーシップレポートを転送すべきではない (SHOULD NOT)。この制限を上書きし、レポートメッセージを他のポートにフラッディングできるようにする管理制御を提供してもよい。

これが制御パスにおける IGMP スヌーピングの主要な機能である。

IGMPv1 および IGMPv2 では、メンバーシップレポートを他のホストに送信すると、あるホストが特定のマルチキャストグループに参加できなくなるという意図しない結果を招きうる。IGMPv1 または IGMPv2 のホストは、参加しようとしているグループアドレスのメンバーシップレポートを受信すると、同じグループに対する自身のメンバーシップレポートを抑制する。この参加(メッセージ)抑制は IGMPv1 および IGMPv2 ホストの要件である。しかし、スイッチがそのホストからメンバーシップレポートを受信しない場合、そのホストにマルチキャストデータを転送しない。

IGMPv3 のみのネットワークでは IGMP メンバーシップレポートの抑制が存在しないため、この問題は生じない。

この管理制御により、IGMP メンバーシップレポートメッセージをパケットアナライザやポートレプリケータなどのネットワーク監視装置で処理できるようになる。

IGMP スヌーピングをサポートするスイッチは、マルチキャストルータとそれらが接続されているポートの一覧を維持しなければならない (MUST)。この一覧は、以下の方法の任意の組み合わせで構築できる:

  • a) この一覧は、IGMP マルチキャストルータディスカバリ [MRDISC] に記述されているマルチキャストルータ要請 (Multicast Router Solicitation) メッセージをスヌーピングスイッチが送信することによって構築すべきである (SHOULD)。また、他のノードとの間で送信されるマルチキャストルータ通知 (Multicast Router Advertisement) メッセージをスヌープしてもよい。

  • b) 送信元アドレスが 0.0.0.0 ではない IGMP クエリ(マルチキャストルータが送信)の受信ポート。0.0.0.0 アドレスは、スイッチがネットワーク収束を高速化するために IGMP クエリを代理送信しているが、自身がクエリアではないという特殊なケースを表す。スイッチは自身の IP アドレスを使用しない(たとえ保持していても)。これを使用すると、クエリが新たに選出されたクエリアから来たものと見なされるためである。0.0.0.0 アドレスは、そのクエリパケットがマルチキャストルータからのものではないことを示すために使用される。

  • c) 上記のルータポート検出方法に加えて、またはそれに代えて、管理によって IGMP 転送ポートとして明示的に設定されたポート。

  1. IGMP ネットワークには、「代理報告 (proxy-reporting)」を実装する装置が含まれることがある。これは、下流のホストから受信したレポートを要約し、内部のメンバーシップ状態の構築に使用するものである。このような代理報告装置は、要約したレポートを上流へ転送する際に全ゼロの IP 送信元アドレスを使用することがある。このため、スヌーピングスイッチが受信した IGMP メンバーシップレポートは、送信元 IP アドレスが 0.0.0.0 であることを理由に拒否されてはならない (MUST NOT)。

  2. IGMP スヌーピングをサポートするスイッチは、認識できないすべての IGMP メッセージを他のすべてのポートにフラッディングしなければならず (MUST)、ネットワーク層ヘッダの終端を超えた情報を利用しようとしてはならない (MUST NOT)。

さらに、古いバージョンの IGMP は、それぞれのバージョンで定義されたとおりに IGMP フィールドを解釈すべきであり、メッセージを転送する際にこれらのフィールドを変更してはならない (MUST NOT)。新しいメッセージを生成する場合、ある IGMP バージョンは自身のバージョンに適した値をフィールドに設定すべきである (SHOULD)。ある IGMP バージョンにとって予約済みまたは未定義のフィールドがある場合、メッセージの解析時にはそれらを無視し、その IGMP バージョンの実装が新しいメッセージを生成する際にはゼロを設定しなければならない (MUST)。例外は、スイッチがスプーフィング機能を実行しており、別の IGMP バージョン用に正しくスプーフィングするために必要な新規または予約フィールドの設定を把握している場合である。

これらの細部を気にする理由は、IGMPv3 が古い IGMP クエリメッセージと同じタイプ番号 (0x11) を使用しつつ拡張ヘッダを追加して再利用しているためである。したがって、IGMPv3 のクエリが、例えば IGMPv2 スヌーピングスイッチによって古いバージョンのクエリとして解釈される危険がある。これはすでに報告されており [IETF56]、2.2 節で論じられている。

  1. IGMP スヌーピングスイッチは、スパニングツリーの動作によって生じるリンク層のトポロジ変更を認識すべきである (SHOULD)。スパニングツリーによってポートが有効化または無効化されたとき、ネットワーク収束時間を短縮するために、すべてのアクティブな非ルータポート上で一般クエリ (General Query) を送信してもよい。非クエリアスイッチは、クエリアが IGMPv3 モードであるかどうかを認識すべきである (SHOULD)。そうである場合、真のクエリアが送信した最新の情報に準拠した IGMPv3 クエリを送信できるのでなければ、スイッチは一般クエリをスプーフィングすべきではない (SHOULD NOT)。いかなる場合も、スイッチは IGMPv3 ネットワークにスプーフィングされた IGMPv2 クエリを持ち込んではならない。これにより深刻なネットワーク障害が生じうるためである。

スイッチがクエリアでない場合、これらの代理クエリでは「全ゼロ」の IP 送信元アドレスを使用すべきである (SHOULD)。(一部のホストは 0.0.0.0 を送信元とするクエリを処理しないことを選ぶかもしれないが。)そのような代理クエリを受信した場合、クエリア選出プロセスに含めてはならない (MUST NOT)。

  1. IGMP スヌーピングスイッチは、IP ヘッダまたは IGMP ヘッダにチェックサムエラーや完全性エラーがある IGMP パケットの情報を利用してはならない (MUST NOT)。スイッチはそのようなパケットをフラッディングすべきではない (SHOULD NOT) が、もしフラッディングする場合は、その事象を何らかの形で記録すべきである (SHOULD)(例えばカウンタを増やす)。これらのエラーとその処理については、[IGMPv3]、[MLD]、[MLDv2] でさらに論じられている。

  2. スヌーピングスイッチは、転送テーブルからエントリを削除すべき時を判断するために、IGMP グループ離脱 (Group Leave) 通知の出現のみに依存してはならない (MUST NOT)。すべての非ルータポート上で、IGMP および MLD 仕様に記述されている IGMP プロトコルのルータ側機能のようなメンバーシップタイムアウト機構を実装すべきである (SHOULD)(IGMPv1-3 および MLDv1-2 については規定の参照節を参照)。このタイムアウト値は設定可能であるべきである (SHOULD)。

2.1.2. データ転送規則 (Data Forwarding Rules)​

  1. 宛先 IP アドレスが 224.0.0.X の範囲外であり、かつ IGMP ではないパケットは、グループベースのポートメンバーシップテーブルに従って転送すべきであり (SHOULD)、かつルータポート上でも転送しなければならない (MUST)。

これがデータパスにおける IGMP スヌーピングの主要な機能である。実装が取りうる一つの方法は、メンバーシップテーブルとマルチキャストルータテーブルをソフトウェア内で別々に維持し、それらを転送キャッシュに「マージ」することである。

  1. 宛先 IP (DIP) アドレスが 224.0.0.X の範囲内であり、かつ IGMP ではないパケットは、すべてのポートで転送しなければならない (MUST)。

この推奨事項は、多くのホストシステムが IP マルチキャストパケットを送信または受信する前に、この範囲のマルチキャストアドレスへの参加 (Join) を送信しないという事実に基づいている。さらに、224.0.0.X アドレス範囲はリンクローカル(ルーティングされない)と定義されているため、この範囲の各アドレスについて状態を保持する必要はないと考えられる。加えて、一部のルータは IGMP 参加を発行せずに 224.0.0.X アドレス範囲で動作しており、スイッチがそのルータから参加グループメッセージを見ていないことを理由にこれらを剪定すると、これらのアプリケーションは動作しなくなる。

  1. 未登録パケットとは、宛先アドレスが以前の IGMP メンバーシップレポートで通知されたどのグループにも一致しない IPv4 マルチキャストパケットと定義される。

スイッチが未登録パケットを受信した場合、IGMP ルータが接続されているすべてのポートにそのパケットを転送しなければならない (MUST)。スイッチは、既定で未登録パケットをすべてのポートに転送してもよい。未登録パケットをすべてのポートに転送しないスイッチは、指定したポートで未登録パケットを強制的にフラッディングさせる設定オプションを備えなければならない (MUST)。

IGMPv3 ホストが、まだ IGMPv3 をサポートしていないスヌーピングスイッチと混在する環境では、スイッチが未登録ストリームをフラッディングしないことにより、v3 ホストが自身のトラフィックを受信できなくなる可能性がある。逆に、スヌーピングスイッチが存在するすべての IGMP バージョンをサポートしている環境では、未登録ストリームをフラッディングすると IGMP ホストがマルチキャストトラフィックに圧倒され、クエリを受信できず自身のグループに対する新しいメンバーシップレポートを発行できなくなる可能性さえある。

スヌーピングスイッチは、少なくとも IGMPv3 の参加レポートを認識して処理することが望ましい。たとえその処理が IGMPv2 の参加に対する動作に限定されるもの(すなわち、追加の「送信元包含」や「送信元除外」フィルタリングを考慮しないもの)であってもよい。IGMPv3 の参加が認識されない場合、スヌーピングスイッチは(上述のように)そのグループの未登録データストリームを誤って剪定するか、あるいは、そのグループが以前に IGMPv2 として参加されていた場合には、データストリームがすでに登録済みと見なされるため、新しい IGMPv3 ホストへの転送を追加できない可能性がある。

  1. すべての非 IPv4 マルチキャストパケットは、通常の IEEE ブリッジ動作に従って、転送状態にある残りのすべてのポートへ引き続きフラッディングすべきである (SHOULD)。

この推奨事項は、IPv4 ホストからなるグループと IPv6 ホストからなるグループが完全に別個の異なるグループであるという事実に基づく。その結果、IPv4 グループのメンバー間のトポロジから得られた情報は、IPv6 グループのメンバー間のトポロジを形成する際には適用できない。

  1. IGMP スヌーピングスイッチは、MAC アドレスベースまたは IP アドレスベースのいずれかで転送テーブルを維持してもよい。両方の種類の転送テーブルをサポートするスイッチの場合、既定の動作は IP アドレスを使用すべきである (SHOULD)。IP マルチキャストアドレスとリンク層マルチキャストアドレスの対応付けが曖昧であるため、IP アドレスベースの転送が好ましい。イーサネットの場合、1 つのイーサネットアドレスが 32 個の IP アドレスに対応する [RFC1112]。

  2. IP ヘッダ内の情報に依存するスイッチは、IP ヘッダのチェックサムが正しいことを検証すべきである (SHOULD)。チェックサムが失敗した場合、そのパケット内の情報を転送テーブルに組み込んではならない (MUST NOT)。さらに、そのパケットは廃棄すべきである (SHOULD)。

  3. 共有セグメント上で IGMPv3 の「送信元包含」および「送信元除外」メンバーシップレポートを受信した場合、スイッチは受信したすべてのメンバーシップレポートの上位集合をその共有セグメントへ転送する必要がある。特定の送信元 S からグループ G へのトラフィックの転送は、共有セグメント上の少なくとも 1 台のホストが INCLUDE(G, Slist1) または EXCLUDE(G, Slist2) タイプの IGMPv3 メンバーシップを報告している場合に必ず行わなければならない (MUST)。ここで S は Slist1 の要素であり、Slist2 の要素ではない。

(G,S1,S2,...) に基づくデータ転送テーブルの実際の実装は本文書の範囲外である。ただし、一つの可能性として、2 つの (G,S) 転送リストを維持する方法がある。1 つは INCLUDE フィルタ用で、特定の (G,S) に一致することが転送の前提となるもの、もう 1 つは EXCLUDE フィルタ用で、特定の (G,S) に一致すると転送されないものである。

IGMPv3 ルータと、IGMPv2 スヌーピングスイッチを介して相互接続された IGMPv2 および IGMPv3 ホストからなるネットワークでは、最近報告されたような特殊な問題が生じる [IETF56]。ルータは IGMPv2 ホストが存在する場合でも IGMPv3 を維持し続けるため、ネットワークは IGMPv2 に収束しない。しかし IGMPv2 スヌーピングスイッチは IGMPv3 メンバーシップレポートを認識も処理もしない可能性が高い。するとこれらの未認識レポートに対応するグループは、(マルチキャスト負荷の高いネットワークでホストにさまざまな問題を引き起こす)フラッディングの対象となるか、スヌーピングスイッチによって剪定されるかのいずれかになる。

したがって、このようなネットワークでは、マルチキャストルータを IGMPv2 を使用するよう設定することが推奨される。それが不可能であり、かつスヌーピングスイッチが IGMPv3 メンバーシップレポートを認識・処理できない場合は、代わりにスイッチの IGMP スヌーピング機能を無効化することが推奨される。この問題には明確な解決策が存在しないためである。