要約

  • RFC 9072 はオプションパラメータ型255と2オクテットの拡張長を使い、BGP OPEN のオプションパラメータ領域を255オクテットより大きくできるようにする。
  • 大きな領域は能力の包括承認ではない。拡張を理解しないピアは拒否するため、旧上限を越える判断には実証済みの相互運用性が必要である。

従来の上限は能力ごとではなく全体で共有される

BGP OPEN は、2台のスピーカーがセッション確立を試みる条件を示す。能力はオプションパラメータで運ばれるが、RFC 4271 が全領域の長さに与えたのは1オクテットだけだ。何個の能力を通知しても、その符号化後の合計は255オクテットに収まらなければならない。

この制約は長く見えないことがある。追加される能力はそれぞれ小さく、個別の導入判断も独立して見える。それでも、単体では正しい機能の集合が、合計長だけを理由に基本形式で表現できなくなる。

RFC 9072 はこの入れ物を変える。型255を拡張形式の合図として予約し、従来形式の長さと型に相当する位置の後に2オクテットの拡張合計長を置く。各パラメータの長さも2オクテットになる。符号化容量は増えるが、個々の能力の意味は変わらない。

空間が増えても、隣接相手への権限は増えない。送信側はより大きな能力セットを提示できるが、どの構文を理解し、どの能力を支持するかは受信側が決める。セッション確立は、少なくとも双方が交渉を解析できたことを示す観測可能な証拠である。

型255は容量を開くと同時に境界を露呈させる

拡張形式には厳密な条件がある。従来の1オクテット長は255であることが推奨され、ゼロであってはならない。通常ならパラメータ型が入る次のオクテットも255でなければならない。対応するピアはこれを見て、2オクテットの拡張長と後続列を読む。

全体が255オクテット以内なら基本形式を使うことが推奨される。試験のために設定で拡張形式を強制でき、準拠実装は短い内容でも拡張形式を受理しなければならない。255を超える場合は拡張形式が必須となる。

ここが本当の管理点である。上限未満なら、基本形式への退路を残したまま新しいパーサーを試験できる。上限を超えると、同じ能力セットを旧形式で表現できない。ピアが拡張を受け入れるか、送信側が能力を削るか、セッションが成立しないかのいずれかになる。

後方互換性は明示的に失敗する。RFC 9072 未対応のピアは型255を未知のオプションパラメータとみなし、Unsupported Optional Parameters で接続を閉じることが想定される。型255を拡張指示以外に使った場合も未知として扱う。互換性の欠如は黙って誤解されず、失敗として現れる。

能力の増加は共同の互換性予算になる

恩恵を受けるのは、正当な能力セットが従来領域に収まらないネットワークである。長さ欄が短いという理由だけで必要な機能を削らずに済む。一方、コストは調整へ移る。

拡張形式へ移るまで、各能力は共有 OPEN 予算の一部を消費する。新機能を有効にするチームと、最後の数オクテットで境界を越える対外ピア関係を担当するチームは同じとは限らない。共通の台帳がなければ、日常的な変更が拡張を必須にする最後の増分となり、相手側の古い実装を露呈させる。

255に達する前に拡張形式を強制試験する価値はここにある。容量圧力とパーサー準備を切り離せる。OPEN の正確な長さ、選択形式、相手ソフトウェア、失敗時のエラー、再試行で能力セットが変わったかを証拠として残すべきだ。

拡張は相手を認証せず、OPEN を保護せず、経路ポリシーを検証せず、後続 UPDATE の安全も保証しない。RFC 9072 は BGP 本体のセキュリティーと機密性の問題を変えない。大きな入れ物をシステム全体の準備完了証明とみなすことは、標準にない権限を与える。

証拠と限界

RFC 9072 は型255、2オクテット長、形式選択、旧ピアの想定挙動を規定する。RFC 4271 は OPEN とエラーモデル、RFC 5492 は能力枠組み、IANA は割り当て、RFC 4272 はセキュリティー背景を示す。合計長を統治予算と捉える部分は分析である。

資料は特定事業者やベンダーの導入を証明せず、未対応ピアの割合や上限に達する能力数も示さない。拡張 OPEN の成功は交渉を解析できた証拠だが、ポリシー、経路選択、後続 UPDATE の正しさを証明しない。

情報源