要約

  • RFC 2042は、新しいBGP属性タイプの開発用として値255を予約した。インターネットで実際に使うには、RFCとして文書化し、IANAから一意なtype codeを得て、文書とコードベースの双方を更新する必要があった。
  • 同文書は、コード空間をpublic/privateまたはInternet/OSIに分割する考えを明確に退けた。255の観測は、ベンダー私用割り当て、相互運用、展開、採用、安全性、互換性、認可のいずれも証明しない。

開発用の札に必要なのは、遠くの誰にでも意味が通じることではない。むしろ、まだ公開名ではないと分かることである。RFC 2042における255は、その弱さを意図的に備えていた。

この短い文書は1997年1月にInformational RFCとして刊行された。RFC Editorでは現在Legacy streamに分類され、IETF DatatrackerはIETFの承認を受けず、標準化手続き上の正式な地位を持たないと注記する。したがって、現代の包括的なBGP規範としてではなく、当時の調整境界を記録した史料として読むべきである。

一つの値に複数の実験

当時のBGP-4仕様であるRFC 1771は、パス属性の形式と既存属性を記述していた。RFC 2042が扱った問いは、その次に新しい属性を試すとき、公開コードを早々に占有せずにどう開発するかだった。

答えは単純で、開発中は1オクテットの255を使う。ここで予約されているのは用途であって、所有者ではない。異なる実験が255の後ろに異なる長さ、フラグ、データ構造を置ける。閉じた試験環境なら、参加者が共有する設定とビルド情報が解釈を補う。そうした文脈から切り離されたパケットでは、255だけを見ても実験を特定できない。

この曖昧さには利点があった。消えるかもしれない試作のたびに公開番号を消費せず、形式を変更しやすい。ただし、同じ曖昧さが境界も作る。事前合意のない相手へ届く前に、実験は共用札から一意な公開識別子へ移らなければならない。

公開識別子への手順

RFC 2042は、インターネットで実際に使う新属性をRFCで文書化し、IANAから一意なtype codeを得るよう求めた。割り当て後には、文書とコードベースを認可された値へ更新する。

三つの行為は別々の証拠を生む。RFCは意味を参照可能にする。登録は公開コードの衝突を避ける。コード変更は実装がその番号を送出できるようにする。登録済みだから実装済みとは限らず、実装済みだから配備済みとも限らない。相手が正しく処理したかは、さらに別の観測を要する。

文書だけが新番号へ進み、実行ファイルが255を送り続ければ、仕様とワイヤ上の事実が分かれる。送信側だけが更新されれば、旧式の受信側は正規に割り当てられた属性を拒否し得る。切替を検証するには、登録行、仕様版、定数を変えたコミット、テストベクトル、ビルド、実際の配備記録が必要になる。

privateという読み方を文書自身が否定する

RFC 2042は、属性コード空間をpublicとprivateに分ける意図はなく、Internet、OSI、その他の区画にも分けないと明記する。この一文により、255をベンダー私用番号や企業向け拡張枠と呼ぶ読み方は成立しない。これは一つの共用開発値であり、特定主体の恒久的な領域ではない。

現在のIANA BGP Path Attributesレジストリも、255を「Reserved for development」とし、RFC 2042を参照している。同表にはPrivate Use範囲がない。BGP Parameters配下の別レジストリにはvendor-specificやprivate-useの範囲があり得るが、その方針は表ごとに独立している。「BGPの255」というだけで、別表の規則をPath Attributesへ移すことはできない。

現在のPath Attributes表は登録手続きをStandards Actionとし、RFC 4271を参照する。RFC 8126は後年、そのような登録方針の用語を定義した。これは今日の状態を説明する材料であり、1997年のRFC 2042が同じ言葉で制度を定めたことにはならない。

登録が示すのは、所定の手続きの下で番号と意味の対応が記録されたことまでである。実装の存在、広範な採用、相互運用、運用上の許可、安全性は、レジストリからは導けない。

公式の訂正は参照番号だけ

RFC 2042の公式Errata ID 3681は、BGP Route Reflection文書の参照をRFC 1998からRFC 1966へ直す。分類はEditorial、状態はHeld for Document Updateである。255の用途や割り当て手順を変更する訂正ではない。

本文に見える英単語「documentation」の綴り誤りは、この公式Errataの対象ではない。目につく誤りと、訂正記録が実際に検証した内容を分けることも、史料の境界を守る作業である。

登録と稼働を混同しない

Heng Luのrunning-code論は、この境界を編集上理解する助けになる。ただしIETFの規則として持ち込むべきではない。文書と登録は制度的・象徴的な現実を作る。ビルドは実行可能な現実を作る。配備とピアの挙動は運用上の現実を作る。一段を確認しても、次の段は自動的には成立しない。

255は弱いからこそ役立った。試作に自由を与え、公開空間を短命な案から守った。その代わり、ローカルな実験名、形式版、ピア、期限を保存し、公開利用前に必ず離脱する必要があった。

レジストリは、どの番号がどの属性を公に指すかを示せる。属性が動くことまでは示せない。そして共用の255は、それだけではどの実験を指すかすら示せなかった。

出典