要約

  • RFC 1403 の OSPF external-route tag は、生成方法、経路情報の完全性、経路長の区分を 32 bit に収めた。そこに完全な AS_PATH が入っていたわけではない。
  • 手動タグはローカルな不透明値であり、自動タグも長さを零、一、複数の区分でしか表せない。タグの出自が先に分からなければ、同じ bit 列から意味を読んではならなかった。
  • 経路が切り詰められた場合や、完全な履歴を別の BGP 更新から待つべき場合、OSPF から BGP への再輸出は禁止された。欠損の表示が権限の縮小につながっていた。

境界装置は翻訳者である前に記録の管理者だった

1990 年代初頭、AS の外側では BGP が AS 間の経路を扱い、内側では OSPF が別の尺度と構造で到達性を計算していた。両方を話す ASBR は、BGP の情報を OSPF に取り込み、別の ASBR がその内部経路を見て再び BGP に出すことができる。

ここで問題になるのは互換性だけではない。最初の変換で履歴の一部が消えたなら、二台目の装置が外部向けの経路履歴を作る根拠はどこにあるのか。

RFC 1403 は OSPF の 32 bit external-route tag を小さな証拠文法にした。自動生成を示す一 bit、完全性を示す一 bit、PathLength を区分する二 bit、任意用途の十二 bit、AS 番号の十六 bitである。

PathLength は正確な個数ではなく、零、一、複数、予約済みという分類だった。タグが保存したのは履歴そのものではなく、手元の履歴がどの状態にあるかだった。

Automatic は信頼印ではなく、読み方の境界だった

Automatic bit が 0 なら、残り 31 bit は管理者が定める LocalInfo だった。既存実装との互換性のため、それが既定値でもあった。RFC は、その bit から経路の性質を推論してはならないとした。

Automatic bit が 1 のときだけ、Completeness と PathLength に共有された意味が生じる。同じ整数型の欄でも、生成過程が違えば別の記録である。見た目が同じだからといって、自動生成された証拠へ昇格させることはできない。

ただし Automatic は認証ではない。装置の正当性も、入力の正確さも、改ざん防止も保証しない。RFC 1403 は security issues を論じていない。これは「誰を信じるか」の bit ではなく、「どの文法で読めるか」の bit だった。

失われた履歴と、別経路で届く履歴

短い経路なら、粗い分類と AS 番号から限定された AS_PATH を構成できる場合があった。ローカル由来か、隣接 AS が一つ分かるかによって、定められた ORIGIN と短い path を作る。もちろん明示的な import/export policy が前提である。

複数 AS にまたがる履歴はタグに入らない。ここで RFC は二つの状態を分けた。

一つは、取り込み時点ですでに path が truncated だった場合だ。タグは「不完全で長い」としか言えない。別の ASBR がそれを BGP に再輸出することは禁じられた。欠けた順序を補う標準的な推測は用意されなかった。

もう一つは、完全な BGP path が存在するが、OSPF のタグには載せられない場合である。完全な履歴は AS 内の BGP によって別途運ばれる。OSPF の経路を見つけた ASBR は、その内部 BGP update を待ってから外部広告を行わなければならなかった。

RFC の表は後者を “out of band” と表現した。これは packet data の別チャンネルではない。小さな投影が保持できない情報を、別の routing protocol の記録が運ぶという意味である。

前者は証拠が失われ、後者は権威ある証拠が別の場所にある。理由は異なるが、どちらも OSPF の投影だけから外部履歴を再発明してはならない。

表に載ったことと、外へ語る権利は別だった

RFC 1403 は export の既定値を none とした。OSPF external route を BGP に出すには明示的な設定が必要で、逆方向の import も選択されなければならない。default route の生成も明示的な設定なしには認めなかった。

したがって、learn、import、export は同じ成功状態ではない。OSPF table に destination が存在することは、BGP が要求する provenance の保存も、外部 peer への広告許可も証明しない。

metric の扱いも同じ発想だった。OSPF cost と BGP-3 の INTER-AS METRIC は幅も意味も異なる。訂正版 RFC 1403 は、BGP 側の optional metric を既定では設定しない。数値の写像は意味の同一性を作らない。

ID の一致は二つの記録を結ぶためにあった

BGP Identifier と OSPF router ID は稼働中に一致するよう求められた。複数 ASBR が同じ外部 network を OSPF に入れたとき、別の装置は実際の OSPF next hop を提供する ASBR を特定し、それに対応する BGP path を選ぶ必要があったからだ。

RFC 1745 は 1994 年に BGP-4/IDRP、可変長 mask、path set、MULTI_EXIT_DISC、LOCAL_PREF へモデルを更新した。等 cost の出口が複数なら path を set に統合する処理も加わった。それでも truncated path の再輸出禁止と、完全な長い path を内部 BGP/IDRP から待つ規則は残った。

周辺のデータモデルが進化しても、有損タグが可逆になることはなかった。

Forwarding Address と NEXT_HOP の対応は不要な一 hop を避ける。しかし next hop の構成は、packet が転送された証明ではない。外部広告も、remote reachability や application outcome の証明ではない。

証拠は source route、import、タグの生成方式、completeness、export policy、full path の受領、広告、forwarding、remote response、利用結果へと段階を上がる。下の記録を上の結果に読み替えた瞬間、正しいログが誤った結論になる。

RFC 1403 と RFC 1745 は現在 Historic であり、security analysis も提供していない。現在の vendor 設定を指図する資料ではない。それでも歴史的な設計判断は明確だ。不完全だと名乗る記録には、欠けた情報を必要とする操作を許してはならない。

出典

これらが裏付けるのは文書の status、field semantics、protocol requirement であり、現在の普及、vendor behavior、incident、認証、forwarding success、user outcome ではない。