Zenn
🦖

RFC 3376: インターネット・グループ管理プロトコル、バージョン3

2024/07/25に公開
RFC
multicast
tech

本文書の位置付け

本文書は、インターネット・コミュニティのためのインターネット標準トラック・プロトコルを規定し、改善のための議論と提案を求める。このプロトコルの標準化状況とステータスについては、最新版の「インターネット公式プロトコル標準」(STD 1)を参照のこと。このメモの配布は無制限である。

著作権表示

著作権 (C) The Internet Society (2002)。

概要

本文書は、インターネット・グループ管理プロトコルのバージョン3、IGMPv3を規定する。IGMPは、IPv4システムが近隣のマルチキャスト・ルータにIPマルチキャスト・グループ・メンバーシップを報告するために使用するプロトコルである。IGMPのバージョン3では、「送信元フィルタリング」のサポートが追加されている。つまり、特定の送信元アドレスから特定のマルチキャスト・アドレスに送られたパケットのみ、あるいは特定の送信元アドレスを除くすべての送信元アドレスからのパケットを受信したいことをシステムが報告する機能が追加された。この情報は、マルチキャスト・ルーティング・プロトコルによって使用され、特定の送信元からのマルチキャスト・パケットを、関心のある受信者がいないネットワークに配信するのを回避することができる。

本文書は、RFC 2236を廃止する。

1. はじめに

インターネット・グループ管理プロトコル(IGMP)は、IPv4システム(ホストとルータ)が、近隣のマルチキャスト・ルータにIPマルチキャスト・グループ・メンバーシップを報告するために使用する。IPマルチキャスト・ルータは、それ自体が1つ以上のマルチキャスト・グループのメンバーになる場合があり、その場合、プロトコルの「マルチキャスト・ルータ部分」(マルチキャスト・ルーティング・プロトコルに必要なメンバーシップ情報を収集する)と、「グループ・メンバー部分」(ルータ自身と近隣の他のマルチキャスト・ルータにそのメンバーシップを通知する)の両方を実行することに留意する。

IGMPは、グループ・メンバーシップの報告に使われるメッセージ・タイプ以外のメッセージ・タイプを使って、他のIPマルチキャスト管理機能にも使われる。本文書では、グループ・メンバーシップの報告機能とメッセージのみを規定する。

本文書は、IGMPのバージョン3を規定する。[RFC-1112]で規定するバージョン1は、最初に広く展開されたバージョンで、インターネット標準となった最初のバージョンである。[RFC-2236]で規定するバージョン2は、「低離脱待ち時間」(low leave latency)のサポートが追加された。この機能は、接続するネットワーク上に特定のグループのメンバーが存在しなくなったことをマルチキャスト・ルータが認識するまでにかかる時間を短縮する。バージョン3では、「送信元フィルタリング」を追加する。これは、送信元固有マルチキャスト(Source-Specific Multicast) [SSM]をサポートするために必要となり、特定の送信元アドレスからのパケットを受信すること、あるいは特定のマルチキャスト・アドレスに送られる、特定の送信元アドレスを除くすべてのパケットを受信することをシステムが報告する機能である。バージョン3は、バージョン1及び2と相互運用できるように設計されている。

⚠️ IGMPv3で変わったこと
  • メンバーシップ・レポートではグループ・アドレスだけでなく、送信元アドレスを指定(フィルタリング)できるようになった。指定方法(モード)は、送信元アドレスを指定する(INCLUDEモード)、もしくは除外する(EXCLUDE モード)。
  • IGMPv2で追加された離脱メッセージをメンバーシップ・レポートに統合した。EXCLUDEモードにして送信元を指定しないと参加、INCLUDEモードにして送信元を指定しないと脱退となる(セクション2)。
  • レポート・メッセージの宛先IPアドレスが224.0.0.22に変更された。IGMPv1とv2では、メンバーシップ・レポートの宛先IPアドレスは、参加するグループ・アドレスだったが、v3では224.0.0.22で、全てのIGMPv3ルータが受信する(セクション4.2.14)。

マルチキャスト・リスナー検出(MLD)は、IPv6システムでも同様の方法で使用する。MLDバージョン1[MLD]は、IGMPバージョン2の機能を実装しており、MLDバージョン2[MLDv2]は、IGMPバージョン3の機能を実装している。

本文書で大文字で表記されているキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、[RFC-2119]で説明されているとおりに解釈される。イタリック体がないため、本文書では単語や語句を「*」文字で囲むことで強調を示す。

2. IPマルチキャスト受信を要求するサービス・インタフェース

IPシステム内には、上位層プロトコルやアプリケーション・プログラムが、特定のIPマルチキャスト・アドレスに送信されたパケットの受信の有効/無効をIP層に要求するために使用するサービス・インタフェースが(少なくとも概念的には)存在する。IGMPv3の機能を最大限に活用するには、システムのIPサービス・インタフェースは以下の動作をサポートしなければならない。

IPMulticastListen ( socket, interface, multicast-address,
                    filter-mode, source-list )

ここで:

  • 「socket」は、システム内のさまざまな要求エンティティ(プログラムやプロセスなど)を区別するために使用する実装固有のパラメータである。BSD Unixシステムコールのsocketパラメータがその具体例である。

  • 「interface」は、指定されたマルチキャスト・アドレスの受信を有効または無効にするネットワーク・インタフェースのローカル識別子である。インタフェースは、物理的なもの(イーサネット・インタフェースなど)でも、仮想的なもの(フレーム・リレー仮想回線のエンドポイントや IP-in-IP「トンネル」の終点など)でもよい。実装は、特別な「未指定」値をインタフェース・パラメータとして渡すことができる。その場合、リクエストはシステムの「プライマリ」または「デフォルト」インタフェースに適用される(おそらく、システム構成によって確立される)。同じマルチキャスト・アドレスを複数のインタフェースで受信したい場合、必要なインターフェースごとにIPMulticastListenを個別に呼び出す。

  • 「multicast-address」は、リクエストが関連するIPマルチキャスト・アドレスまたはグループである。指定されたインタフェースで複数のマルチキャスト・アドレスを受信したいる場合、必要なマルチキャスト・アドレスごとにIPMulticastListenを個別に呼び出す。

  • 「filter-mode」には、INCLUDEまたはEXCLUDEのいずれかを指定する。INCLUDEモードでは、指定されたマルチキャスト・アドレスに送られたパケットの受信は、source-listパラメータに列挙されているIP送信元アドレスからのみ要求される。EXCLUDEモードでは、指定されたマルチキャスト・アドレスに送られたパケットの受信は、source-listパラメータに列挙されているIP送信元アドレスを除くすべてのIP送信元アドレスから要求される。

  • 「source-list」は、フィルタ・モードに応じて、マルチキャスト受信が要求されるか要求されないかの、0個以上のIPユニキャスト・アドレスの順序なしリストである。実装において、送信元リストのサイズに制限を課してもよい(MAY)が、その制限はリストあたり64アドレス未満であってはならない(MUST NOT)。操作によって送信元リストのサイズ制限を超えた場合、サービス・インタフェースはエラーを返さなければならない(MUST)。

ソケット、インタフェース、マルチキャスト・アドレスの組み合わせに対して、一度に有効なフィルタ・モードと送信元リストは1つだけである。しかし、同じソケット、インタフェース、マルチキャスト・アドレスを指定する後続のIPMulticastListenリクエストによって、フィルタ・モードまたは送信元リストのいずれか、あるいは両方を変更することができる。後続の各リクエストは、指定されたソケット、インタフェース、マルチキャスト・アドレスに対するそれ以前のリクエストを完全に置き換える。

旧バージョンのIGMPは送信元フィルタ機能をサポートしておらず、指定されたインタフェースで指定されたマルチキャスト・アドレス(すべての送信元から)の受信を有効/無効にする参加(Join)と離脱(Leave)操作からなる、シンプルなサービス・インタフェースを持っていた。新しいサービス・インタフェースの同等の操作を以下に示す:

参加操作は、以下の操作と同等である。

IPMulticastListen ( socket, interface, multicast-address, EXCLUDE, {} )

離脱操作は、以下の操作と同等である。

IPMulticastListen ( socket, interface, multicast-address, INCLUDE, {} )

ここで、{}は空の送信元リストである。

このサービス・インタフェースで概説されている機能を提供するAPIの例は、[FILTER-API]にある。

3. システムが保持するマルチキャスト受信状態

3.1. ソケットの状態

IPMulticastListenを呼び出した各ソケットに対して、システムはそのソケットの希望するマルチキャスト受信状態を記録する。この状態は、概念的に以下の形式のレコードの集合で構成される:

(interface, multicast-address, filter-mode, source-list)

IPMulticastListenを呼び出すたびに、ソケットの状態は以下のように変化する:

  • 要求されたフィルタ・モードがINCLUDEであり、要求された送信元リストが空であれば、要求されたインタフェースとマルチキャスト・アドレスに対応するエントリが存在する場合は削除する。そのようなエントリが存在しない場合、リクエストは無視する。

  • 要求されたフィルタ・モードがEXCLUDEであり、または要求された送信元リストが空でない場合、要求されたインタフェースとマルチキャスト・アドレスに対応するエントリが存在すれば、要求されたフィルタ・モードと送信元リストを含むように変更される。そのようなエントリが存在しない場合、リクエストで指定されたパラメータを使用して新しいエントリを作成する。

3.2. インタフェース状態

システムは、ソケットごとのマルチキャスト受信状態に加えて、各インタフェースのマルチキャスト受信状態も保持または計算しなければならない。この状態は概念的に、以下の形式のレコードの集合で構成される:

(multicast-address, filter-mode, source-list)

与えられたインタフェースに対して、マルチキャスト・アドレスごとに最大1つのレコードが存在する。このインタフェースごとの状態はソケットごとの状態から派生するが、異なるソケットが同じマルチキャスト・アドレスとインタフェースに対して異なるフィルタ・モードや送信元リストを持つ場合、ソケットごとの状態とは異なる場合がある。例えば、あるアプリケーションまたはプロセスがソケットs1に対して以下の操作を呼び出すとする:

IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} )

は、マルチキャスト・アドレスmに送信されたパケットが送信元a、b、またはcから送信された場合のみ、インタフェースiでの受信を要求する。別のアプリケーションやプロセスがソケットs2に対して以下の操作を呼び出すとする:

IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} )

は、同じマルチキャスト・アドレスmに送信されたパケットが、送信元b、c、またはdから送信された場合のみ、同じインタフェースiでの受信を要求する。

両ソケットの受信要件を満たすには、インタフェースiは送信元a、b、c、dのいずれか1つからmに送信されたパケットを受信する必要がある。したがって、この例では、マルチキャスト・アドレスmに対するインタフェースiの受信状態は、フィルタモードINCLUDEと送信元リストa、b、c、dを持つ。

IP層によって、マルチキャスト・パケットがインタフェースから受け入れられた後、ソケットをリッスンしているアプリケーションやプロセスへのその後の配送は、そのソケットのマルチキャスト受信状態に依存する[そして、おそらくソケットがどのトランスポート層ポートにバインドされているかなど、他の条件にも依存する]。したがって、上記の例では、マルチキャスト・アドレスm宛のパケットが送信元アドレスaでインタフェースiに到着した場合、パケットはソケットs1に配送されるが、ソケットs2には配送されない。IGMPクエリとレポートは送信元フィルタリングの対象ではないため、常にホストとルータによって処理されなければならないことに留意する。

ソケットのマルチキャスト受信状態に基づくパケットのフィルタリングは、このサービス・インタフェースの新機能である。以前のサービス・インタフェース[RFC1112]では、マルチキャスト参加状態に基づくフィルタリングは説明されていなかった。むしろ、ソケットの参加によって、ホストは与えられたインタフェース上のグループに参加するだけであり、そのグループ宛てのパケットは、そのホストが参加しているかどうかに関係なく、すべてのソケットに配送される可能性があった。

ソケットごとの状態からインタフェースごとの状態を得るための一般的なルールは以下の通りである。どのソケット状態でも、(インタフェース、マルチキャスト・アドレス)のペアが現れると、そのインタフェース上のマルチキャスト・アドレスに対してインタフェースごとのレコードが作成される。同じ(インタフェース、マルチキャスト・アドレス)ペアを含むすべてのソケット・レコードを考慮し、

  • このようなレコードのフィルタ・モードがEXCLUDEの場合、インタフェース・レコードのフィルタ・モードはEXCLUDEである。そして、インタフェース・レコードの送信元リストは、EXCLUDEモードのすべてのソケット・レコードの送信元リストから、INCLUDEモードのソケット・レコードに現れる送信元アドレスを除いたものの共通部分になる。例えば、インタフェースiのマルチキャスト・アドレスmのソケット・レコードが以下の場合:

    from socket s1:  ( i, m, EXCLUDE, {a, b, c, d} )
