告別 ARP，迎向IPv6-Only 架構下的 IPv4 服務化
IPv6-Only (IPv6-only) 網路環境在實務上往往仍高度依賴 IPv4 子網域與 ARP 協定。本文將介紹一項 IETF 提案，旨在徹底消除這兩項依賴，讓 IPv4 得以在IPv6-Only 基礎架構上以「服務」形式運作，且完全不需進行位址轉換 (Translation) 或建立隧道 (Tunnelling)。
本文源自布加勒斯特 RIPE 91 大會上一場題為「A Farewell to ARPs」的短講。現場熱烈反應與會後討論，證明這是網路維運社群極具共鳴的痛點。
隨之催生的網際網路草案 draft-vanmook-intarea-ipv6-resolved-gateway 目前已推進至第三版，正由 IETF IntArea 工作小組審議。預計於維也納 IETF 126 大會進行簡報，並在會後發布採納呼籲 (Adoption call)。本文將帶您了解此提案的背景，以及網路營運商為何該密切關注。
IPv6-Only 架構，卻仍留 IPv4
對多數網路營運商而言，IPv6-Only 架構早已落實。路由協定、位址空間及周邊工具皆已成熟，許多資料中心與存取網路也早已在控制平面 (Control plane) 採IPv6-Only 運作。
然而，幾乎所有這類網路都還背負著 1982 年代的歷史包袱：平行的 IPv4 架構。並非 IPv6 無法勝任，而是上層的應用程式、設備與舊系統仍預期 IPv4 存在。這導致網路團隊在建構了乾淨的IPv6-Only 架構後，卻得永遠維護並行的 IPv4 子網域、閘道器位址與 ARP。
雙協定架構 (Dual-stack) 的隱藏成本
雙協定架構不僅有管理兩套位址與防火牆規則的表面成本，更潛藏嚴重的維運負擔：
- ARP 維運負擔：ARP 是針對數十台主機設計的區域網路 (LAN) 廣播協定。在現代架構中，它是引發 ARP 風暴、快取中毒、L2 網段表格耗盡及故障轉移問題的源頭。在極端情況下，一萬台虛擬機器甚至能輕易產生每秒高達 50 萬次的 ARP 請求。
- 位址經濟成本：IPv4 位址在次級市場要價高昂。傳統 IPv4 子網域會在網路、廣播和閘道器上浪費位址，例如 /30 連線就浪費了一半。透過新機制，主機只需要唯一一個 /32 的 IPv4 位址即可。
- 子網域無序擴張：每個 IPv4 網段都需經歷分配、記錄與路由設定。將 IPv4 作為純 /32 服務承載於 IPv6 上，營運商只需管理主機位址本身。
- 資安態勢：一個 /24 網段會提供攻擊者 254 個可透過 ARP 掃描的目標；全為 /32 且無 ARP 的網路，則徹底消除了可被掃描的子網域空間。
已經在正式環境中解決——但做法並不理想
對標準制定社群最尷尬的是，大型主機代管商 (Hosting providers) 早已在大規模生產環境中解決了這項難題，但因缺乏標準而導致各家做法無法互通。
若您曾在 Hetzner、OVHcloud 或 Scaleway 供裝伺服器，會發現伺服器會取得一個 /32 位址 (或明顯不在前綴內的閘道器)，並要求透過特定作業系統指令才能連線：
- Hetzner: routes: [ to: 0.0.0.0/0, via: 172.31.1.1, on-link: true ]
- OVHCloud: post-up route add <x.y.z.254> dev eth0
- Scaleway: iface eth0 inet static ... pointopoint 62.210.0.1
三家業者使用了三種不同的閘道器位址與設定法，目的都是強迫主機透過 ARP 去尋找不在其子網域上的閘道器。這完全未記錄於任何 RFC 中，每家自創的配置配方，正是 IETF 急需解決的互通性災難。
為什麼不直接修改 DHCP？
為何不直接定義一個帶有 IPv6 Next-hop (下一跳) 的新 DHCPv4 選項？因為 DHCP 選項容易改，難的是周邊龐大的生態系統。
每一個 IPAM、供裝系統、計費平台與監控工具都已將「四個八位元」的 IPv4 閘道器格式深植於驗證邏輯中。改變這個資料格式，是需耗時數十年的業界大工程。因此，最好的解法是：不改變它的形狀，而是改變它的意義。
運作機制：單一標記值 (Sentinel Value)
本草案定義了一個特殊用途的 IPv4 位址——192.0.0.11——作為標記值。DHCPv4 伺服器會將其作為普通路由器選項 (Option 3) 發放。全球的 DHCP 中繼站、IPAM 都能無縫處理它。
真正的變革在主機端。更新後的主機網路堆疊會辨識出這個標記值，不發送 ARP 請求，而是直接從其 IPv6 鄰居快取 (Neighbour cache) 中提取 MAC 位址（這些資訊早已透過常規的 IPv6 路由器通告與鄰居探索學習而來）。IPv4 封包會直接封裝入鏈路層影格發向路由器 MAC。
全程為原生 IPv4 端到端傳輸，完全摒棄了 ARP、子網域、隧道或封包轉換。更關鍵的是，未更新的主機會像往常一樣對 192.0.0.11 發出 ARP 請求，路由器則回覆自己的 MAC。新舊主機可無限期共存，沒有「強制切換日」，營運商可自行決定何時全面關閉 ARP。
在路由器端，此機制完美銜接 RFC 8950 以及即將成為標準的 draft-ietf-intarea-v4-via-v6，共同構成服務雙協定終端的單一協定堆疊架構。至此，IPv4 回歸純粹的服務端點識別碼，並承載於 IPv6 傳輸層之上。
額外紅利：單一通用閘道器位址
此方案還帶來一項意外紅利：各家代管商各自為政的閘道器位址，將收斂為統一的 192.0.0.11。一份伺服器映像檔或供裝範本，未來在不同供應商間皆可通用。
資安防護也隨之提升。此位址不具備子網域資訊、不可轉發且無法作為有效來源位址，因此無法從外部鏈路觸及，從根本上消除了遠端攻擊與巨量流量濫用風險。如同 IPv6 使用鏈路本地位址 (fe80::1) 作為下一跳一樣，沒人會質疑它是否在正確的子網域上，192.0.0.11 為 IPv4 賦予了同等優勢。
可運作的程式碼
目前 GitHub 上已提供 Linux 參考實作 (github.com/remcovanmook/v4-with-v6-nh)，包含主機解析邏輯與 OSPFv3 配置，且無需修改系統核心 (Kernel)。
退場機制同樣經過驗證：在路由器回應 ARP 的模式下，Windows 11、macOS、Android、iOS 等各大系統均無需修改系統或 DHCPv4 設定即可無縫連線。
目前進展與您可以提供的協助
該草案目前處於 IETF IntArea 工作小組第 -01 修訂版，並已獲得 David Lamparter 等資深社群專家的強力支持。提案人將於維也納 IETF 126 大會進行簡報，後續可望進入正式的採納呼籲階段。
IETF 的標準採納高度仰賴實際的營運需求。若消除 ARP 與 IPv4 子網域能解決您的維運痛點，請發送簡短電郵至 int-area@ietf.org 表達支持；若您將出席 IETF 126，也歡迎參與 IntArea 議程。
IPv4 網際網路短期內不會消失，但承載 IPv4 的基礎架構，真的已經不再需要依賴雙協定架構了。
本文為作者個人想法，不代表TWNIC之立場，若對此內容有興趣，請參閱原文：
https://labs.ripe.net/author/remco-van-mook/a-farewell-to-arps-ipv4-service-on-ipv6-only-networks/