要約

  • BOOTPを使えば、ディスクレス端末は通常のIP通信を始める前に、自分のIPアドレス、サーバー、ブートファイル名を問い合わせられた。ファイルそのものは通常、TFTPなど別の転送で受け取る。
  • 返信にも難題があった。アドレスを知らない端末はARPに応答できない。RFC 951はサーバー側で一時的なARPキャッシュ項目を作る方法と、返信をブロードキャストする方法を示し、後の中継仕様はサブネットを越える経路を明確にした。

電源を入れたディスクレス端末には、ネットワークを設定するOSがまだない。PROMにある起動プログラムなら要求を送れるが、まず使うべきアドレスと読み込むファイルを知る必要がある。それを受け取って初めて、ファイルを取りに行ける。順序は循環しているように見える。ネットワーク上の識別情報がない端末は、どうやってネットワークから最初の返事を受け取るのか。

Bill CroftとJohn Gilmoreは、1985年9月のRFC 951でこの問題を記した。BOOTPはファイル転送の仕組みではない。最初の段階である「アドレスの決定とブートファイルの選択」を担う。クライアントのPROMはアドレス、サーバー、ファイル名を問い合わせ、応答後に通常はTFTPを使う第二段階でファイルをメモリーに読み込む。人が操作しなくても電源投入時に起動できる設計を想定していた。ただしRFCが示すのは設計内容であり、実際の利用台数ではない。(RFC 951、§§2、7.5。)

まだ知らないIPアドレスを、要求の送信前に用意する必要はなかった。サーバーが分からない場合、クライアントは送信元アドレスをゼロにしたIP/UDPパケットを 255.255.255.255 に送り、接続中のケーブル全体にブロードキャストできる。要求にはハードウェアの種類とアドレス、トランザクションIDも含まれた。サーバーは自分のデータベースでハードウェアアドレスに対応するIPアドレスを調べ、応答の yiaddr に入れ、ブートファイルの完全なパスを選べた。unix のような汎用名を求められても、その端末用のファイルに解決できる。つまり、サーバー上のローカルな記録も起動経路の一部だった。(RFC 951、§§2–3、7.1、7.3、9。)

最初の返信には、もう一つの「鶏と卵」があった。サーバーがIP宛てに送るには、通常ARPでリンク層の宛先を調べる。しかし、まだ自分のIPアドレスを知らない端末は、サーバーからのARP要求に返事をできない。RFC 951は二つの回避策を挙げた。送信側に必要なカーネルまたはドライバー機能があれば、chaddr と yiaddr から一時的なARPキャッシュ項目を作り、時間切れを設定する。RFCはUNIX 4.2 BSDにこの機能があったと記している。そうした機能がなければ、サーバーは端末の接続されたインターフェースに応答をブロードキャストできる。どちらを使えるかは、送信側のローカルな実装に左右された。(RFC 951、§4。)

UDPの二つのポートも返信経路に関係していた。要求はBOOTPサーバーの67番ポートへ、応答はクライアントの68番ポートへ送る。RFC 951によれば、番号を分ければ、クライアント用ポートを待ち受けていない他のホストではブロードキャスト応答をカーネルが除外できる。関係のないBOOTPサーバーのデーモンを起こして処理させる必要がない。クライアントが無作為なポートを使えば、そのブロードキャストを別ホストの待ち受けプロセスが受け取る恐れもあった。これは単なる番号の整理ではない。一台への起動応答がセグメント全体のアプリケーションイベントになるのを防いだ。(RFC 951、§3。)

ブートサーバーが必ず同じケーブル上にあるとは限らない。RFC 951はゲートウェイ越しの起動を任意機能とし、ゲートウェイとサーバーの協力を求めた。ゲートウェイなどのエージェントはブロードキャストを受け、クライアント側ネットワークを示す giaddr を設定して、サーバーに要求を渡せる。RFCの著者は要求をどこまでも再ブロードキャストするとループが起きると警告した。1993年10月のRFC 1542は境界を明確にした。BOOTPリレーエージェントは、IPデータグラムを透過的に転送するだけのルーターではない。BOOTPメッセージを最終宛先として受け取り、新しいBOOTPメッセージを生成する役割だった。機能はルーターにも、クライアントのサブネットにつながる別のホストにも置ける。通常のルーティングとは別に設定し、専用の処理規則に従うサービスだった。(RFC 951、§8；RFC 1542、§§4–4.1。)

したがって、BOOTPを単に「古いDHCP」と呼ぶと違いが見えなくなる。後のRFC 2131はDHCPをBOOTP方式の拡張と説明し、既存のクライアントとの相互運用のため、メッセージ形式とリレーの動作を引き継いだ。一方で重要な追加機能は、期限付きのアドレスを割り当て、不要になったアドレスを再利用できることだった。1985年のBOOTPモデルでは、クライアントのアドレスとブートファイルをサーバーの記録から調べる。DHCPにも手動割り当ては残る。違いは、後のアドレスがすべて一時的になったことではなく、動的割り当てがプロトコルに加わったことだ。(RFC 2131、§§1–2。)

BOOTPの歴史的な役割は小さいが、起動には欠かせなかった。ディスクレス端末を単独で動かしたわけでも、利用者を認証したわけでも、OSのイメージをそれ自体で転送したわけでもない。ハードウェアアドレスだけを持ち、使えるIP上の識別情報がない端末が、起動に必要な情報をどう尋ねるか、サーバーが何を返すか、ARPが通常どおり動く前に返信をどう戻すかを定義した。このケースでは、接続はローカルなブロードキャスト、サーバー上の明示的な記録、特別な扱いを要する返信から始まった。

出典と限界

RFC 951は議論を求める提案であり、想定された動作を記したもので、普及率の調査ではない。4.2 BSDのARPキャッシュ機能への言及も、すべての実装に同じ機能があったことを示さない。RFC 1542は後のリレー規則を記録するが、全ネットワークでの遵守を証明しない。BOOTPが選ぶのはネットワーク設定とファイル名であり、ファイル転送は別段階だ。DHCPは動的なリースを加えた一方、手動割り当ても残した。