要約

  • RFC 9898はIETF Informational文書であり、既知のIPv6 Neighbor Discoveryの問題と緩和策を整理するが、新しいプロトコル解決策は導入しない。
  • 根因は、マルチキャスト、リンク上の全ノードへの信頼、ルーターによるNCEのオンデマンド作成の三群に整理される。
  • L3+L2分離は最も広く問題を抑える一方、L2分離、ホストごとの一意なプレフィックス、ルーターの対応またはインターフェースを要する。L3のみは大半を扱い、部分L2は主にマルチキャスト領域と負荷を減らす。

一つのアクセスセグメントを三つの根因で読む

共有IPv6セグメントでは、NDのリンクローカル通信により、マルチキャストの範囲がアドレス解決などの制御トラフィックに影響する。同じリンクにいるノードは同一のオンリンク信頼コンテキストにも置かれる。さらに、通信要求を契機にルーターがNCEを作成することがある。三者は関係するが同じ障害ではない。基本的なNDの動作はRFC 4861、SLAACの動作はRFC 4862が定義し、RFC 9898はそれらに重ねる展開上の考察である。

分離の階層とトレードオフ

L3+L2分離では、各ホストを固有のサブネットとリンクに置く。RFC 9898の整理では、マルチキャスト範囲と信頼関係を縮小し、ルーターによるオンデマンドNCE作成をなくすことで、棚卸しされたND問題のすべてに対処できる。ただし、L2分離、一意なプレフィックス、ルーターの対応または必要なインターフェースが条件になる。ホスト間通信をルーターに集中させる構成では、転送がルーターに集中し得る。また、mDNSのようなホスト間マルチキャストサービスを中断する可能性もある。

L3のみの分離は、共有媒体を許したまま各ホストに異なるサブネットを与える。大半の問題を緩和するが、共有媒体を独立リンクにはしない。リンクローカルDADのマルチキャスト性能と信頼性は媒体に依存し、オンリンクのセキュリティコンテキストは信頼モデルに依存する。RFC 8273はホストごとの一意なプレフィックスを扱い、RFC 9663は大規模ブロードキャストネットワークでのDHCPv6 Prefix Delegationの展開を扱うが、特定の構成や閾値を運用者に命じるものではない。

部分L2分離は、ホストを一つのサブネットに残しつつ、プロキシや最適化機能でマルチキャスト領域を分ける。明示された効果は、特にアドレス解決に関わるマルチキャストトラフィックの削減である。それだけでオンリンク信頼やルーターのオンデマンドNCE作成が消えるわけではない。

RFC 9898は、強い方法から弱い方法へ検討する考え方を示す。強い方法ほど多くの問題を防ぐが導入条件は重く、弱い方法ほど残余問題への補完策が必要になる。これは文脈に応じた運用指針であり、普遍的なMUSTではない。Theo Marchの分析は、利用可能なL2、プレフィックス、ルーターインターフェース、ホストマルチキャストサービスの制約内で受け入れられる最も強い分離を選び、残余の根因を監視することである。RFC 9898は、ベンダー設定、インターフェース数の上限、NCE上限、マルチキャスト率の閾値、移行タイマー、普及率、費用、スループット効果、事故削減率を規定していない。

運用者の判断経路と検証フィクスチャ

  1. マルチキャスト負荷、オンリンクノードへの信頼境界、NCEのオンデマンド増加を別々の証拠として記録する。
  2. 各ホストに一意なプレフィックスを割り当てられるか、L2分離が可能か、ルーターが必要な機能とインターフェースを提供できるか確認する。
  3. ホスト間マルチキャストに依存するサービスがあれば、L3+L2を試験セグメントで検証する。L2が受け入れられない場合はL3のみを評価し、DADとオンリンクセキュリティの残余を登録する。
  4. 部分L2しか実施できない場合、利益をマルチキャスト領域の分離に限定して説明し、信頼とNCEを別に扱う。

検証フィクスチャは、NDマルチキャストをアドレス解決、DAD、その他に分類して捕捉すること、分離前後でリンクローカル近隣の可視性を管理された試験で確認すること、ルーターのNCEが依然としてオンデマンドで生成されるか照合すること、mDNSなどの発見を端から端まで試すこと、各ホストのプレフィックスが一意か確認することである。一度の成功を一般的な性能値へ外挿してはならない。

出典