Linux 核心裡 IPv4 跟 IPv6 這兩個協定共用同一組 socket、routing、netfilter 骨架已經超過二十年。IPv6 從一開始就是後續加上去的，很多 helper 函式的預設路徑仍然是 IPv4，CONFIG_INET=y 這一開就把兩邊全部帶進來。Fernando Fernandez Mancera 在 2026 年 9 月遞出的 v2 patch series（net-next，13 個 patch）第一次讓 CONFIG_IPV4 從一個藏起來的 def_bool y 變成可以在 Kconfig 面板上關掉的 boolean。這條原本走了半年、被半開玩笑當成 April Fools 版本的路線，正式走進主線審核，IPv6-only kernel 的 build system 準備工作也算補完。
April Fools 之後真的有人接手做
回頭看時間軸。2026 年 4 月 1 日 David Woodhouse 在 kernel mailing list 寄了 6 個 patch，加了一個 CONFIG_LEGACY_IP 選項，還在 IPv4 socket 上開 warning，把 IPv4 標成「legacy IP」。日期挑得剛好，語氣半戲謔，社群反應普遍當成節日梗。但 Woodhouse 在自己 patch cover letter 裡就寫了：「我們確實應該把 CONFIG_INET 跟 CONFIG_IPV[64] 拆開，讓 kernel 可以只帶其中一邊 build。」
7 月 RFC 版本由 Fernando Fernandez Mancera 遞出，13 個 patch 的第一版，重點放在 build system 不再假設 IPv4 一定存在。9 月的 v2 進到 net-next，把 CONFIG_IPV4 從隱藏值變成可暴露的開關，同時保留 default y 免得踩到現有 config。這個順序是刻意的：先把耦合拆乾淨、再開放使用者關掉，不是一次跳到 IPv6-only。
差別在於 Fernandez Mancera 這條路徑的目標是可 merge 的實作，不是宣示立場。cover letter 明確列出目標場景：strict IPv6-only 部署、資源受限的 embedded、單一用途的 network appliance，理由是「移除 IPv4 子系統可以減少 network 的攻擊面」。這個框架比 Woodhouse 的「legacy IP」用詞冷靜很多，也是 net-next maintainer 願意收的原因。
13 個 patch 動了哪些邊界
技術上真正麻煩的部分是「歷史上 IPv4 跟 generic socket、transport 層綁在一起」。tcp、udp、raw、ping socket 的 hot path 都有 struct sockaddr_in 或 AF_INET 的直接引用，netfilter hook 的 default table 也預設有 IPv4 chain。要把 IPv4 抽掉，得先把這些依賴改成 conditional compilation。
patch series 幹的事分成幾類。一是 socket family 層級：inet_init 這條路徑改用 #ifdef CONFIG_IPV4 包起來，AF_INET 的 register 放進條件式。二是 transport 層：tcp_v4、udp_v4、raw_v4 這幾個檔案整個變成 optional 編譯。三是 driver：drivers/net/ 底下一堆 driver 對 IPv4 有 hard dependency，特別是 tunnel driver 的 IPv4 encap、netfilter connection tracking helper。這些改成 conditional 之後，關掉 IPv4 的 kernel image 才 build 得起來。四是 socket API 的錯誤路徑：使用者 space 呼叫 socket(AF_INET, ...) 得回 -EAFNOSUPPORT，而不是 crash。
系列裡有一支 patch 專門處理 AF_INET6 的 IPv4-mapped 位址（::ffff:0:0/96）行為。IPv6 socket 預設可以接 IPv4 連線，這個相容機制在 IPv6-only 模式下沒意義，patch 把它跟 CONFIG_IPV4 綁在一起 disable，同時修 net.ipv6.bindv6only 相關預設值。
對 VPS operator 的實際意義
短期內把 CONFIG_IPV4=n 打進 production kernel 是不切實際的。理由不是 kernel patch 沒收進來，是使用者 space 還沒準備好。glibc 的 getaddrinfo、systemd-networkd、Docker 的 bridge network、大量 daemon 的預設 config 都預期 IPv4 stack 存在。強行關掉，開機第一秒就會有一堆 warning 或直接跳 error。
真正合適的候選是三類機器。第一是專用 NAT64 gateway：這種機器本身跑 Jool 或 Tayga 做協定翻譯，對外只需要 IPv6 交握，IPv4 stack 純屬冗餘。第二是 DNS resolver 或監控 collector 這類單一用途 appliance：協定行為受控、上下游都可以指定，關掉 IPv4 之後 kernel image 也能小上百 KB 到數 MB。第三是 immutable image 走的 edge instance：build 一次跑很久，把不用的協定編譯掉本來就是常態。
一般 VPS operator 目前該做的不是關 CONFIG_IPV4，而是理解 kernel 在往哪個方向走。這條路徑會 merge，未來三到五個 kernel 版本會陸續把還沒拆乾淨的角落補完，distro maintainer 也會跟進提供 IPv6-only kernel variant。這時候「IPv6-only 部署到底能不能走」這個問題會從「服務端能不能扛」變成「上游能不能通」，重心整個換掉。
上游生態才是真正的瓶頸
kernel 這條線走通之後，實際部署的難點集中在使用者 space 跟外部服務。Hacker News 那串討論裡最常被拿出來抱怨的是三件事：GitHub 到 2026 年還沒有原生 IPv6 endpoint、AWS 的很多 managed service 仍然只走 IPv4、Docker 跟 containerd 的 IPv6-only 模式常常在 network policy 或 registry pull 時出狀況。
這三個痛點對應到不同的補救方案。GitHub 這類外部服務只能靠 NAT64。Jool 走 kernel module 路徑，stateful 模式效能吃得住 gigabit 等級流量，比 userspace 的 Tayga 快非常多，這是目前 Linux 上做 NAT64 的預設選擇。搭配 DNS64（Unbound 或 BIND 都內建）把 A record 合成 AAAA，IPv6-only client 就能透明存取 IPv4 origin。
AWS 這類 cloud provider 的 IPv4 dependency 得靠 464XLAT 補。CLAT 裝在 IPv6-only VPS 上，把 application 發出的 IPv4 packet 就地翻成 IPv6，往 PLAT（也就是 NAT64 gateway）送。這條路徑 RFC 6877 已經寫了十年，clatd 這類 daemon 也成熟，但很多人第一次部署會忘記 DNS64 跟 CLAT 得分工——CLAT 只處理 application 直接送 IPv4 literal 的情況，其他都靠 DNS64 走。
Docker 這邊 2026 年狀況比兩年前好，--ipv6 加上 IPv6 subnet allocation 可以跑 bridge 網路，但 Docker Hub 的 registry endpoint 仍然沒有穩定的 IPv6 AAAA，pull image 這步驟繞不開 NAT64。實務上把 registry mirror 架成 IPv6-native 的 caching proxy 是最省事的辦法。
過渡期比較實用的三個中間態
不是每個環境都適合一次跳到 IPv6-only。IETF RFC 8925 的 DHCP option 108「IPv6-only preferred」提供了明確的中間路徑：client 支援 IPv6-only 時主動放棄 IPv4，不支援時仍然收到 IPv4 lease。Fedora 從 42 開始 NetworkManager 預設處理 option 108，Ubuntu 24.10 之後也跟上。
三個中間態值得規劃。「Dual-stack + prefer IPv6」：所有服務同時 listen 兩邊，client 選 IPv6，這是最保守的過渡。「IPv6-mostly」：client 收 option 108 時走 IPv6-only，legacy client 保留 IPv4 lease，NAT64 在網路邊緣。「IPv6-only + 464XLAT」：整個網段沒有 IPv4 DHCP，靠 CLAT 補相容性。三種都是可跑的生產模式，第二種對臺灣 ISP 環境目前最務實——用戶端狀況混雜，強制 IPv6-only 太激進。
CONFIG_IPV4=n 這件事的時間表可以這樣估：kernel 端 6 到 12 個月內把 API 拆乾淨、distro 端 12 到 24 個月內出 IPv6-only kernel variant、使用者 space 大概還要三年才能像現在的 IPv4 一樣「開箱能用」。IPv6-only 部署在這個時間軸上會從「先驅嘗鮮」變成「有明確場景可推」，NAT64 gateway、DNS64 resolver、464XLAT CLAT 這幾個角色會被大量部署。
要驗這條路徑，得先有完整的 IPv6 位址池
要驗過 NAT64 gateway、跑 464XLAT，或者實作 IPv6-only VPS 加 CLAT 的完整鏈路，都需要真的能取得完整的 IPv6 位址池，不是拿到一個 /64 就完事。NCSE Network 的 IP Transit 服務直接分派完整的 IPv6 prefix，VPS 服務跑在臺灣是方電訊機房、雙棧原生支援，可以直接開 Jool 或 clatd 測試。想了解 IPv6 網段規劃、AS 對接或 VPS 相關方案細節，可以到 ncse.tw 查看。