from socket s2:  ( i, m, EXCLUDE, {b, c, d, e} )
from socket s3:  ( i, m, INCLUDE, {d, e, f} )

    インタフェースiの対応するインタフェース・レコードは以下のようになる:

    ( m, EXCLUDE, b, c )

    4番目のソケットが追加された場合、以下のようになる:

    from socket s4:  ( i, m, EXCLUDE,  )

    従って、インタフェース・レコードは以下のようになる:

    ( m, EXCLUDE,  )

  • このようなレコードのすべてにINCLUDEのフィルタ・モードを持つ場合、インタフェース・レコードのフィルタ・モードはINCLUDEであり、インタフェース・レコードの送信元リストはすべてのソケット・レコードの送信元リストの和集合である。例えば、インタフェースiのマルチキャスト・アドレスmのソケット・レコードが以下の場合:

    from socket s1:  ( i, m, INCLUDE, {a, b, c} )
from socket s2:  ( i, m, INCLUDE, {b, c, d} )
from socket s3:  ( i, m, INCLUDE, {e, f} )

    インターフェースiの対応するインタフェース・レコードは以下のようになる:

    ( m, INCLUDE, a, b, c, d, e, f )

    実装は、このグループのすべてのソケットがINCLUDE状態のとき、グループを表すためにEXCLUDEインタフェース・レコードを使用してはならない(MUST NOT)。インタフェース状態送信元リストを計算する時にシステム送信元の制限に達した場合、その操作を要求したアプリケーションにエラーを返さなければならない(MUST)。

IPMulticastListen呼び出しがソケットごとの状態レコードを追加、削除、変更するたびに、インタフェース状態を導出するための上記ルールが(再)評価される。ソケット状態が変更されても、必ずしもインタフェース状態が変更されるわけではないことに留意する。

4. メッセージ・フォーマット

IGMPメッセージは、IPv4データグラムにカプセル化され、IPプロトコル番号は2である。本文書で説明するすべてのIGMPメッセージは、IP Time-to-Liveが1、IP Precedence(優先度)がインターネットワーク制御(例: Type of Service 0xc0)で送信され、IPヘッダにIPルータ・アラート・オプション[RFC-2113]を持つ。IGMPメッセージ・タイプは、[RFC-3228]で説明しているように、IANA[IANA-REG]が登録している。

本文書で説明するIGMPv3プロトコルに関連するIGMPメッセージ・タイプは2つある:

タイプ番号(16進数) メッセージ名
0x11 メンバーシップ・クエリ
0x22 バージョン3メンバーシップ・レポート

IGMPv3の実装は、前のバージョンのIGMPとの相互運用性を確保するため(セクション7を参照)、以下の3つのメッセージ・タイプをサポートしなければならない。

タイプ番号(16進数) メッセージ名 引用
0x12 バージョン1メンバーシップ・レポート [RFC-1112]
0x16 バージョン2メンバーシップ・レポート [RFC-2236]
0x17 バージョン2グループ離脱 [RFC-2236]

認識できないメッセージ・タイプは、黙って無視しなければならない(MUST)。他のメッセージ・タイプは、IGMPの新しいバージョンや拡張機能、マルチキャスト・ルーティング・プロトコル、または他の用途で使用されるかもしれない。

本文書では、特に断りのない限り、大文字の「クエリ」(Query)と「レポート」(Report)は、それぞれIGMPメンバーシップ・クエリとIGMPバージョン3メンバーシップ・レポートを指す。

4.1. メンバーシップ・クエリ・メッセージ

メンバーシップ・クエリは、IPマルチキャスト・ルータが隣接インタフェースのマルチキャスト受信状態を照会するために送信する。クエリの形式は以下のとおりである:

fig1

4.1.1. 最大応答コード

最大応答コード・フィールドは、応答レポートを送信する前に許容される最大時間を指定する。最大応答時間と呼ばれる実際の許容時間は、1/10秒単位で表され、最大応答コードから以下のように導出される:

If 最大応答コード < 128, 最大応答時間 = 最大応答コード

If 最大応答コード >= 128, 最大応答コードは、以下のように浮動小数点値を表す:

fig2

最大応答時間 = (mant | 0x10) << (exp + 3)

最大応答時間の値が小さいと、IGMPv3ルータは「離脱待ち時間(leave latency)」(最後のホストがグループを離脱した時点から、ルーティング・プロトコルにメンバーがもういなくなったことが通知されるまでの時間)を調整できる。より大きな値、特に指数範囲の値を使用すると、ネットワーク上のIGMPトラフィックのバースト性を調整することができる。

4.1.2. チェックサム

チェックサムは、IGMPメッセージ全体(IPペイロード全体)の1の補数の合計の16ビットである。チェックサムを計算するため、チェックサム・フィールドはゼロに設定される。パケットを受信するとき、パケットを処理する前にチェックサムを検証しなければならない(MUST)。[RFC-1071]を参照のこと。

4.1.3. グループ・アドレス

グループ・アドレス・フィールドは、一般クエリ(General Query)を送信する場合はゼロに設定し、グループ固有クエリ(Group-Specific Query)またはグループ及び送信元固有クエリ(Group-and-Source-Specific Query)を送信する場合は、クエリ対象のIPマルチキャスト・アドレスに設定する(以下のセクション4.1.9を参照)。

4.1.4. 予約済み(Resv)

予約済みフィールドは、送信時にゼロに設定され、受信時には無視される。

4.1.5. Sフラグ(ルータ側の処理を抑制)

Sフラグが1に設定されている場合、受信側のマルチキャスト・ルータはクエリを受信したときに実行する通常のタイマ更新を抑制する必要がある。ただし、ルータ自身がグループ・メンバーである結果として、実行する必要があるクエリのクエリア(クエリの送信者)の選択や通常の「ホスト側」処理は抑制しない。

⚠️ クエリア

メンバーシップ・クエリを定期送信する装置をクエリア(querier)と呼ぶ。

4.1.6. QRV(クエリアの堅牢性変数)

QRVフィールドはゼロ以外の場合、クエリア、すなわちクエリの送信者が使用する[堅牢性変数] (Robustness Variable)値を含む。クエリアの[堅牢性変数]がQRVフィールドの最大値である7を超える場合、QRVは0に設定される。ルータは、直近に受信したクエリのQRV値を自身の[堅牢性変数]値として採用する。ただし、直近に受信したQRVがゼロの場合は、受信側はセクション8.1で規定されたデフォルトの[堅牢性変数]値または静的に設定された値を使用する。

4.1.7. QQIC (クエリアのクエリ間隔コード)

クエリアのクエリ間隔コード・フィールドは、クエリアが使用する[クエリ間隔]を指定する。実際の間隔は、クエリアのクエリ間隔(QQI)と呼ばれ、秒単位で表され、クエリアのクエリ間隔コードから以下のように導出される:

If QQIC < 128, QQI = QQIC

If QQIC >= 128, QQICは、次のように浮動小数点値を表す:

fig3

QQI = (mant | 0x10) << (exp + 3)

現時点でクエリアではないマルチキャスト・ルータは、直近に受信したクエリアのQQI値を自身の [クエリ間隔]値として採用する。ただし、直近に受信したQQIがゼロの場合、受信ルータはセクション8.2で規定されているデフォルトの[クエリ間隔]値を使用する。

4.1.8. 送信元の数 (N)

送信元の数(N)フィールドは、クエリに存在する送信元アドレスの数を指定する。この数は、一般クエリまたはグループ固有クエリではゼロ、グループ及び送信元固有クエリではゼロ以外である。この数は、クエリが送信されるネットワークのMTUによって制限される。例えば、MTUが1500オクテットのイーサネットでは、ルータ・アラート・オプションを含むIPヘッダは24オクテットを消費し、送信元数(N)フィールドを含むIGMPフィールドは12オクテットを消費するため、送信元アドレス用に1464オクテットが残り、送信元アドレスの数は366(1464/4)に制限される。

4.1.9. 送信元アドレス [i]

送信元アドレス[i]フィールドは、n個のIPユニキャスト・アドレスのベクトルで、nは送信元の数(N)フィールドの値である。

4.1.10. 追加データ

受信したクエリのIPヘッダのパケット長フィールドが、ここで説明したフィールド以外に追加オクテットのデータが存在することを示す場合、IGMPv3実装は受信したIGMPチェックサムを検証するための計算にこれらのオクテットを含めなければならない(MUST)が、そうでなければ、これらの追加オクテットを無視しなければならない(MUST)。クエリを送信する場合、IGMPv3実装は、ここで説明されているフィールド以外の追加オクテットを含めてはならない(MUST NOT)。

4.1.11. クエリのバリエーション

クエリ・メッセージには3つのバリエーションがある:

  1. 「一般クエリ」は、隣接インタフェース(つまり、クエリが送信されるネットワークに接続しているインタフェース)の完全なマルチキャスト受信状態を確認するため、マルチキャスト・ルータが送信する。一般クエリでは、グループ・アドレス・フィールドと送信元の数(N)フィールドの両方が0である。

  2. 「グループ固有クエリ」は、隣接インタフェースの単一のマルチキャスト・アドレスに関する受信状態を確認するために、マルチキャスト・ルータが送信する。グループ固有クエリでは、グループ・アドレス・フィールドに対象のマルチキャスト・アドレスが含まれ、送信元の数(N)フィールドは0である。

  3. 「グループ及び送信元固有クエリ」は、指定されたリストの送信元のいずれかから、指定されたマルチキャスト・アドレスに送信されたパケットの受信を望む隣接インタフェースがあるかどうかを確認するために、マルチキャスト・ルータが送信する。グループ及び送信元固有クエリでは、グループ・アドレス・フィールドに対象のマルチキャスト・アドレスが含まれ、送信元アドレス[i]フィールドには対象の送信元アドレスが含まれる。

4.1.12. クエリのIP宛先アドレス

IGMPv3では、一般クエリは、全システムのマルチキャスト・アドレスである224.0.0.1のIP宛先アドレスで送信される。グループ固有クエリとグループ及び送信元固有クエリは、対象のマルチキャスト・アドレスと同じIP宛先アドレスで送信される。ただし、システムは、IP宛先アドレス・フィールドに、そのクエリが到着したインタフェースに割り当てられたアドレス(ユニキャストまたはマルチキャスト)のいずれかを含むクエリを受け入れ、処理しなければならない(MUST)。

4.2.バージョン3メンバーシップ・レポート・メッセージ

バージョン3メンバーシップ・レポートは、IPシステムが送信し、そのインタフェースの現在のマルチキャスト受信状態、またはマルチキャスト受信状態の変化を(隣接ルータに)報告する。レポートの形式は以下のとおりである:

fig4

各グループ・レコードの内部形式は以下のとおり:

fig5

⚠️ メンバーシップ・レポートのパケット

以下のようなパケットの構成になっている。

memrepo

4.2.1. 予約済み

予約済みフィールドは、送信時にはゼロに設定し、受信時には無視する。

4.2.2. チェックサム

チェックサムは、IGMPメッセージ全体(IPペイロード全体)の1の補数の合計の16ビットである。チェックサムを計算するために、チェックサム・フィールドはゼロに設定される。パケットを受信するときは、メッセージを処理する前にチェックサムを検証しなければならない(MUST)。

4.2.3. グループ・レコードの数(M)

グループ・レコードの数(M)フィールドは、このレポートに存在するグループ・レコードの数を指定する。

4.2.4. グループ・レコード

各グループ・レコードは、レポートが送信されるインタフェース上の単一のマルチキャスト・グループにおける送信者のメンバーシップに関する情報を含むフィールド・ブロックである。

4.2.5. レコード・タイプ

以下のセクション4.2.12を参照のこと。

4.2.6. 補助データ長

補助データ長フィールドは、このグループ・レコードの補助データ・フィールドの長さが32ビットワード単位で含まれる。補助データが存在しないことを示すために、ゼロが含まれる場合がある。

4.2.7. 送信元の数 (N)

送信元の数(N)フィールドは、このグループ・レコードに存在する送信元アドレスの数を指定する。

4.2.8. マルチキャスト・アドレス

マルチキャスト・アドレス・フィールドは、このグループ・レコードが関係するIPマルチキャスト・アドレスが含まれる。

4.2.9. 送信元アドレス [i]

送信元アドレス[i]フィールドは、n個のIPユニキャスト・アドレスのベクトルである。ここで、nはこのレコードの送信元の数(N)フィールドの値である。

4.2.10. 補助データ

補助データ・フィールドが存在する場合、このグループ・レコードに関連する追加情報が含まれる。本文書で規定されているプロトコル、IGMPv3では、補助データは定義されていない。したがって、IGMPv3の実装では、送信されたグループ・レコードに補助データを含めてはならず(MUST NOT) (つまり、補助データ長フィールドをゼロに設定しなければならない(MUST))、受信したグループ・レコードに存在する補助データを無視しなければならない(MUST)。補助データ・フィールドのセマンティクスと内部エンコーディングは、このフィールドを使用するIGMPの将来のバージョンまたは拡張機能によって定義される。

4.2.11. 追加データ

受信したレポートのIPヘッダのパケット長フィールドが、最後のグループ・レコードを超える追加のデータ・オクテットが存在することを示す場合、IGMPv3実装は、受信したIGMPチェックサムを検証するための計算にこれらのオクテットを含めなければならない(MUST)が、そうでなければ、それらの追加オクテットを無視しなければならない(MUST)。IGMPv3実装は、レポートを送信するとき、最後のグループ・レコードを超える追加オクテットを含めてはならない(MUST NOT)。

