メインコンテンツまでスキップ

3. Review of ND Mitigation Solutions (ND緩和ソリューションのレビュー)

表1は、セクション2.4で説明した問題1～15に利用可能なND緩和ソリューションをまとめたものです。類似のソリューションはグループ化され、最も多くの問題に対処するものから始まります。関連性のないソリューションは、それらが対処する問題（セクション2.4にリスト）に基づいて順序付けられています。表内の各ソリューションは、後のサブセクションで説明され、表内の略語が説明されます。

表1では、文字コードが緩和ソリューションのRFCカテゴリを示しています（これらのカテゴリの説明については、BCP 9 [RFC2026]を参照）：

  • S: Standards Track（提案標準またはインターネット標準）
  • E: Experimental（実験的）
  • I: Informational（情報提供）
  • B: Best Current Practice（最良の現行慣行）
  • N/A: Not Applicable（非RFC）

表1の略語はセクション2.4に対応しています：

  • On-link sec.: すべてのノードを信頼することに関連する問題
  • NCE exh.: NCE枯渇
  • Fwd. delay: ルーター転送遅延
  • No addr. acc.: アドレス説明責任の欠如

表1：特定された問題に対するソリューション

NDソリューションRFCカテゴリマルチキャストパフォーマンス信頼性リンク上セキュリティNCE枯渇転送遅延アドレス説明責任なし
123456
MBBv6Iすべての特定された問題を解決
FBBv6N/Aすべての特定された問題を解決
UPPHIXXX
WiNDS低電力有損ネットワーク（LLN）のすべての問題を解決
SARPEX
ND TRILLSX
ND EVPNSX
RFC 7772BX
GRANDSX
SAVI/RA-GI
RFC 6583I
RFC 9686S

3.1. Mobile Broadband IPv6 (MBBv6) (モバイルブロードバンドIPv6)​

"IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)" [RFC6459]、"IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts" [RFC7066]、および"Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link" [RFC7278]で定義されているIPv6ソリューションは、本文書ではモバイルブロードバンドIPv6（MBBv6）と呼ばれます。これらは情報提供RFCです。重要なポイントは：

  • すべてのホスト（例：モバイルユーザー機器（UE））をルーター（例：モバイルゲートウェイ）とのポイントツーポイント（P2P）リンクに配置すると、以下の結果が得られます：

    • すべてのマルチキャストが効果的にユニキャストに変換されます。
    • P2PリンクにはMACアドレスがありません。したがって、オンデマンドルーターNCEは不要です。
    • すべてのノードを信頼することは、ルーターにのみ関連します。ルーターでフィルタリングを適用する（例：ホストからのRAをドロップする）ことで、悪意のあるホストでも害を及ぼすことはできません。

  • 各ホストに一意の/64プレフィックスを割り当てます。P2Pリンクと合わせて、これにより各ホストが別々のリンクとサブネット上に配置されます。

  • 転送目的でルーターに（プレフィックス、インターフェース）バインディングを維持します。

ND問題の3つの原因すべてが対処されているため、セクション2.4で説明したすべての問題が対処されます。

3.2. Fixed Broadband IPv6 (FBBv6) (固定ブロードバンドIPv6)​

"IPv6 in the context of TR-101" [TR177]で定義されているIPv6ソリューションは、本文書では固定ブロードバンドIPv6（FBBv6）と呼ばれます。FBBv6には2つのフレーバーがあります：

  • P2P: すべてのホスト（例：住宅用ゲートウェイ（RG））がルーター（例：ブロードバンドネットワークゲートウェイ（BNG））とのP2Pリンクにあります。この場合、ソリューションは機能的にMBBv6に似ています。セクション2.4で説明したすべてのND問題が解決されます。

  • ポイントツーマルチポイント（P2MP）: アクセスデバイス（例：光回線終端装置（OLT））に接続されたすべてのホスト（例：RG）が、ルーター（例：BNG）とのP2MPリンクにあります。これは、すべてのホストをルーター上の単一のVLANに配置し、OLTを設定してアクセスポート間でフレームが転送されないようにブロックすることで実現されます。各ホストからのトラフィックはルーターに向かってのみ移動でき、別のホストへの横方向の移動はできないため、直接のホスト間通信が防止されます。

