要約

  • RFC 1931 は、障害に備えて複数の Dynamic RARP サーバーを置く一方、同じセグメントの全サーバーが同一の論理的アドレス権威と通信することを求めた。
  • 権威データベースは現実そのものではない。空きと記録されたアドレスが使用中の場合に備え、割り当て前の ARP や ICMP による確認が勧められた。
  • 文書は 1996 年 4 月に Informational として公開され、現在は Legacy に分類される。1988 年以降の一部 Sun プラットフォームの仕組みを記録したもので、標準でも DHCP の起源を証明する資料でもない。

返事がない、という情報不足

RFC 903 の RARPは、起動端末が既知のハードウェアアドレスから未知のプロトコルアドレスを得るための仕組みだった。対応表を持つサーバーが一台とは限らないため、否定応答は定義されていない。一台が知らなくても、別の一台が知っているかもしれないからだ。

この慎重さは、無人インストールには不便だった。無応答は、パケット損失、サーバー停止、未登録端末、誤ったセグメント、サーバー不在のどれでもあり得る。クライアントは指数バックオフで再送できても、待つ価値があるかを判断できない。しかもケーブルを挿すだけで全てが自動的に決まるわけではない。ネットワーク番号や命名系は管理者が先に用意しなければならなかった。

RFC 1931 の DRARP は、この曖昧さに必ず返事を返す設計を与えた。従来の形式を保ちながら opcode 5 の要求、6 の一時割り当て、7 のエラーを追加する。恒久的な対応があれば通常の REVARP_REPLY、なければ一時アドレスの DRARP_REPLY、割り当て不能なら DRARP_ERROR となる。

エラーは、動的割り当て禁止、空き枯渇、権威の一時停止または遅延、既知端末の別セグメントへの移動、その他の失敗を区別した。分類は運用判断を助けるが、エラー名が応答者を認証するわけではない。

RFC Editor の記録では、文書は Informational、現在のストリームは Legacy であり、インターネット標準を定めない。本文によれば一部の Sun Microsystems プラットフォームで 1988 年から使われ、1996 年 4 月の公開時には対象製品は販売を終えていた。DHCP が役割の一部を既に担っていた、という記述もある。したがってこれは後継標準を主張する提案ではなく、消えかけた設計知を残す記録である。

複数の返答口を一つのサービスにする条件

DRARP の重要な規則は、同じ要求への返答が、送信サーバーを示す欄以外で食い違ってはならないことだ。相違はプロトコルエラーになる。サーバーの数が増えても、割り当て判断は増えない。

各ケーブルセグメントにサーバーを置けば分断時の損失を小さくでき、複数台を置けば単一機器の故障にも耐えやすい。しかし全サーバーは同じアドレス権威と連携する。記載された実装では NIS と集中型 RPC の IPalloc がその役割を担い、管理者や DRARP サーバーなど許可された主体だけが割り当てを変更した。RFC はこの方式を標準化せず、安全性も扱っていない。

権威は恒久対応、一時対応、空きプールを管理し、作成、検索、削除、期限切れ処理、同時要求、変更権限を扱う。「一つ」は物理サーバー一台という意味ではない。分割実装も可能だが、実装と管理の負担が大きいと文書は述べる。必要なのは、どの応答口から見ても同時に矛盾する割り当てが正当化されないことだ。

冗長化は正しさの複製ではない。誤った共有状態を五台が高速に返せば、利用者から見える停止は減る一方、誤りの到達範囲は広がる。応答面の高可用性と、書き込み権限の分散は別物である。

台帳よりケーブルが新しいことがある

RFC 1931 は中央の記録を絶対視しなかった。管理上は空きでも、実際には誰かがそのアドレスを使っている可能性がある。そのため割り当て前にネットワークを調べ、実装では ARP と ICMP Echo を使ったという。

RFC 826 の ARPは、必要に応じてプロトコルアドレスとハードウェアアドレスの対応を流通させる。応答があれば、その瞬間そのリンクで誰かが利用を主張した証拠にはなる。だが所有権、管理上の許可、将来の一意性は証明しない。無応答も、分断や損失を越えて永続的な空きを保証しない。

ここで三つの現実が分かれる。ハードウェア識別子はパケットに載った値、権威台帳は組織が認める対応、プローブは時刻とリンクを限定した観測である。機器がセグメントを移動したと認識するには、双方の権威が同一か通信し、識別子の範囲も衝突を避けられるほど広くなければならない。それでも識別子は利用者の本人確認にはならない。

サーバーは他のサーバーの通知を聞き、協調していないように見える応答者を報告できた。ただし誰が偽物かを相互に裁くプロトコルはない。検出は証拠の入口であり、裁定は権威や運用者の仕事として残った。

一時間は成功条件ではない

一時割り当ては、インストールと管理データの伝播が終わるまで、途中の故障を越えて残る必要がある。初期実装では一時間のキャッシュで足りたとされるが、普遍的なリース規則ではない。期限は資源を回収する仕組みで、設定完了を証明する時計ではない。

後の DHCP は別の状態機械を採用した。RFC 1541では複数オファー、クライアントによる選択、サーバー識別子、有限のリースが明示され、RFC 2131ではローカル確認で使用中と判明したアドレスをクライアントが拒否できる。これは設計比較であって、DRARP が DHCP を生んだという因果主張ではない。

中央権威を使わない局所的な選択も後に整備された。RFC 3927の IPv4 リンクローカルは、ホストが同一リンク内で候補を選び、調べ、宣言し、場合により防御する。ただし非ルーティングで、持続的な身元にはならない。RFC 5227の競合検出も ARP Probe と Announcement による局所・時限の証拠であり、隔離や悪意ある応答という限界を残す。

記録を動作へ変える前の最小条件

Heng Lu の「Running-Code Primacy」という視点では、台帳は調整のための記号であり、ケーブル上の動作はそれを拘束する現実である。現場確認は管理を不要にせず、管理上の判断を実行へ変える直前に反証可能にする。

「Minimum Initial Specification」に照らせば、共有すべき核は小さい。同一要求には整合した答えを返し、失敗を区別し、依存先が整う前に一時状態を回収しない。NIS、RPC、キャッシュ時間、現場の権限設計まで一つに固定する必要はない。

「On Reality Layers」が示す層の違いも見える。データベースは合意を表し、応答は端末を設定し、プローブは合意を否定し得る。RFC 1931 の価値は、複数の機械を複数の真実と呼ばず、一つの台帳を現実そのものとも呼ばなかった点にある。

出典

  1. RFC 1931 — Dynamic RARP Extensions for Automatic Network Address Acquisition
  2. RFC Editor — RFC 1931 現行記録
  3. RFC 903 — A Reverse Address Resolution Protocol
  4. RFC 826 — An Ethernet Address Resolution Protocol
  5. RFC 1541 — Dynamic Host Configuration Protocol
  6. RFC 2131 — Dynamic Host Configuration Protocol
  7. RFC 3927 — Dynamic Configuration of IPv4 Link-Local Addresses
  8. RFC 5227 — IPv4 Address Conflict Detection
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile