ARP (Address Resolution Protocol) は、同じネットワーク (同一サブネット) の中で 「この IP アドレスを持つ機器の MAC アドレスは何か？」を問い合わせるプロトコル。IP は L3 の論理アドレス、MAC は L2 の物理アドレスで、Ethernet は MAC アドレスでしかフレームを配れない。だから IP 通信のたびに、宛先 IP を MAC に翻訳する ARP が裏で走る。本稿では ARP の必要性 / 解決の流れ / キャッシュ / 同一サブネットに閉じる性質 / Gratuitous ARP / そして認証がない設計が生む ARP スプーフィングと防御までを扱う。
ARP とは — L3 と L2 の橋渡し #
通信相手を指すアドレスは、階層ごとに別物が使われる。アプリは「ホスト名」、IP 層は「IP アドレス」、Ethernet 層は「MAC アドレス」。送信元はアプリ名 → IP までは DNS で解決できるが、最後の IP → MAC をその場で埋めるのが ARP の役割。
IP アドレスは「会社の部屋番号」、MAC アドレスは「実際の机」。郵便 (フレーム) は最終的に机に置かないと届かない。「301 号室の担当者の机はどれ？」とフロア全体に大声で聞いて (Request)、本人が「私の机はこれです」と手を挙げる (Reply) — これが ARP。
なぜ必要か — Ethernet は MAC でしか配れない #
データを送るとき、IP パケットは Ethernet フレームに包まれて (カプセル化) 線に流れる。そのフレームのヘッダには宛先 MAC アドレスを書く欄があり、ここが埋まらないとスイッチはフレームをどのポートへ出せばよいか分からない。
| 層 | 使うアドレス | 解決手段 |
|---|---|---|
| L7 アプリ | ホスト名 (example.com) | DNS |
| L3 ネットワーク | IP アドレス (192.168.1.1) | ルーティング |
| L2 データリンク | MAC アドレス (aa:bb:cc:..) | ARP |
つまり ARP は「IP は分かっているが MAC が空欄」という最後の 1 マスを埋めるためにある。
解決の流れ — Request はブロードキャスト、Reply はユニキャスト #
手順はシンプルで 2 往復もしない。「全員に聞く → 本人だけが答える」の 1 往復。
ff:ff:ff:ff:ff:ff（全員宛）にして「192.168.1.1 を持っているのは誰？ 192.168.1.5 (= 私) まで教えて」をセグメント全体に投げる。同じスイッチ配下の全機器がこれを受け取る。ARP キャッシュ — 毎回は聞かない #
毎回ブロードキャストすると無駄なので、解決結果は数十秒〜数分キャッシュされる。中身は手元で確認できる。
# Windows / 旧 Linux
$ arp -a
? (192.168.1.1) at aa:bb:cc:dd:ee:ff [ether] on eth0
? (192.168.1.20) at 11:22:33:44:55:66 [ether] on eth0
# 今どきの Linux (iproute2)
$ ip neigh
192.168.1.1 dev eth0 lladdr aa:bb:cc:dd:ee:ff REACHABLE
REACHABLE / STALE といった状態は「最近通信して生きているか」を表す。エントリが古くなると再度 ARP で確認する。
同一サブネット内だけ — リモートはゲートウェイの MAC を引く #
ARP の最重要ポイント。ARP はブロードキャストなので、ルータを越えられない (= 同じサブネット内でしか効かない)。では別ネットワークの相手と話すときは？
答え: 宛先そのものの MAC ではなく、デフォルトゲートウェイ (ルータ) の MAC を ARP で引く。「遠くへの郵便はまず最寄りの郵便局へ」と同じで、フレームはいったんルータに渡され、ルータが次のホップへ転送していく。
同一セグメントの相手に届かないときは、まず ip neigh で相手の MAC が解決できているかを見る。FAILED や INCOMPLETE なら L2 で届いていない（ケーブル・スイッチ・VLAN 不一致など）。リモート宛が全滅ならゲートウェイの ARP が解決できているかを確認する。
Gratuitous ARP — 誰も聞いていないのに答える #
Gratuitous ARP (GARP) は、要求がないのに自分の「IP↔MAC」を一方的にブロードキャストする特殊な ARP。主な用途は 3 つ。
- IP 重複検知 — 起動時に「この IP は私が使う」と宣言し、他に同じ IP がいれば衝突を検知する。
- フェイルオーバー — 冗長構成で待機系が昇格したとき、「この仮想 IP の MAC が変わった」と周知してスイッチの転送先を切り替えさせる (VRRP / keepalived など)。
- ARP キャッシュ更新 — 周囲のテーブルを最新化する。
便利な一方で、この「言ったもの勝ち」の性質こそが次の攻撃の土台になる。
ARP スプーフィング — 認証がない設計の弱点 #
ARP には送信者を検証する仕組みが一切ない。Reply を受け取った側は、それが本物かを確かめずにキャッシュを書き換える。ここを突くのが ARP スプーフィング / ARP ポイズニング。
arpspoof / ettercap / bettercap が代表的なツール。ARP スプーフィングで経路を奪っても、通信が TLS で暗号化されていれば中身は読めず、証明書検証で改竄も弾かれる。「同じ LAN にいる相手は信用できない」前提（ゼロトラスト的発想）が、カフェや社内 LAN でも HTTPS が必須な理由。
防御 — ネットワーク側で偽 ARP を弾く #
| 対策 | 仕組み | 適用先 |
|---|---|---|
| DAI (Dynamic ARP Inspection) | DHCP スヌーピングの台帳と照合し、IP↔MAC が一致しない ARP をスイッチが破棄 | 業務スイッチ (最有力) |
| 静的 ARP | 重要機器の IP↔MAC を手で固定し上書きを禁止 | サーバ・ゲートウェイ |
| ポートセキュリティ | ポートごとに学習する MAC 数・値を制限 | アクセススイッチ |
| 検知 (arpwatch 等) | IP↔MAC の対応変化を監視し通知 | 監視サーバ |
根本的には「同一セグメントに信用できない端末を入れない」セグメント分割 (VLAN・[[vlan]]) と、上位レイヤの暗号化 (TLS) の二段構えが現実的。
まとめ — 押さえる 5 点 #
- ARP は IP → MAC を解決する IPv4 の基盤。Ethernet は MAC でしか配れないため不可欠。
- 流れは Request (ブロードキャスト) → Reply (ユニキャスト) → キャッシュ。
- 同一サブネット内だけ。リモート宛はゲートウェイの MAC を引く。
- 認証がないため ARP スプーフィングで MITM が成立する。
- 防御は DAI / 静的 ARP / ポートセキュリティ + 上位の TLS 暗号化。
- IPv6 には ARP はなく、NDP (ICMPv6 の近隣探索) が同じ役割を担う。
