要約

  • オプショナル・トランジティブ属性は、その意味を実装していない機器を新しい拡張が通過するための仕組みである。未知の属性を含むパスを受け入れて再広告するなら、属性を保持してPartialを1にしなければならず、後続ASはその痕跡を消せない。
  • Partialは意味上の管理が不完全だったことを残す印であり、完全性検証ではない。どのホップが知らなかったか、起源が正しいか、値が妥当か、全員が支持したかは証明しない。
  • RFC 7606の処理では、セッションを維持したまま属性を捨てたり、経路を撤回として扱ったりできる。監視は隣接状態だけでなく、受信・送信バイト、エラー動作、RIB、FIB、実パケットを結び付ける必要がある。

午前2時10分、運用者が管理下の2拠点で新しいポリシー属性を試す。送信側は新リリース、中間トランジットは型コードを知らず、受信側は更新直後で型を理解する。

UPDATEの外枠は正しい。フラグ、型、長さ、値、IPv4プレフィックスが並ぶ。中間機器は属性の境界を読めるが、内部の意味を解釈するコードを持たない。OptionalとTransitiveが立っているため、パスを受け入れ、バイト列を保存し、Partialを立てて下流へ広告する。

受信側では権限の所在が変わる。型を知るデコーダーが属性固有の文法を適用し、値の異常を発見する。指定された動作はtreat-as-withdrawで、Adj-RIB-Inから経路は消えるがTCPは継続する。KEEPALIVEも届き、中間機器のプレフィックス数も変わらない。顧客経路だけが失われる。

事例は合成だが、境界は現実のものだ。BGPは、将来の情報が古い話者を通過できるよう設計された。全世界の同時更新を避けるためである。その代わり、ルーターは検証できない意味を仕様どおり運び、後日の更新が長く不透明だった物体を初めて解読し、拒否することがある。

4ビットが約束するものは別々である

Attribute Flagsの上位4ビットは異なる役割を持つ。Optionalは全実装が認識すべきwell-known属性と拡張を分ける。Transitiveは未知のオプショナル属性がBGP境界を越えられるかを示す。Partialはオプショナル・トランジティブ属性の情報が不完全であることを表す。Extended Lengthは長さ欄を1オクテットか2オクテットにするだけである。下位4ビットは予約済みだ。

Well-known属性は認識が必須で、Transitiveは1だがPartialは0でなければならない。オプショナル・ノントランジティブ属性は対応機器間で意味を持てるが、知らない受信者は黙って無視し、先へ渡さない。ここでもPartialは0である。

漸進的な拡張を可能にするのがオプショナル・トランジティブ属性だ。RFC 4271は全実装が全拡張を理解するとは想定しない。未知属性を含むパスは原則として受け入れられ、再広告するなら属性も一緒に運びPartialを1にする。

約束は限定的だ。バイト列の保管であって、意味の理解ではない。ルーターは境界、型、フラグを知るが、値に商用上の権限があるか、真正か、内部構造が正しいか、将来のパーサーに安全かを知らない。

Extended Lengthも内容を保証しない。長さ欄の幅を変えるだけである。外枠が正しくても内部文法が壊れていることはある。旧ノードがそれを保持するのは、まさに異常を見つけるロジックを持たないからだ。

Partialは信頼スコアではない

名称から「破損」「未検証」「低信頼」と読みたくなるが、定義はもっと狭い。未知属性を再広告した話者はPartialを立てる。後続話者が属性を認識しても、すでに1なら0に戻せない。起源以外の話者が新しいオプショナル・トランジティブ属性を付加するときも1にする。

残るのは、起源から現在まで完全な意味上の管理連鎖を仮定できないという事実である。どのASが知らなかったか、誰が理解したか、許された変更が行われたか、送信者に付加権限があったかは分からない。

Partial自体に認証もない。UPDATE内の1ビットであり、セッションと運用経路の信頼境界を引き継ぐ。起源検証、関係ポリシー、トランスポート保護、設定来歴、データプレーン証拠の代わりにはならない。

価値は控えめな点にある。「完全な意味の所有者がいない境界を越えた」とだけ認める。そこから必要なのは調査と局所的ポリシーであり、自動的な信頼でも一律拒否でもない。

アップグレードは認識境界を移動させる

「未知」は型コードの恒久的性質ではなく、実装、リリース、AFI/SAFI、有効機能、時刻に依存する。同じバイト列が火曜日には不透明でも、水曜日には解析対象になる。

未知の間、内部値は検証されない。認識されると、許容フラグ、長さ、下位構造、意味、エラー動作が適用される。何か月も運ばれた値が、最初のデコーダーや既存ノードの更新後にattribute discardまたはtreat-as-withdrawを起こし得る。

これは必ずしも回帰ではない。新リリースが真の不正値を初めて検出した可能性がある。旧トランジットも基礎仕様を正しく実行していたかもしれない。障害は非同期導入、不透明な伝播、新たに有効になった意味境界の交点で生じる。

したがって更新前には未知属性を持つ経路を棚卸しする。型コード、フラグ、長さ、値ハッシュ、隣接、AFI/SAFI、NLRI、Partialを保存する。更新後は、何が既知になり、どの検証が走り、どの動作が選ばれ、どの経路が変わったかを比較する。

この記録がなければ経路消失は単なる「ソフトウェア障害」になる。あれば、パーサー不具合、正当な拒否、過剰な封じ込め、属性契約を破った送信者を区別できる。

