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

9. 拡張性 - オプション処理 (Extensibility - Option Processing)

近隣探索プロトコル (Neighbor Discovery Protocol) は、新しいオプションの追加を通じて拡張可能になるように設計されています。このセクションでは、将来の拡張が現在の実装と共存できるように、ノードが受信した近隣探索メッセージ内のオプションをどのように処理するかについて説明します。

9.1. 一般原則 (General Principles)​

後方互換性と前方拡張性を確保するために：

  • 認識されないオプション (Unrecognized Options): すべてのノードは、受信した近隣探索パケット内で認識しないオプションを静かに無視し (MUST)、パケットの処理を継続しなければなりません (MUST)。これにより、既存の実装を壊すことなく、将来新しいオプションを定義できるようになります。

  • 複数のオプション (Multiple Options): オプションは同じメッセージ内に複数回出現する場合があります。ノードは、このケースを適切に処理できるように準備しなければなりません (MUST)。

  • オプションの順序 (Option Order): メッセージ内でオプションが出現する順序は、特定のオプションタイプに対して明示的に指定されていない限り、一般的には重要ではありません。

  • パディング (Padding): オプションは、自然な64ビット境界で終了するように、必要に応じてパディングする必要があります。

9.2. 処理規則 (Processing Rules)​

オプションを含む近隣探索メッセージを処理する際：

  1. すべてのオプションを解析 (Parse All Options): ノードは、一部が認識されていない場合でも、メッセージ内のすべてのオプションを解析しなければなりません (MUST)。

  2. 未知のオプションを無視 (Ignore Unknown Options): オプションが（その Type フィールドに基づいて）認識されない場合、ノードはそれを無視し (MUST)、後続のオプションとメッセージ自体の処理を継続しなければなりません (MUST)。

  3. 既知のオプションを検証 (Validate Known Options): 認識されたオプションについては、ノードはそのオプションタイプに指定されたルールに従ってオプションを検証しなければなりません (MUST)。オプションが検証に失敗した場合（例：不正な長さ、無効なフィールド値）、動作は特定のオプションタイプとメッセージタイプに依存します。

  4. 処理を継続 (Continue Processing): 1つ以上のオプションが無効または認識されない場合でも、特定のメッセージタイプまたはオプションの仕様で別途要求されていない限り、ノードはメッセージと残りの有効なオプションの処理を継続すべきです (SHOULD)。

9.3. オプション形式の要件 (Option Format Requirements)​

近隣探索用に定義されたすべての新しいオプションは、Type と Length フィールドを持つ、セクション 4.6 で指定された一般的なオプション形式に従わなければなりません (MUST)。Length フィールドは 8 オクテット単位で指定されます。

新しいオプションを定義する際、プロトコル設計者は以下を行うべきです (SHOULD)：

  • それを実装していないノードがオプションを安全に無視でき、運用上の問題を引き起こさないことを確認する。
  • メッセージサイズとリンク MTU への影響を考慮する。
  • オプションの明確な検証ルールを指定する。

9.4. 将来の拡張 (Future Extensions)​

近隣探索プロトコルへの将来の後方互換性のある変更には、以下が含まれる可能性があります：

  • 新しいオプションタイプの定義
  • メッセージ形式内の現在予約されているフィールドの使用の指定
  • 既存のメッセージ内の新しいフラグビットの定義（認識されないフラグは無視されることを理解した上で）

後方互換性のない変更には、新しいメッセージタイプ（異なる ICMP Type または Code 値を使用）の定義、またはプロトコルの新しいバージョンの定義が必要になります。

9.5. 実装に関する考慮事項 (Implementation Considerations)​

実装は以下を行うべきです (SHOULD)：

  • 大きなコード変更を必要とせずに新しいオプションタイプを簡単に受け入れられるように設計する。
  • デバッグと将来のプロトコル展開を支援するために、認識されないオプションに関するログまたは診断情報を提供する。
  • オプションを処理する際、特にルーティング決定やキャッシュエントリに影響を与える可能性のあるオプションについて、セキュリティへの影響を考慮する。

9.6. セキュリティと拡張性 (Security and Extensibility)​

拡張性メカニズムは本質的にセキュリティを提供しません。新しいオプションは、慎重に設計されていない場合、新しいセキュリティ脆弱性を導入する可能性があります。新しいオプションを定義するプロトコル設計者は以下を行うべきです (SHOULD)：

  • オプションが Secure Neighbor Discovery (SEND) [RFC3971] とどのように相互作用するかを考慮する。
  • 新しいオプションを悪用する可能性のある攻撃を分析する。
  • 新しいオプションに固有のセキュリティ上の考慮事項を文書化する。

実装は、ローカルセキュリティポリシーに基づいて、特定のオプションタイプのサポートを選択的に有効または無効にするメカニズムを提供すべきです (SHOULD)。

に最終更新