4.2.12. グループ・レコードの種類

レポート・メッセージに含まれる可能性のあるグループ・レコードには、多くの種類がある:

  • 「現状レコード」(Current-State Record)は、インタフェース上で受信したクエリに応答してシステムから送られる。これは、単一のマルチキャスト・アドレスに関して、そのインタフェースの現在の受信状態を報告する。現状レコードのレコード・タイプは、以下の2つの値のいずれかとなる。

    値 名前と意味
    1 MODE_IS_INCLUDE - インタフェースが指定されたマルチキャスト・アドレスに対して、INCLUDEフィルタ・モードを持っていることを示す。このグループ・レコードの送信元アドレス[i]フィールドは、指定されたマルチキャスト・アドレスのインタフェースの送信元リストが含まれる(空でない場合)。
    2 MODE_IS_EXCLUDE - インタフェースが指定されたマルチキャスト・アドレスに対して、EXCLUDEフィルタ・モードを持っていることを示す。このグループ・レコードの送信元アドレス[i]フィールドは、指定されたマルチキャスト・アドレスのインタフェースの送信元リストが含まれる(空でない場合)。

  • 「フィルタ・モード変更レコード」(Filter-Mode-Change Record)は、IPMulticastListenのローカル呼び出しが、特定のマルチキャスト・アドレスのインタフェース・レベル状態エントリのフィルタ・モードの変更(つまり、INCLUDEからEXCLUDEに変更、またはEXCLUDEからINCLUDEに変更)のたびに、システムによって送信される。レコードは、変更が発生したインタフェースから送信されるレポートに含まれる。フィルタ・モード変更レコードのレコード・タイプは、以下の2つの値のいずれかとなる。

    値 名前と意味
    3 CHANGE_TO_INCLUDE_MODE - インタフェースが指定されたマルチキャスト・アドレスに対して、INCLUDEフィルタ・モードに変更されたことを示す。このグループ・レコードの送信元アドレス[i]フィールドは、指定されたマルチキャスト・アドレスのインタフェースの送信元リストが含まれる(空でない場合)。
    4 CHANGE_TO_EXCLUDE_MODE - インタフェースが指定されたマルチキャスト・アドレスに対して、EXCLUDEフィルタ・モードに変更されたことを示す。このグループ・レコードの送信元アドレス[i]フィールドは、指定されたマルチキャスト・アドレスのインタフェースの送信元リストが含まれる(空でない場合)。

  • 「送信元リスト変更レコード」(Source-List-Change Record)は、IPMulticastListenのローカル呼び出しが、特定のマルチキャスト・アドレスのインタフェース・レベル状態エントリのフィルタ・モードの変更と一致しない送信元リストの変更を引き起こすたびに、システムによって送信される。レコードは、変更が発生したインタフェースから送信されるレポートに含まれる。送信元リスト変更レコードのレコード・タイプは、以下の2つの値のいずれかとなる。

    値 名前と意味
    5 ALLOW_NEW_SOURCES - このグループ・レコードの送信元アドレス[i]フィールドが、指定されたマルチキャスト・アドレスに送信されたパケットに対して、システムが受信を希望する追加送信元のリストが含まれていることを示す。INCLUDE送信元リストへの変更の場合、これらはリストに追加されたアドレスであり、EXCLUDE送信元リストへの変更の場合、これらはリストから削除されたアドレスである。
    6 BLOCK_OLD_SOURCES - このグループ・レコードの送信元アドレス[i]フィールドに、指定されたマルチキャスト・アドレスに送信されたパケットに対して、システムが受信を希望しなくなった送信元のリストを含んでいることを示す。INCLUDE送信元リストに変更があった場合、これらはリストから削除されたアドレスであり、EXCLUDE送信元リストに変更があった場合、これらはリストに追加されたアドレスである。

送信元リストの変更の結果、新しい送信元を許可し、古い送信元をブロックする場合、同じマルチキャスト・アドレスに対して、ALLOW_NEW_SOURCESタイプとBLOCK_OLD_SOURCESタイプの2つのグループ・レコードが送信される。

「状態変更レコード」という用語は、フィルタモード変更レコードまたは送信元リスト変更レコードのいずれかを指す。

認識されないレコード・タイプの値は、黙って無視しなければならない(MUST)。

4.2.13. レポートのIP送信元アドレス

IGMPレポートは、宛先サブネットの有効なIP送信元アドレスとともに送信される。0.0.0.0送信元アドレスは、まだIPアドレスを取得していないシステムで使用されることがある。0.0.0.0送信元アドレスは、LAN 上の複数のシステムで同時に使用される場合があることに留意する。ルータは、送信元アドレスが0.0.0.0のレポートを受け入れなければならない(MUST)。

4.2.14. レポートIP宛先アドレス

バージョン3レポートは、すべてのIGMPv3対応マルチキャスト・ルータがリッスンする 224.0.0.22のIP宛先アドレスで送信する。バージョン1またはバージョン2互換モードで動作しているシステムは、レポートのグループ・アドレス・フィールドで指定したマルチキャスト・グループにバージョン1またはバージョン2レポートを送信する。さらに、システムは、IP宛先アドレス・フィールドが、レポートが到着したインタフェースに割り当てられたアドレス(ユニキャストまたはマルチキャスト)のいずれかを含むバージョン1またはバージョン2レポートを受け入れ、処理しなければならない(MUST)。

4.2.15.グループ・レコードの表記

本文書の残りの部分では、特定のマルチキャスト・アドレスに関連するグループ・レコードの内容を記述するために、以下の表記を使用する:

IS_IN ( x ) - タイプMODE_IS_INCLUDE, 送信元アドレス x
IS_EX ( x ) - タイプMODE_IS_EXCLUDE, 送信元アドレス x
TO_IN ( x ) - タイプCHANGE_TO_INCLUDE_MODE, 送信元アドレス x
TO_EX ( x ) - タイプCHANGE_TO_EXCLUDE_MODE, 送信元アドレス x
ALLOW ( x ) - タイプALLOW_NEW_SOURCES, 送信元アドレス x
BLOCK ( x ) - タイプBLOCK_OLD_SOURCES, 送信元アドレス x

xは以下のいずれか:

  • 大文字(例: "A")で送信元アドレスの集合を表す、または

  • 集合式(例:「A+B」)、「A+B」は集合Aと集合Bの結合を意味し、「A*B」は集合Aと集合B共通部分を意味し、「A-B」は集合Aから集合Bのすべての要素を取り除くことを意味する。

4.2.16. メンバーシップ・レポートのサイズ

レポートに必要なグループ・レコードのセットが、1つのレポート・メッセージのサイズ制限内に収まらない場合(送信されるネットワークのMTUによって決定)、グループ・レコードはセット全体をレポートするために必要な数のレポート・メッセージで送信される。

1つのグループ・レコードが、1つのレポート・メッセージのサイズ制限に収まらないほど多くの送信元アドレスを含む場合、そのタイプがMODE_IS_EXCLUDEまたはCHANGE_TO_EXCLUDE_MODEでない場合、複数のグループ・レコードに分割され、それぞれが送信元アドレスの異なるサブセットを含み、それぞれが別のレポート・メッセージで送信される。タイプがMODE_IS_EXCLUDEまたはCHANGE_TO_EXCLUDE_MODEの場合は、収まるだけの数の送信元アドレスが含まれ、残りの送信元アドレスはレポートされない。どの送信元を報告するかは任意だが、毎回異なる送信元を報告するよりも、後続の各レポートで同じ送信元セットを報告する方が望ましい。

5. グループ・メンバーのプロトコルの説明

IGMPは非対称プロトコルで、グループ・メンバー、つまり、マルチキャスト・パケットを受信するホストやルータと、マルチキャスト・ルータに対してそれぞれの動作を規定している。このセクションでは、すべてのグループ・メンバーに適用されるIGMPv3の部分について説明する。(グループ・メンバーでもあるマルチキャスト・ルータは、IGMPv3の両方のパートを実行し、自分のIGMPメッセージの送信と隣接ルータのIGMPメッセージを受信して応答する両方を行うことに留意する。IGMPv3のマルチキャスト・ルータ部分については、セクション6で説明する。)

システムは、マルチキャスト受信をサポートしているすべてのインタフェース上で、たとえこれらのインタフェースのうち1つ以上が同じネットワークに接続されていても、このセクションで説明するプロトコルを実行する。

古いバージョンのIGMPを実行するマルチキャスト・ルータとの相互運用性を確保するため、システムは、マルチキャスト受信をサポートしている各インタフェースに対してMulticastRouterVersion変数を保持する。このセクションでは、MulticastRouterVersion = 3のインタフェース上のグループ・メンバー・システムの動作について説明する。MulticastRouterVersionを決定するアルゴリズムと、3以外のバージョンでの動作はセクション7で説明する。

全システム・マルチキャスト・アドレスである224.0.0.1は、特別なケースとして扱われる。すべてのシステム(つまり、マルチキャスト・ルータを含むすべてのホストとルータ)で、マルチキャスト受信をサポートしているすべてのインタフェース上で、すべての送信元からの全システム・マルチキャスト・アドレス宛てのパケットの受信が恒久的に有効になる。全システム・マルチキャスト・アドレスに関して、IGMPメッセージが送信されることはない。

インタフェース上でIGMPv3プロトコル・アクションをトリガーするイベントには、以下の2種類がある。

  • IPMulticastListenのローカル呼び出しによって引き起こされるインタフェース受信状態の変更。

  • クエリの受信。

(クエリ以外のタイプの受信IGMPメッセージは、以前のバージョンのIGMPとの相互運用に必要な場合を除き、黙って無視する。)

以下のサブセクションでは、これら2つのケースのそれぞれに対して実行されるアクションを説明する。これらの説明では、タイマーとカウンタの名前が角括弧で囲んでいる。これらのタイマーとカウンタのデフォルト値はセクション8で規定する。

5.1. インタフェース状態変更時のアクション

IPMulticastListenの呼び出しは、セクション3.2のルールに従って、インタフェースのマルチキャスト受信状態が変更されるかも知れない。このような変更はそれぞれ、1つのマルチキャスト・アドレスに対するインタフェースごとのエントリに影響する。

インタフェース状態が変更されると、システムは直ちにそのインタフェースから状態変更レポート(State-Change Report )を送信する。そのレポート中のグループ・レコードのタイプと内容は、以下の表に従って、変更前と変更後の影響を受けるマルチキャスト・アドレスのフィルタ・モードと送信元リストを比較することによって決定する。変更前にそのマルチキャスト・アドレスのインタフェース状態が存在しなかった場合(つまり、変更は新しいインタフェースごとのレコードの作成で構成されていた)、または変更後に状態が存在しなかった場合(つまり、変更はインタフェースごとのレコードの削除で構成されていた)、「存在しない」状態は、INCLUDEのフィルタ・モードと空の送信元リストを持つと見なされる。

古い状態 新しい状態 状態変更レコードの送信
INCLUDE (A) INCLUDE (B) ALLOW (B-A), BLOCK (A-B)
EXCLUDE (A) EXCLUDE (B) ALLOW (A-B), BLOCK (B-A)
INCLUDE (A) EXCLUDE (B) TO_EX (B)
EXCLUDE (A) INCLUDE (B) TO_IN (B)

ALLOWまたはBLOCK状態変更レコードの計算された送信元リストが空の場合、そのレコードはレポート・メッセージから省略される。

状態変更レポートが1つ以上のマルチキャスト・ルータで見逃される可能性をカバーするために、範囲(0、[非要請レポート間隔])からランダムに選ばれた間隔で、さらに[堅牢性変数] - 1 回以上再送信される。

最初の変更に対する状態変更レポートの再送信がすべて完了する前に、同じインタフェース状態エントリにさらに変更が発生した場合、そのような追加の変更ごとに、新しい状態変更レポートの即時送信がトリガーとなる。

新しく送信されるレポートの内容は、以下のように計算する。最初のレポートと同様に、最新の変更前後の、影響を受けるグループのインタフェース状態を比較する。差分を表すレポート・レコードは、上の表に従って作成する。しかし、これらのレコードはメッセージで送信されるのではなく、保留中のレポートの内容とマージされ、新しい状態変更レポートを作成する。状態変更と保留レポートの結果の差分レポートをマージするためのルールは、以下で説明する。

マージされた状態変更レポートの送信は、同じマルチキャスト・アドレスに対する以前の状態変更レポートの再送信が終了し、状態変更レポートの[堅牢性変数]送信の最初のものとなる。

上記で計算された差分レポートに送信元が含まれるたびに、ホストから[堅牢性変数]状態変更レポートが送信されるまで、その送信元の再送信状態を維持する必要がある。これは、一連の連続した状態変化がプロトコルの堅牢性が損なわれないようにするために行われる。

