RFC 903：RARP が返したのはアドレスで、設定一式ではない

要約

RFC 903 が扱ったのは、具体的なコールドスタートの問題だった。ディスクレス・ホストはハードウェア・アドレスを知っていても、IP を使うには先にプロトコル・アドレスを得る必要があった。
RARP はデータリンク層で照会し、サーバーは維持しているハードウェア・アドレスとプロトコル・アドレスの対応表から返答した。その応答は機器を認証せず、起動完了の証明にもならなかった。
明示的な「該当なし」応答は定義されていない。クライアントは応答がなければタイムアウトするしかなく、対応表に記録がないのか、パケットが失われたのか、サーバーが応答しなかったのかを区別できなかった。
RFC 950 と BOOTP を読むと、アドレスだけではホストの設定が終わらないことが分かる。ゲートウェイ、ネームサーバー、サブネット・マスク、起動ファイルも必要になり得た。

IP より先に必要だった問い

ローカル・ディスクを持たないワークステーションを考えてみる。起動コードは Ethernet インターフェースのハードウェア・アドレスを読み取れるが、インターネット・アドレスは保存されていない。送信元アドレスが分からないため、IP 要求を送って解決することもできない。

1984 年 6 月に公開された RFC 903 で、Ross Finlayson、Timothy Mann、Jeffrey Mogul、Marvin Theimer は RARP を提案した。Ethernet のようなブロードキャスト媒体で、ホストが外部の相手に自分のプロトコル・アドレスを尋ねる構想だ。ARP は逆向きの問題、つまりプロトコル・アドレスが分かっている相手のハードウェア・アドレスを見つける。RARP はハードウェア・アドレスから出発し、対応するプロトコル・アドレスを求めた。

これは汎用の本人確認サービスではない。RARP は機器の所有者や、そのアドレスを使う権利の有無を尋ねない。未設定のホストが通常の IP 通信を始める前に、特定の対応関係を照会する手段だった。

答えを持つのはローカル・サーバー

RFC 903 は RARP を意図的に独立したデータリンク・プロトコルとして定義した。パケットの形は ARP と同じだが、逆引き要求と応答には別のオペレーション・コードを割り当てた。自分のアドレスを尋ねる場合、ホストは送信元と対象の両方のハードウェア・アドレス欄に同じ値を入れる。該当するアドレスを知るサーバーは、対象のプロトコル・アドレスを返せる。

返答はサーバー側の状態に依存した。RFC は、1 台以上の RARP サーバーがハードウェア・アドレスとプロトコル・アドレスの対応表を保持すると記す。これは通常の ARP とは異なる。ARP ではホストが相手の対応関係をキャッシュに蓄積し、クライアントとサーバーを分けない。したがって RARP は運用上の依存関係を持ち込んだ。クライアントは質問できるが、ローカルの管理者がサーバーの表を使える状態にしておかなければならない。

返答は対応関係を示す記録であり、資格情報ではない。RFC はハードウェア・アドレスと人物、所有者、許可された機器を結びつける認証を定義しない。ホストがアドレスを正しく設定したか、ゲートウェイに届いたか、OS を読み込んだかも分からない。そこから先は別の段階だ。

無応答は「未登録」と同じではない

RFC 903 は逆引き要求と応答を定義するが、「見つからない」またはエラーを知らせるパケットは設けない。複数のサーバーが応答してよい場合があるためだ。独立した拒否メッセージを定義せず、合理的な時間内に応答がなければ要求側がタイムアウトするよう求めた。

交換の仕組みは小さく保たれた一方、クライアントに残る観測は曖昧だった。タイムアウトは対応表に記録がないことを示すかもしれない。要求または応答の消失、リンク障害、サーバー不在でも同じ結果になり得る。無応答だけでは原因を区別できない。起動ログが「RARP がタイムアウトした」とだけ記録しても、理由は確定しない。

障害を再構成するときは、この違いが重要になる。応答がないことから分かるのは、クライアントが何を受け取ったか——何も受け取らなかった、ということだ。それだけではアドレスが割り当てられていないとは言えない。原文はこの限界を明確にする一方、あらゆる原因を切り分ける診断システムまでは規定していない。

アドレスだけではホストを設定できない

起動時に必要な情報は、すぐに一つのアドレスを超えた。RFC 950 は、新たに起動したホストがインターネット・アドレスを知る方法として RARP を挙げたあと、ゲートウェイのハードウェア・アドレス、ネームサーバーの IP アドレス、サブネット・マスクなども必要になると記す。複数回ブロードキャストするより、一度の要求で複数のパラメーターを得るほうが望ましいという。

翌年に規定された BOOTP は、ハードウェアから IP への照会を残しながら、任意のファイル名など、より多くの起動情報を運べるようにした。ゲートウェイを越えた起動も可能にする設計だった。RFC 951 は IP/UDP を使う方式と、データリンク層の生パケットにアクセスするため特別なカーネルやドライバー変更を要する RARP を明示的に比較する。RFC 1542 は後に BOOTP リレーの挙動を明確化し、RFC 2131 は BOOTP を基礎に再利用可能なアドレスの自動割り当てと設定オプションを追加した DHCP を説明する。

この流れから、すべてのネットワークが一日にして RARP をやめたとは言えない。変化したのは問われる内容だ。事前に割り当てられたアドレスを知るだけでは足りず、ルーターを越えて起動するには、より多くの情報とリレー経路が必要になった。

記録は機器そのものではない

Heng Lu のノート72は後年の分析視点であり、1984 年を説明する史料ではない。そこでは登録記録は現実を記述するが、現実そのものを作るわけではないと整理されている。RARP は世界規模のレジストリーではないが、この区別は当てはまる。サーバーの表はローカルな対応関係を調整できても、返したアドレスを機器の所有、利用者の身元、正常動作の証明にはできない。

RARP の歴史的貢献は、もっと狭く実用的だった。ホストがすでに届くリンクに問いかけ、IP 通信を始めるのに必要な一つのアドレスを得られるようにした。その境界は運用コストでもあった。ローカルの対応表を維持する必要があり、無応答は理由を語らず、返答も完全な設定ではなかった。