要約

  • RFC 5492 は BGP OPEN に対応能力の一覧を載せる。ある拡張をセッションで使えるのは双方が広告した場合だけで、受信側が知らない能力は無視しなければならない。一方、予定したピアリングに必須の能力を相手が広告しなければ、能力名を添えて終了できる。
  • Scudder の公開された著作記録は、RFC 8810 による Capability Code の私用領域の整理と、Enke Chen と共著した RFC 9072 による OPEN の 255 オクテット上限の拡張へ続く。相互表明、番号の一意性、古い実装が理解できない地点での明白な停止が、同時更新なしの発展を支える。

接続成立の直後に残る不一致

BGP は経路を交換する前に OPEN を交わす。そこにはバージョン、AS 番号、ホールド時間などとともに、任意機能に関する情報を置ける。運用画面では短い初期処理に見えるが、ここで答える問いは大きい。独立した二つの実装が、同時に更新されなくても新機能を安全に導入できるか。

RFC 5492 が説明する基礎仕様では、未知の Optional Parameter を含む OPEN を受け取るとピアリングを終了する。この反応は解釈不能な入力を曖昧に扱わない。しかし、新機能を新しいパラメーターで表すたび、旧実装との基礎的な経路交換まで失う可能性があった。

Capability Advertisement は、未知の「容器」と未知の「中身」を分ける。Capability を理解する実装は、共通の Capabilities Optional Parameter の中に対応機能を列挙する。相手は容器を読めれば、知らない capability だけを作用させずに残りのセッションを続けられる。

RFC 5492 の著者は John Scudder と Ravi Chandra である。Scudder は 2020 年の RFC 8810 で Capability Code の登録手続きを改め、2021 年の RFC 9072 では Enke Chen とともに OPEN Optional Parameters の長さを拡張した。IETF Datatracker の人物ページ は三文書を本人の公開記録へ結び、本人写真も掲載する。

ここから一人の発明物語を作ることはできない。RFC は共同著者、作業部会、レビュー、IANA、実装者、運用者による共有成果である。署名は文書化された関与を示すが、BGP 全体、各製品の実装、導入判断、実ネットワークの成否まで一人に帰属させない。

Code、Length、Value が分ける責任

Capability は三つの要素からなる。1 オクテットの Capability Code が種類を一意に示し、1 オクテットの Capability Length が後続値の長さを示し、可変長の Capability Value はその code を定義する仕様に従って解釈される。

共通仕様が引き受けるのは最小限である。番号と境界を揃え、どの文書が value の意味を決めるかを特定する。能力ごとの挙動を一つの中央仕様へ詰め込まない。新しい capability が同じ code で複数の異なる value を許すなら、その能力を導入する文書が処理方法を定める。

この分離は、正しい構文と正しい動作を混同させない。登録済みの code は共通の名前であって、相手の身元証明ではない。length が正しくても value の実装が正しいとは限らない。正常に解析できても、運用者がその隣接で利用を許可した証拠にはならない。

通常は一つの Capabilities Optional Parameter に複数 TLV を入れる。しかし過去との互換性のため、受信側は複数の Capabilities Optional Parameter も受け入れ、合成した集合を同じように扱う必要がある。同一の重複は意味を増やさないが、受信実装は耐えなければならない。相互運用契約は一社の送信形式ではなく、許容される表現が生む同じ意味に置かれている。

一方の宣言だけでは有効にならない

ある capability をセッションで使えるのは、双方がそれを広告した場合だけである。片方でも広告していなければ利用できない。これが RFC 5492 の中核である。

製品仕様書に「対応」と書かれているだけでは不足する。同じソフトウェアでも設定、アドレスファミリー、隣接の役割、機能フラグによって OPEN に出す内容は変わる。今回この相手に何を宣言したかという実行時の記録が、セッション境界の根拠になる。

また、一方が capability を送りつけて沈黙を同意とみなすこともできない。IANA が code を割り当てても機能は有効にならず、RFC が挙動を定義しても運用者の設定を代行しない。二つのノードが別々に広告して初めて、任意拡張を使う前提が成立する。

ただし相互広告は、必ずしも左右対称の動作を意味しない。方向や role、value の意味は capability ごとの仕様が決める。監視システムが一つの「対応済み」フラグに縮約すると、誰が何をどの値で宣言したかが消える。local と remote の OPEN を別々に保持すべき理由である。

知らない能力は拒否理由ではない

受け取った capability を自分が知らない、または対応していない場合、RFC 5492 はその capability を無視するよう求める。それだけを理由に Unsupported Capability を返したり、セッションを切ったりしてはならない。

この規則は段階導入の核心である。旧実装は理解したふりをしない。新実装も、任意情報を一つ広告しただけで旧隣接全体を停止させる力を得ない。未知の機能は不活性のまま、共有できる基礎部分だけが続く。

反対に、ローカル側が特定の capability をピアリング目的に不可欠と定めた場合がある。相手がそれを広告しなければ、ローカルは Unsupported Capability NOTIFICATION を送って終了できる。通知の Data には、判断の原因となった capability を列挙する。