以下のリストは、[TR177]で説明されているFBBv6-P2MPアーキテクチャの2つの重要な側面と関連する利点をまとめたものです：

  • DADプロキシの実装 [RFC6957]:

    上記のP2MPアーキテクチャでは、ホストが互いにNSを交換できないため、通常のND DAD手順が機能しなくなります。これに対処するため、ルーターがDADプロキシとしてDADプロセスに参加し、アドレスの重複を解決します。

    利点は：

    • すべてのホストからルーターへのマルチキャストトラフィックが効果的にユニキャストに変換されます。これは、ホストがルーターとのみ直接通信できるためです。
    • すべてのノードを信頼するモデルは、ルーターに限定されます。単純なフィルタリング（例：ホストからのRAをドロップ）を適用することで、ルーターは悪意のあるホストからでもセキュリティリスクを軽減できます。

  • 各ホストに一意の/64プレフィックスを割り当てる:

    各ホストに一意の/64プレフィックスを割り当てると、いくつかの運用上の改善がもたらされます：

    • ルーターは、そのプレフィックスに向けてホストへの転送エントリを事前にインストールでき、オンデマンドルーターNCEの必要性がなくなります。
    • 各ホストは異なるサブネットにあるため、ホスト間のトラフィックはルーターを経由してルーティングされ、ホストが互いにアドレス解決を実行する必要がなくなります。
    • アドレス解決がないため、ルーターからホストへのマルチキャストは非送信請求RAに限定されます。各ホストは独自のサブネットにあるため、これらのRAは個々のホストにユニキャストパケットとして送信されます。これは[RFC6085]で指定されているアプローチに従っており、ホストのMACアドレスがRA内のマルチキャストMACアドレスを置き換えます。

ND問題の3つの原因すべてが対処されているため、すべてのND問題（セクション2.4）も対処されます。

3.3. Unique Prefix per Host (UPPH) (ホストごとの一意のプレフィックス)​

ホストごとの一意のプレフィックス（UPPH）ソリューションは、[RFC8273]と[RFC9663]で説明されています。両方とも情報提供RFCです。[RFC8273]は一意のプレフィックス割り当てにSLAACを使用し、[RFC9663]はDHCPv6プレフィックス委任（DHCPv6-PD）を使用します。割り当てメカニズムのこの違いは、ND問題に関する議論を変更しません。なぜなら、DHCPv6-PDを介してプレフィックスを受信する場合でも、すべてのIPv6ノードはSLAACを実行する必要があるためです。したがって、[RFC8273]のみを議論すれば十分です。

[RFC8273]は、Wi-Fiやイーサネットなどの「共有ネットワークセグメント上のホスト分離と強化されたサブスクライバー管理を改善」します。重要なポイントは：

  • プレフィックスがホストに割り当てられると、ルーターはそのプレフィックスに向けてホストへの転送エントリを事前にインストールできます。オンデマンドルーターNCEはもう存在しません。

  • アドレス解決がない場合、ルーターからホストへのマルチキャストは非送信請求RAのみで構成されます。すべてのホストのプレフィックスが異なるため、これらは1つずつユニキャストでホストに送信されます。

  • 異なるホストは異なるサブネットにあるため、ホストはルーター経由で他のホストにトラフィックを送信します。ホスト間のアドレス解決はありません。

したがって、オンデマンドルーターNCEとルーターからホストへのマルチキャストによって引き起こされるND問題は防止されます。

[RFC8273]は、「ホストごとに一意のIPv6プレフィックスを実装するネットワークは、デバイスがファーストホップルーターを経由する以外に互いにパケットを送信できないことを単純に保証できる」と示しています。ただし、ホストがイーサネットなどの共有メディア上にある場合、「デバイスがファーストホップルーターを経由する以外に互いにパケットを送信できない」ことを保証するには、プライベートVLAN [RFC5517]などの追加措置が必要です。このような追加措置がない場合、共有メディア上では、ホストは同じ要請ノードマルチキャストグループに属しているため、L2で互いに到達できます。したがって、すべてのノードを信頼することとホストからルーターへのマルチキャストが問題を引き起こす可能性があります。ホストマルチキャストの問題（つまり、問題1、3、5、6、7）のうち、UPPHは問題5と7を防ぎます。これは、ホスト間のアドレス解決が不要であり（問題5）、GUAの重複の可能性がないためです（問題7）。ただし、問題1、3、6は発生する可能性があります。

3.4. Wireless ND (WiND) (ワイヤレスND)​

本文書では、「ワイヤレスND（WiND）」という用語を使用して、[RFC6775]、[RFC8505]、[RFC8928]、および[RFC8929]（Standards Track）で低電力有損ネットワーク（LLN）[RFC7102]用に定義されている根本的に異なるNDソリューションを説明します。WiNDは、ルーター発見にのみマルチキャストを使用するようにホストとルーターの動作を変更します。重要なポイントは：

  • ホストはユニキャストを使用して、ルーターでアドレスを事前に登録します。ルーターはユニキャストを使用してホストと通信し、アドレス所有権の抽象的なレジストラおよび仲裁者になります。

  • ルーターはホストのNCEも事前にインストールします。これにより、ホストのアドレス解決の必要性が回避されます。

  • ルーターはPrefix Information Option（PIO）Lビットを0に設定します。各ホストはルーターとのみ通信します（[RFC4861]のセクション6.3.4）。

  • LLNにのみ関連するその他の機能。

WiNDは、LLNのすべてのND問題（セクション2.4）に対処します。ただし、WiNDサポートは汎用ホストには必須ではありません。したがって、参加ノードに追加の制約を課すことなく、展開オプションとして依存することはできません。

注：この文書では他のソリューション（3.5～3.15）も説明されていますが、紙面の都合上省略します。完全な内容については、RFC 9898公式文書を参照してください。

に最終更新