要約

  • RFC 1048 は BOOTP のベンダー欄を 99.130.83.99 で始め、その後をタグ、長さ、値として読む共通形式を定めた。長さがあるため、受信側は知らない項目を飛ばして次へ進める。
  • cookie が示すのは解釈方式だけである。64オクテットに収まり、Pad と End を正しく扱える応答でも、送信者、値の新しさ、設定権限、後続サービスの安全性は別途確認しなければならない。

RFC 951 の BOOTP クライアントは、まだ通常のホストではない。ハードウェアアドレスと小さな起動プログラムは持っていても、自分の IP アドレス、起動サーバー、取得すべきファイル名を知らない。まず設定とファイル位置を知り、次に別のプロトコルでファイルを転送する、という二段階の構成だった。

パケットには64オクテットの vend 欄があった。ベンダーが起動に必要な情報を追加できる一方、同じ並びを別々の製品が違う意味に解釈する余地もあった。RFC 951 は、使う場合には先頭へ4バイトの magic number を置き、情報の種類を示すことを勧めた。識別子はあっても、その後をたどる一般文法はまだなかった。

1988年2月の RFC 1048 は、欄を広げずに内部を共通化した。異なる実装が全オプションを理解しなくても、知っている部分まで到達できるようにしたのである。この設計は、互換性のための最小限の合意と、信頼判断の責任を意図的に分けている。

公開された印は話者の身分証ではない

magic cookie は十進表記で 99.130.83.99、16進表記で 63.82.53.63 であり、ネットワークバイト順で送られる。RFC 1048 は、これを「後続データを解釈するモード」の識別子としている。

受信プログラムは、その4オクテットを見て RFC 1048 のパーサーを選べる。だが値は公開定数であり、秘密鍵でも署名でもない。BOOTP サーバーの本人性、リレーによる非改変、示されたルーターの管理権限は何も証明しない。

トランザクション ID、ハードウェアアドレス、各種アドレス欄には、要求と応答を対応させ、配送する役割がある。これらは別の観測である。「待っている要求らしい応答」と「許可された主体の応答」を同一視してはならない。

RFC 1542 は後に、BOOTP には妥当な認証機構がなく、無許可のサーバーが偽の IP アドレス、ルーター、DNS 情報を与え得ると記した。攻撃に壊れた文法は必要ない。正しい形式の嘘の方が、むしろクライアントを動かしやすい。

「知らない」を越えるための長さ

通常の項目は、1オクテットのタグ、1オクテットの長さ、その長さ分の値からなる。長さにタグと長さ自身は含まれない。複数オクテットの数値はネットワークバイト順で表す。

長さは、未知の範囲を限定する。タグを知っていれば値を解釈し、知らなければ指定された分だけ進んで次の項目を読む。古いクライアントは新しい項目の意味を推測せず、それでも後方にある既知の設定を失わない。

互換性の核心は、全員に同じ知識を要求しないことにある。送信側は小さな追加のたびにパケット全体の世代を変えなくてよい。受信側は「理解できない」と「境界を失った」を区別できる。

ただし、長さは意味の証明ではない。4オクテットに収まったアドレスが正しいとは限らない。サイト固有コードは別の組織で違う意味を持ち得る。長さ通りに読み進められても、実装のメモリ処理が安全とは限らない。RFC 1084 と RFC 1497 が項目一覧を更新しつつ同じ枠組みを残したことは、形式の有用性を示すが、実装の一様性までは示さない。

Pad と End は読み取りを止める規則である

タグ0の Pad は1オクテットだけで、長さを持たない。位置合わせや未使用部分に用いる。タグ255の End も1オクテットであり、そこで項目列を終える。残りはゼロで埋める。

この二つを長さゼロの通常項目と考えると、パーサーは壊れる。Pad の次を長さと誤認すれば以後がずれ、End の後を読み続ければ埋め草を架空の設定に変えてしまう。拡張可能な形式には、追加法だけでなく停止法が必要である。

