3. IPv6 に関する考慮事項 (IPv6 Considerations)

混乱を避けるため、これまでの議論は IPv4 のみに基づいてきた。IPv6 における対応プロトコルはマルチキャストリスナディスカバリ [MLD] である。MLD は IGMP に基づいているため、完全な記述と推奨事項をここで繰り返すことはせず、MLD が IGMP と異なる点のみを指摘する。

第 2 節で IGMP について記述した制御転送規則およびデータ転送規則は、わずかな考慮を加えることで MLD にも適用できる。すなわち、MLD メッセージを傍受し、メンバーシップ一覧とマルチキャストルータ一覧を構築するという基本機能は IGMP と同じである。

IPv6 のデータ転送は、ある点で IPv4 より単純である。スコープ 2(リンクローカル)以上の範囲のアドレスに対しては MLD が必須である。唯一の例外は全ホストリンクローカルアドレス FF02::1 であり、これは MLD メッセージを送信しない。全ホストリンクローカルアドレス宛のパケットは、すべてのポートで転送すべきである (SHOULD)。

FF00::/15(予約済みの FF00::/16 とノードローカルの FF01::/16 を含む)のアドレスを持つグループは MLD メッセージを送信しないため、これらのアドレスはリンク上のパケットに現れないはずである。

スヌーピングに関連する IPv4 と IPv6 の相違点は以下のとおりである:

IPv6 のマルチキャストグループ維持のプロトコルはマルチキャストリスナディスカバリバージョン 2 [MLDv2] と呼ばれる。MLDv2 は、IGMP メッセージタイプの代わりに ICMPv6 メッセージタイプを使用する。
[IPV6-ETHER] および [IPV6-FDDI] は、128 ビットの宛先 IP (DIP) アドレスのうち 32 ビットを使って 48 ビットの宛先 MAC (DMAC) アドレスを形成する方法を記述している。[IPV6-TOKEN] はトークンリングの DMAC アドレスについて下位 3 ビットを使った対応付けを記述し、[IPV6-1394] は 6 ビットのチャネル番号を使用する。
マルチキャストルータディスカバリは、[MRDISC] で定義される MRDISC プロトコルによって行われる。

IPv4 におけるヌル IP 送信元アドレスに関する挙動と同等に、MLD メンバーシップレポートは、指定されていない IP 送信元アドレス (::) であることを理由に MLD スヌーピングスイッチによって拒否されてはならない (MUST NOT)。さらに、非クエリアスイッチが(スパニングツリートポロジ変更に対して、上記 2.1 節で述べたように)一般クエリをスプーフィングする場合、そのスイッチは当該クエリを送信する際に指定されていない IP 送信元アドレス (::) を使用すべきである (SHOULD)。そのような代理クエリを受信した場合、クエリア選出プロセスに含めてはならない (MUST NOT)。

IPv6 ヘッダにはチェックサムフィールドが含まれない。しかしスイッチは、可能な限り、アドレスバージョンとペイロード長の整合性など、他のパケット完全性の問題を検出するよう努めるべきである (SHOULD)。そのようなエラーが検出された場合、そのパケット内の情報を MLD 転送テーブルに組み込んではならず (MUST NOT)、転送コードはそのパケットを廃棄し、前述したような妥当な後続処理を行うべきである (SHOULD)。

MLDv2 は ICMPv6 を使用し、ICMPv6 には MLD 以外の用途も多数あるため、IP ヘッダの next-header フィールドが ICMPv6 であることだけから、そのパケットが MLD スヌーピングに関係するかどうかを判断するのではもはや十分ではない。すべての ICMPv6 パケットを MLD スヌーピングの候補として扱うソフトウェア実装は、受信キューを容易に埋め尽くして CPU を停滞させ、スヌーピング機能の目的を達成できなくするとともに、他のホスト宛の非 MLD パケットを失うことになる。

これに対処する方法は 2 つ考えられる:

スヌーピングスイッチがパケット内容をより深く調べることを要求する。管理者がどの ICMPv6 パケットタイプを CPU リダイレクトの対象とすべきかを指定できる設定オプションを提供する場合、この方法が好ましい。パケットタイプをハードコーディングすると、将来新しいタイプを導入する際の柔軟性が失われる。
ICMPv6 の検出とマルチキャスト DMAC アドレスを組み合わせる。この方法では、ICMPv6 とマルチキャスト DMAC アドレスを使用する新しいプロトコルを MLD と誤判定する危険がある。

第 1 の方法が推奨される。そのような設定オプションを提供できない場合、実装者はこれを追加することを真剣に検討すべきである (SHOULD)。近隣探索 (Neighbor Discovery) メッセージは誤判定される類に属しており、IPv6 ネットワークの運用上の完全性にとって極めて重要であるためである。

[RFC3307] に記述されているように、IPv6 マルチキャストアドレスの初期割り当てはグループ ID の下位 32 ビットのみを対象としている。したがって、IP マルチキャストアドレスからマルチキャスト DMAC アドレスへの対応付けには大きな重複が存在する。IPv6 マルチキャストアドレスの構造は次のとおりである:

   |   8    |  4 |  4 |             112 bits                  |
   +--------+----+----+---------------------------------------+
   |11111111|flgs|scop|             group ID                  |
   +--------+----+----+---------------------------------------+

したがって、イーサネットと FDDI では、2 ** (112 - 32)、すなわち 1.2e24 を超える一意な DIP アドレスが同じ DMAC アドレスに対応する。IPv4 ではこれが 2**5 である。ただし [RFC3307] によれば、IPv6 マルチキャストアドレスの初期割り当てはグループ ID の下位 32 ビットのみを対象としているため、フラグ値とスコープ値が異なるグループ ID に曖昧さの問題は当面限定されるが、割り当てポリシーは将来変更される可能性がある。この潜在的な重複を考慮すると、MAC アドレスではなく IPv6 アドレスに基づく転送が推奨される。