# EVPNにおけるProxy ARP/ND ## 定義 Proxy ARP/ND は、[[EVPN]] の PE(Provider Edge)が CE(Customer Edge)からの ARP Request / Neighbor Solicitation(NS)を代理応答することで、ブロードキャストドメイン(BD)内のアドレス解決フラッディングを削減・抑制する機能である。RFC 9161 が RFC 7432 を更新する形で運用面を包括的に規定する。PE は動的(dynamic、CE の ARP/NA メッセージのスヌープによる学習)・静的(static、管理システムからのプロビジョニング)・EVPN学習(EVPN-learned、遠隔 PE からの RT2 受信による学習)の3種類の IP→MAC エントリを持つ Proxy テーブルを BD ごとに構築し、CE からの ARP Request/NS に対してテーブルの当たりがあれば代理応答し、EVPN ネットワークや他のローカル CE へのフラッディングを回避する。(Source: [[@2022__IETF__RFC 9161 - Operational Aspects of Proxy ARP-ND in Ethernet Virtual Private Networks]] 本文§1, §3) ## 6つのサブ機能 Proxy ARP/ND 機能は Learning・Reply・Unicast-Forward・Maintenance・Flood Handling・Duplicate IP Detection の6つのサブ機能に構造化される。実装は少なくとも Learning・Reply・Maintenance・重複IP検知を MUST でサポートする。 - **Learning**: IPv4 は ARP パケット全般(Ethertype 0x0806)を、IPv6 は NA メッセージ(NS ではない、R Flag を含まないため)をスヌープして動的エントリを学習する。 - **Reply**: 同一アタッチメント回線上からの要求には応答しない(要求元と要求先が直接通信できるため)。ブロードキャスト/マルチキャストの要求(ARP Request・ARP probe・NS・DAD NS)には応答し、ユニキャスト要求(NUD NS 等)には応答しない。 - **Unicast-Forward**: テーブルヒット時に応答する代わりに、MAC の所有者へユニキャスト転送するオプション。"always" と "unknown-options" の2パラメータで制御する。 - **Maintenance**: Age-time による動的エントリのフラッシュと、Send-refresh オプションによる定期プローブでの延命を規定する。EVPN の RT2 撤回を不要な形で発生させないための仕組みでもある。 - **Flood Handling**: 未知の ARP Request/NS・GARP/unsolicited-NA を遠隔 PE へフラッディングするか個別に抑制するかを、運用者が選択できる。 - **Duplicate IP Detection**: 下記参照。 (Source: 本文§3.1–§3.6) ## 重複IP検知(Duplicate IP Detection)とAS-MAC Proxy ARP/ND は MUST で重複IP検知をサポートする。既存の RFC 6957(IPv6 Duplicate Address Detection Proxy)が point-to-multipoint かつ split-horizon 前提であり CE 間の直接通信がないネットワークを想定するのに対し、本手続きは CE 間が直接通信可能な EVPN BD にも適用できる形で新規に定義される。 手続きは、既存エントリの MAC 変更を検知すると M秒タイマー(既定180秒)を起動し、タイマー内に N回(既定5回)の IP 移動を検知すると重複と判定する。より早期の検知のため、PE は旧所有者へユニキャストの Confirm メッセージを送り、既定30秒以内に応答がなければ新エントリを確定する。重複検知後は当該エントリの更新を凍結し操作者へ警告するとともに、任意で全 PE 共通の管理された MAC アドレスである AS-MAC(anti-spoofing MAC)を紐付けて GARP/RT2 で周知し、スプーファーへのトラフィック誘導を防ぐ。静的エントリ(ARP/ND Extended Community の Immutable Flag I=1)はこの手続きの対象外であり、動的エントリで上書きされない。(Source: 本文§3.7) ## IPv6 "anycast"能力とのトレードオフ Proxy ND は、NA メッセージの O Flag(Override Flag)が 0 の場合は原則としてエントリを学習しないが、BD で IPv6 "anycast" 能力が明示的に有効化されている場合は例外的に学習し、同一 IP に複数の MAC が共存することを許容する(分散エニーキャストゲートウェイ用途)。この場合、重複IP検知は必ず無効化しなければならない——複数 MAC の共存を検知の観点では「重複」と区別できないためである。DC でエニーキャストゲートウェイを使う要件と、スプーフィング対策としての重複IP検知は、この機能内では同時に有効化できない構造的トレードオフの関係にある。(Source: 本文§3.2.1, §3.7) ## 展開シナリオとIXP/DCでの選好の違い 4つの展開シナリオ(全動的学習・動的学習+Proxy ARP/ND・ハイブリッド・全静的プロビジョニング)が定義され、IXP と DC で選好が異なる。IXP のピアリング参加者は数百台規模でも既知かつ静的であるため、ポートセキュリティ(MAC アドレスの allowlist 管理と顧客ライフサイクル)と組み合わせた「全静的プロビジョニング」が主流になる。DC は仮想マシンのモビリティ要件から動的学習寄りのモデルが適する。この選好の違いは、[[EVPN]] ページが記録する Clos Network の設計原則(スケーラビリティ vs GPU 基盤での前提反転)とは異なる軸だが、同じ「運用文脈が RFC の想定する複数モードのどれを選ぶかを決める」という構図を持つ。(Source: 本文§5, §5.5, §5.6) ## 横断的知見 - **RFC 7432 の MAC Mobility 重複検知(M=180秒・N=5回)と本文書の重複IP検知は、同じパラメータ値・同じ「M秒内にN回」という検知アルゴリズムの骨格を、MAC アドレス版(RFC 7432)から IP アドレス版(RFC 9161)へそのまま転用したものである**。[[EVPN]] ページが記録する RFC 7432 の MAC Mobility 拡張コミュニティ(シーケンス番号による移動検知、既定 M=180秒・N=5回)と、本ページの重複IP検知(既定 M=180秒・N=5回)は、検知対象(MAC vs IP)こそ違うが、閾値ベースで「移動」と「攻撃/重複」を区別する設計思想と既定値を完全に共有する。EVPN の設計者は、同じ検知アルゴリズムの骨格を EVPN の複数レイヤー(L2 の MAC 到達性、L3/ARP の IP→MAC 束縛)へ繰り返し適用している。(Source: [[@2022__IETF__RFC 9161 - Operational Aspects of Proxy ARP-ND in Ethernet Virtual Private Networks]] 本文§3.7, [[@2015__RFC__BGP MPLS-Based Ethernet VPN]]) ## 未解決の問い - ARP/ND Extended Community(RFC 9047)自体は本 wiki に未 ingest であり、R/O Flag の EVPN 上での正確なビットエンコーディングは未確認。 - IXP における「全静的プロビジョニング」運用が、顧客数が数千規模までスケールした際に管理システム側の運用コスト(手動プロビジョニングの負荷)としてどう現れるかは、本文書には定量的な記述がない。 ## 関連 - 概念: [[EVPN]](本機能が更新する基礎仕様。MAC Mobility の重複検知アルゴリズムを共有) / [[MPLS]] - 実体: [[Jorge Rabadan]] / [[Nokia]] / [[IETF]] ## 出典 - [[@2022__IETF__RFC 9161 - Operational Aspects of Proxy ARP-ND in Ethernet Virtual Private Networks]](RFC 9161、全文)