要約

  • RFC 2370 はアプリケーション固有情報を Type 9、10、11 の Opaque LSA に収め、配布範囲をそれぞれリンク、エリア、AS に限定した。
  • O-bit、再送確認、LSDB 保存は能力と搬送の証拠になっても、本文の理解、鮮度の受理、経路計算、転送状態の導入、通信成功までは証明しない。

リンクステート広告には普通、計算上の役割が最初からある。Router-LSA は接続を語り、Network-LSA は共有網を語る。RFC 2370 が導入したのは、OSPF が意味を所有しない本文を、それでも正しく運べる広告だった。

ここで Opaque は暗号化や秘密を意味しない。標準 LSA ヘッダーの後ろに、32 ビット境界へ整列したアプリケーション固有情報が置かれる。年齢、Options、種類、Link State ID、広告元、シーケンス、チェックサム、長さは OSPF が扱う。本文の意味と利用条件は別の仕様と実装が扱う。

共通層は識別、範囲、フラッディング、確認、老化、保存を提供する。将来の用途は同じ配布網を再利用できるが、OSPF の受領証を借りて、自分の意味や結果まで確定したとは言えない。

9、10、11 は重要度でなく到達境界を示した

Type 9 はリンクローカルで、対応するネットワークを越えない。実装は所属インターフェースを覚え、別のリンクへ出してはならない。Type 10 はエリアローカルで、ABR の向こうへ渡らない。Type 11 は AS 全体を対象にするが、stub area へは入らない。

したがって scope は説明用ラベルではなく、送受信双方が実行する制約である。正しいチェックサムを持つ Type 10 にも、エリア境界を越える権利はない。stub area で受け取った Type 11 は、余分な情報として保存するのではなく、範囲違反として拒否する。

Link State ID の上位八ビットは Opaque Type、残る 24 ビットは種類固有 ID だった。これは拡張の名前空間とインスタンスを区別する。本文が正しいこと、広告元に業務上の権限があること、受信側が行動すべきことまでは示さない。

O-bit は運ぶ意思であって、すべての本文を理解する証明ではない

混在環境では、ルータは Database Description 交換時の O-bit で Opaque 機構への対応を知らせた。対応する隣接にだけデータベース要約と再送リストへ Opaque LSA を載せる。マルチキャストを未対応ルータが偶然受けても、未知の LS type として破棄する。

このビットが答えるのは、共通の封筒を受信・転送できるかという問いである。どの Opaque Type をローカルアプリケーションが解釈するかは列挙しない。意味を知らない中継ルータが忠実に運ぶことも、途中の未対応境界によって消費側のビューが欠けることもあり得る。

だから LSDB 同期とアプリケーション収束は別に観測する必要がある。プロトコル層は、範囲内で有効な LSA を保存して確認する。アプリケーション層は種類を選び、本文を解析し、広告元と鮮度を評価し、他の状態と照合して採否を決める。LSDB の一行は OSPF の受理記録であり、アプリケーションの受領証ではない。

新しいシーケンスでも、主張が新鮮とは限らない

Opaque LSA は OSPF の年齢、シーケンス、チェックサム、MaxAge、MinLSInterval、MinLSArrival、再送、ACK を継承した。それぞれは必要な事実を示す。しかしチェックサムは意味を検証せず、新しいシーケンスは元データの測定時刻を証明せず、ACK は利用を証明しない。

Type 11 では、この差が後に修正対象となった。RFC 5250 は RFC 2370 を置き換え、別エリアの受信側が、広告元停止後も最大約一時間 AS スコープ情報を使い続け得る問題を扱った。広告元を ASBR として到達可能にし、到達性を失ったら、その広告元の Opaque LSA を利用しないよう求めた。

元のフラッディング機構が仕様どおり動いていても、アプリケーションが古い状態を使うことはできた。広く届くことは、真実性を増やさない。主張者が今も到達可能かという別の証拠が要る。

TE は封筒の再利用と意味の不一致を見せた

RFC 3630 は Type 10 Opaque LSA にトラフィックエンジニアリング属性を載せた。TE を理解しないノードも Opaque オブジェクトとして転送でき、消費側は TE データベースを構築できた。新しい用途が OSPF の配布機構を再発明せずに済む点は、この設計の成果である。

同時に、受信と実行の差も明確だった。TE LSA の変更は TE データベースを更新するが、通常の SPF 計算を必要としない。経路のインスタンス化は別の仕事であり、未対応ノードが混じれば TE トポロジーに欠落が生じる。LSA の同期、アプリケーションビュー、計算済みパス、導入済み転送状態、実トラフィックは別々に証明しなければならない。

RFC 7684 は後に拡張プレフィックスとリンク属性へ同じ仕組みを使った。現在の IANA 登録簿も Type 9、10、11 と関連名前空間を保持する。登録は識別子の証拠であって、特定網の採用や効果の証拠ではない。

認証も境界を消さない。OSPF 認証や RFC 5709 の HMAC-SHA は交換を保護するが、アプリケーション固有の主張が真であることや、その広告元が主張権限を持つことまでは保証しない。異なる広告を大量に生成すれば、認証済みでも LSDB と処理資源を圧迫できる。

Heng Lu の Running-Code Primacy と最小初期仕様の視点では、RFC 2370 の強さは共通層を細くした点にある。互換性に必要な形式と範囲を共有し、その後の意味と採用は実装へ残した。文書は可能性を公開する。動くコードと観測結果が現実を作る。

情報源