必須かどうかはローカル判断である。たとえば特定アドレスファミリーの交換を目的とした接続なら、対応 capability の不在を許容しない選択があり得る。RFC はこの理由で終了したピアリングを自動再確立しないよう勧める。同じ証拠で同じ失敗を繰り返すだけの再接続は復旧ではない。

「未知の受信能力」と「必要能力の欠落」は似たログ名でも正反対である。前者は新しさを封じないために無視し、後者は目的を満たせない関係を明示的に止める。両者を一般的な capability mismatch にまとめると、不要なアップグレードや再接続ループを招く。

古い相手への再接続は、機能の回復ではない

さらに古い実装は Capabilities Optional Parameter 自体を理解せず、Unsupported Optional Parameter で OPEN を拒否することがある。この場合、RFC 5492 は capability 容器を付けずに接続を再試行するよう勧める。

これは基礎 BGP への橋であり、当初の目的を達成した証明ではない。通常の IPv4 経路交換だけなら有効な場合がある。特定の拡張やアドレスファミリーが業務要件なら、Established になっても必要なサービスは存在しない。

したがって運用記録は、最初の拒否、二度目に省いた情報、失われた機能、最終的な経路集合を一つの遷移として残す必要がある。TCP や BGP state だけを緑にする監視は、互換フォールバックを完全復旧に見せてしまう。

後方互換性は共有できる最小部分を残す仕組みであって、古い実装を永続的な基準にする制度ではない。必要条件を満たさないなら、明示的な停止も正しい互換性判断である。

私用 code は製品同士が会った瞬間に衝突する

RFC 5492 は当初、Capability Code 128–255 を Private Use とした。RFC 8810 は、その後の経験からこの区分が無用で実装者を混乱させたと記す。

閉じた環境では、二社が同じ番号へ別の意味を割り当てても気付かない。ところが両製品が接続すると、同じ code が capability A と capability B を同時に名乗る。互換性を示すはずの記録が、誤った相互理解を生む。

RFC 8810 は 1–63 を IETF Review のまま維持し、64–238 を First Come First Served、239–254 を Experimental Use、255 を Reserved とした。実験範囲は初期開発のためで、長期利用や出荷製品には使わない。番号の一意性と参照先だけを薄く共有し、採用や設定の権限は奪わない設計である。

変更前には既知の私用値を調査し、prestandard の利用を登録表へ反映した。それでも全利用を発見した保証はないと RFC 自身が認める。登録簿を直した日から衝突が消えるわけではない。残る不一致を観測し、個別に解消する責任が残る。

能力を入れる封筒にも上限が来た

BGP OPEN の Optional Parameters Length は元来 1 オクテットで、可選領域全体が 255 オクテットに制限された。能力を増やす仕組みそのものが、増えた能力を名乗る空間の限界に近づいた。

RFC 9072 は、小さい OPEN をすべて新形式にしない。合計が 255 以下なら通常は従来形式を使う。超える場合は Optional Parameter type 255 を特別な印として置き、続く Extended Optional Parameters Length を 2 オクテットにし、個別 Parameter Length も 2 オクテットへ広げる。対応実装は、小さい内容で extended form を受けても受理しなければならない。

新旧間の境界は条件付きである。新実装の可選領域が旧形式に収まる間は、その点で問題はない。実際に 255 を超えて新形式が必要になると、旧実装は type 255 を未知の Optional Parameter と解釈し、Unsupported Optional Parameters で接続を閉じると想定される。

停止は不格好でも誠実である。理解できない長さを黙って切り捨てれば、両者は別の capability 集合を見たままセッションが成立し得る。後方互換性は過去の実装に存在しない解析能力を与えない。

RFC 9072 は BGP 固有のセキュリティや機密性の問題を変えないとも明記する。封筒が大きくなっても、宣言の真正性や実装品質が増すわけではない。

共通部分は薄く、証明は稼働中の系へ戻す

Lu Heng の Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption は、Sofia Ren がこの記録を読むための後年の視点を与える。世界で共有するのは、解釈可能な容器、一意な番号、双方広告の条件、限定された失敗、将来へ広げられる長さで足りる。各 capability の意味と、どの隣接で必須にするかは、実装者と運用者に残る。

これは 2026 年の編集上の適用で、Scudder、Chandra、Chen、IETF の私的意図を示す証拠ではない。規範的事実は三つの RFC 本文に置く。

Running-Code Primacy は検証先を示す。OPEN はカタログより強い。稼働中の二台が互いに何を宣言したかを残すからである。しかし宣言は結果ではない。交渉後の状態、実際に受理したメッセージ、経路、エラー、再接続、データプレーンを照合して初めて、能力が仕事をしたと言える。

Capability Advertisement は中央の命令で BGP を進化させない。二つの独立した実装が、知っていること、知らないこと、欠ければ進めないことを共通形式で記録する。新しさを許容しながら、互換性の終点も隠さない。この小さな節度が、拡張を強制から切り離している。

情報源