新しいレポートのトリガーとなるインタフェース受信状態の変更がフィルタ・モードの変更である場合、次回の[堅牢性変数]状態変更レポートにはフィルタ・モード変更レコードが含まれる。これは、次のレポートが 1 つ以上ある場合でも適用されます。これは、その期間に任意の数の送信元リストの変更が発生しても適用される。ホストは、[堅牢性変数]状態変更レポートが送信されるまで、グループの再送状態を維持しなければならない。最後のフィルタ・モード変更後に[堅牢性変数]状態変更レポートがフィルタ・モード変更レコードとともに送信され、インタフェース受信に対する送信元リストの変更によって追加のレポートがスケジュールされている場合、次の状態変更レポートには送信元リスト変更レコードが含まれる。

状態変更レポートが送信されるたびに、その内容は以下のように決定される。レポートにフィルタ・モード変更レコードを含める必要がある場合、インタフェースの現在のフィルタ・モードが INCLUDEであれば、TO_INレコードがレポートに含まれ、そうでなければTO_EXレコードが含まれる。代わりに、レポートに送信元リスト変更レコードが含まれる場合、ALLOWレコードとBLOCKレコードが含まれる。これらのレコードの内容は、以下の表に従って作成する。

レコード 含まれる送信元
TO_IN 現在のインタフェースの状態で、すべて転送する必要がある
TO_EX 現在のインタフェースの状態で、すべてブロックする必要がある
ALLOW 再送状態で、すべて転送する必要がある
BLOCK 再送状態で、すべてブロックする必要がある

ALLOWまたはBLOCKレコードの計算された送信元リストが空の場合、そのレコードは状態変更レポートから省略される。

注: 最初の状態変更レポートが送信されるとき、マージする存在しない保留レポートは、空のALLOW及びBLOCKレコードを持つ送信元変更レポートとして処理できる(再送信状態を持つ送信元がない)。

5.2. クエリ受信時のアクション

システムはクエリを受信しても、すぐには応答しない。その代わり、受信したクエリ・メッセージの最大応答コードから得られる最大応答時間値で制限されるランダムな時間だけ応答を遅らせる。システムは、さまざまなインタフェースでさまざまな種類のさまざまなクエリ(一般クエリ、グループ固有クエリ、グループ及び送信元固有クエリなど)を受信する可能性がある。これらのクエリはそれぞれ独自の遅延応答を必要とする場合がある。

クエリに対する応答をスケジューリングする前に、システムはまず、前にスケジュールされた保留中の応答を考慮し、多くの場合、結合応答をスケジュールしなければならない。したがって、システムは以下の状態を維持できなければならない:

  • 一般クエリに対する応答をスケジューリングするためのインタフェースごとのタイマー。

  • グループ固有クエリとグループ及び送信元固有クエリへの応答をスケジューリングするためのグループ及びインタフェースごとのタイマー。

  • グループ及び送信元固有クエリへの応答で報告される送信元のグループ及びインタフェースごとのリスト。

ルータ・アラート・オプションを含む新しいクエリがインタフェースに到着すると、システムが報告する状態がある場合、応答の遅延は(0、[最大応答時間])の範囲でランダムに選択される。ここで、最大応答時間は、受信したクエリ・メッセージの最大応答コードから導かれる。以下のルールを使用して、レポートがスケジューリングする必要があるかどうか、及びスケジュールするレポートのタイプを決定する。ルールは順番に考慮され、最初に一致したルールのみが適用される。

  1. 選択した遅延よりも早くスケジューリングされた、前の一般クエリに対する保留中の応答がある場合、追加の応答をスケジューリングする必要はない。

  2. 受信したクエリが一般クエリの場合、インタフェース・タイマーを使用して、選択した遅延後に一般クエリへの応答をスケジューリングする。前に保留されていた一般クエリに対する応答はすべてキャンセルする。

  3. 受信したクエリがグループ固有クエリまたはグループ及び送信元固有クエリであり、このグループの前のクエリに対する保留中の応答がない場合、グループ・タイマーを使用してレポートをスケジューリングする。受信したクエリがグループ及び送信元固有クエリの場合、応答を生成するときに使用するために、クエリされた送信元のリストを記録する。

  4. このグループに対してスケジューリングされた以前のクエリに対する保留中の応答がすでに存在し、新しいクエリがグループ固有クエリであるか、グループに関連付けられた記録済み送信元リストが空である場合、グループの送信元リストはクリアされ、グループ・タイマーを使用して1つの応答がスケジューリングされる。新しい応答は、保留中のレポートの残り時間と選択された遅延のうち、最も早い時間に送信されるようにスケジューリングする。

  1. 受信したクエリがグループ及び送信元固有クエリであり、送信元リストがからでないこのグループに対する保留中の応答がある場合、グループ送信元リストは新しいクエリの送信元リストを含むように拡張し、グループ・タイマーを使用して1つの応答がスケジューリングする。新しい応答は、保留中のレポートの残り時間と選択された遅延のうち、最も早い時間に送信されるようにスケジューリングする。

保留中の応答レコードのタイマーが期限切れになると、システムは関連するインタフェース上で、1つ以上の現状レコード(セクション4.2.12を参照)を含む1つ以上のレポート・メッセージを以下のように送信する。

  1. 期限切れのタイマーがインタフェース・タイマーの場合(つまり、一般クエリに対する保留中の応答である場合)、セクション3.2で説明しているように、指定されたインタフェースが受信状態を持つ各マルチキャスト・アドレスに対して、1つの現状レコードが送信する。現状レコードは、マルチキャスト・アドレスとそれに関連付けられたフィルタ・モード(MODE_IS_INCLUDEまたはMODE_IS_EXCLUDE)と送信元リストを伝送する。複数の現状レコードは、可能な限り、個別のレポート・メッセージにパックする。

    この単純なアルゴリズムは、システムが多数のグループのメンバーである場合に、パケットのバーストを引き起こす可能性につながる。単一のインタフェース・タイマーを使用する代わりに、実装では、そのようなレポート・メッセージの送信を間隔(0、[最大応答時間])に分散させることが推奨される。そのような実装は、「ACK集中」(ack-implosion)問題を回避しなければならない(MUST)ことに留意する。つまり、一般クエリの受信時に直ちにレポートを送信してはならない(NOT MUST)。

  2. 期限切れのタイマーがグループ・タイマーであり、そのグループの記録された送信元リストが空の場合(つまり、グループ固有クエリに対する保留中の応答である場合)、そのインタフェースがそのグループ・アドレスに対する受信状態を持つ場合に限り、そのアドレスに対して1つの現状レコードが送信される。現状レコードは、マルチキャスト・アドレスとそれに関連付けられたフィルタ・モード(MODE_IS_INCLUDEまたはMODE_IS_EXCLUDE)と送信元リストを伝送する。

  3. 期限切れのタイマーがグループ・タイマーであり、そのグループの記録済み送信元リストが空でない場合(つまり、グループ及び送信元固有クエリに対する保留中の応答である場合)、インタフェースがそのグループ・アドレスの受信状態にある場合に限り、応答する現状レコードの内容は、以下の表で規定しているように、インタフェース状態と保留中の応答レコードから決定する。

    インタフェース状態 保留中の
    応答レコード内
    の送信元セット    		 現状レコード
    INCLUDE (A) B IS_IN (A*B)
    EXCLUDE (A) B IS_IN (B-A)

その結果、現状レコードに空の送信元アドレス・セットがある場合、応答は送信されない。

最後に、必要なレポート・メッセージが生成された後、レポートされたグループに関連付けられた送信元リストはクリアされる。

6. マルチキャスト・ルータのプロトコルの説明

IGMPの目的は、各マルチキャスト・ルータが、直接接続されたネットワークごとに、そのネットワークに接続されたシステムがどのマルチキャスト・アドレスに関心があるかを学習できるようにすることである。IGMPバージョン3は、マルチキャスト・ルータが、特定のマルチキャスト・アドレスに送信されたパケットについて、どの送信元が隣接システムにとって関心があるかも学習する機能を追加している。IGMPによって収集された情報は、ルータが使用しているマルチキャスト・ルーティング・プロトコルにも提供され、関心のある受信者がいるすべてのネットワークにマルチキャスト・パケットが確実に配信されるようにする。

このセクションでは、マルチキャスト・ルータが実行するIGMPv3の部分について説明する。マルチキャスト・ルータは、それ自体がマルチキャスト・グループのメンバーになることもあるため、セクション5で説明しているIGMPv3のグループ・メンバー部分も実行する。

マルチキャスト・ルータは、直接接続している各ネットワーク上で、このセクションで説明するプロトコルを実行する。マルチキャスト・ルータに同じネットワークに複数のインタフェースを持つ場合、そのうちの1つのインタフェースでこのプロトコルを動作させるだけでよい。このプロトコルが実行される各インタフェースで、ルータはすべての送信元からのマルチキャスト・アドレス224.0.0.22の受信を有効にしなければならない(MUST)(また、そのインタフェース上でそのアドレスに対してIGMPv3のグループ・メンバー部分を実行しなければならない(MUST))。

マルチキャスト・ルータは、接続されたネットワーク上の 少なくとも1つのシステムが特定の送信元からの特定のマルチキャスト・アドレスへのパケットに関心があることだけを知っていればよい。マルチキャスト・ルータは、各隣接システムの関心を追跡する必要はない。(ただし、説明については付録A.2のポイント1を参照のこと。)

IGMPv3は、前のバージョンのIGMPプロトコルと下位互換性がある。古いIGMPシステムとの下位互換性を維持するため、IGMPv3マルチキャスト・ルータはプロトコルのバージョン1と2も実装しなければならない(MUST)(セクション7を参照)。

6.1. IGMPクエリの条件

マルチキャスト・ルータは、接続されたネットワークからグループ・メンバーシップ情報を要求するために、定期的に一般クエリを送信する。これらのクエリは、接続されたネットワーク上のシステムのグループ・メンバーシップ状態を構築し、更新するために使用する。システムはこれらのクエリに応答し、IGMPv3メンバーシップ・レポートの現状グループ・レコードで、グループ・メンバーシップの状態(及び希望する送信元セット)を報告する。

マルチキャスト・グループのメンバーとして、システムは特定の送信元からのトラフィックを受信するか受信しないかを表明することができる。システムの希望する受信状態が変化すると、システムはフィルタ・モード変更レコードまたは送信元リスト変更レコードを使用してこれらの変更を報告する。これらのレコードは、グループ・レコードの送信元リストまたはフィルタ・モードのいずれかで、システムのグループ内の明示的な状態変更を示す。特定のシステムでグループ・メンバーシップが終了したとき、または特定の送信元からのトラフィックが不要になったとき、マルチキャスト・ルータは、グループ(または送信元)を削除して、そのトラフィックをプルーニングする前に、グループの他のメンバーまたは送信元のリスナーを照会しなければならない。

ネットワーク上のすべてのシステムがグループ・メンバーシップの変更に対応できるように、マルチキャスト・ルータは特定のクエリを送信する。グループ固有クエリは、指定されたグループの受信を希望するシステムがないことを確認するため、または特定のグループの希望する受信状態を「再構築」するために送信される。グループ固有クエリは、システムがグループを抜けることを示す状態変更レコードをルータが受信したときに送信される。

グループ及び送信元固有クエリは、ネットワーク上に送信元セットからのトラフィックの受信を希望するシステムが存在しないことを確認するために使用される。グループ及び送信元固有クエリは、転送しないように要求された特定のグループの送信元をリストする。このクエリは、指定された送信元アドレスから指定されたグループ・アドレスへのパケットの受信を希望するシステムがあるかどうかを確認するために、マルチキャスト・ルータによって送信される。グループ及び送信元固有クエリは、状態変更レコードへの応答としてのみ送信され、現状レコードへの応答として送信されることはない。セクション4.1.11で、各クエリの詳細を説明する。

6.2. マルチキャスト・ルータが維持するIGMP状態

IGMPv3を実装するマルチキャスト・ルータは、接続されたネットワークごとにグループごとに状態を維持する。このグループ状態は、フィルタ・モード、送信元のリスト、及びさまざまなタイマーで構成される。IGMPを実行している各接続ネットワークに対して、マルチキャスト・ルータはそのネットワークに望ましい受信状態を記録する。その状態は、概念的には以下の形式のレコード・セットで構成される:

(multicast address, group timer, filter-mode, (source records))

各送信元レコードは以下の形式である:

(source address, source timer)

特定のグループ内のすべての送信元が望ましい場合は、空の送信元レコード・リストがフィルタ・モードをEXCLUDEに設定した保持される。これは、このネットワーク上のホストがこのグループのすべての送信元が転送されることを望むことを意味する。これは、IGMPv1またはIGMPv2のグループ参加に相当するIGMPv3である。

6.2.1. ルータのフィルタ・モードの定義

内部状態を減らすために、IGMPv3ルータは接続されたネットワークごとにグループごとにフィルタ・モードを保持する。このフィルタ・モードは、グループの望ましい受信状態の全体を、すべてのシステムのメンバーシップが満たされるような最小セットに凝縮するために使用される。このフィルタ・モードは、特定の種類のグループ・レコードの受信に応じて、または特定のタイマー条件の発生に応じて変更される場合がある。以下のセクションでは、ルータ内の特定のグループのフィルタ・モードを指すために、「ルータ・フィルタ・モード」という用語を使用する。セクション6.4では、受信したグループ・レコードごとのルータ・フィルタ・モードの変更について説明する。

