要約
- RFC 826が扱ったのは、経路選択の直後に残る小さな空白だった。次に渡すIPアドレスが分かっても、ローカル媒体で使う48ビットの宛先は別に見つけなければならない。
- ARP Requestは対象への質問であると同時に、送信者自身の対応関係を示す観測材料だった。受信側はopcodeを見る前に送信者を学び、キャッシュが次回の実行を速くした。
- Proxy ARPとアドレス競合検出は、応答を本人確認とみなせないことを示した。応答者は代理転送者かもしれず、正式に割り当てられたIPでも現場の衝突によって使用を断念することがある。
ルーティングの後に残った宛先
IP層は、宛先が直結網にあるか、あるいはルーターに渡すべきかを判断する。そこで選ばれるのは出力インターフェースと当面のIPアドレスである。しかしEthernetの送信装置には、フレームに書くハードウェアアドレスが必要だ。二つの名前は長さも管理目的も異なる。
David C. Plummerによる1982年11月の RFC 826 は、この変換不能な境界に手続きを置いた。Address Resolutionモジュールは、プロトコル種別と対象プロトコルアドレスの組をローカル表で探す。見つかれば対応するEthernetアドレスを返し、なければ経路が選んだLANで問い合わせる。
メッセージにはハードウェア種別、プロトコル種別、それぞれのアドレス長、操作、送信者と対象の両アドレスがある。この構造は、IPアドレスからMACアドレスを計算するのではなく、独立した名前空間の間に観測された関係を置く。元の10Mbps Ethernetを越える一般化も、その発想に含まれていた。
遠隔サーバーへ送る場合、IPパケットの宛先はサーバーのままでも、最初のフレームの宛先は通常ルーターである。ARPは世界の経路を探す仕組みではない。ルーティングが既に選んだ一歩を、ローカル媒体で実行可能にする。
近くの全員に聞こえる問い
キャッシュに答えがなければ、ホストは自分のプロトコルアドレスとハードウェアアドレス、知りたい対象アドレスを入れたRequestをブロードキャストする。同じブロードキャストドメインの機器はすべて受信できるが、自分が対象だと認識した機器だけが送信者へ直接Replyを返す。
発見は公開、返答は単一宛先という組み合わせは合理的だった。未知の相手へ最初からunicastはできない。一方、答えの届け先はRequestから分かる。RFC 826は、全ホストが定期的に全対応表を広告する案も避けた。利用しない対応を全員に覚えさせる「完全性」は、帯域とメモリーを浪費する。
初期案では、解決を起こしたIPパケットを捨て、上位層の再送に期待することも想定された。1989年の RFC 1122 は、未解決宛先について少なくとも最新の一個を保存すべきだとした。待ち行列は通信開始を滑らかにするが、後で届く対応の正当性までは保証しない。
問いには量の限界も要る。RFC 1122は同じIPへのRequest洪水を防ぐ仕組みを必須とし、一宛先につき毎秒一回を推奨上限とした。返事がない理由は不在だけではない。損失、分断、休止、妨害もあり得る。回数を増やしても、その区別は自動では得られない。
opcodeより先に学ぶ
RFC 826の受信手順では、ハードウェアとプロトコルを理解できるか確認した後、まず送信者の対応を表へ反映する。既存のプロトコルアドレスなら新しいハードウェア値で更新する。自分が対象で未登録なら追加する。それから初めて、RequestかReplyかを調べる。
したがってRequestは片方向の質問ではない。「対象には誰が届けられるか」と尋ねながら、「私への返答はこのハードウェアへ」と伝える。対象は返答を作る前に帰路を学ぶ。上位プロトコルを実装しないモニターでも、ARPだけを見てローカル活動を記録できる。
新しい観測が古い値を上書きすることは、移動や交換後の回復に効く。しかし暗号学的な本人確認はない。最新の発言者が正しいとは限らない。キャッシュは運用に使う仮説であって、所有権台帳ではない。
RFC 826はagingやtimeoutの必要性を議論したが、方式を規定しなかった。RFC 1122は古いエントリーを排除する機構を必須にした。時間切れ、既知のハードウェアへのunicast確認、リンク層や上位層からの失敗通知など、選択肢は複数ある。共通するのは、過去の一観測に永続的な実行権を与えないことだ。
ゲートウェイが他者の名で答える
1987年10月の RFC 1027 はProxy ARPを記録した。テキサス大学では大きなEthernetをsubnetに分ける必要があったが、多数のベンダーOSはsubnetを理解していなかった。一斉改修の代わりに、ゲートウェイが境界を隠した。
Aが別の物理網にいるBを尋ねると、Bへの経路を持つゲートウェイが自分のハードウェアアドレスで答える。Aはそれをキャッシュし、IP上の宛先Bを変えないまま、ローカルフレームをゲートウェイへ渡す。B側でも逆向きに同様の代理ができる。
古いホストを無変更で使えるのが利点だった。しかしReplyの意味は「私はB」ではなく、「B宛てを受け取り、先へ運ぶ」である。ARP応答は運用上の委任になり得る。
その委任はルーティング表と管理設定に依存する。複数ゲートウェイが答えれば最初の応答がキャッシュを取ることもある。代理経路が壊れていれば、ローカル解決は成功しても配送は失敗する。ARP単体は、回答者と最終宛先の同一性を証明しない。
配布されたIPを現場が拒む
1997年のDHCP仕様 RFC 2131 は、中央の割り当て後にもローカル確認を残した。サーバーは再利用アドレスを検査すべきであり、クライアントもDHCPACK後に最終確認する。
クライアントは送信元IPをゼロにしたARP Requestで候補をprobeできる。自分のハードウェアは示すが、まだIP使用者だとは名乗らない。失敗するかもしれない対応を周囲のキャッシュへ先に書かせないためである。
既使用を検知したらDHCPDECLINEを送り、設定をやり直す。利用可能ならannouncementで以前の利用者に由来する古いキャッシュを更新させる。サーバーのleaseが帳簿上正しくても、LAN上には静的重複や古い機器、偽装が残り得る。
一度の解決から継続する競合検出へ
2005年の RFC 3927 はIPv4 link-local用にprobeとannouncementの時系列を定めた。ホストはランダムに待ち、送信元IPがゼロのprobeを送り、競合がなければ選んだIPを送信元と対象の両方に入れてannounceする。多数ホストの同時起動や、すべての候補に答える異常機器によるstormを、乱数とrate limitで抑える。
監視は取得時だけでは終わらない。別々だった二つのLANが後に接続され、同じlink-localアドレスが衝突することがある。過去の成功は、新しいトポロジーを拘束できない。
2008年の RFC 5227 はIPv4 Address Conflict Detectionを一般化した。Probeは「誰か使っているか」という問いと「私は使いたい」という弱い宣言を同時に運ぶ。Announcementは「現在使っている」という強い宣言である。
競合時、通常のホストは撤退するか、一度だけ防御announceを送れる。DEFEND_INTERVAL内に再び矛盾が来れば使用をやめなければならない。二台が永久に主張を繰り返すbroadcast戦争を避けるためだ。重要なルーターなどは例外設定できるが、通知と送信量を制御する必要がある。
競合検出は所有権認証ではない。攻撃者は偽の競合で正規ホストを退かせられる。応答がないprobeも、将来の不在を保証しない。これは現在の行動を変えるための限定的な観測である。
コード番号の登録が支配しなかったもの
ARP内部のhardware typeやopcodeには共通番号が要る。2009年の RFC 5494 はIANAの割り当て指針と実験値を定めた。同じビットを同じ意味に読むための重要な調整である。
だが、プロトコルの語彙を登録することと、各LAN上のIP利用者を決めることは別だ。IANAのコード表はメッセージを相互運用可能にするが、そのメッセージで語られた個々の身元を認証しない。
忘れられることがキャッシュの条件
ARPは世界全体の正解を求めず、今いるLANで次の一フレームに必要な答えだけを求めた。必要時に聞き、必要なホストだけが覚える。その小ささが普及の力だった。
同じ小ささが限界でもある。偽の新情報、見えないproxy依存、長生きしすぎるstatic entryは、局所的な便利さを障害へ変える。キャッシュは忘れられるから安全なのであり、永続するから権威的なのではない。
ケーブルは証人になったが、主権者にはならなかった。受け入れ、送信し、再確認し、防御し、撤退するのはホストである。ローカル発言を永久の身元と誤解した責任も、実行者に残る。
情報源と証拠の限界
RFC 826は基本交換と学習順序、RFC 1027は代理応答、RFC 1122は失効と流量制限を示す。RFC 2131はDHCP割り当て後の検査、RFC 3927とRFC 5227はprobe・announce・競合防御、RFC 5494はコード番号を扱う。
これらは設計と要件の史料であって、全世界の導入日や現在の普及率ではない。ARP captureが証明するのは、ある時点の一リンクで誰かが何を発言したかまでであり、認証済み身元、所有権、意図、代理後の配送までは証明しない。
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
