Loading article…
インターネット グループ管理プロトコル( IGMP ) は、IPv4ネットワーク上のホストおよび隣接ルータがマルチキャスト グループ メンバーシップを確立するために使用する通信プロトコルです。IGMP はIP マルチキャストの不可欠な部分であり、ネットワークがマルチキャスト送信を要求したホストにのみ送信できるようにします。
IGMP は、オンラインストリーミング ビデオやゲームなどの 1 対多のネットワーク アプリケーションに使用でき、これらの種類のアプリケーションをサポートするときにリソースをより効率的に使用できます。
IGMP はIPv4ネットワークで使用されます。IPv6 ネットワーク上のマルチキャスト管理は、 IGMP の単なる IP カプセル化とは対照的に 、ICMPv6の一部であるマルチキャスト リスナー検出(MLD)によって処理されます。
建築
IGMP を使用してマルチキャスト サービスを配信するように設計されたネットワークでは、次の基本アーキテクチャが使用される場合があります。
IGMP は、ホストとローカル マルチキャスト ルータの間で動作します。IGMPスヌーピング機能を備えたスイッチは、これらの IGMP トランザクションを監視することで、有用な情報も取得します。次に、ローカル マルチキャスト ルータとリモート マルチキャスト ルータの間でプロトコル独立マルチキャスト (PIM) を使用し、マルチキャストを送信するホストから、マルチキャストを受信するために IGMP を通じて登録したホストにマルチキャスト トラフィックを送信します。
IGMPはICMPなどの他のネットワーク管理プロトコルと同様に、ネットワーク層（レイヤー3）で動作します。[1]
IGMP プロトコルは、ホスト上およびルータ内に実装されています。ホストはローカル ルータを介してグループへのメンバーシップを要求し、ルータはこれらの要求をリッスンして、定期的にサブスクリプション クエリを送信します。このクエリ機能を実行するために、サブネットごとに 1 つのルータが選択されます。一部のマルチレイヤ スイッチには、IGMP クエリ機能が含まれており、レイヤ 2 ネットワークに IGMP 対応ルータがない場合でも IGMP スヌーピング機能が動作できます。
IGMPはいくつかの攻撃に対して脆弱であり[2] [3] [4] [5]、ファイアウォールでは一般的に、必要がない場合はユーザーがIGMPを無効にすることができます。
バージョン
IGMPには3つのバージョンがあります。[6] IGMPv1は1989年に定義されました。[7] 1997年に定義されたIGMPv2 [8]は、ホストがマルチキャストグループからの離脱を通知する機能を追加することでIGMPv1を改良しました。
2002年にIGMPv3はIGMPv2を改良し、ソース固有のマルチキャスト[9]をサポートし、メンバーシップレポートの集約を導入しました。[10]ソース固有のマルチキャストのサポートは2006年に改良されました。[11]
IGMP の 3 つのバージョンには下位互換性があります。IGMPv3 をサポートするルータは、IGMPv1、IGMPv2、および IGMPv3 を実行しているクライアントをサポートできます。IGMPv1 はクエリ応答モデルを使用します。クエリは224.0.0.1に送信されます。メンバーシップ レポートはグループのマルチキャスト アドレスに送信されます。IGMPv2 はグループからの脱退プロセスを高速化し、その他のタイムアウトを調整します。グループ脱退メッセージは224.0.0.2に送信されます。グループ固有のクエリが導入されました。グループ固有のクエリはグループのマルチキャスト アドレスに送信されます。ルータがネットワークの IGMP クエリアを選択する手段が導入されました。IGMPv3 はソース固有のマルチキャスト機能を導入します。メンバーシップ レポートは224.0.0.22に送信されます。
メッセージ
IGMP メッセージにはいくつかの種類があります。
- 一般的な会員に関する質問
- マルチキャスト ルータによって送信され、ネットワークに接続されたシステムにとって重要なマルチキャスト アドレスを判別し、ネットワーク上のすべてのシステムのグループ メンバーシップ状態を更新します。
- グループ固有のメンバーシップクエリ
- 特定のマルチキャスト アドレスの受信状態を判別するために使用されます。
- グループおよびソース固有のクエリ
- ルータが、ユニキャスト アドレスのリストで指定された送信元アドレスからマルチキャスト グループに送信されたメッセージの受信を希望するシステムがあるかどうかを判断できるようにします。
- 会員レポート
- メンバーシップ クエリへの応答としてマルチキャスト レシーバーによって送信されるか、マルチキャスト グループに最初に登録するときに非同期的に送信されます。
- グループメッセージから退出
- 指定されたマルチキャスト送信が受信側で不要になったときに、マルチキャスト受信側によって送信されます。
IGMPメッセージは、 IPプロトコル番号2のベアIPパケットで伝送されます。[10] ：§4 インターネット制御メッセージプロトコルと同様に、 IGMPメッセージングでは トランスポート層は使用されません。
IGMPv2 メッセージ
- タイプ: 8 ビット
- メッセージの種類を次のように示します。
- 最大応答時間: 8 ビット
- メンバーシップクエリ（0x11）への応答の必要な応答性を指定します。このフィールドはメンバーシップクエリでのみ意味を持ちます。他のメッセージでは、0に設定され、受信者によって無視されます。このフィールドは、0.1秒単位で時間を指定します（フィールド値が10の場合は1秒を指定します）。値が大きいほどIGMPトラフィックのバースト性が低下し、値が小さいほど最後のホストがグループを離れる際のプロトコルの応答性が向上します。[8] ：§2.2
- チェックサム: 16ビット
- これは、IGMP メッセージ全体の 1 の補数の合計の16 ビットの 1 の補数です。送信前に計算され、このフィールドはゼロに設定されます。パケットの受信時に再計算されると、このフィールドが含まれ、結果はゼロになります。
- グループアドレス: 32 ビット
- これは、グループ固有またはグループとソース固有のクエリを送信するときにクエリされるマルチキャスト アドレスです。一般クエリを送信する場合、このフィールドはゼロになります。
- メッセージは次のIPマルチキャストアドレスに送信される: [8] : §9
IGMPv3 メンバーシップクエリ
- タイプ: 8 ビット
- パケットのタイプを示します。値0x11はIGMPv3 メンバーシップ クエリを示します。
- 最大応答コード: 8 ビット
- このフィールドは、応答レポートを送信する前に許可される最大応答時間 (1/10 秒単位) を計算するために使用されます。数値が 128 未満の場合は、値が直接使用されます。値が 128 以上の場合は、指数と仮数として解釈されます。
- チェックサム: 16ビット
- これは、IGMP メッセージ全体の 1 の補数の合計の16 ビットの 1 の補数です。送信前に計算され、このフィールドはゼロに設定されます。パケットの受信時に再計算されると、このフィールドが含まれ、結果はゼロになります。
- グループアドレス: 32 ビット
- これは、グループ固有またはグループとソース固有のクエリを送信するときにクエリされるマルチキャスト アドレスです。一般クエリを送信する場合、このフィールドはゼロになります。
- 予約: 4 ビット
- このフィールドは予約されています。送信時にはゼロに設定され、受信時には無視されます。
- ルータ側処理の抑制 （S）：1ビット
- このフラグが設定されている場合、受信側ルータに対して通常のタイマー更新を抑制することを示します。
- クエリの堅牢性変数 (QRV): 3 ビット
- この値がゼロ以外の場合、クエリの送信者が使用した堅牢性変数値が含まれます。値がゼロでない限り、ルータは、最後に受信したクエリと一致するように堅牢性変数を更新する必要があります。
- クエリーのクエリ間隔コード (QQIC): 8 ビット
- このコードは、クエリー側で使用されるクエリ間隔値 (秒単位) を指定するために使用されます。数値が 128 未満の場合は、値が直接使用されます。値が 128 以上の場合は、指数と仮数として解釈されます。
- ソース数 (N): 16 ビット
- このフィールドは、クエリ内に存在する送信元アドレスの数を指定します。一般クエリとグループ固有のクエリの場合、この値は 0 です。グループおよびソース固有のクエリの場合、この値は 0 以外ですが、ネットワークの MTU によって制限されます。
- 送信元アドレス [i]: 32 ビット
- 送信元アドレス [i] フィールドは、 n 個のIP ユニキャスト アドレスのベクトルです。ここで、n は送信元数 (N) フィールドの値です。
実装
FreeBSD、[注 1]、 Linux [注 2]、Windowsはすべてホスト側でIGMPをサポートしています。
参照
注記
- ^ IGMPv3 は FreeBSD バージョン 8.0 で追加されました。
- ^ IGMPv3 は Linux 2.5 カーネル シリーズで追加されました。
参考文献
- ^ Forouzan, Behrouz A. (2012).データ通信とネットワーキング(第 5 版). ニューヨーク: McGraw-Hill. p. 658. ISBN 978-0073376226。
- ^ 偽装された IGMP レポートによるサービス拒否の脆弱性。
- ^ 「断片化された IGMP パケットが「サービス拒否」攻撃を促進する可能性がある」 2004 年 12 月 20 日。2005 年 2 月 13 日時点のオリジナルからアーカイブ。
- ^ IGMP セキュリティ問題ステートメントと要件は、2006 年 10 月 13 日にWayback Machineにアーカイブされています。
- ^ 「TCP/IP の脆弱性により、サービス拒否が発生する可能性があります (MS06-007、913446))」。2006 年 2 月 14 日。2007 年 2 月 5 日時点のオリジナルよりアーカイブ。
- ^ IP マルチキャスト ルーティング コンフィギュレーション ガイド、Cisco、pp. 25– 28、2017年 5 月 27 日取得
- ^ S. Deering (1989 年 8 月)。IP マルチキャストのホスト拡張。ネットワーク ワーキング グループ。doi : 10.17487 /RFC1112。STD 5。RFC 1112 。 インターネット標準 5。RFC 988 および 1054 は廃止されました。RFC 2236 によって更新されました。
- ^ abcd W. Fenner (1997 年 11 月). インターネット グループ管理プロトコル、バージョン 2. ネットワーク ワーキング グループ. doi : 10.17487/RFC2236 . RFC 2236. 提案された標準。RFC 1112 を更新します。RFC 3376 によって更新されます。
- ^ 「インターネット グループ管理プロトコルの概要」。 Javvin。 2010 年 11 月 10 日時点のオリジナルよりアーカイブ。2010 年 11 月 18 日閲覧。
- ^ abc B. Cain; S. Deering ; I. Kouvelas; B. Fenner; A. Thyagarajan (2002 年 10 月). インターネット グループ管理プロトコル、バージョン 3. ネットワーク ワーキング グループ. doi : 10.17487/RFC3376 . RFC 3376. 提案された標準。RFC 2236 を更新します。RFC 4604 によって更新されます。
- ^ H. Holbrook、B. Cain、B. Haberman (2006 年 8 月)。ソース固有のマルチキャストにインターネット グループ管理プロトコル バージョン 3 (IGMPv3) とマルチキャスト リスナー検出プロトコル バージョン 2 (MLDv2) を使用する。ネットワーク ワーキング グループ。doi : 10.17487 / RFC4604。RFC 4604 。 提案された標準。RFC 3376 および 3810 を 更新します。