#0169（2025/06/14）ARP解説

## 1. はじめに

* ARP (Address Resolution Protocol) は IPv4 ネットワークの **L2–L3 ブリッジ**として45年以上にわたり使われ続けています。
* 本稿では、単なるプロトコル仕様の説明にとどまらず、**OS 実装差・障害解析・セキュリティ脅威と防御・クラウド／DC における最適化手法**を段階的に深掘りします。
* 読者想定: ルータ／スイッチの CLI が扱え、Linux カーネルパラメータを調整しながらトラブルシュートできるレベルのエンジニア。

---

## 2. ARP の基礎再確認

* **役割**: IPv4 アドレスと同一ブロードキャストドメイン内の MAC アドレスをマッピングし、Ethernet フレームの宛先 MAC を決定。
* **パケット構造**:

  * `HTYPE (16bit)` = 0x0001 (Ethernet)、`PTYPE (16bit)` = 0x0800 (IPv4)
  * `HLEN (8bit)` = 6, `PLEN (8bit)` = 4
  * `OPER (16bit)` = 0x0001: request, 0x0002: reply, 0x0003: RARP request, 0x0004: RARP reply
  * **Payload フィールド**: 送信者/宛先の MAC・IP の組み合わせが続く (合計28バイト)。
* **フレーム形式**: Ethernet Type = 0x0806、宛先 MAC = ff\:ff\:ff\:ff\:ff\:ff (request 時)
* **キャプチャ例 (tcpdump)**:

  ```bash
  $ sudo tcpdump -ennvvv arp
  12:00:01.123456 eth0 ff:ff:ff:ff:ff:ff > 00:11:22:33:44:55, ARP, Request who‑has 192.168.0.10 (Broadcast) tell 192.168.0.1, length 28
  ```
* **GC Algorithm**: 「送信トリガ」「受信時自動学習」「GARP」によりキャッシュを生成し、時間経過でエージング。

---

## 3. ARP キャッシュの挙動と OS 実装差

* **Linux**

  * デフォルト有効期限: `net.ipv4.neigh.default.base_reachable_time_ms` (30,000) × `random\_factor (0.75–1.25)` ≒ 22–37 秒。
  * 再試行インターバル: `retrans_time_ms` (1,000ms) を 3 回送信後 FAILED 状態。
  * `gc_thresh1/2/3` によりエントリ数が溢れると GC が発動。
* **Windows (10 以降)**

  * 未使用エントリ: 30 秒で削除。
  * 直近通信エントリ: 2 分。
  * REGEDIT: `ArpCacheLife`, `ArpRetryCount` で調整可能。
* **Cisco IOS**

  * `arp timeout` コマンド (秒単位) で VLAN 毎に設定。
  * CPU で処理するため高スループット時の **punt rate** に注意。
* **JunOS / Arista EOS** も同様に VRF またぎで個別に調整可能。
* **ポイント**: マイクロバースト的に ARP が増えると **CPU ポリシング**が無い機器はスロットルが発生し、全体通信が巻き添えで落ちる。

---

## 4. Gratuitous ARP (GARP)

* **定義**: 送信元と宛先 IP が同一の ARP Request/Reply を自身へ向けてブロードキャストし、周囲キャッシュを同期。
* **ユースケース**

  1. **フェイルオーバ**: VRRP/HSRP/GLBP がマスタ昇格時に `5 回 × 50ms` 間隔で送信。
  2. **IP 移設**: 仮想マシン Live Migration 後、自動で新 MAC を通知。
  3. **CAM 更新**: L2 スイッチのポートフラップ後にブラックホールを防止。
* **注意点**: 無差別に垂れ流すとセグメント規模に比例してストーム化しうるため、**DC 環境では EVPN ARP Suppression** を併用。

---

## 5. Proxy ARP の内部動作

* **仕組み**: ルータが同一サブネット内のホストになりすまし ARP Reply を返答→ホストはルータ MAC を登録。
* **典型シナリオ**

  * /24 サブネットを 2 台のルータで分割広告せず、クライアント側は CIDR を意識せずに通信可。
  * Legacy IoT デバイスが IP 設定を変えられない場合の延命策。
* **副作用**

  * ネットワーク境界が不透明になり、**ACL/FW ポリシング**が困難。
  * ルータ CPU へ L2 処理が集中し、DDoS の標的になりやすい。
  * トラフィックエンジニアリング不可: 必ず Proxy ARP ルータ経由となりイコライゼーションが効かない。
* **ベストプラクティス**: 近代 DC では **IRB + EVPN**(MAC/IP ルーティング) が主流で、Proxy ARP はレガシー移行期間に限定。

---

## 6. ARP スプーフィング／Poisoning 攻撃

### 6.1 攻撃フロー

1. 悪意端末 A がターゲット T と GW に対し **偽 ARP Reply** を無差別送信。
2. T の ARP キャッシュ: GW IP→A MAC に更新。
3. GW の ARP キャッシュ: T IP→A MAC に更新。
4. A は MITM の位置を獲得し、パケットをリレー or 改竄。

### 6.2 再現ラボ (Linux)

```bash
# ターゲット 192.168.0.20, GW 192.168.0.1
sudo arpspoof -i eth0 -t 192.168.0.20 192.168.0.1
sudo arpspoof -i eth0 -t 192.168.0.1 192.168.0.20
```

* **検証ポイント**: arp -n で MAC が悪意端末のものへ瞬時に書き換わる。

### 6.3 緩和策

