RFC 3376 - Internet Group Management Protocol, Version 3 (インターネットグループ管理プロトコル、バージョン3)

ステータス: Proposed Standard
発行日: October 2002
ストリーム: IETF
更新: RFC2236
廃止: RFC9776
エラッタ: エラッタなし

Status of this Memo (このメモの位置づけ)

このドキュメントは、インターネットコミュニティのためのインターネット標準化過程のプロトコルを指定し、改善のための議論と提案を求めます。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

Copyright Notice (著作権表示)

Abstract (概要)

このドキュメントは、インターネットグループ管理プロトコル (Internet Group Management Protocol) のバージョン 3、IGMPv3 を規定します。IGMP は、IPv4 システムが隣接するマルチキャストルーターに IP マルチキャストグループへの参加を報告するために使用されるプロトコルです。IGMP のバージョン 3 では、「ソースフィルタリング」のサポートが追加されました。つまり、特定のマルチキャストアドレスに送信されたパケットのうち、特定の送信元アドレスからのパケットのみ、または特定の送信元アドレス以外からのパケットを受信することに関心があることをシステムが報告できる機能です。この情報は、関心のある受信者がいないネットワークに特定の送信元からのマルチキャストパケットを配信しないようにするために、マルチキャストルーティングプロトコルによって使用される場合があります。

このドキュメントは RFC 2236 を廃止します。

Contents (目次)

1. Introduction (はじめに)

インターネットグループ管理プロトコル (IGMP) は、IPv4 システム (ホストおよびルーター) が、隣接するマルチキャストルーターに IP マルチキャストグループへの参加を報告するために使用されます。IP マルチキャストルーター自体が 1 つ以上のマルチキャストグループのメンバーである可能性があることに注意してください。その場合、ルーターはプロトコルの「マルチキャストルーター部分」(マルチキャストルーティングプロトコルに必要なメンバーシップ情報を収集するため) とプロトコルの「グループメンバー部分」(自身のメンバーシップを自身および他の隣接するマルチキャストルーターに通知するため) の両方を実行します。

IGMP は、グループメンバーシップの報告に使用されるもの以外のメッセージタイプを使用して、他の IP マルチキャスト管理機能にも使用されます。このドキュメントでは、グループメンバーシップの報告機能とメッセージのみを指定します。

このドキュメントでは、IGMP のバージョン 3 を規定します。[RFC-1112] で規定されたバージョン 1 は、最初に広く展開されたバージョンであり、インターネット標準になった最初のバージョンでした。[RFC-2236] で規定されたバージョン 2 では、「低脱退遅延 (low leave latency)」のサポートが追加されました。これは、特定のグループのメンバーが接続されたネットワーク上に存在しなくなったことをマルチキャストルーターが学習するのにかかる時間を短縮するものです。バージョン 3 では、「ソースフィルタリング」のサポートが追加されました。つまり、特定送信元マルチキャスト [SSM] をサポートするために必要なように、特定の送信元アドレスからのパケットのみ、または特定の送信元アドレス以外からのパケットを受信することに関心があることをシステムが報告できる機能です。バージョン 3 は、バージョン 1 および 2 と相互運用できるように設計されています。