概念的には、グループ・レコードを受信すると、そのグループのルータ・フィルタ・モードは、最小の状態を使用して、要求されたすべての送信元をカバーするように更新される。原則として、フィルタ・モードがEXCLUDEであるグループ・レコードを受信すると、そのグループのルータ・フィルタ・モードはEXCLUDEになる。

グループのルータ・フィルタ・モードがEXCLUDEの場合、送信元レコード・リストには2種類の送信元が含まれる。最初のタイプは、望ましい受信状態での競合を示すセットである。このセットは、ネットワーク上のいずれかのルータによって転送されなければならない。2番目のタイプは、ホストが転送しないように要求した送信元のセットである。付録Aでは、EXCLUDEモードのときにこの2番目のセットを保持する理由を説明する。

グループのルータ・フィルタ・モードがINCLUDEの場合、送信元レコード・リストは、グループに必要な送信元のリストである。これは、そのグループに必要な送信元のセット全体である。送信元レコード・リスト内の各送信元は、ネットワーク上のいずれかのルータによって転送しなければならない。

EXCLUDEのフィルタ・モードを持つ報告されたグループ・レコードは、そのグループに対するフィルタ・モードをEXCLUDEに移行させるので、ルータのフィルタ・モードをINCLUDEに戻すメカニズムが存在しなければならない。EXCLUDEフィルタ・モードのグループ・レコードを持つすべてのシステムが報告を停止した場合、そのグループに対するルータ・フィルタ・モードをINCLUDEモードに戻すことが望ましい。この遷移はグループ・タイマーの期限が切れたときに発生し、セクション6.5で詳しく説明している。

6.2.2. グループ・タイマーの定義

グループ・タイマーは、グループがEXCLUDEモードの場合にのみ使用され、グループのフィルタ・モードが期限切れとなり、INCLUDEモードに切り替わるまでの時間を表す。グループ・タイマーは、グループごと、接続されたネットワークごとに0の下限を持つ減分タイマーとして定義する。グループ・タイマーは、受信したグループ・レコードのタイプに応じて更新される。

グループに対するルータ・フィルタ・モードがEXCLUDEのときにグループ・タイマーが期限切れになるということは、EXCLUDEモードの接続されたネットワーク上にリスナーがいないことを意味する。この時点で、ルータはINCLUDEフィルタ・モードに移行する。セクション6.5では、EXCLUDEモード中にグループ・タイマーが期限切れになったときに実行されるアクションについて説明する。

以下の表は、グループ・タイマーの役割をまとめたものである。セクション6.4では、受信したグループ・レコードのタイプごとにグループ・タイマーを設定する詳細について説明する。

グループ・フィルタ・モード グループ・タイマー値 アクション/コメント
INCLUDE Timer >= 0 すべてのメンバーがINCLUDEモード。
EXCLUDE Timer > 0 少なくとも1つのメンバーがEXCLUDEモード。
EXCLUDE Timer == 0 グループへのリスナーがいない。すべての送信元タイマーが期限切れの場合、グループ・レコードを削除する。まだ実行中の送信元レコード・タイマーがある場合は、実行中のタイマーが送信元レコードをINCLUDE送信元レコード状態として使用して、INCLUDEフィルタ・モードに切り替える。

6.2.3. 送信元タイマーの定義

送信元タイマーは送信元レコードごとに保持され、下限が0の減分タイマーである。送信元タイマーは、受信したグループ・レコードのタイプとフィルタ・モードに応じて更新される。送信元タイマーは、そのグループの受信レコードに送信元が存在する場合は常に更新される(特定のグループに対して)。セクション6.4では、受信したグループ・レコードのタイプごとの送信元タイマーの設定について説明する。

INCLUDEのグループのルータ・フィルタ・モードの実行タイマーを持つ送信元レコードは、現在、その送信元の受信を望む1つ以上のシステム(INCLUDEフィルタ・モード)があることを意味する。INCLUDEのグループに対するルータ・フィルタ・モードの送信元タイマーが期限切れになると、ルータは、この特定の送信元からのトラフィックは、接続されたネットワーク上ではもはや望まれていない判断し、関連する送信元レコードを削除する。

グループのルータ・フィルタ・モードがEXCLUDEの場合、送信元タイマーは異なる方法で処理される。EXCLUDEグループのルータ・フィルタ・モードの実行タイマーを持つ送信元レコードは、少なくとも1つのシステムがその送信元を望んでいることを意味する。したがって、ネットワーク上のルータによって転送される必要がある。付録Aでは、EXCLUDE状態の間に転送を要求された送信元の状態を保持する理由を説明する。

グループのルータ・フィルタ・モードがEXCLUDEの状態で送信元タイマーが期限切れになると、ルータはルーティング・プロトコルに、この送信元からのトラフィックに関心のある受信者がネットワーク上に存在しなくなったことを通知する。

グループのルータ・フィルタ・モードがEXCLUDEの場合、送信元レコードはグループ・タイマーが期限切れになったときにのみ削除される。セクション6.3では、送信元タイマーの値に応じて実行する必要があるアクションについて説明する。

6.3. IGMPv3送信元固有の転送ルール

マルチキャスト・ルータが特定のグループ宛てとする送信元からのデータグラムを受信すると、そのデータグラムを接続ネットワークに転送するかどうかを決定する必要がある。使用中のマルチキャスト・ルーティング・プロトコルはこの決定を担当し、IGMPv3情報を使用して、サブネットワーク上で望まれるすべての送信元/グループがそのサブネットワークに転送されるようにすべきである。IGMPv3情報はマルチキャスト・ルーティング情報を上書きしない。例えば、GのIGMPv3フィルタ・モード・グループがEXCLUDEの場合、ルータは除外された送信元のパケットをトランジット・サブネットに転送することができる。

要約すると、以下の表は、グループ宛ての送信元から発信されたトラフィックに対して、IGMPがルーティング・プロトコルに対して行う転送提案を説明している。また、グループのルータ・フィルタ・モードに基づいて、送信元タイマーの期限が切れたときに実行されるアクションについてもまとめている。

グループ・
フィルタ・モード		 送信元タイマー値 アクション
INCLUDE TIMER > 0 送信元からのトラフィック転送を提案
INCLUDE TIMER == 0 送信元からのトラフィック転送を停止し、
送信元レコードを削除することを提案する。
グループの送信元レコードがなくなった場合は、
グループ・レコードを削除する。
INCLUDE 送信元要素なし 送信元を転送しないことを提案
EXCLUDE TIMER > 0 送信元からのトラフィックを転送することを提案
EXCLUDE TIMER == 0 送信元からのトラフィックを転送しないことを提案(レコードを削除しない)
EXCLUDE 送信元要素なし 送信元からのトラフィックを転送することを提案

6.4. レポート受信時のアクション

6.4.1. 現状レコードの受信

現状レコードを受信すると、ルータはグループ・タイマーと送信元タイマーの両方を更新する。状況によっては、あるタイプのグループ・レコードを受信すると、そのグループに対するルータ・フィルタ・モードが変更される。以下の表は、現状レコードの受信時にルータの状態に発生する状態とタイマーに関するアクションを説明している。

送信元タイマーの更新を説明するために、以下の表記法を使用する。特定のグループの送信元の合計数を表すには、( A, B )という表記を使用する。

A = 送信元タイマーが0より大きい送信元レコードのセット(少なくとも1つのホストが転送を要求した送信元)
B = 送信元タイマーが0である送信元レコードのセット(IGMPがルーティング・プロトコルに転送しないように提案する送信元)

グループに対するルータのフィルタ・モードがEXCLUDEの場合、2つのセットしかないことに留意する。グループに対するルータのフィルタ・モードがINCLUDEの場合、転送を要求された送信元のセット(例えば、単に(A))を表すために、1つのセットが使用される。

以下の表では、いくつかの変数に略語が使われている(すべてセクション8で詳しく説明している)。変数GMIは、グループ・メンバーシップ間隔(Group Membership Interval)の略語で、グループ・メンバーシップがタイムアウトする時間である。変数LMQTは、最終メンバー ・クエリ時間(Last Member Query Time)の略語で、最終メンバー・クエリ回数(Last Member Query Count)の再送後に費やされる合計時間である。LMQTは、「離脱待ち時間 (leave latency)」、つまりメンバーシップ変更が送信されてからルーティング・プロトコルに提供される情報が変更されるまでの差を表す。

ルータ状態テーブルの「アクション」セクションでは、「A=J」という表記を使用する。これは、送信元レコードのセットAの送信元タイマーを値Jに設定することを意味する。「Aを削除」は、送信元レコードのセットAを削除することを意味する。 「Group Timer = J」は、グループのグループ・タイマーを値Jに設定することを意味する。

ルータ状態 レポートが受信 新しいルータ状態 アクション
INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B)=GMI
INCLUDE (A) IS_EX (B) EXCLUDE (A*B, B-A) (B-A)=0
Delete (A-B)
Group Timer=GMI
EXCLUDE (X, Y) IS_IN (A) EXCLUDE (X+A, Y-A) (A)=GMI
EXCLUDE (X, Y) IS_EX (A) EXCLUDE (A-Y, Y*A) (A-X-Y)=GMI
Delete (X-A)
Delete (Y-A)
Group Timer=GMI

6.4.2. フィルタ・モード変更レコードと送信元リスト変更レコードの受信

あるシステムでグループのグローバル状態に変更が起こると、システムはそのグループに対して送信元リスト変更レコードまたはフィルタ・モード変更レコードのいずれかを送信する。現状レコードと同様に、ルータはこれらのレコードに基づいて動作し、ネットワークの新しい望ましいメンバーシップ状態を反映するために、それ自身の状態を変更しなければならない。

ルータは、グループに転送されなくなるように要求された送信元を照会する必要がある。ルータが特定の送信元セットを照会または受信すると、それらの送信元の送信元タイマーが最終メンバー ・クエリ時間秒の短い間隔に短縮される。クエリに応答して、照会された送信元からのトラフィックを受信することに関心を示すグループ・レコードを受信した場合、対応するタイマーが更新される。

同様に、ルータが特定のグループを照会すると、そのグループのグループ・タイマーが最終メンバー ・クエリ時間秒の短い間隔に短縮される。その間隔内に、そのグループに対する EXCLUDEモードの関心を示すグループ・レコードが受信されると、そのグループに対するグループ・タイマーが更新され、グループを転送するためのルーティング・プロトコルへの提案が中断することなく有効になる。

クエリ期間中(つまり、最終メンバー ・クエリ時間秒)、ルータのIGMPコンポーネントは、クエリ対象のグループまたは送信元からのトラフィックを転送するようにルーティング・プロトコルに提案し続ける。ルータがネットワークからグループまたは送信元をプルーニングできるのは、クエリ対象のグループまたは送信元に対する関心を示すレコードを受信しないまま、最終メンバー ・クエリ時間秒が経過してからである。

以下の表は、フィルタ・モード変更または送信元リスト変更レコードのいずれかを受信したときの、グループ状態の変更と実行されるアクションについて示している。この表は、特定のレポートを受信したときにクエリアが送信するクエリについても説明している。

送信されるクエリを説明するために、以下の表記法を使用する。「Q(G)」という記法を使用して、Gに対するグループ固有クエリを説明する。「Q(G,A)」という記法を使用して、送信元リストAを持つGに対するグループ及び送信元固有クエリを説明する。アクションの結果として、送信元リストAがnullの場合(例えば、A*B)、操作の結果としてクエリは送信されない。

プロトコルの堅牢性を維持するために、以下の表のアクションによって送信されたクエリは、[最終メンバー ・クエリ回数]、[最終メンバー ・クエリ間隔]ごとに1回送信する必要がある。

新しいクエリをスケジューリングしている間に、同じグループに対して再送される保留中のクエリがすでに存在する場合、新しいクエリと保留中のクエリをマージする必要がある。さらに、保留中のクエリを持つグループに対する受信したホスト・レポートは、それらのクエリの内容に影響を与えるかもしれない。セクション6.6.3では、保留中のクエリの状態を構築及び維持するプロセスについて説明する。

ルータ状態 レポートを受信した 新しいルータの状態 アクション
INCLUDE (A) ALLOW (B) INCLUDE (A+B) (B)=GMI
INCLUDE (A) BLOCK (B) INCLUDE (A) Send Q(G,A*B)
INCLUDE (A) TO_EX (B) EXCLUDE (A\*B,B-A) (B-A)=0
Delete (A-B)
Send Q(G,A*B)
Group Timer=GMI
INCLUDE (A) TO_IN (B) INCLUDE (A+B) (B)=GMI
Send Q(G,A-B)
EXCLUDE (X,Y) ALLOW (A) EXCLUDE (X+A,Y-A) (A)=GMI
EXCLUDE (X,Y) BLOCK (A) EXCLUDE (X+(A-Y),Y) (A-X-Y)=Group Timer
Send Q(G,A-Y)
EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y)=Group Timer
Delete (X-A)
Delete (Y-A)
Send Q(G,A-Y)
Group Timer=GMI
EXCLUDE (X,Y) TO_IN (A) EXCLUDE (X+A,Y-A) (A)=GMI
Send Q(G,X-A)
Send Q(G)