順序にも意味がある。サブネットマスクとゲートウェイが同時に入る場合、RFC 1048 はマスクを先に置く。クライアントはローカル範囲を知ってからゲートウェイを扱う必要があるためだ。タグで独立に区切られていても、すべてを自由に並べ替えられるわけではない。

この小さな文法は、cookie、通常項目、二つの制御例外、順序依存、終了という構成を持つ。単に TLV と呼ぶだけでは、実際の相互運用性を支える「読まない規則」が抜け落ちる。

64オクテットは優先順位を要求した

cookie だけで4オクテットを使う。通常項目は値の前に2オクテットを要し、IPv4 アドレスならさらに4オクテット、リストならその倍数が必要になる。RFC 1048 は vend を越えてはならないとし、不可欠でない情報は別の発見サービスで得るよう勧めた。

したがって、拡張は単なる追加作業ではない。起動時の最初の回答へ、マスク、ルーター、時刻、名前、ログなどのどれを入れるか選ばなければならない。標準は表現を割り当てるが、ローカルの重要度までは決めない。

共通コードも限られていた。一般用途は登録して衝突を避け、128から254はサイト固有に残した。ローカル実験の余地は保たれたが、その意味は当事者間の合意に依存する。同じ枠で運べることは、世界共通の意味を持つことではない。

一度この形式がファームウェア、サーバー、運用手順へ埋め込まれると、項目追加は容易でも外枠の交換は難しくなる。小さな拡張を支える仕組みは、同時に歴史的な境界を長く固定する。これが互換性とロックインの両面である。

中央の表を管理してもサービスの本人にはならない

RFC 1048 は、BOOTP の集中管理データと分散的な発見方法を比較している。必要な情報が一つの応答に収まれば効率は高い。クライアントは多くの探索をせず、受け取った表から起動を進められる。一方、そのデータは古かったり欠けていたりし得る。

BOOTP データベースの管理者には、ローカルな起動情報を掲載する権限がある。しかし、そこに書かれたファイルサーバーの身元や、取得するイメージの真正性まで自動的に証明するわけではない。RFC 1048 自身が、強いファイルサーバー認証には BOOTP の表だけでは足りず、サービス側の認証が必要だと区別している。

成功した起動には複数の記録がある。文法に従って読めたこと、要求と応答が対応したこと、あるサーバー経路が値を供給したこと、後続サービスが独自の条件を満たしたことだ。それらを「cookie が正しかった」の一語に畳むと、原因も責任も見えなくなる。

RFC 1542 は、送るオプションがないクライアントにも cookie、End、ゼロ埋めを含めるよう勧める。サーバーへ期待する返信形式を伝えるためである。内容をほとんど持たない形式宣言は、cookie が認証情報ではないことをよく示している。

DHCP が受け継いだのは器である

RFC 1533 は DHCP オプションに BOOTP のベンダー拡張形式を用いた。タグ、長さ、値、Pad と End の例外、cookie、ネットワークバイト順、サイト固有範囲が続く。RFC 2132 は、同じ系譜上でより成熟した DHCP オプション群を文書化した。

これは明示された形式の継承であって、後年の DHCP 運用を1988年へさかのぼらせる根拠ではない。すべての項目が同じ意味を保った証明でもない。RFC 1533 はセキュリティ問題を扱わないと述べている。器が継承されても、送信元の権威は器の属性にはならなかった。

RFC 1048 の成果は、共通部分を達成可能な大きさに留めたことにある。4オクテットで読み方を選び、長さで未知を越え、Pad と End で移動を制御し、狭い欄とコード範囲で拡張を管理した。誰を信じ、いつ行動するかは、別の制御面に残した。

情報源と証拠の限界

RFC 951 は元の BOOTP と64オクテット欄、magic number の提案を示す。RFC 1048 は cookie、項目形式、順序、割当て、容量を定める。RFC 1084 と RFC 1497 は BOOTP 拡張の改訂を記録する。RFC 1533、RFC 1542、RFC 2132 は DHCP 形式への継承と BOOTP の安全性境界を示す。

これらは仕様と文書上の変遷の証拠である。各時代の普及率、特定ネットワークの設定、全実装が未知タグを安全に処理したことまでは証明しない。