マルチキャストリスナー検出 (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. The Service Interface for Requesting IP Multicast Reception (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 送信元アドレスから要求されます。
"source-list" は、フィルタモードに応じてマルチキャスト受信が望まれるか望まれない、0 個以上の IP ユニキャストアドレスの順序なしリストです。実装はソースリストのサイズに制限を課すことができます（MAY）が、その制限はリストあたり 64 アドレス未満であってはなりません（MUST NOT）。操作によってソースリストのサイズ制限を超えた場合、サービスインターフェースはエラーを返さなければなりません（MUST）。

ソケット、インターフェース、およびマルチキャストアドレスの特定の組み合わせに対して、一度に有効にできるのは単一のフィルタモードとソースリストのみです。ただし、同じソケット、インターフェース、およびマルチキャストアドレスを指定する後続の IPMulticastListen 要求によって、フィルタモードまたはソースリスト、あるいはその両方を変更できます。後続の各要求は、指定されたソケット、インターフェース、およびマルチキャストアドレスに対する以前の要求を完全に置き換えます。

IGMP の以前のバージョンではソースフィルタがサポートされておらず、特定のインターフェースで特定のマルチキャストアドレス（すべてのソースから）の受信を有効および無効にする Join および Leave 操作で構成される単純なサービスインターフェースがありました。新しいサービスインターフェースでの同等の操作は次のとおりです。

The Join operation is equivalent to

Join 操作は次と同等です。

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

Leave 操作は次と同等です。

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

ここで、{} は空のソースリストです。

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

3. Multicast Reception State Maintained by Systems (システムによって維持されるマルチキャスト受信状態)

3.1. Socket State (ソケット状態)

IPMulticastListen が呼び出された各ソケットについて、システムはそのソケットの希望するマルチキャスト受信状態を記録します。その状態は概念的には次の形式の一連のレコードで構成されます。

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

ソケット状態は、ソケットでの IPMulticastListen の各呼び出しに応じて次のように変化します。

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

3.2. Interface State (インターフェース状態)

ソケットごとのマルチキャスト受信状態に加えて、システムは各インターフェースのマルチキャスト受信状態も維持または計算する必要があります。その状態は概念的には次の形式の一連のレコードで構成されます。

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

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

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

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

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

同じマルチキャストアドレス m に送信されたパケットの同じインターフェース i での受信を、ソース b、c、または d からのものである場合のみ要求します。両方のソケットの受信要件を満たすには、インターフェース i がソース a、b、c、または d のいずれかから m に送信されたパケットを受信する必要があります。したがって、この例では、マルチキャストアドレス m に対するインターフェース i の受信状態は、フィルタモード INCLUDE とソースリスト {a, b, c, d} を持ちます。

マルチキャストパケットが IP 層によってインターフェースから受け入れられた後、特定のソケットで待機しているアプリケーションまたはプロセスへのその後の配信は、そのソケットのマルチキャスト受信状態 [および場合によっては、ソケットがバインドされているトランスポート層ポートなどの他の条件] に依存します。したがって、上記の例では、パケットがインターフェース i に到着し、マルチキャストアドレス m 宛てで、送信元アドレスが a である場合、それはソケット 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をInternetwork Control(例:Type of Service 0xc0)として送信され、IPヘッダーにIP Router Alertオプション[RFC-2113]を含みます。IGMPメッセージタイプは[RFC-3228]で説明されているようにIANA [IANA-REG]によって登録されます。

このドキュメントで説明されているIGMPv3プロトコルに関係する2つのIGMPメッセージタイプがあります:

Type Number (hex)	Message Name
0x11	Membership Query
0x22	Version 3 Membership Report

IGMPv3の実装は、以前のバージョンのIGMPとの相互運用のために、以下の3つのメッセージタイプもサポートする必要があります(セクション7を参照):

Type Number (hex)	Message Name	Reference
0x12	Version 1 Membership Report	[RFC-1112]
0x16	Version 2 Membership Report	[RFC-2236]
0x17	Version 2 Leave Group	[RFC-2236]

認識されないメッセージタイプは無視される必要があります。他のメッセージタイプは、IGMPの新しいバージョンや拡張、マルチキャストルーティングプロトコル、またはその他の用途で使用される場合があります。

このドキュメントでは、特に限定されない限り、大文字の"Query"と"Report"は、それぞれIGMP Membership QueriesとIGMP Version 3 Membership Reportsを指します。

4.1. Membership Queryメッセージ

Membership QueriesはIPマルチキャストルーターによって送信され、隣接インターフェースのマルチキャスト受信状態を照会します。Queriesは以下のフォーマットを持ちます:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 0x11  | Max Resp Code |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Group Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Resv  |S| QRV |     QQIC      |     Number of Sources (N)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address [1]                      |
   +-                                                             -+
   |                       Source Address [2]                      |
   +-                              .                              -+
   .                               .                               .
   .                               .                               .
   +-                                                             -+
   |                       Source Address [N]                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.1. Max Resp Code

Max Resp Codeフィールドは、応答レポートを送信する前に許可される最大時間を指定します。実際に許可される時間(Max Resp Time)は1/10秒単位で表され、Max Resp Codeから次のように導出されます:

Max Resp Code < 128の場合、Max Resp Time = Max Resp Code

Max Resp Code >= 128の場合、Max Resp Codeは次のように浮動小数点値を表します:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |1| exp | mant  |
   +-+-+-+-+-+-+-+-+

Max Resp Time = (mant | 0x10) << (exp + 3)

Max Resp Timeの小さい値により、IGMPv3ルーターは"leave latency"(最後のホストがグループを離れた瞬間から、ルーティングプロトコルがメンバーがいなくなったことを通知される瞬間までの時間)を調整できます。より大きい値、特に指数範囲の値により、ネットワーク上のIGMPトラフィックのバースト性を調整できます。

4.1.2. Checksum

Checksumは、IGMPメッセージ全体(IP payload全体)の1の補数の和の16ビット1の補数です。チェックサムを計算する際、Checksumフィールドはゼロに設定されます。パケットを受信する際、パケットを処理する前にチェックサムを検証する必要があります。[RFC-1071]

4.1.3. Group Address

Group AddressフィールドはGeneral Queryを送信するときにゼロに設定され、Group-Specific QueryまたはGroup-and-Source-Specific Queryを送信するときに照会されるIPマルチキャストアドレスに設定されます(以下のセクション4.1.9を参照)。

4.1.4. Resv (Reserved)

Resvフィールドは送信時にゼロに設定され、受信時に無視されます。

4.1.5. S Flag (Suppress Router-Side Processing)

1に設定すると、S Flagは、受信するすべてのマルチキャストルーターに対し、Queryを聞いたときに実行する通常のタイマー更新を抑制するよう指示します。ただし、querierの選出や、ルーターがグループメンバーであることの結果として実行する必要がある通常の"ホスト側"のQueryの処理は抑制しません。

4.1.6. QRV (Querier's Robustness Variable)

ゼロでない場合、QRVフィールドには、querier(Queryの送信者)が使用する[Robustness Variable]値が含まれます。querierの[Robustness Variable]がQRVフィールドの最大値7を超える場合、QRVはゼロに設定されます。ルーターは、最後に受信したQueryのQRV値を自身の[Robustness Variable]値として採用しますが、最後に受信したQRVがゼロの場合、受信者はセクション8.1で指定されたデフォルトの[Robustness Variable]値または静的に構成された値を使用します。

4.1.7. QQIC (Querier's Query Interval Code)

Querier's Query Interval Codeフィールドは、querierが使用する[Query Interval]を指定します。実際の間隔(Querier's Query Interval、QQI)は秒単位で表され、Querier's Query Interval Codeから次のように導出されます:

QQIC < 128の場合、QQI = QQIC

QQIC >= 128の場合、QQICは次のように浮動小数点値を表します:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |1| exp | mant  |
   +-+-+-+-+-+-+-+-+

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

現在のquerierではないマルチキャストルーターは、最後に受信したQueryのQQI値を自身の[Query Interval]値として採用しますが、最後に受信したQQIがゼロの場合、受信ルーターはセクション8.2で指定されたデフォルトの[Query Interval]値を使用します。

4.1.8. Number of Sources (N)

Number of Sources (N)フィールドは、Queryに存在するソースアドレスの数を指定します。この数は、General QueryまたはGroup-Specific Queryではゼロであり、Group-and-Source-Specific Queryではゼロ以外です。この数は、Queryが送信されるネットワークのMTUによって制限されます。たとえば、MTUが1500オクテットのイーサネットでは、Router Alertオプションを含むIPヘッダーが24オクテットを消費し、Number of Sources (N)フィールドまでのIGMPフィールドが12オクテットを消費するため、ソースアドレス用に1464オクテットが残り、ソースアドレスの数は366 (1464/4)に制限されます。

4.1.9. Source Address [i]

Source Address [i]フィールドは、n個のIPユニキャストアドレスのベクトルであり、nはNumber of Sources (N)フィールドの値です。

4.1.10. Additional Data

受信したQueryのIPヘッダーのPacket Lengthフィールドが、ここで説明されているフィールドを超えて追加のデータオクテットが存在することを示している場合、IGMPv3実装は、受信したIGMP Checksumを検証する計算にそれらのオクテットを含める必要がありますが、それ以外の場合はそれらの追加オクテットを無視する必要があります。Queryを送信する際、IGMPv3実装は、ここで説明されているフィールドを超えて追加のオクテットを含めてはなりません。

4.1.11. Queryのバリエーション

Queryメッセージには3つのバリエーションがあります:

"General Query"は、隣接インターフェースの完全なマルチキャスト受信状態を知るためにマルチキャストルーターによって送信されます(つまり、Queryが送信されるネットワークに接続されているインターフェース)。General Queryでは、Group AddressフィールドとNumber of Sources (N)フィールドの両方がゼロです。
"Group-Specific Query"は、隣接インターフェースの単一のマルチキャストアドレスに関する受信状態を知るためにマルチキャストルーターによって送信されます。Group-Specific Queryでは、Group Addressフィールドに対象のマルチキャストアドレスが含まれ、Number of Sources (N)フィールドにはゼロが含まれます。
"Group-and-Source-Specific Query"は、隣接インターフェースが、指定されたマルチキャストアドレスに送信されるパケットを指定されたソースのリストのいずれかから受信したいかどうかを知るためにマルチキャストルーターによって送信されます。Group-and-Source-Specific Queryでは、Group Addressフィールドに対象のマルチキャストアドレスが含まれ、Source Address [i]フィールドに対象のソースアドレスが含まれます。

4.1.12. QueriesのIP宛先アドレス

IGMPv3では、General QueriesはIP宛先アドレス224.0.0.1(all-systemsマルチキャストアドレス)で送信されます。Group-SpecificおよびGroup-and-Source-Specific Queriesは、対象のマルチキャストアドレスに等しいIP宛先アドレスで送信されます。ただし、システムは、IP Destination Addressフィールドに、Queryが到着するインターフェースに割り当てられたアドレス(ユニキャストまたはマルチキャスト)のいずれかを含むQueryを受け入れて処理する必要があります。

4.2. Version 3 Membership Reportメッセージ

Version 3 Membership ReportsはIPシステムによって送信され、(隣接ルーターに)インターフェースの現在のマルチキャスト受信状態、またはマルチキャスト受信状態の変化を報告します。Reportsは以下のフォーマットを持ちます:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 0x22  |    Reserved   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |  Number of Group Records (M)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [1]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [2]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   .                               .                               .
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [M]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

各Group Recordは次の内部フォーマットを持ちます:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Record Type  |  Aux Data Len |     Number of Sources (N)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Multicast Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address [1]                      |
   +-                                                             -+
   |                       Source Address [2]                      |
   +-                                                             -+
   .                               .                               .
   .                               .                               .
   .                               .                               .
   +-                                                             -+
   |                       Source Address [N]                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                         Auxiliary Data                        .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2.1. Reserved

Reservedフィールドは送信時にゼロに設定され、受信時に無視されます。

4.2.2. Checksum

Checksumは、IGMPメッセージ全体(IP payload全体)の1の補数の和の16ビット1の補数です。チェックサムを計算する際、Checksumフィールドはゼロに設定されます。パケットを受信する際、メッセージを処理する前にチェックサムを検証する必要があります。

4.2.3. Number of Group Records (M)

Number of Group Records (M)フィールドは、このReportに存在するGroup Recordsの数を指定します。

4.2.4. Group Record

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

4.2.5. Record Type

以下のセクション4.2.12を参照してください。

4.2.6. Aux Data Len

Aux Data Lenフィールドには、このGroup Record内のAuxiliary Dataフィールドの長さが32ビットワード単位で含まれます。補助データがないことを示すためにゼロを含めることができます。

4.2.7. Number of Sources (N)

Number of Sources (N)フィールドは、このGroup Recordに存在するソースアドレスの数を指定します。

4.2.8. Multicast Address

Multicast Addressフィールドには、このGroup Recordが関係するIPマルチキャストアドレスが含まれます。

4.2.9. Source Address [i]

Source Address [i]フィールドは、n個のIPユニキャストアドレスのベクトルであり、nはこのレコードのNumber of Sources (N)フィールドの値です。

4.2.10. Auxiliary Data

Auxiliary Dataフィールドは、存在する場合、このGroup Recordに関する追加情報を含みます。このドキュメントで指定されているプロトコルIGMPv3は、補助データを定義していません。したがって、IGMPv3の実装は、送信されるGroup Recordに補助データを含めてはならず(つまり、Aux Data Lenフィールドをゼロに設定する必要があります)、受信されたGroup Recordに存在する補助データを無視する必要があります。Auxiliary Dataフィールドのセマンティクスと内部エンコーディングは、このフィールドを使用するIGMPの将来のバージョンまたは拡張によって定義される必要があります。

4.2.11. Additional Data

受信したReportのIPヘッダーのPacket Lengthフィールドが、最後のGroup Recordを超えて追加のデータオクテットが存在することを示している場合、IGMPv3実装は、受信したIGMP Checksumを検証する計算にそれらのオクテットを含める必要がありますが、それ以外の場合はそれらの追加オクテットを無視する必要があります。Reportを送信する際、IGMPv3実装は、最後のGroup Recordを超えて追加のオクテットを含めてはなりません。

4.2.12. Group Recordタイプ

Reportメッセージに含めることができる異なるタイプのGroup Recordsがいくつかあります:

"Current-State Record"は、インターフェースで受信したQueryに応答してシステムによって送信されます。単一のマルチキャストアドレスに関するそのインターフェースの現在の受信状態を報告します。Current-State RecordのRecord Typeは、次の2つの値のいずれかです:

Value	Name and Meaning
1	MODE_IS_INCLUDE - 指定されたマルチキャストアドレスに対してインターフェースがINCLUDEフィルターモードを持っていることを示します。このGroup Record内のSource Address [i]フィールドには、指定されたマルチキャストアドレスのインターフェースのソースリストが含まれます(空でない場合)。
2	MODE_IS_EXCLUDE - 指定されたマルチキャストアドレスに対してインターフェースがEXCLUDEフィルターモードを持っていることを示します。このGroup Record内のSource Address [i]フィールドには、指定されたマルチキャストアドレスのインターフェースのソースリストが含まれます(空でない場合)。

"Filter-Mode-Change Record"は、IPMulticastListenのローカル呼び出しが特定のマルチキャストアドレスのインターフェースレベル状態エントリのフィルターモードの変更(つまり、INCLUDEからEXCLUDE、またはEXCLUDEからINCLUDEへの変更)を引き起こすたびにシステムによって送信されます。Recordは、変更が発生したインターフェースから送信されるReportに含まれます。Filter-Mode-Change RecordのRecord Typeは、次の2つの値のいずれかです:

Value	Name and Meaning
3	CHANGE_TO_INCLUDE_MODE - 指定されたマルチキャストアドレスに対してインターフェースがINCLUDEフィルターモードに変更されたことを示します。このGroup Record内のSource Address [i]フィールドには、指定されたマルチキャストアドレスのインターフェースの新しいソースリストが含まれます(空でない場合)。
4	CHANGE_TO_EXCLUDE_MODE - 指定されたマルチキャストアドレスに対してインターフェースがEXCLUDEフィルターモードに変更されたことを示します。このGroup Record内のSource Address [i]フィールドには、指定されたマルチキャストアドレスのインターフェースの新しいソースリストが含まれます(空でない場合)。

Value

Name and Meaning

CHANGE_TO_INCLUDE_MODE - 指定されたマルチキャストアドレスに対してインターフェースがINCLUDEフィルターモードに変更されたことを示します。このGroup Record内のSource Address [i]フィールドには、指定されたマルチキャストアドレスのインターフェースの新しいソースリストが含まれます(空でない場合)。

CHANGE_TO_EXCLUDE_MODE - 指定されたマルチキャストアドレスに対してインターフェースがEXCLUDEフィルターモードに変更されたことを示します。このGroup Record内のSource Address [i]フィールドには、指定されたマルチキャストアドレスのインターフェースの新しいソースリストが含まれます(空でない場合)。

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

Value	Name and Meaning
5	ALLOW_NEW_SOURCES - このGroup Record内のSource Address [i]フィールドに、指定されたマルチキャストアドレスに送信されるパケットに対してシステムが受信したい追加のソースのリストが含まれていることを示します。変更がINCLUDEソースリストに対するものであった場合、これらはリストに追加されたアドレスです。変更がEXCLUDEソースリストに対するものであった場合、これらはリストから削除されたアドレスです。
6	BLOCK_OLD_SOURCES - このGroup Record内のSource Address [i]フィールドに、指定されたマルチキャストアドレスに送信されるパケットに対してシステムが受信したくないソースのリストが含まれていることを示します。変更がINCLUDEソースリストに対するものであった場合、これらはリストから削除されたアドレスです。変更がEXCLUDEソースリストに対するものであった場合、これらはリストに追加されたアドレスです。

Value

Name and Meaning

ALLOW_NEW_SOURCES - このGroup Record内のSource Address [i]フィールドに、指定されたマルチキャストアドレスに送信されるパケットに対してシステムが受信したい追加のソースのリストが含まれていることを示します。変更がINCLUDEソースリストに対するものであった場合、これらはリストに追加されたアドレスです。変更がEXCLUDEソースリストに対するものであった場合、これらはリストから削除されたアドレスです。

BLOCK_OLD_SOURCES - このGroup Record内のSource Address [i]フィールドに、指定されたマルチキャストアドレスに送信されるパケットに対してシステムが受信したくないソースのリストが含まれていることを示します。変更がINCLUDEソースリストに対するものであった場合、これらはリストから削除されたアドレスです。変更がEXCLUDEソースリストに対するものであった場合、これらはリストに追加されたアドレスです。

ソースリストの変更が新しいソースの許可と古いソースのブロックの両方をもたらす場合、同じマルチキャストアドレスに対して2つのGroup Recordsが送信されます。1つはALLOW_NEW_SOURCESタイプで、もう1つはBLOCK_OLD_SOURCESタイプです。

"State-Change Record"という用語は、Filter-Mode-Change RecordまたはSource-List-Change Recordを指すために使用します。

認識されないRecord Type値は無視される必要があります。

4.2.13. ReportsのIPソースアドレス

IGMPレポートは、宛先サブネットの有効なIPソースアドレスで送信されます。まだIPアドレスを取得していないシステムは、ソースアドレス0.0.0.0を使用できます。ソースアドレス0.0.0.0は、LAN上の複数のシステムによって同時に使用される場合があることに注意してください。ルーターは、ソースアドレスが0.0.0.0のレポートを受け入れる必要があります。

4.2.14. ReportsのIP宛先アドレス

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

4.2.15. Group Recordsの表記法

このドキュメントの残りの部分では、特定のマルチキャストアドレスに関するGroup Recordの内容を記述するために次の表記法を使用します:

   IS_IN ( x )  -  Type MODE_IS_INCLUDE, source addresses x
   IS_EX ( x )  -  Type MODE_IS_EXCLUDE, source addresses x
   TO_IN ( x )  -  Type CHANGE_TO_INCLUDE_MODE, source addresses x
   TO_EX ( x )  -  Type CHANGE_TO_EXCLUDE_MODE, source addresses x
   ALLOW ( x )  -  Type ALLOW_NEW_SOURCES, source addresses x
   BLOCK ( x )  -  Type BLOCK_OLD_SOURCES, source addresses x

ここで、xは次のいずれかです:

ソースアドレスのセットを表す大文字(例:"A")、または
セット式(例:"A+B")。ここで、"A+B"はセットAとBの和集合を意味し、"A*B"はセットAとBの積集合を意味し、"A-B"はセットAからセットBのすべての要素を削除することを意味します。

4.2.16. Membership Reportのサイズ

Reportに必要なGroup Recordsのセットが単一のReportメッセージのサイズ制限内に収まらない場合(送信されるネットワークのMTUによって決定されます)、セット全体を報告するために必要な数のReportメッセージでGroup Recordsが送信されます。

単一のGroup Recordに非常に多くのソースアドレスが含まれており、単一のReportメッセージのサイズ制限内に収まらない場合、そのTypeがMODE_IS_EXCLUDEまたはCHANGE_TO_EXCLUDE_MODEでない場合、それは複数のGroup Recordsに分割され、それぞれが異なるソースアドレスのサブセットを含み、それぞれが別のReportメッセージで送信されます。そのTypeがMODE_IS_EXCLUDEまたはCHANGE_TO_EXCLUDE_MODEの場合、収まるだけのソースアドレスを含む単一のGroup Recordが送信され、残りのソースアドレスは報告されません。どのソースを報告するかの選択は任意ですが、毎回異なるソースを報告するのではなく、各後続のレポートで同じソースのセットを報告することが望ましいです。

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

IGMPは非対称プロトコルであり、グループメンバー(マルチキャストパケットを受信したいホストまたはルーター)とマルチキャストルーター(IGMPメッセージをリッスンし、マルチキャスト転送を調整する)に異なる動作を指定します。このセクションでは、グループメンバーに適用されるIGMPv3の部分について説明します。(ルーターもグループメンバーになることができることに注意してください。)

システムは、マルチキャスト受信がサポートされている各インターフェース上で、このセクションで説明されているプロトコルを実行します。各インターフェース上のプロトコルには、2種類のイベントの即時処理が含まれます:

IPMulticastListen定義のローカル呼び出しによって引き起こされる、インターフェース上のマルチキャスト受信状態の変更。
Membership Queryメッセージの受信。

5.1. インターフェース状態の変更に対するアクション

IPMulticastListenの呼び出しは、セクション3.2の規則に従って、インターフェースのマルチキャスト受信状態を変更する可能性があります。このような各変更は、単一のマルチキャストグループアドレスのインターフェースごとの状態に影響します。

インターフェース状態の変更により、システムはそのインターフェースからState Change Reportを即座に送信します。State Change Reportのタイプと内容は次のように決定されます:

状態変更が重要でない場合、たとえばグループのフィルターモードがINCLUDEからINCLUDEへ、またはEXCLUDEからEXCLUDEへ移動し、ソースアドレスのセットが変更されない場合、レポートは生成されません。
状態変更が重要である場合、State Change Reportが生成されます。Reportには、状態が変更されたグループの単一のGroup Recordが含まれます。Group Recordのタイプと内容は、次の表に示すように、Old State(変更前の状態)とNew State(変更後の状態)を比較することによって決定されます:

Old State New State State Change Record Sent
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 (B-A)"という表記は、State Change Recordが、セットBにはあるがセットAにはないすべてのソースアドレスを含むソースリストを保持することを意味します。"BLOCK (A-B)"という表記は、State Change Recordが、セットAにはあるがセットBにはないすべてのソースアドレスを含むソースリストを保持することを意味します。

ALLOWまたはBLOCKレコードの計算されたソースリストが空の場合、そのレコードはState Change Reportから省略されます。

Old State	New State	State Change Record Sent
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)

State Change Reportがネットワーク上のすべてのマルチキャストルーターによって受信されることを保証するために、システムはReportを[Robustness Variable] - 1回再送信します。再送信は、(0, [Unsolicited Report Interval])の範囲から選択されたランダムな間隔で行われます。[Robustness Variable]は調整可能なパラメーターで、デフォルトは2です。[Unsolicited Report Interval]も調整可能なパラメーターで、デフォルトは10秒です。

State Change Reportが送信予定であり、Current State Reportを生成するQueryが受信された場合(セクション5.2を参照)、保留中のState Change Reportは破棄され、代わりにCurrent State Reportが送信されます。Current State Reportには、State Change Reportに含まれていたであろうすべての情報が含まれている必要があります。

5.2. Queryの受信に対するアクション

システムがQueryを受信すると、まずQueryが有効かどうかを確認します。有効であるためには、Queryは次の条件を満たす必要があります:

少なくとも12オクテットの長さである,
正しいIPチェックサムを持つ,
宛先IPアドレスがall-systemsマルチキャストアドレス(224.0.0.1)または照会されている特定のグループアドレスに等しい。

Queryが無効な場合、それは無視されます。Queryが有効な場合、システムは次のアクションを実行します:

必要に応じて、Querierのタイマーを更新します(セクション6を参照)。
Queryに応答する必要があるかどうかを判断します。

次のサブセクションでは、さまざまなタイプのQueriesへの応答規則について説明します。

5.2.1. General Queryの受信に対するアクション

General Queryを受信すると、システムは各インターフェースをチェックして、グループのマルチキャスト受信状態があるかどうかを確認します。状態があるグループごとに、システムはCurrent State Reportの送信をスケジュールします。

ReportにはグループのGroup Recordが含まれます。Group RecordのタイプはMODE_IS_INCLUDE(グループのフィルターモードがINCLUDEの場合)、またはMODE_IS_EXCLUDE(フィルターモードがEXCLUDEの場合)です。Group Record内のソースリストには、グループのソースアドレスのセットが含まれます。

Reportは、QueryのMax Resp Codeフィールドで指定された値である[Max Resp Time]の範囲(0, [Max Resp Time])から選択されたランダムな時刻に送信されるようにスケジュールされます。

5.2.2. Group-Specific Queryの受信に対するアクション

Group-Specific Queryを受信すると、システムは、Queryで指定されたグループアドレスのマルチキャスト受信状態があるかどうかを確認します。ない場合、Queryを無視します。

グループの状態がある場合、システムはCurrent State Reportの送信をスケジュールします。Reportには、セクション5.2.1で説明されているように構築されたグループのGroup Recordが含まれます。

Reportは、範囲(0, [Max Resp Time])から選択されたランダムな時刻に送信されるようにスケジュールされます。

5.2.3. Group-and-Source-Specific Queryの受信に対するアクション

Group-and-Source-Specific Queryを受信すると、システムは、Queryで指定されたグループアドレスのマルチキャスト受信状態があるかどうかを確認します。ない場合、Queryを無視します。

グループの状態がある場合、システムは、Queryで指定されたソースアドレスのいずれかに関心があるかどうかを判断します。システムは、次の場合にソースアドレスに関心があります:

グループのフィルターモードがEXCLUDEである、または
グループのフィルターモードがINCLUDEであり、ソースアドレスがソースリストに含まれている。

システムが少なくとも1つのソースアドレスに関心がある場合、Current State Reportの送信をスケジュールします。Reportには、セクション5.2.1で説明されているように構築されたグループのGroup Recordが含まれます。

Reportは、範囲(0, [Max Resp Time])から選択されたランダムな時刻に送信されるようにスケジュールされます。

5.2.4. "S"フラグが設定されたQueryの受信に対するアクション

受信したQueryで"S"(Suppress Router-Side Processing)フラグが設定されている場合、システムはQuerierのタイマーを更新しません。ただし、セクション5.2.1から5.2.3で説明されているように、Queryに応答します。

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

IGMPの目的は、各マルチキャストルーターが、直接接続されている各ネットワークについて、そのネットワーク上でリスナーを持つマルチキャストアドレスを学習できるようにすることです。IGMPv3により、マルチキャストルーターは、リスナーが関心を持つソースも学習できます。

6.1. Querier選出の条件

IGMPv3はIGMPv2と同様に、ネットワークごとに1つのQuerierのみが存在すべきであることに同意しています。ただし、IGMPv3 QuerierとIGMPv2 Querierは同じネットワーク上で共存できます。選出プロトコルはIGMPv2と同じです:

最初に、すべてのマルチキャストルーターは、接続されている各ネットワーク上でQuerierとして起動します。
マルチキャストルーターが、より低いIPアドレスを持つルーターからのQueryメッセージを受信した場合、そのネットワーク上でNon-Querierになる必要があります。
マルチキャストルーターが[Other Querier Present Interval]の間、より低いIPアドレスを持つルーターからのQueryメッセージを受信しなかった場合、Querierの役割を再開します。

6.2. Queryの受信時のQuerierのアクション

QuerierがQueryメッセージを受信すると、QueryのソースIPアドレスをチェックします。

ソースIPアドレスが自身のIPアドレスよりも低い場合、ルーターはNon-Querierになります。
ソースIPアドレスが自身のIPアドレスよりも高い場合、ルーターはQuerierのままです。
ソースIPアドレスが自身のIPアドレスと等しい場合、Queryは無視されます(反射またはループバック)。

6.3. Queriesの送信

Querierは定期的にGeneral Queriesを送信して、メンバーシップ情報を要求します。また、特定のタイプのState Change Reportsを受信したときに、Group-SpecificまたはGroup-and-Source-Specific Queriesを送信します。

6.3.1. General Queries

Querierは定期的にGeneral Queriesをall-systemsマルチキャストアドレス(224.0.0.1)に送信します。デフォルトの[Query Interval]は125秒です。

General Queriesは、すべてのグループとソースのメンバーシップ情報を更新するために使用されます。

6.3.2. Group-Specific Queries

Querierが、システムがグループを離れたことを示すState Change Reportを受信した場合(例:EXCLUDEからINCLUDEへのフィルターモード変更、またはソースをブロックするソースリスト変更)、グループアドレスにGroup-Specific Queryを送信します。

このQueryは、グループに関心のある残りのシステムがあるかどうかを判断するために使用されます。

6.3.3. Group-and-Source-Specific Queries

Querierが、システムがグループの特定のソースに関心がなくなったことを示すState Change Reportを受信した場合(例:特定のソースをブロック)、Group-and-Source-Specific Queryを送信します。

このQueryは、それらの特定のソースに関心のある残りのシステムがあるかどうかを判断するために使用されます。

6.4. Reportsの受信

マルチキャストルーターは、受信したReportsに基づいて、各グループとソースの受信状態を記録します。状態はインターフェースごとに維持されます。

6.4.1. Current State Recordsの受信

ルーターがCurrent State Recordを受信すると、グループ/ソースタイマーを更新します。

レコードがMODE_IS_INCLUDEの場合、ルーターはリストされたソースのタイマーを更新します。
レコードがMODE_IS_EXCLUDEの場合、ルーターはグループタイマーと除外されたソースのタイマー(存在する場合)を更新します。

6.4.2. Filter-Mode-Change Recordsの受信

ルーターがFilter-Mode-Change Recordを受信すると、フィルターモードとタイマーを更新します。

CHANGE_TO_INCLUDE_MODE: ルーターはINCLUDEモードに切り替え(まだでない場合)、ソースタイマーを更新します。
CHANGE_TO_EXCLUDE_MODE: ルーターはEXCLUDEモードに切り替え、グループタイマーを更新します。

6.4.3. Source-List-Change Recordsの受信

ルーターがSource-List-Change Recordを受信すると、ソースタイマーを更新します。

ALLOW_NEW_SOURCES: ルーターは新しいソースをリストに追加し、それらのタイマーを開始します。
BLOCK_OLD_SOURCES: ルーターは、削除する前に他のシステムがこれらのソースをまだ必要としているかどうかを照会する場合があります。

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

グループのルーターフィルターモードは、グループタイマーとソースタイマーの状態に基づいて、INCLUDEとEXCLUDEの間で遷移します。

グループタイマーが実行中の場合、フィルターモードはEXCLUDEです。
グループタイマーが期限切れになると、フィルターモードはINCLUDEに切り替わります。

6.6. Group Leaveメッセージの受信に対するアクション (IGMPv2)

ルーターがIGMPv2 Leave Groupメッセージを受信した場合、Leaveメッセージで指定されたグループについて、INCLUDEモードへの変更(事実上グループを離れる)を示すState Change Reportを受信したかのように動作します。これにより、IGMPv3ルーターはIGMPv2ホストと相互運用できます。

7. IGMPv1およびIGMPv2との相互運用

IGMPv3ホストとルーターは、まだIGMPv3にアップグレードされていないホストやルーターと相互運用します。この互換性は、Querierによってマルチキャストされる定期的なMembership Queryメッセージと、古いホストによってマルチキャストされるVersion 1およびVersion 2 Membership Reportメッセージによって維持されます。

7.1. IGMPv3ホストの動作

IGMPv3ホストの動作は、ネットワーク上のQuerierがIGMPv3、IGMPv2、またはIGMPv1のいずれを使用しているかによって異なります。

7.1.1. Queryバージョンの区別

Membership QueryメッセージのIGMPバージョンは次のように決定されます:

IGMPv1 Query: 長さ = 8オクテット、Max Resp Code = 0.
IGMPv2 Query: 長さ = 8オクテット、Max Resp Code > 0.
IGMPv3 Query: 長さ >= 12オクテット.

7.1.2. 古いQuerierの存在下での動作

IGMPv3ホストは、QuerierがまだIGMPv3にアップグレードされていないネットワークに配置される可能性があります。ホストはこの可能性を考慮する必要があります。

IGMPv1 Querier Present: IGMPv3ホストがIGMPv1 Queryを受信した場合、IGMPv1 Reportsで応答する必要があります。ソースフィルタリングはサポートされていません。
IGMPv2 Querier Present: IGMPv3ホストがIGMPv2 Queryを受信した場合、IGMPv2 Reportsで応答する必要があります。ソースフィルタリングはサポートされていません。
IGMPv3 Querier Present: IGMPv3ホストがIGMPv3 Queryを受信した場合、IGMPv3 Reportsで応答します。ソースフィルタリングがサポートされています。

ホストは各インターフェースの互換性モード変数を維持し、Queryが受信されるたびに更新されます。古いQueryが受信されると、ホストは対応する互換性モードに切り替え、タイマーを設定します。タイマーが期限切れになると、ホストはIGMPv3モードに戻ります。

7.2. IGMPv3ルーターの動作

IGMPv3ルーターの動作は、ネットワーク上に古いホストやルーターが存在するかどうかによって異なります。

7.2.1. 古いホストの存在

IGMPv3ルーターは、古いホストからIGMPv1またはIGMPv2 Reportsを受信する場合があります。

IGMPv1 Report Received: ルーターは、グループに対してIGMPv3 IS_EX({})レポートを受信したかのように動作します。また、そのグループのすべてのLeave Groupメッセージを無視する必要があります(IGMPv1にはLeaveメッセージがないため)。
IGMPv2 Report Received: ルーターは、グループに対してIGMPv3 IS_EX({})レポートを受信したかのように動作します。

古いホストが存在する場合、ルーターは互換性を確保するために、影響を受けるグループのIGMPv3固有の処理(ソース固有のクエリなど)を抑制する必要がある場合があります。

7.2.2. 古いルーターの存在

IGMPv3ルーターが古いルーターのあるネットワーク上にある場合、Querier選出プロセス(セクション6.1)により、どのルーターがQuerierになるかが決定されます。

IGMPv1ルーターが存在し、Querierになった場合、すべてのルーター(IGMPv3ルーターを含む)はIGMPv1ルーターとして動作する必要があります。
IGMPv2ルーターが存在し、Querierになった場合、すべてのルーターはIGMPv2ルーターとして動作する必要があります。
IGMPv3ルーターがQuerierになった場合、IGMPv3 Queriesを送信します。古いルーターはこれらを無効なIGMPv1/v2クエリとして認識します(または部分的に互換性がある場合は処理します)が、一般的に、IGMPv3パケットを処理できない古いルーターと共存する必要がある場合、IGMPv3ルーターはIGMPv1またはIGMPv2モードで動作するように構成する必要があります。

7.3. Version 1、2、3ホストの混在

同じネットワーク上にIGMPv1、IGMPv2、IGMPv3ホストの混在を持つことが可能です。

QuerierがIGMPv3の場合、IGMPv3 Queriesを送信します。
IGMPv3ホストはIGMPv3 Reportsで応答します。
IGMPv2ホストはIGMPv2 Reportsで応答します。
IGMPv1ホストはIGMPv1 Reportsで応答します。

IGMPv3ルーターはこれらすべてのレポートタイプを処理する必要があります。IGMPv1またはIGMPv2メンバーを持つグループの場合、古いホストはソースフィルターを指定できないため、ルーターはグループを空のソースリストを持つEXCLUDEモード(つまり、"このグループのすべてを送信してください")として効果的に扱う必要があります。

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

これらのタイマーとカウンターのほとんどは設定可能です。デフォルト以外の設定を使用する場合、単一のリンク上のすべてのルーター間で一貫している必要があります。括弧はQueryメッセージ内の対応するフィールドの値を示していることに注意してください。

8.1. Robustness Variable

Robustness Variableは、ネットワーク上で予想されるパケット損失に対して調整できるようにします。ネットワークが損失しやすいと予想される場合、Robustness Variableを増やすことができます。IGMPは[Robustness Variable] - 1のパケット損失に対して堅牢です。

デフォルト: 2

8.2. Query Interval

Query IntervalはQuerierによって送信されるGeneral Queries間の間隔です。

デフォルト: 125秒

8.3. Query Response Interval

定期的なGeneral Queriesに挿入されるMax Resp Time。

デフォルト: 100 (10秒)

8.4. Group Membership Interval

Group Membership Intervalは、マルチキャストルーターがネットワーク上にグループまたは特定のソースのメンバーがもういないと判断する前に経過しなければならない時間です。

値: ([Robustness Variable] * [Query Interval]) + [Query Response Interval]

8.5. Other Querier Present Interval

Other Querier Present Intervalは、マルチキャストルーターがQuerierであるべき他のマルチキャストルーターがもういないと判断する前に経過しなければならない時間の長さです。

値: ([Robustness Variable] * [Query Interval]) + ([Query Response Interval] / 2)

8.6. Startup Query Interval

Startup Query Intervalは、起動時にQuerierによって送信されるGeneral Queries間の間隔です。

デフォルト: [Query Interval]の1/4

8.7. Startup Query Count

Startup Query Countは、起動時に送信されるQueriesの数で、[Startup Query Interval]で区切られます。

デフォルト: [Robustness Variable]

8.8. Last Member Query Interval

Last Member Query Intervalは、Leave Groupメッセージに応答して送信されるGroup-Specific Queriesに挿入されるMax Resp Timeです。

デフォルト: 10 (1秒)

8.9. Last Member Query Count

Last Member Query Countは、ルーターがローカルメンバーがいないと想定する前に送信されるGroup-Specific Queriesの数です。

デフォルト: [Robustness Variable]

8.10. Unsolicited Report Interval

Unsolicited Report Intervalは、ホストのグループへのメンバーシップの初期レポートの繰り返し間の時間です。

デフォルト: 10秒

8.11. Older Version Querier Present Timeout

Older Version Querier Present Timeoutは、古いバージョンのクエリが受信された後、ホストがIGMPv3モードに戻るためのタイムアウトです。

値: ([Robustness Variable] * [Query Interval]) + [Query Response Interval]

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

各タイプの偽造メッセージの影響を考察します。

9.1. Queryメッセージ

現在のQuerierよりも低いIPアドレスを持つマシンからの偽造Queryメッセージは、Querier選出を発生させます。これにより、現在のQuerierがQueriesの送信を停止し、新しいQuerierが起動するのを待つ可能性があります。新しいQuerierは無効であるため、ルーター上のQueryタイマーが最終的に期限切れになり、メンバーシップ情報を削除する可能性があります。

小さなMax Resp Codeを持つ偽造Queriesを送信することにより、DoS攻撃が可能です。これにより、LAN上のすべてのホストが同時にReportsを送信し、ネットワークまたはルーターを圧倒する可能性があります。

9.2. Current State Reportメッセージ

偽造Reportメッセージにより、ルーターは実際には存在しないのにネットワーク上にグループのメンバーがいると信じる可能性があります。これにより、マルチキャストトラフィックが不必要にネットワークに転送され、帯域幅が消費される可能性があります。

9.3. State Change Reportメッセージ

偽造State Change Reportメッセージにより、ルーターはシステムがグループに参加したか離脱したと信じる可能性があります。偽造された"Join"レポート(ALLOWまたはTO_IN)は不要なトラフィックを引き起こします。偽造された"Leave"レポート(BLOCKまたはTO_EX)により、ルーターがGroup-Specific Queryを送信する可能性があり、有効なホストが時間内に応答しない場合、ルーターはグループのトラフィックの転送を停止し、正当なメンバーに対してサービス拒否を引き起こす可能性があります。

9.4. IPsec

IPsec認証ヘッダー(AH) [RFC2402]を使用して、IGMPメッセージを保護できます。AHを使用すると、IGMPメッセージを含むIPパケット全体に認証が適用されます。これにより、IGMPメッセージの偽造を防ぐことができます。ただし、マルチキャストの鍵管理は複雑であり、継続的な研究分野です。

10. IANAに関する考慮事項

10.1. IGMPメッセージタイプ

IANAはIGMPメッセージタイプ0x22を"Version 3 Membership Report"に割り当てました。

10.2. グループレコードタイプ

IANAは"IGMPv3 Report Types"(グループレコードタイプ)の新しいレジストリを作成しました。値0x01から0x06はこのドキュメントで定義されています。値0x00と0x07から0xFFは割り当て可能です。

10.3. Max Resp Code

Membership QueryメッセージのMax Resp Codeフィールドは8ビットフィールドです。値はセクション4.1.1で定義されています。レジストリは不要です。

11. 謝辞

IGMPv3の設計と文書化に貢献してくださった多くの方々に感謝いたします。特に以下の方々の貢献を認めます:

Steve Deering氏、IPマルチキャストを発明し、IGMPの以前のバージョンを設計しました。
Van Jacobson氏、タイマーメカニズムの設計に貢献しました。
Isidor Kouvelas氏、以前の草案の共著者でした。
IDMRワーキンググループのメンバー、レビューとコメントをいただきました。

12. 参考文献

12.1. 規範的参考文献

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1981年9月.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, 1989年8月.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997年3月.

12.2. 参考情報

[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, 1997年11月.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1998年11月.
[RFC2933] McCloghrie, K., Farinacci, D., Thaler, D., and B. Fenner, "Internet Group Management Protocol MIB", RFC 2933, 2000年10月.

付録A. 設計根拠

A.1. "Exclude"フィルターモード

"Exclude"フィルターモードは、既存の"Any-Source Multicast" (ASM)モデルとの互換性を維持しながら、"Source-Specific Multicast" (SSM)をサポートするために導入されました。

ASMでは、ホストはグループGに参加し、Gに送信するすべてのソースからトラフィックを受信します。これはEXCLUDE({}, G)に相当します。 SSMでは、ホストは特定のチャネル(S, G)に参加し、グループGに送信されたソースSからのトラフィックのみを受信します。これはINCLUDE({S}, G)に相当します。

EXCLUDEモードにより、ホストはASMグループから特定のソースをブロックできます。これは不要なトラフィックをフィルタリングするのに役立ちます。

A.2. "Include"フィルターモード

"Include"フィルターモードはSSMの主要なモードです。ホストが受信したいソースのセットを明示的に指定できます。これにより、マルチキャストルーティングプロトコルが簡素化されます。ルーターはソース固有のツリーのみを構築する必要があります。

A.3. State Change Reports

State Change Reportsは、信頼性を確保するために送信されます。レポートを繰り返すことにより、それらが失われる確率が減少します。これは、IGMPが信頼性のないトランスポート(IP)上で実行されるため重要です。

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

以下は、IGMPv2 [RFC2236]からIGMPv3への変更点の概要です:

ソースフィルタリング: ホストが受信したいソース(INCLUDEモード)またはブロックしたいソース(EXCLUDEモード)を指定できる機能。
グループレコードタイプ: IGMPv3 Reportsには、さまざまなタイプ(Current State、Filter Mode Change、Source List Change)のGroup Recordsが含まれ、さまざまな種類の情報を伝達します。
Membership Reportフォーマット: Reportフォーマットは、単一のメッセージ内で複数のGroup Recordsをサポートし、ソースアドレスを保持するように完全に再設計されました。
Queryフォーマット: QueryフォーマットはGroup-and-Source-Specific Queriesをサポートし、Robustness VariableとQuery Interval (QQIC)を保持するように拡張されました。
Max Resp Code: Max Resp Codeフィールドは、浮動小数点表現を使用してより大きな値をサポートするように再定義されました。
Querier選出: Querier選出メカニズムは同じままですが、古いバージョンの処理に関するルールが明確化されました。
S Flag: QueriesのS Flag (Suppress Router-Side Processing)により、ルーターはQueriesを受信したときにタイマー更新を抑制できます。これは特定の診断や特別な構成に役立ちます。

Status of this Memo (このメモの位置づけ)​

Copyright Notice (著作権表示)​

Abstract (概要)​

Contents (目次)​

1. Introduction (はじめに)​

2. The Service Interface for Requesting IP Multicast Reception (IPマルチキャスト受信を要求するためのサービスインターフェース)​

3. Multicast Reception State Maintained by Systems (システムによって維持されるマルチキャスト受信状態)​

3.1. Socket State (ソケット状態)​

3.2. Interface State (インターフェース状態)​

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

4.1. Membership Queryメッセージ​

4.1.1. Max Resp Code​

4.1.2. Checksum​

4.1.3. Group Address​

4.1.4. Resv (Reserved)​

4.1.5. S Flag (Suppress Router-Side Processing)​

4.1.6. QRV (Querier's Robustness Variable)​

4.1.7. QQIC (Querier's Query Interval Code)​

4.1.8. Number of Sources (N)​

4.1.9. Source Address [i]​

4.1.10. Additional Data​

4.1.11. Queryのバリエーション​

4.1.12. QueriesのIP宛先アドレス​

4.2. Version 3 Membership Reportメッセージ​

4.2.1. Reserved​

4.2.2. Checksum​

4.2.3. Number of Group Records (M)​

4.2.4. Group Record​

4.2.5. Record Type​

4.2.6. Aux Data Len​

4.2.7. Number of Sources (N)​

4.2.8. Multicast Address​

4.2.9. Source Address [i]​

4.2.10. Auxiliary Data​

4.2.11. Additional Data​

4.2.12. Group Recordタイプ​

4.2.13. ReportsのIPソースアドレス​

4.2.14. ReportsのIP宛先アドレス​

4.2.15. Group Recordsの表記法​

4.2.16. Membership Reportのサイズ​

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

5.1. インターフェース状態の変更に対するアクション​

5.2. Queryの受信に対するアクション​

5.2.1. General Queryの受信に対するアクション​

5.2.2. Group-Specific Queryの受信に対するアクション​

5.2.3. Group-and-Source-Specific Queryの受信に対するアクション​

5.2.4. "S"フラグが設定されたQueryの受信に対するアクション​

6. マルチキャストルーターのプロトコル​

6.1. Querier選出の条件​

6.2. Queryの受信時のQuerierのアクション​

6.3. Queriesの送信​

6.3.1. General Queries​

6.3.2. Group-Specific Queries​

6.3.3. Group-and-Source-Specific Queries​

6.4. Reportsの受信​

6.4.1. Current State Recordsの受信​

6.4.2. Filter-Mode-Change Recordsの受信​

6.4.3. Source-List-Change Recordsの受信​

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

6.6. Group Leaveメッセージの受信に対するアクション (IGMPv2)​

7. IGMPv1およびIGMPv2との相互運用​

7.1. IGMPv3ホストの動作​

7.1.1. Queryバージョンの区別​

7.1.2. 古いQuerierの存在下での動作​

7.2. IGMPv3ルーターの動作​

7.2.1. 古いホストの存在​

7.2.2. 古いルーターの存在​

7.3. Version 1、2、3ホストの混在​

8. タイマー、カウンター、およびそのデフォルト値のリスト​

8.1. Robustness Variable​

8.2. Query Interval​

8.3. Query Response Interval​

8.4. Group Membership Interval​

8.5. Other Querier Present Interval​

8.6. Startup Query Interval​

8.7. Startup Query Count​

8.8. Last Member Query Interval​

8.9. Last Member Query Count​

8.10. Unsolicited Report Interval​

8.11. Older Version Querier Present Timeout​