* **DHCP Snooping + Dynamic ARP Inspection (DAI)**

  * Switch が DHCP Binding Table と照合し、IP↔MAC 不整合の ARP Reply をドロップ。
  * Cisco: `ip dhcp snooping`, `ip arp inspection vlan <VLAN>`。
* **静的 ARP**: `arp -s <IP> <MAC>` (小規模 Only) → メリット: 簡単 / デメリット: 運用負荷。
* **SEND (Secure Neighbor Discovery) は IPv6 のみ**だが、同等発想の **802.1X + NAC** で端末認可後に VLAN へステア。

---

## 7. ARP 応答制御とカーネルパラメータ

* **Linux**

  * `arp_ignore` (0–8): 応答の選択ポリシー。一般に 1 or 2 で **不要応答を抑制**。
  * `arp_announce` (0–2): 送信側アドレスの選択。2 は **最適インタフェースのみ広告**し、クロストークを防止。
  * 適用例: コンテナ/Kubernetes で **CNI ブリッジ**が多層化する場合、`arp_announce=2` が必須。
* **Windows**

  * `weakhostrecv/weakhostsend`: 0 で強ホスト、1 で弱ホスト。強ホストにすることで **IP 跨り応答**を阻止。
* **nftables での L2 フィルタ**

  ```bash
  table bridge arpfilter {
    chain prerouting {
      type filter hook prerouting priority -300;
      arp saddr set 0.0.0.0 drop # Gratuitous ARP Storm 緩和
    }
  }
  ```

---

## 8. トラブルシューティングの深掘り

* **キャプチャ Tips**

  * `tcpdump -i eth0 -nn -e -v arp or rarp` → HW Addr を必ず表示。
  * Wireshark で **"Duplicate IP address detected"** Expert Info をサーチ。
* **sysfs/Event Log**

  * Linux: `dmesg | grep -i arp` で **同一 IP 重複**時のカーネルメッセージ確認。
  * Windows: Event ID 4199 (duplicate IP) に着目。
* **再現テスト**

  * `arping -I eth0 -c 5 -A 192.168.0.5` (GARP)。周囲でキャッシュが即更新されるか観察。
  * **FAILED エントリ**: `ip -s neigh flush failed` で再解決を強制。

---

## 9. IPv6 への展開: Neighbor Discovery Protocol

* **ARP 非採用**: IPv6 は **ICMPv6 Neighbor Solicitation (NS)/Advertisement (NA)** に置換。
* **追加機能**

  * DAD (Duplicate Address Detection)
  * SLAAC (Stateless Address Autoconfiguration)
  * RA (Router Advertisement) による MTU 配布 & Prefix 情報
* **セキュリティ**: SEND (RFC 3971) + Cryptographically Generated Address (CGA) → 現実運用はハードル高／代替として **RA Guard, ND Inspection** がエンタープライズで普及。

---

## 10. モダンデータセンタと ARP 抑制

* **Overlay Network**

  * VXLAN/GENEVE では VTEP が ARP を **コントロールプレーン (BGP-EVPN)** へオフロード。
  * "ARP suppression" 機構: Spine ルータが **Type-5 (IP Prefix)** ルートとして広告→ ブロードキャスト削減。
* **キャンパス・Fabrics**

  * Cisco DNA Center, Juniper Apstra 等のファブリックは **Anycast GW** と EVPN を標準装備。
  * Host mobility が多くても GARP は Spine で吸収され、Leaf 間に氾濫しない。
* **クラウド (AWS)**

  * VPC 内は **AWS Hypervisor が ARP Proxy** を行い、エンドデバイスは他インスタンス MAC を知らない。
  * Security Group が L3/L4 レイヤで適用されるため、ARP スプーフィングは不可能。

---

## 11. Hands‑On: Linux ネットワーク名前空間で再現

1. **名前空間作成**

   ```bash
   ip netns add ns1; ip netns add ns2
   ip link add veth1 type veth peer name veth2
   ip link set veth1 netns ns1; ip link set veth2 netns ns2
   ip -n ns1 addr add 10.0.0.1/24 dev veth1; ip -n ns2 addr add 10.0.0.2/24 dev veth2
   ip -n ns1 link set veth1 up; ip -n ns2 link set veth2 up
   ```
2. **ARP 交換確認**

   ```bash
   ip netns exec ns1 ping -c1 10.0.0.2
   ip netns exec ns1 ip neigh show
   ```
3. **GARP 送信と反映**

   ```bash
   ip netns exec ns2 arping -A -c1 -I veth2 10.0.0.2
   ```
4. **nftables で ARP Block**

   ```bash
   ip netns exec ns1 nft add table bridge filter
   ip netns exec ns1 nft add chain bridge filter prerouting '{ type filter hook prerouting priority -300; }'
   ip netns exec ns1 nft add rule bridge filter prerouting arp op request drop
   ```

   → ns2 からの ARP Request がドロップされ、ping が失敗することを確認。

---

## 12. まとめと今後の展望

* ARP はシンプルゆえに **「放置されやすいレイヤ」** だが、障害・セキュリティ両面で高リスク。
* **OS 実装差 / ネットワーク規模 / マルチテナント要件** を踏まえてチューニングしなければ、大規模化に伴う制御プレーン輻輳が顕在化。
* 将来像としては

  1. **IPv6 NDP 完全移行**
  2. SDN/Fabric による **レイヤ2コントロールプレーンの集中管理**
  3. **ゼロトラスト**における L2-L3 動的認可連携
     が不可避。
* 本稿の検証コマンド／設定例を基に、読者各位の環境で **再現実験→パラメータ最適化→運用手順化** を進めていただきたい。

---