セッション維持はサービス維持ではない

初期BGP-4のエラーモデルは、1個の不正属性でセッション全体をリセットし、無関係な正常経路も失わせ得た。オプショナル・トランジティブ属性は特に厄介で、理解しないノードが未検証値を多数の理解する下流へ扇状に広げられた。

RFC 7606は多くの障害を3種類の動作へ狭める。Session resetは最強のまま。Treat-as-withdrawは問題のUPDATE内の経路を撤回としてAdj-RIB-Inから除き、セッションを保つ。Attribute discardは属性だけを除いて処理を続ける。

単純な強弱ではない。属性だけ捨てる方が見えにくい場合がある。到達性は残る一方、選択やインストールを左右するはずの意味が消えるからだ。RFC 7606がdiscardを、原則として選路や導入に影響しない属性へ限る理由である。

Treat-as-withdrawは経路消失として見えるが、セッション中心の監視には隠れる。隣接はEstablished、Hold Timerは正常、KEEPALIVEも届く。どれもNLRIの存在を証明しない。

既知属性のOptionalまたはTransitiveが仕様と矛盾すれば、属性固有規則がない限り通常はtreat-as-withdrawになる。MP_REACH_NLRIまたはMP_UNREACH_NLRIが重複すれば、そのUPDATE内の全経路を撤回扱いにしつつセッションは維持する。多くの他属性では2個目以降を捨てる。複数エラーがあれば最も強い動作が優先される。

ゆえに「RFC 7606対応」という製品表示だけでは足りない。実際の分類、属性固有規則、最終経路集合が必要だ。実装はセッションを正しく救いながら重大なサービス障害を起こし得る。

ローカルネットワークは封じ込め権限を保つ

標準の伝播規則は拡張性を守るが、すべての未知コードをすべての本番境界へ通す義務ではない。運用者は来歴、資源コスト、下流影響を確認するまで局所的に制限できる。

現在のJuniper文書は二つの異なる選択を示す。未知のオプショナル・トランジティブ属性だけを落として経路を残すか、それを持つ経路を撤回するかである。特定コードの例外と、グローバル、グループ、隣接単位の範囲も持つ。隣接表示から、落とした属性と撤回原因を読み戻せる。

これはローカル実装の制御であり、普遍的なBGP規則ではない。属性削除はパケットを守りながら必要な意味を消すかもしれない。未知コードを一律撤回すれば、漸進導入を到達性障害へ変える。広すぎる例外は元の露出を戻す。

問うべきは「未知属性を許すか」ではなく、「どのコードが、どの関係とAFI/SAFIを、どの証拠の後に通り、不確実なら何をするか」だ。顧客、route server、内部reflector、peer、実験環境で答えは異なり得る。

Cisco NX-OS文書は必要な可視性を示す。未知または破棄属性を持つプレフィックスを列挙し、単一経路でflag、type、length、valueを表示する。単なる件数では、良性の試験コードと数十万経路に付いた異常物を分けられない。

伝播は保管であり、同意ではない

知らない属性を保持するルーターは、その意味に同意していない。プロトコル情報の輸送契約を果たしただけだ。両者を混同すると商業上も安全上も誤った責任を作る。

属性がサービスクラスを表すとしても、理解しないトランジットASがサービスを実施し、顧客資格を確認し、責任を受け入れたとは言えない。Partialは輸送を同意へ変えない。下流は独自の契約とポリシーを維持する。

未知だから悪意があるとは限らず、IANA割り当て済みだから安全とも限らない。登録はコードに安定した識別子を与えるだけで、送信者の準拠や受信側の資源、パーサー、ロジックの安全を証明しない。

不透明なバイトにも実務上のデータ主権がある。ログに入れるか、テナントを越えるか、ドメイン外へ出すか、経路動作を起こすか、調査用に保持するかをネットワークが決める。不透明は無主ではない。

証拠はCLI文字列だけでなく受信・送信バイトのハッシュを残すべきだ。表示はフラグを正規化し、値を省略し、属性を隠す場合がある。生UPDATEとpre/post-policy Adj-RIBを合わせて、保持、変更、削除を証明する。

カナリアは「知らない」を観測可能にする

公開経路表で無作為なコードを試してはならない。ラボ、管理された二者間、または実際の拡張の割り当て手順を用い、少数プレフィックス、既知コード、可逆ポリシー、独立パケット試験で行う。

4段階を保存する。起源UPDATEの正確なバイト。未知ホップの受信値、前後のPartial、送信UPDATE。認識ホップのデコーダー版、検証、エラー動作、Adj-RIB-In。最後に選択経路、FIB、パケットである。

正常値、外枠は正しいが意味上不正な値、未知のノントランジティブ対照を試す。正常値は定義された効果を生み、不正値は規定動作、対照は未知ホップで止まるべきだ。存在ではなく分類を検証する。

次に、未知だったホップを更新して同じUPDATEを再生する。結果が変わっても正しい場合がある。この時間差試験こそ本番の核心で、認識能力が検証境界を移動させる。

ロールバックは独立した二つの手段を要する。送信元で属性を修正・削除する手段と、無関係なセッションを落とさず境界で型を封じる手段だ。緊急コード配布が必要なら、まだ試験可能な状態ではない。

稼働コード優先はここでは文字どおりである。標準は仕組みを与えるが、配備された連鎖がバイトと経路の生死を決める。証拠はUPDATE、Partial遷移、実際のローカル動作、RIB、届いたパケットである。