Summary

  • 1985年のBOOTPは、ディスクレスのクライアントが通常のIP要求をサーバーへ送れるようになる前に、アドレスと起動ファイルの情報を求められるようにした。リレーはそのやり取りをローカルネットワークの外へ運べた。
  • giaddrはBOOTP固有の中継経路を表す欄だった。RFC 1542は後に、クライアントの汎用IPルーターや既定経路ではないと明確にした。

ホストが依頼する前に、誰かが道を作る

ディスクレスのワークステーションは、電源投入時に循環した問題に直面した。IPを使うにはインターネットアドレスが要るが、どのアドレスを使うか知るにはネットワークへの問い合わせが要る。起動を続けるサーバーとファイルも探さなければならない。サーバーが別のネットワークにあるなら、ローカルのブロードキャストだけでは通常のルーターを越えられなかった。

1985年9月のRFC 951は、BOOTPをアドレス決定と起動ファイル選択からなる第一段階として記述した。クライアントはハードウェアアドレスと、分かる場合は自身のIPアドレスを含むBOOTREQUESTを送る。ciaddrがゼロなら、サーバーは自分のデータベースからハードウェアアドレスを照合し、クライアントのアドレスをyiaddrに入れて返せた。別の欄はサーバーとファイルを示す。要求と応答はUDPのポート67、68を使った。

応答だけでOSが読み込まれるわけではない。RFC 951はアドレスとファイルの選択を後続のファイル転送と明確に分け、転送には通常TFTPを想定した。RFC 906はその前年、ネットワーク経由で起動ファイルを読み込む方法を記している。BOOTP応答がサーバーとファイルを指しても、サーバーへの到達、ファイル全体の受信、起動完了までは証明しない。

ローカルブロードキャストから、別ネットワークのサービスへ

BOOTPは未設定のクライアントに、DNSで遠隔サーバーを探したり、あらかじめ遠隔経路を持ったりすることを求めなかった。まずローカルのケーブルに要求をブロードキャストできる。サーバーがその先にあれば、ゲートウェイまたは転送エージェントがBOOTP要求を送り、応答を戻せた。RFC 951ではネットワーク越しのこの機能は任意で、ゲートウェイとサーバーに追加コードを要したが、クライアント側に特別な動作は不要だった。

パケットには、1985年の文書でゲートウェイIPアドレスと呼ばれたgiaddr欄があった。転送の際、最初のゲートウェイは欄がゼロなら自分のアドレスを入れ、hopsを増やせた。giaddrがゼロでなければ、サーバーはサーバーポートを使ってそこへBOOTP応答を送り、リレーにクライアント側ネットワークへ届けさせた。この欄がつないだのは、起動中の端末と遠隔の起動サービスである。

それは起動後にホストが使う経路ではない。RFC 951の初期の文言には誤解の余地があった。ある箇所は、サーバーへ「到達するために」パケットをgiaddrへ転送すると読める。しかし、起動ファイルの転送と、クライアントの通常のIPルーティングは別の仕事だ。欄名に「ゲートウェイ」とあるだけでは、同じアドレスを使うことにはならない。

1993年の明確化

RFC 1542はこの曖昧さを直接扱った。以前の仕様では転送エージェントの動作が明確でなかったため、「リレーエージェント」という語を採用し、通常のIP転送と区別した。BOOTPリレーはメッセージの宛先としてそれを受け取り、別のBOOTPメッセージを生成する。通常のIPデータグラムをそのまま通すだけではない。機能はネットワークを接続するルーターに置くのが便利だが、クライアントのネットワークに直接つながったホストでも実装できる。

RFC 1542によれば、giaddrはBOOTREQUESTをリレー経由で別ネットワーク上のサーバーへ送り、BOOTREPLYをリレー経由で戻すためにある。クライアント向けの汎用IPルーターを表すものではなく、クライアントもそのように解釈してはならない。ローカルではないTFTPサーバーへ向かうには、別の設定項目や発見方式から、第一ホップのルーターアドレスを取得する必要がある。

この明確化は1985年の設計を覆したのではない。クライアントのIP設定が整う前に、起動サービスのメッセージを別ネットワークへ運ぶ、という役割の境界を明示した。後続の通信まですべて設定する機能ではなかった。

起動サービスの集中化と残る依存関係

リレーがあれば、起動サーバー、ハードウェアアドレスとIPアドレスの対応表、起動ファイルをローカルのケーブルから離れた場所に置けた。各セグメントに個別のサーバーを設けずに済む可能性があり、運用者は対応表とファイルを一か所で管理できる。これは仕様から導けるアーキテクチャ上の含意であり、実際の普及率や費用を測ったものではない。

それでも起動には複数の依存関係が残る。ローカルリンク、中継リレー、その宛先設定、サーバー側のクライアント記録、ファイル、クライアント自身の経路、そしてTFTP転送が必要だ。BOOTP応答が見えたからといって、後続の段階が完了したことにはならない。リレーアドレスは利用者の身元や認可を示さず、クライアントの既定経路でもない。

後のDHCPはリレーエージェントの動作を引き継ぎ、期間付きのリースを含む複数のアドレス割り当て方式を加えた。だからといって、BOOTPの起動交換、DHCPのリース周期、TFTPのファイル転送、通常のIP経路設定を一つの仕組みにまとめてはならない。同じ起動で四つが関わっても、それぞれ状態と確認すべき記録は異なる。

歴史の論点は四文字の欄に表れている。giaddrは、ホストがIPに参加する方法を学んでいる間、制御メッセージをネットワーク境界の向こうへ運んだ。名前に「ゲートウェイ」とあっても、ホスト自身のゲートウェイにはならない。制御メッセージの返信経路、クライアントの次ホップ、ファイルサーバーのアドレス、サービスの成功は、関連していても別々の事実だ。

出典