要約

  • RFC 1868 は、ダイヤルイン端末が一台目の通信サーバーから切断し、二台目から再接続した後も、LAN の相手が一台目の Proxy ARP 対応を保持する問題を扱った。
  • UNARP はハードウェアアドレス長をゼロにした未要求の ARP Reply を送り、対応する受信者に古い IP のキャッシュ削除を求めた。非対応実装は短い形式を拒否する想定で、拡張を無効化する設定も勧められた。
  • 送信、フレーム受信、構文受理、キャッシュ削除、新しい解決、転送成功は別の出来事である。UNARP は後続段階の確認応答を返さない。

同じ IP が別の入口から戻る

共有モデム群へ接続する端末を考える。LAN 上の Host A には、その端末の IP アドレスが同じネットワークにあるように見える。実際には端末は通信サーバー CS1 の先にいる。Host A が ARP Request を送ると、CS1 が端末に代わって自分のハードウェアアドレスを答える。Host A はその対応をキャッシュし、以後のフレームを CS1 へ渡す。

RFC 1027 が記録した Proxy ARP は、古いホストからサブネットの存在を隠す互換技法だった。ホスト側に新しい経路理解を要求せず、ゲートウェイが対象の代理として応答する。その便利さは、経路の現在性を一つのローカルな IP―ハードウェア対応に託した。

端末が切断し、Host A のキャッシュが期限切れになる前に CS2 から再接続すると、番号は同じでも代理が違う。Host A は古い CS1 宛てに送る。保存された値は壊れていない。ただし、値が表した現実が終わっている。

1995 年11月の Experimental 文書 RFC 1868 は、この時間差だけを狙った。経路制御全体を置き換えず、ARP のパケット形式も作り直さない。離脱を知るサーバーが「その対応をもう使うな」と伝える仕組みを加えた。

対応表は各ホストの内側にあった

RFC 826 の ARP では、プロトコルアドレスからローカルなハードウェアアドレスを求める。Request は対象を尋ね、Reply は送信者の対応を示す。受信者はそれを自分の表に併合し、次の送信に使える。

全ホストが同じ版を同時に確定する台帳はない。必要な隣接情報を、それぞれが局所的に持つ。この分散性は中央装置への依存を避けたが、移動直後には異なるホストが異なる古さの事実を保持しうる。

RFC 1122 は1989年、古い ARP エントリを無効化する何らかの仕組みをホストに要求した。例は、タイムアウト、単一相手への定期的な問い合わせ、リンク層からの障害通知、上位層が配送問題を見つけたときの通知である。Proxy ARP の普及によって、キャッシュが現実から外れる可能性が高まったと説明した。

ここで証拠の種類を混ぜてはいけない。タイムアウトは信頼期限の終了、問い合わせ失敗は応答の欠如、リンク通知は局所的な配送障害、上位通知は別層で観測した問題を示す。どれも「端末が CS2 に移った」という直接の受領証ではない。

ハードウェアアドレスを持たない Reply

UNARP は通常の Reply と同じ opcode 2 を使いながら、ハードウェアアドレス長をゼロにした。送信元プロトコルアドレスには離脱端末の IP、対象プロトコルアドレスには 255.255.255.255 を置く。長さがゼロなので、送信元・対象のハードウェアアドレス欄は存在しない。リンクヘッダーを除けば十六バイトである。

RFC 1868 を理解する受信者は、送信元 IP に対応する ARP キャッシュを削除する。通信サーバーは、自分が以前に Proxy ARP Reply を出したかどうかを覚えていなくてもよい。端末が切れたときに常に UNARP を出せばよいとされた。自ら穏当に LAN を離れるホストも送信できた。

余分に削除すれば、次の通信で再解決が起きる。削除しなければ、既に役目を失った代理へ送り続ける。この非対称性が「疑わしい継続より忘却」を合理的にした。

ただし、削除は新しい所在を作らない。Host A は CS1 を使わない状態へ移るだけで、CS2 をまだ知らない。新しい Request、Reply、学習、データ送信が必要である。古い情報がないことは、新しい経路があることではない。

非対応者との共存が沈黙を曖昧にした

RFC 1868 は、対応ノードと非対応ノードが同じ LAN にいる期間を前提にした。ハードウェアアドレス長ゼロは、その境界を示す。UNARP を知らない実装は短縮された Reply を不正として捨て、ゼロのアドレスを誤って学習しないことが期待された。

安全側の互換策だが、送信者から見た沈黙には複数の意味が残る。相手は受信して削除したかもしれない。受信したが拒否した、拡張を無効にしていた、フレームを失った、あるいは削除対象を最初から持っていなかったかもしれない。応答の集合は規定されていない。

さらに、短縮形式を嫌う既存ベンダー実装に備え、UNARP を止める設定スイッチが推奨された。局所的な拒否は欠陥ではなく移行設計に組み込まれていた。文書が公開されても、走っているコードが同じ解釈へ変わるわけではない。

「広く対応されるだろう」という本文の見通しも、観測値ではない。Experimental の文書と後年の一覧は規格史を示すが、採用率を示さない。

MAPOS は三回送り、削除条件を加えた

RFC 2176 は1997年、MAPOS 向けに関連する UNARP を定めた。専用 opcode と実際のハードウェア欄を使い、ポートが上がったノードは三十秒間隔で三回送る。受信者は、パケットのハードウェアアドレスがキャッシュと異なる場合に限って IP エントリを消す。

三回送信は一回の損失を補いやすくする。比較条件は、既に正しい対応まで消すのを防ぐ。しかし三送信は三受領証ではない。同じ RFC はキャッシュの期限管理とリンク喪失時の即時削除を別に要求した。UNARP だけに正しさを委ねなかったのである。

RFC 3790 は後に、RFC 1868 をリンク上の ARP キャッシュ削除に用いる IPv4 依存仕様と整理した。この記述は用途の分類であり、実装実績ではない。

「今使う」という宣言も最終証明ではない

RFC 5227 は、ARP Request が一つのパケット内で主張と質問を併せ持つと整理した。Probe は「このアドレスを誰か使っているか」と尋ねながら、使いたい意思を含む。Announcement は「私は今このアドレスを使っている」と、より強く主張する。

UNARP は反対側から「以前の対応を信じるな」と言う。正負いずれの通知も、受信者が構文と自分の状態を照合するための入力である。全員の一致、競合の不存在、フレームの到達、アプリケーションの成果を単独では保証しない。

歴史から得られるのは中央判定者の必要性ではなく、局所状態に正しい名前を付ける必要性である。「離脱通知を送信」「この観測点で受信」「このホストで削除」「新しい対応を学習」「転送に成功」は個別に検証できる。「LAN 全体が忘れた」は、必要な地点を観測しない限り言えない。

出典と限界

RFC 826、1027、1122 は ARP、Proxy ARP、キャッシュ検証の基礎を示す。RFC 1868 は Experimental な離脱通知を定義し、RFC 2176 は後のリンク固有版、RFC 3790 は IPv4 依存の整理、RFC 5227 は探査と宣言の意味を示す。これらは仕様と記録を裏付けるが、現在の普及率、全実装の挙動、特定製品の適合、実際の攻撃・障害、または実ネットワークでの配送結果を証明しない。