6.5. ルータ・フィルタ・モードの切り替え

グループ・タイマーは、ルータ・フィルタ・モードをEXCLUDEからINCLUDEに移行するためのメカニズムとして使用される。

ルータ・フィルタ・モードがEXCLUDEでグループ・タイマーが期限切れになると、ルータは、接続されたネットワーク上にEXCLUDEのフィルタ・モードを持つシステムが存在しないものと見なす。ルータのグループ・フィルタ・モードがEXCLUDEで、グループ・タイマーが期限切れになると、そのグループに対するルータ・フィルタ・モードはINCLUDEに移行する。

ルータは、INCLUDEのフィルタ・モードに切り替える状態として、実行中の送信元タイマーを持つ送信元レコードを使用する。送信元タイマーが0より大きい(つまり、転送が要求された)送信元レコードがある場合、ルータはそれらの送信元レコードを使用してINCLUDEのフィルタ・モードに切り替える。タイマーが0の送信元レコードは(前のEXCLUDEモードから)削除される。

例えば、あるグループに対するルータの状態がEXCLUDE(X,Y)で、そのグループのグループ・タイマーが期限切れになった場合、ルータは状態INCLUDE(X)のINCLUDEのフィルタ・モードに切り替える。

6.6. クエリ受信時のアクション

6.6.1. タイマーの更新

ルータが、ルータ側処理抑制(Suppress Router-Side Processing)フラグがクリアされたクエリを送信または受信する場合、ルータはそのタイマーを更新して、クエリ対象のグループまたは送信元の正しいタイムアウト値を反映する必要がある。以下の表は、ルータ側処理抑制フラグが設定されていないグループ固有クエリまたはグループ及び送信元固有クエリを送信または受信する場合のタイマーのアクションについて説明している。

クエリ アクション
Q(G,A) Aの送信元の 送信元タイマーをLMQTに下げる
Q(G) グループ・タイマーをLMQTに下げる

ルータ側処理抑制フラグが設定されたクエリを送信または受信する場合、ルータはそのタイマーは更新しない。

6.6.2. クエリの選択

IGMPv3は、IGMPv2と同じクエリア選択メカニズム(つまりIPアドレス)を使用して、サブネットごとに1つのクエリアを選出する。ルータは、より低いIPアドレスを持つクエリを受信すると、他クエリア存在(Other-Querier-Present)タイマーを他クエリア存在間隔に設定し、以前に選出されたクエリであれば、ネットワーク上でクエリの送信を停止する。他クエリア存在タイマーが期限切れになると、一般クエリの送信を開始する。

ルータが古いバージョンのクエリを受信した場合、ネットワーク上で最も古いバージョンの IGMPを使用しなければならない(MUST)。IGMPバージョン間の互換性の問題の詳細については、セクション7を参照のこと。

6.6.3. 特定のクエリの作成と送信

6.6.3.1. グループ固有クエリの作成と送信

テーブル・アクション「Send Q(G)」が検出されると、グループ・タイマーをLMQTに下げなければならない。その後、ルータは直ちにグループ固有クエリを送信し、[最終メンバー ・クエリ回数 - 1]回のクエリ再送信を[最終メンバー ・クエリ間隔]ごとに[最終メンバー ・クエリ時間]にわたって送信するようにスケジュールしなければならない。

グループ固有クエリを送信するときに、グループ・タイマーがLMQTより大きい場合、クエリ・メッセージに「ルータ側処理抑制」ビットを設定する。

6.6.3.2.グループ及び送信元固有クエリの作成と送信

セクション6.4.2の表でクエリアがテーブル・アクション「Q(G,X) を送信」に遭遇した場合、送信元タイマーがLMQTより大きいグループGのXの各送信元に対して、以下のアクションを実行しなければならない。

  • 各送信元の再送回数を[最終メンバー・クエリ回数]に設定する。

  • 送信元タイマーをLMQTに下げる。

その後、ルータは直ちにグループ及び送信元固有クエリを送信し、さらに[最終メンバー・クエリ回数 - 1]回のクエリ再送を[最終メンバー・クエリ間隔]ごとに[最終メンバー・クエリ時間]にわたって送信するようにスケジューリングしなければならない。これらのクエリの内容は以下のように計算する。

グループGに対して、グループ及び送信元固有クエリを作成する場合、2つの別々のクエリ・メッセージを送信する。最初のメッセージには「ルータ側処理抑制」ビットが設定され、再送状態と、タイマーがLMQTより大きいすべての送信元が含まれる。2番目は「ルータ側処理抑制」ビットがクリアされ、再送状態とLMQT以下のタイマーを持つすべての送信元が含まれる。計算された2つのメッセージのいずれかに送信元を含まない場合、その送信は抑制される。

注記: グループ固有クエリが、同じグループに対するグループ及び送信元固有クエリと同時に送信されるようにスケジュールされている場合、「ルータ側処理抑制」ビットが設定されたグループ及び送信元固有メッセージの送信が抑制されることがある。

7. 旧バージョンのIGMPとの相互運用

IGMPバージョン3のホストやルータは、まだIGMPv3にアップグレードされていないホスト及びルータと相互運用できる。この互換性は、ネットワーク内のホストやルータで動作しているIGMPのバージョンに応じて、ホストやルータが適切なアクションを実行することで維持する。

7.1. クエリ・バージョンの区別

メンバーシップ・クエリ・メッセージのIGMPバージョンは、以下のように決定する。

IGMPv1クエリ: 長さ = 8オクテット、かつ、最大応答コード・フィールドがゼロ

IGMPv2クエリ: 長さ = 8 オクテット、かつ、最大応答コード・フィールドがゼロ以外

IGMPv3クエリ: 長さ >= 12オクテット

上記の条件のいずれにも一致しないクエリ・メッセージ(長さ10オクテットのクエリなど)は、黙って無視しなければならない(MUST)。

7.2. グループ・メンバーの動作

7.2.1. 旧バージョンのクエリが存在する場合

旧バージョンのルータとの互換性を保つため、IGMPv3ホストはバージョン1とバージョン2の互換モードで動作しなければならない(MUST)。IGMPv3ホストは、接続された各ネットワークの互換モードに関して、ローカル・インタフェースごとに状態を保持しなければならない(MUST)。ホストの互換モードは、ホスト互換モード変数から決定する。この変数は、IGMPv1、IGMPv2、または IGMPv3の3つの状態のいずれかとなる。この変数はインタフェースごとに保持され、そのインタフェースで受信される一般クエリのバージョンと、そのインタフェースの旧バージョン・クエリア存在タイマーに依存する。

IGMPのバージョンを適切に切り替えるため、ホストはインタフェースごとにIGMPv1クエリア存在タイマーとIGMPv2クエリア存在タイマーの両方を保持する。IGMPv1クエリア存在は、IGMPv1メンバーシップ・クエリを受信するたびに、旧バージョン・クエリア存在タイムアウト秒に設定する。IGMPv2一般クエリを受信するたびに、IGMPv2クエリア存在を旧バージョンのクエリア存在タイムアウト秒に設定する。

インタフェースのホスト互換モードは、(現在の互換モードよりも)古いバージョンのクエリを受信したときや、特定のタイマー条件が発生したときに変更する。 IGMPv1クエリア存在タイマーが期限切れになると、ホストはIGMPv2クエリア存在タイマーが実行中の場合、IGMPv2のホスト互換モードに切り替わる。IGMPv2クエリア存在タイマーが実行中でない場合は、IGMPv3のホスト互換モードに切り替わる。IGMPv2クエリア存在タイマーが期限切れになると、ホストはIGMPv3のホスト互換モードに切り替わる。

ホスト互換モード変数は、直前の古いバージョンのクエリア存在タイムアウト秒内に古いバージョンの一般クエリが受信されたかどうかに基づく。ホスト互換モードは、以下の条件に応じて設定される:

ホスト互換
モード		 タイマー状態
IGMPv3
(デフォルト)		 IGMPv2クエリア存在が実行中でなく、IGMPv1クエリア存在が実行中でない
IGMPv2 IGMPv2クエリア存在が実行中で、IGMPv1クエリア存在が実行中でない
IGMPv1 IGMPv1クエリア存在が実行中

ホストがクエリア存在タイマーを更新し、それに応じて互換モードを更新するクエリを受信した場合、ホストは直ちに互換モードを切り替える必要がある。

ホスト互換モードがIGMPv3の場合、ホストはそのインタフェースでIGMPv3プロトコルを使用して動作する。ホスト互換モードがIGMPv2の場合、ホストはそのインタフェース上でIGMPv2プロトコルのみ使用して、IGMPv2互換モードで動作する。ホスト互換モードがIGMPv1の場合、ホストはそのインタフェース上でIGMPv1プロトコルのみを使用するIGMPv1互換モードで動作する。

IGMPv1ルータは、最大応答コードを0に設定して一般クエリを送信する。これは、100(10秒)の値と解釈しなければならない(MUST)。

IGMPv2ルータは、最大応答コードを目的の最大応答時間に設定した一般クエリを送信する。つまり、このフィールドの全範囲は線形であり、セクション4.1.1で説明されている指数アルゴリズムは使用しない。

ホストが互換モードを変更するたびに、保留中の応答タイマーと再送信タイマーをすべて取り消す。

7.2.2. 旧バージョンのグループ・メンバーが存在する場合

IGMPv3ホストは、まだIGMPv3にアップグレードされていないホストが存在するネットワーク上に配置される場合がある。ホストは、 IGMPv3メンバーシップ・レコードが、バージョン1のメンバーシップ・レポートまたはバージョン 2のメンバーシップ・レポートのいずれかによってを抑制されることを許可してもよい(MAY)。

7.3. マルチキャスト・ルータの動作

7.3.1. 旧バージョンのクエリーが存在する場合

IGMPv3ルータは、ネットワーク上の少なくとも1つのルータがまだIGMPv3にアップグレードされていないネットワーク上に配置することができる。以下の要件が適用される:

  • ルータに旧バージョンのIGMPが存在する場合、クエリはネットワーク上に存在する最も低いバージョンのIGMPを使用しなければならない(MUST)。これは管理上保証しなければならない。IGMPv1とIGMPv2の互換性を持たせたいルータには、IGMPv1またはIGMPv2互換モードで動作する設定オプションを持たせなければならない(MUST)。IGMPv1モードのとき、ルータは最大応答コードが0で、グループ・アドレス・フィールドで切り捨てられた定期クエリ(つまり、8バイト長)を送信しなければならず(MUST)、グループ離脱メッセージを無視しなければならない(MUST)。IGMPv2またはIGMPv3クエリの受信についても警告する必要がある(SHOULD)が、そのような警告はレート制限しなければならない(MUST)。IGMPv2モードのとき、ルータはグループ・アドレス・フィールドで切り捨てられた定期クエリ(つまり、8バイト長)を送信しなければならず(MUST)、IGMPv3クエリの受信についても警告する必要がある(SHOULD)(このような警告はレート制限しなければならない(MUST))。また、最大応答コード フィールドに最大応答時間を入力しなければならない(MUST)。つまり、セクション4.1.1で説明している指数アルゴリズムは使用しない。

  • ルータがIGMPv1またはIGMPv2を使用するように明示的に設定されておらず、IGMPv1クエリまたはIGMPv2一般クエリを受信した場合、警告をログに記録する必要がある(SHOULD)。これらの警告はレート制限しなければならない(MUST)。

7.3.2. 旧バージョンのグループ・メンバーが存在する場合

IGMPv3ルータは、まだIGMPv3にアップグレードされていないホストが存在するネットワーク上に配置されるかもしれない。旧バージョンのホストと互換性を保つために、IGMPv3ルータはバージョン1とバージョン2の互換モードで動作しなければならない(MUST)。IGMPv3ルータは、グループ・レコードごとに互換モードを保持する。グループの互換モードは、IGMPv1、IGMPv2、またはIGMPv3の3つの状態のいずれかになるグループ互換モード変数から決定する。この変数はグループ・レコードごとに保持され、そのグループに対して受信されたメンバーシップ・レポートのバージョンと、そのグループの旧バージョンのホスト存在タイマーに依存する。

IGMPのバージョン間を適切に切り替えるために、ルータはグループ・レコードごとにIGMPv1ホスト存在タイマーとIGMPv2ホスト存在タイマーを保持する。IGMPv1ホスト存在タイマーは、IGMPv1メンバーシップ・レポートを受信するたびに、旧バージョンのホスト存在タイムアウト秒に設定する。IGMPv2ホスト存在タイマーは、IGMPv2メンバーシップ・レポートを受信するたびに、旧バージョンのホスト存在タイムアウト秒に設定する。

グループ・レコードのグループ互換モードは、(現在の互換モードよりも)旧バージョンのレポートを受信するか、特定のタイマー条件が発生するたびに変更さする。IGMPv1ホスト存在タイマーが期限切れになると、ルータは実行中のIGMPv2ホスト存在タイマーがあれば、IGMPv2のグループ互換モードに切り替わる。実行中のIGMPv2ホスト存在タイマーがない場合は、IGMPv3のグループ互換モードに切り替わる。IGMPv2ホスト存在タイマーが期限切れになり、IGMPv1ホスト存在タイマーが動作していない場合、ルータはIGMPv3のグループ互換モードに切り替わる。グループがIGMPv3モードに切り替わると、送信元固有状態情報を取り戻すのに時間がかかることに留意する。送信元固有の情報は次の一般クエリの間に学習されるが、ブロックする必要がある送信元はその後の[グループ・メンバーシップ間隔] までブロックされない。

グループ互換性モード変数は、直近の旧バージョンのホスト存在タイムアウト秒内に旧バージョンのレポートが受信されたかどうかに基づいている。グループ互換モードは、以下の条件に応じて設定される:

グループ互換
モード		 タイマー状態
IGMPv3
(デフォルト)		 IGMPv2ホスト存在が動作しておらず、IGMPv1ホスト存在は動作していない
IGMPv2 IGMPv2ホスト存在が動作中で、IGMPv1ホスト存在が動作していない。
IGMPv1 IGMPv1ホスト存在が動作中

ルータが、古いホスト存在タイマーを更新させ、それに応じて互換モードも更新させるレポートを受信した場合、ルータはすぐに互換モードを切り替える必要がある(SHOULD)。

グループ互換モードがIGMPv3の場合、ルータはそのグループに対してIGMPv3プロトコルを使用して動作する。

グループ互換モードがIGMPv2の場合、ルータはそのグループの次のIGMPv2メッセージをIGMPv3の同等メッセージに内部的に変換する。

IGMPv2メッセージ IGMPv3同等メッセージ
レポート IS_EX( {} )
離脱 TO_IN( {} )

IGMPv3 BLOCKメッセージは無視され、TO_EX()メッセージ内の送信元リストも無視する(つまり、TO_EX()メッセージはすべてTO_EX( )として扱われる)。

グループ互換モードがIGMPv1の場合、ルータはそのグループの次のIGMPv1とIGMPv2メッセージを、IGMPv3の同等メッセージに内部的に変換する。

IGMPメッセージ IGMPv3 同等メッセージ
v1レポート IS_EX( {} )
v2レポート IS_EX( {} )

IGMPv2グループ互換モードの場合と同様に、IGMPv3 BLOCKメッセージとTO_EX()メッセージ内の送信元リストを無視するだけでなく、IGMPv2離脱メッセージとIGMPv3 TO_IN()メッセージも無視する。

8. タイマー、カウンター、及びそれらのデフォルト値のリスト

これらのタイマーのほとんどは設定可能である。デフォルト以外の設定を使用する場合、単一リンク上のすべてのシステム間で一貫していなければならない(MUST)。代数をわかりやすくするため、括弧を使って式をグループ化していることに留意する。

8.1.堅牢性変数

堅牢性変数を使用すると、ネットワーク上で予想されるパケット損失をチューニングできる。ネットワークが損失を被ると予想される場合、堅牢性変数を増やすことができる。IGMPは(堅牢性変数 - 1)パケット損失に対して堅牢である。堅牢性変数は0であってはならず(MUST NOT)、1であってもならない(SHOULD NOT)。デフォルト: 2

8.2. クエリ間隔

クエリ間隔は、クエリアが送信する一般クエリ間の間隔である。デフォルト: 125秒。

[クエリ間隔]を変更することで、管理者はネットワーク上のIGMPメッセージの数をチューニングできる。値が大きいほど、IGMPクエリの送信頻度が低くなる。

8.3. クエリ応答間隔

定期的な一般クエリに挿入される最大応答コードを計算するために使用される最大応答時間。デフォルト: 100(10秒)

[クエリ応答間隔]を変更することで、管理者はネットワーク上のIGMPメッセージのバースト性をチューニングできる。値が大きいほど、ホスト応答がより長い間隔に分散するため、トラフィックのバースト性が低くなる。 [クエリ応答間隔]で表される秒数は、[クエリ間隔]より短くなければならない。

8.4. グループ・メンバーシップ間隔

グループ・メンバーシップ間隔は、マルチキャスト・ルータがネットワーク上にグループのメンバーまたは特定の送信元がもう存在しないと判断するまでに経過しなければならない時間である。

この値は((堅牢性変数) × (クエリ間隔)) + (1つのクエリ応答間隔)でなければならない(MUST)。

8.5. 他クエリア存在間隔

他クエリア存在間隔は、クエリアとなるべき他のマルチキャスト・ルータがもはや存在しないと判断するまでに経過しなければならない時間の長さである。この値は((堅牢性変数) × (クエリ間隔)) + (1つのクエリ応答間隔の半分)でなければならない(MUST)。

8.6. 起動クエリ間隔

起動クエリ間隔は、起動時にクエリアが送信する一般クエリ間の間隔である。デフォルト: クエリ間隔の1/4。

8.7. 起動クエリ数

起動クエリ数は、起動クエリ間隔で区切られた、起動時に送信されるクエリの数である。デフォルト: 堅牢性変数。

8.8. 最終メンバー・クエリ間隔

最終メンバー・クエリ間隔は、グループ離脱メッセージへの応答として送信されるグループ固有クエリに挿入される最大応答コードを計算するために使用される最大応答時間である。また、グループ及び送信元固有クエリ・メッセージの最大応答コードを計算するために使用される最大応答時間でもある。デフォルト: 10(1秒)

LMQIの値が12.8秒を超える場合、最大応答コードの連続値に対応する限られた値しか表すことができないことに留意すること。設定された時間を最大応答コード値に変換する場合、可能であれば正確な値を使用するか、もし、要求された値が正確に表せない場合は、その次の低い値を使用することを推奨する。

この値を、ネットワークの「離脱待ち時間」を変更するために調整することができる。値を小さくすると、グループや送信元の最後のメンバーの損失を検出する時間が短くなる。

8.9. 最終メンバー・クエリ数

最終メンバー・クエリ数は、ルータがローカル・メンバーが存在しないと見なす前に送信されたグループ固有クエリの数である。また、最終メンバー・クエリ数は、ルータが特定の送信元のリスナーが存在しないと見なす前に送信されるグループ及び送信元固有クエリ数でもある。デフォルト: 堅牢性変数。

8.10. 最終メンバー・クエリ時間

最終メンバー・クエリ時間は、最終メンバー・クエリ間隔に最終メンバー・クエリ数を掛けた値で表される時間値である。これは調整可能な値ではないが、その構成要素を変更することで調整できる。

8.11. 未承諾レポート間隔

未承諾レポート間隔は、ホストがグループ内のメンバーシップの最初のレポートの繰り返し間隔である。デフォルト: 1秒。

8.12. 旧バージョンのクエリア存在タイムアウト

旧バージョンのクエリア存在間隔は、旧バージョンのクエリが受信したホストが IGMPv3モードに戻るためのタイムアウトである。旧バージョンのクエリを受信すると、ホストは旧バージョンのクエリア存在タイマーを旧バージョンのクエリア存在間隔に設定する。

この値は、((堅牢性変数) × (最後に受信したクエリのクエリ間隔)) + (1つのクエリ応答間隔)でなければならない(MUST)。

8.13. 旧ホスト存在間隔

旧ホスト存在間隔は、そのグループに対して旧バージョンのレポートが送信された後にグループをIGMPv3モードに戻すためのタイムアウトである。旧バージョンのレポートを受信すると、ルータは旧ホスト存在タイマーを旧ホスト存在間隔に設定する。

この値は、((堅牢性変数) × (クエリ間隔)) + (1つのクエリ応答間隔)でなければならない(MUST)。

8.14. タイマーの設定

このセクションは、ネットワーク管理者に、ネットワークに合わせてこれらの設定をどのように調整するかについてアドバイスを提供することを目的としている。野心的なルータの実装は、ネットワークの特性の変化に基づいて、これらの設定を動的に調整するかもしれない。

8.14.1. 堅牢性変数

堅牢性変数は、リンク上の予想される損失に合わせてIGMPを調整する。IGMPv3は(堅牢性変数 - 1)パケット損失に対して堅牢である。例えば、堅牢性変数がデフォルト値の2に設定されている場合、IGMPv3は1つのパケット損失に対して堅牢だが、それ以上の損失が発生すると動作が不完全になる可能性がある。損失の多いサブネットワークでは、予想されるパケット損失を許容するために、堅牢性変数を増やす必要がある。ただし、堅牢性変数を増やすと、サブネットワークの離脱待ち時間が長くなる。(離脱待ち時間とは、最後のメンバーが送信元またはグループの受信を停止してから、トラフィックが流れなくなるまでの時間である。)

8.14.2. クエリ間隔

定期的なIGMPトラフィックの全体的なレベルは、クエリ間隔に反比例する。クエリ間隔が長いほど、IGMPトラフィックの全体的なレベルは低くなる。クエリ間隔は、一般クエリ・メッセージに挿入されている最大応答時間と同じか、それよりも長くしなければならない(MUST)。

8.14.3. 最大応答時間

IGMPトラフィックのバースト性は、最大応答時間に反比例する。最大応答時間が長いほど、レポート・メッセージが長い間隔に分散される。しかし、グループ固有クエリと送信元及びグループ固有クエリの最大応答時間が長いほど、離脱待ち時間が長くなる。(離脱遅延とは、最後のメンバーが送信元またはグループの受信を停止してから、トラフィックが流れなくなるまでの時間である。) レポート・メッセージの予想レートは、予想されるレポーター数を最大応答時間で割ることで計算できる。最大応答時間は、クエリごとに、そのクエリの予想レポーター数を使用して、以下のように動的に計算することができる。

クエリ・タイプ 予想レポーター数
一般クエリ サブネットワーク上のすべてのシステム
グループ固有クエリ サブネットワーク上のグループに関心を示したすべてのシステム
送信元及びグループ固有クエリ サブネットワーク上の送信元とグループに関心を示していたすべてのシステム

ルータは、これらの個数を計算したり、最大応答時間を動的にチューニングする必要はない。これらは単なるガイドラインである。

9. セキュリティに関する考慮事項

各タイプのメッセージが偽造された場合の影響について考慮し、必要に応じてメッセージを認証するためのIPSEC AHの使用について説明する。

9.1. クエリ・メッセージ

現在のクエリアよりも低いIPアドレスを持つマシンからの偽造クエリ・メッセージは、クエリアの役割を偽造者に割り当てる。その後、偽造者がクエリ・メッセージを送信しないと、他のルータのその他のクエリア存在タイマーがタイムアウトし、クエリアの役割を再開する。この間、偽造者が離脱メッセージを無視すると、[グループ・メンバーシップ間隔]までの間、メンバーが存在しないグループにトラフィックが流れるかも知れない。

ホストへのDoS攻撃は、偽造されたグループ及び送信元固有クエリを通じて実行される可能性がある。攻撃者は、一般的なクエリを使用して、特定のホストのメンバーシップを知ることができる。その後、大規模な送信元リストと大きな値に設定された最大応答時間を持つ、多数のグループ及び送信元固有クエリを送信する可能性がある。ホストは、遅延応答を送信するのにかかる時間だけ、これらのすべてのクエリで指定された送信元を保存して維持する必要がある。このため、連続するクエリに含まれる送信元リストで記録された送信元を補強するために、メモリとCPUサイクルの両方が消費される。

このようなDoS攻撃から保護するために、ホスト・スタックの実装は、この間隔内でグループ・メンバーシップごとのグループ及び送信元固有クエリの数を制限したり、限られた数の送信元のみを記録することができる。

ローカル・ネットワークからの偽造クエリ・メッセージは簡単に追跡できる。外部で偽造されたクエリを防御するために必要な手段は3つある:

  • ルータはクエリを転送すべきではない(SHOULD NOT)。クエリがルータ・アラート・オプションを伝える場合、ルータが簡単に実行できる。

  • ホストは、ルータ・アラート・オプションのないv2またはv3のクエリを無視する必要がある(SHOULD)。

  • ホストは、全システム・アドレスである224.0.0.1以外のマルチキャスト・アドレスに送信されたv1、v2、またはv3の一般クエリを無視する必要がある(SHOULD)。

9.2. 現状レポート・メッセージ

