要約

  • RFC 906は、メーカーごとに異なる起動方式とサーバー実装を抱える現場に向け、ディスクレス機が最初のコードを取得する共通手段としてIP上のTFTPを提案した。
  • Ross Finlaysonが報告したMotorola 68000/Ethernetの例では、一つのサーバーからERRORが返っても探索を打ち切らず、最初の有効なDATAが転送相手を固定した。ROMコードはEthernetドライバーを除いて4 KB未満だったが、これは一つの実装の記録であり、広範な採用を示すものではない。

起動後なら近隣の機器と同じInternetプロトコルを使えるワークステーションでも、その状態に到達するには別の仕組みが要る。OSはまだ動いておらず、自分のファイルを要求できない。読み出し専用メモリーの小さなプログラムが、次のコードを取得できるだけの通信機能を先に立ち上げる。

Ross Finlaysonが1984年6月に公表したRFC 906は、その境界にある運用上の摩擦を記している。メーカーごとに初期ファイルの読み込み方法が異なっていたため、複数種類の機器を支える組織は、起動サーバーの実装をいくつも維持することになり得た。機器は起動さえすれば自由に通信できても、その前段が別々だった。RFC 906は最初の転送に共通プロトコルを使う案として、IPで運ぶTFTPを提案した。文書自身が、ARPA Internet向けの提案であり、議論と改善案を求めると明記している。すでに一般化した方式だとは述べていない。

TFTPを選んだ理由は、仕組みを小さく保てることにあった。起動プログラムはファイル名を含む読み出し要求を送り、DATAを受け取り、ACKまたはERRORを返す。最初の転送が遅くても、後続の段階でより高速なプロトコルを使えるため問題ではない、とRFCは説明する。クライアントはIPヘッダーを除いて最大524オクテットのIPデータグラムを受け取る必要があった。内訳は最大516オクテットのTFTP DATAパケットと、8オクテットのUDPヘッダーである。起動中の機器が受信したTFTP読み出し要求や書き込み要求に応答する必要はない。一般的なファイルサーバーではなく、コードを取得するための限定されたクライアントだった。

文書は起動体験全体を標準化しようとはしなかった。規定したのはネットワークプロトコルであり、利用者がどう起動操作を行うか、コンソールに何と入力するかは定めていない。Ethernetなど特定のデータリンクも前提にしなかった。通信上の共通部分を設けつつ、起動の入口やファイルの選び方は現場に残せる構成だった。

Finlaysonが報告した実装は、この設計を具体的に見せる。EthernetにつながるMotorola 68000ワークステーションで、起動コードはROMに置かれていた。利用者はファイル名を入力し、自機とサーバーのInternetアドレスも指定できた。サーバーのアドレスを省略すると、複数のTFTPサーバーに要求が届くことがある。そこで問われるのは、単に応答があるかではなく、どの応答を受けてクライアントの状態を変えるかだった。

その規則は明確だ。一台のサーバーからTFTP ERRORが届いても、別のサーバーが後からファイルを送る可能性があるため、クライアントは中断しない。最初の有効なDATAパケットのInternetアドレスとEthernetアドレスが、後続ACKの宛先になる。その後で別のサーバーからDATAが届けば、クライアントはERRORを返す。要求は複数のサーバーに届いても、一つの有効な先着応答が今回の転送相手を決める。

この仕組みは認証と取り違えられやすいが、認証ではない。TFTP第2版は、ユーザー認証の仕組みを持たないと説明している。最初の有効なDATAを選ぶ規則は応答者を決めるだけで、それが運用者の想定したサーバーであることや、起動イメージの出所が別途検証されたことは証明しない。資料に攻撃や導入時の事故は記録されていない。資料が示すのは、提案のどこに判断を置いたかである。クライアントの応答処理と、どのサーバーが応答できるかを決める現場環境だ。

コードサイズも同じように範囲を限定して読む必要がある。報告された実装は、Ethernetデバイスドライバーを除き4 KB未満だった。これは、一人の実装者が制約のあるROMにクライアントを収めたという記録である。他のプロセッサでの規模や導入台数を示すものではなく、メーカー固有の起動方式が消えた証拠でもない。

後年の文書は設計の広がりを理解する手掛かりになるが、直接の採用経路を証明するわけではない。1985年のRFC 951は、BOOTPでアドレスと起動ファイルを決めた後、一般にはTFTPでファイルを転送する二段階を説明した。1989年のRFC 1123も、ROMの起動プログラムがまずIPを設定し、次にホストのシステムコードを読み込む二つの段階を記している。準備と転送の分担が後に明確に記述されたことは分かるが、RFC 906が挙げた一つの実装を普及率に変えるものではない。

RFC 906の歴史的な意味は、成し遂げた勝利ではなく、境界を引いた点にある。ROMの小さなプログラムが通常のIP転送で次のファイルを要求する一方、起動操作やサーバー選択の一部は現場に残った。最初の有効なDATAは、一つの応答者が転送相手になる明確な切り替わりを与えた。そのぶんプロトコルを小さく保てたが、最初にコードを返す相手を把握する責任は運用側に残った。

後年のHeng LuのNote 65は、ここでは編集上の注意として使う。提案文書と報告された実装は、実際の展開や利用とは異なる証拠である。これはFinlaysonの意図を示す資料ではない。今ある根拠が確認するのは提案と一つの実装までであり、何か所で採用されたか、指摘されたサポート負担を減らしたかは分からない。

参照資料