偽造されたレポート・メッセージは、マルチキャスト・ルータに、ネットワーク上にグループのメンバーが存在しないのに存在すると思わせる可能性がある。ローカル・ネットワークからの偽造レポート・メッセージは無意味である。というのも、ホスト上のグループへの参加は一般的に非特権操作であるため、ローカル・ユーザはメッセージを偽造することなく、同じ結果を簡単に得ることができるからである。外部送信元からの偽造レポート・メッセージはより厄介である。外部からの偽造レポートに対する防御策は2つある:

  • パケットの送信元アドレスが、パケットを受信したインタフェースに割り当てられたネットワークに属するものであることを識別できない場合、レポートを無視する。この解決策は、ローカル・ネットワーク上のアドレスを持たないモバイル・ホストから送られたレポートが無視されることを意味する。送信元アドレスが0.0.0.0のレポート・メッセージは、どのインタフェースでも受け入れられる必要がある(SHOULD)。

  • ルータ・アラート・オプション[RFC-2113]のないレポート・メッセージを無視し、ルータがレポート・メッセージを転送しないように要求する。(パケットにはすでにルータ・アラート・オプションが含まれているので、この要件は転送パスにおける一般的されたフィルタリングの要件ではない。) このソリューションは、ルータ・アラートを必要としないIGMPv1または以前のバージョンのIGMPv2の実装との下位互換性を破壊する。

偽造されたバージョン1レポート・メッセージは、ルータが離脱メッセージを無視することを意味し、特定のグループに対して「バージョン1メンバーが存在する」状態にルータを置くかも知れない。このため、最大[グループ・メンバーシップ間隔]の間、トラフィックがメンバーのいないグループに流れる可能性がある。これは、バージョン1メッセージを完全に無視する設定スイッチをルータに提供することで解決できる。これは、バージョン1ホストとの自動的な互換性が損なわれるため、「高速離脱」が重要な状況でのみ使う必要がある。

偽造されたバージョン2レポート・メッセージは、ルータがIGMPv3送信元固有の状態メッセージを無視することを意味し、特定のグループに対して「バージョン2メンバーが存在する」状態にルータを置くかも知れない。このため、最大[グループ・メンバーシップ間隔]の間、不要な送信元からトラフィックが流れる可能性がある。これは、バージョン2メッセージを完全に無視する設定スイッチをルータに提供することで解決できる。これは、バージョン2ホストとの自動互換性が失われるため、送信元のincludeとexcludeが重要な状況でのみ使用する必要がある。

9.3. 状態変更レポート・メッセージ

偽造された状態変更レポート・メッセージにより、クエリアは問題のグループに対してグループ固有クエリまたは送信元及びグループ固有クエリを送信する。これにより、各ルータとグループの各メンバーで余分な処理が発生するが、必要なトラフィックが失われることはない。外部で偽造された状態変更レポート・メッセージに対する防御策は2つある。

  • パケットの送信元アドレスが、パケットを受信したインタフェースに割り当てられたサブネットに属するものであると識別できない場合、状態変更レポート・メッセージを無視する。この解決策は、ローカル・サブネット上のアドレスを持たないモバイル・ホストから送信された状態変更レポート・メッセージが無視されることを意味する。送信元アドレスが0.0.0.0の状態変更レポート・メッセージは、どのインタフェースでも受け入れられる必要がある(SHOULD)。

  • ルータ・アラート・オプションのない状態変更レポート・メッセージを無視し[RFC-2113]、ルータが状態変更レポート・メッセージを転送しないように要求する。(パケットにはすでにルータ・アラート・オプションが含まれているため、この要件は転送パスにおける一般的なフィルタリングの要件ではない。)

9.4. IPSECの使用法

これらの対策に加えて、IGMPv3メッセージがLAN上のシステム(より具体的には、適切なキーを持つシステム)からのものであることを保証することによって、リモート攻撃から保護するために、認証ヘッダ・モードのIPSEC[AH]を使用することできる。IPSECを使用する場合、224.0.0.1と224.0.0.22に送られるメッセージは、AHを使用して認証する必要がある。キー認証を使用する場合、以下の2つの可能性がある。

  1. LANに単一のキー(または各グループに1つのキー)を持つ対称署名アルゴリズムを使用する。これにより、パケットがキーを持つシステムから送信されたことを検証できる。これには、キーを持つシステムであれば誰でもメッセージを偽造できるという制限があり、個々の送信者を正確に認証することはできない。また、IPSecのリプレイ保護を無効にする必要がある。

  2. 適切なキー管理標準が開発されている場合は、非対称署名アルゴリズムを使用する。すべてのシステムはすべてのルータの公開鍵を知っている必要があり、すべてのルータはすべてのシステムの公開鍵を知っている必要がある。これには大量のキー管理が必要だが、送信者を個別に認証できるという利点がある。そのため、例えば、ホストはルータのみが送信できるメッセージを偽造することはできない。

このソリューションは、IGMPv1とIGMPv2のクエリ・メッセージと離脱メッセージにのみ直接適用される。なぜなら、レポートはレポート対象のグループに送信され、任意のマルチキャスト・グループに対してホストとルータ間の通信用のキーを合意することは実行不可能だからである。

10. IANA の考慮事項

本文書で説明するすべてのIGMPタイプは、すでに[IANA-REG]で割り当てられている。

11. 謝辞

ラン・アトキンソン、ルイス・コスタ、トアレス・エッカート、ディノ・ファリナッチ、セルジュ・フディダ、ウィルベルト・デ・グラーフ、スミト・グプタ、マーク・ハンドレー、ボブ・クイン、マイケル・スピアー、デーブ・ターラー、ロラン・ヴィダらに、本文書に対するコメントと提案を感謝する。

本文書の一部は、[RFC-1112]と[RFC-2236]からコピーした。

12. 引用規格

[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.

[IANA-REG] <http://www.iana.org/assignments/igmp-type-numbers>

[RFC-1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.

[RFC-2113] Katz, D., "IP Router Alert Option," RFC 2113, February, 1997.

[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC-2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.

[RFC-3228] Fenner, B., "IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)", BCP 57, RFC 3228, February 2002.

13. 参考規格

[RFC-1071] Braden, R., Borman, D. and C. Partridge, "Computing the Internet checksum", RFC 1071, September 1988.

[FILTER-API] Thaler, D., B. Fenner, and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", Work in Progress.

[SSM] Bhattacharyya, S., et. al., "An Overview of Source- Specific Multicast (SSM)", Work in Progress.

[MLD] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.

[MLDV2] Vida, R., L. Costa, S. Fdida, S. Deering, B. Fenner, I. Kouvelas, and B. Haberman, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", Work in Progress.

付録 A. 設計の根拠

A.1 状態変更メッセージの必要性

IGMPv3では、現在の状態と状態変更の2種類のメンバーシップ・レポートが規定している。このセクションでは、これら2種類のレポートの必要性について説明する。

ルータは、クエリに応答して送信されたメンバーシップ・レポートと、インタフェース状態の変更の結果として送信されたメンバーシップ・レポートを区別する必要がある。メンバーシップ・クエリに応答して送信されたメンバーシップ・レポートは、主にルータの既存の状態を更新するために使用される。これらは通常、ルータで状態の遷移を引き起こさない。インタフェース状態の変更に応答して送信されるメンバーシップ・レポートは、受信したレポートに対してルータが何らかのアクションを取ることを要求する(セクション6.4を参照)。

2種類のレポートを区別できない場合、ルータはすべてのメンバーシップ・レポートを潜在的な状態変更として扱わざるを得なくなり、ルータでの処理が増えるだけでなく、ネットワーク上の IGMPトラフィックが増加する可能性がある。

A.2 ホスト抑制

IGMPv1とIGMPv2では、ネットワーク上の他のメンバーから同様のレポートが観測された場合、ホストは保留中のメンバーシップ・レポートの送信を取り消していた。IGMPv3では、ホスト・メンバーシップ・レポートの抑制は削除された。この決定の背景には以下のような理由がある。

  1. ルータは、インタフェース上のホストごとのメンバーシップ・ステータスを追跡したいと思うかも知れない。これにより、ルータは高速離脱(例えば、階層化マルチキャスト輻輳制御スキームのため)を実装できるだけでなく、アカウンティング目的でメンバーシップ・ステータスを追跡することができる。

  2. メンバーシップ・レポートの抑制は、ブリッジLANではうまく機能しない。IGMPスヌーピングを実装している多くのブリッジやレイヤ2/レイヤ3スイッチは、メンバーシップ・レポート抑制を防ぐために、LANセグメント間でIGMPメッセージを転送しない。メンバーシップ・レポート抑制を削除すると、これらのIGMPスヌーピング・デバイスの作業が軽減される。

  3. メンバーシップ・レポート抑制をなくすことで、ホストは処理するメッセージが少なくなり、ステート・マシンの実装が簡単になる。

  4. IGMPv3では、1つのメンバーシップ・レポートが複数のマルチキャスト・グループ・レコードをバンドルし、送信するパケットの数を減らす。それに比べて、IGMPの以前のバージョンは、各マルチキャスト・グループを個別のメッセージで報告する必要があった。

A.3 ルータのフィルタ・モードをEXCLUDEからINCLUDEに切り替える

ネットワーク内の1つのマルチキャスト・グループに対して、EXCLUDEモードとINCLUDEモードの両方のホストが存在する場合、ルータもEXCLUDEモードでなければならない(セクション6.2.1を参照)。EXCLUDEモードでは、その送信元が除外送信元リストに存在しない限り、ルータはすべての送信元からのトラフィックを転送する。EXCLUDEモードのすべてのホストが存在しなくなった場合、ルータは既存の受信者へのトラフィックの流れを中断することなく、シームレスにINCLUDEモードに戻ることが望ましい。

これを実現する方法の1つは、ルータ自体がEXCLUDEモードであっても、INCLUDEモードのホストが望むすべての送信元をルータが追跡することである。グループ・タイマーがEXCLUDEモードで期限切れになった場合、ネットワーク上にEXCLUDEモードのホストがないことを意味する(そうでなければ、そのホストからのメンバーシップ・レポートがグループ・タイマーを更新したことになる)。その後、ルータは、送信元リストで現在転送されている送信元リストを使用して、シームレスにINCLUDEモードに切り替えることができる。

付録 B. IGMPv2からの変更の概要

IGMPv3の主な追加機能は送信元フィルタリングの追加だが、RFC 2236からの他の変更の概要は以下のとおりである。

  • 状態は、IGMPv2のように単にグループではなく、グループ + 送信元リストとして維持される。

  • IGMPv1及びIGMPv2システムとの相互運用性は、IGMPv3状態の操作として定義される。

  • IPサービス・インタフェースは、送信元リストを指定できるように変更された。

  • クエリアは、クエリ以外でこれらの変数を同期できるように、その堅牢性変数とクエリ間隔をクエリ・パケットに含めた。

  • クエリ・メッセージの最大応答時間は指数関数的な幅を持たせ、最大が25.5秒から約53分に変更され、多数のシステムとのリンクで使用できる。

  • ホストは、堅牢性を高めるために状態変更メッセージを再送する。

  • 後で拡張できるよう、追加のデータ・セクションが定義された。

  • レポート・パケットは224.0.0.22に送信され、レイヤ2スイッチの「スヌーピング」を支援する。

  • レポート・パケットは、より少ないパケットで完全な現在の状態を報告できるよう、複数のグループ・レコードを含むことができる。

  • 実装が簡素化され、明示的なメンバーシップ追跡を可能にするために、ホストは抑制を実行しなくなった。

  • クエリ・メッセージの新しいルータ側処理抑制 (S)フラグにより、IGMPv2にも存在していた堅牢性問題を修正した。

著者のアドレス

ブラッド・カイン
Cereva Networks

スティーブ・ディーリング
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA 95134-1706
電話: +1-408-527-8213
メール: deering@cisco.com

ビル・フェナー
AT&T Labs - Research
75 Willow Rd.
Menlo Park, CA 94025
電話: +1-650-330-7893
メール: fenner@research.att.com

イシドー・クーヴェラス
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA 95134-1706
電話: +1-408-525-0727
メール: kouvelas@cisco.com

アジット・ティヤガラジャン
Ericsson IP Infrastructure

完全な著作権に関する声明

Copyright (C) The Internet Society (2002)。無断複写・転載を禁ずる。

本文書およびその翻訳は、複製して他者に提供することができる。また、本文書に注釈を加えたり、解説を加えたり、実装を支援したりする派生著作物は、上記の著作権表示とこの段落がすべての複製および派生著作物に含まれている限り、いかなる種類の制限もなく、全体または一部を問わず作成、複製、公開、配布することができる。ただし、著作権表示やインターネットソサエティや他のインターネット組織への言及を削除するなど、本文書そのものをいかなる形でも改変してはならない。ただし、インターネット標準を策定する目的で必要な場合は、インターネット標準プロセスで定義されている著作権に関する手順に従わなければならない。また、英語以外の言語に翻訳する必要がある場合は除く。

上記で付与された限定的な許可は永続的なものであり、インターネットソサエティまたはその承継者や譲受者によって取り消されることはない。

本文書及びここに含まれる情報は「現状のまま」で提供され、インターネットソサエティ及びインターネット・エンジニアリング・タスク・フォースは、明示的または黙示的を問わず、ここに記載された情報の使用がいかなる権利も侵害しないという保証、または商品性または特定目的への適合性に関する黙示的保証を含むが、これに限定されないすべての保証を否認する。

謝辞

RFCエディタ機能の資金は現在、インターネットソサエティから提供されている。

更新履歴

  • 2024.7.15
  • 2024.7.23
GitHubで編集を提案

Discussion