IPv4 進入“付費時代”

去年的 7 月，Amazon Web Services 宣布自 2024 年 2 月 1 日 起，所有公有 IPv4 將按 $0.005/小時（約 $4/月）計費，無論是否綁定到具體服務(wù)；

容器化部署平臺 Fly.io 隨后也在社區(qū)公告中更新：2 月 1 日后，每個專用 IPv4 約 $2/月；

開源數(shù)據(jù)處理與后端平臺 Supabase 計劃推出 IPv4 付費附加包，**$4/月**。

隨著時間逼近，關(guān)于「IPv4 付費、向 IPv6 遷移」的討論驟然升溫。

近期，Supabase 聯(lián)合創(chuàng)始人兼 CEO Paul Copplestone 發(fā)起號召：“準(zhǔn)備好，IPv6 要來了。”然而，由于 IPv4/IPv6 首部差異巨大、互不兼容，升級之路困難重重。即便一些開發(fā)者嘗試上手，結(jié)論卻是：“IPv6 很糟糕”——至少在當(dāng)前生態(tài)與工具鏈支持不足的情況下如此。

1.全球 IPv4 余量見底，IPv6 走到聚光燈下

隨著互聯(lián)網(wǎng)終端迅猛增長，RIPE NCC（負(fù)責(zé)英國、歐洲、中東及部分中亞的互聯(lián)網(wǎng)資源分配）在 2019 年 11 月 25 日 15:35（UTC+1） 宣布：最后的 IPv4 地址儲備池已耗盡。全球 約 42 億 個 IPv4 地址已全部分配。

自此之后，想繼續(xù)使用公有 IPv4 的用戶，主要依賴回收與再分配：來源要么是已注銷的機構(gòu)，要么是完成 IPv6 遷移而釋放出來的地址段。

獲取成本隨稀缺性自然攀升。AWS 曾披露：過去五年中，單個公有 IPv4 的收購成本上漲超過 300%——難找又昂貴。 因此，多家云廠商開始按地址收費，一方面倒逼用戶提高使用效率，另一方面也推動行業(yè)轉(zhuǎn)向 IPv6。

Paul Copplestone 指出：“**$4/月** 對個人看似不多，但 AWS 是很多基礎(chǔ)設(shè)施公司的底層。以 Supabase 為例，我們?yōu)槊總€ Postgres 數(shù)據(jù)庫提供獨立 EC2 實例，這項變更會讓我們的 AWS 賬單增加到百萬級?！?/span>

也有分析認(rèn)為：大型 AWS 客戶可能幾乎感覺不到這筆錢；但中小企業(yè)與初創(chuàng)團隊則不然，這筆費用**很容易占到總賬單的 10%–30%**。

2.三條應(yīng)對路徑

面對新增成本，企業(yè)如何盡量降低支出？Paul Copplestone 給出了 三種選擇：

• 把成本轉(zhuǎn)嫁給客戶：與 AWS、Fly.io 的做法類似，調(diào)整定價，將租用/購入 IPv4 的開銷體現(xiàn)在產(chǎn)品價格中。以單個 IPv4 為例，**43.80/年**。
• 提供替代方案（如代理/NAT）：比如提供 IPv4 代理，通過代理將 IPv6 流量映射到 IPv4 資源；或利用 NAT 提高 IPv4 地址利用率——一地址多端口區(qū)分不同服務(wù)/用戶。
• 只提供 IPv6：寄希望于生態(tài)盡快跟上、用戶端與鏈路端快速適配。

3.IPv6 推廣的核心難題

從長期看，“僅 IPv6” 最干脆、也最能從根上緩解地址稀缺。IPv6 作為繼任者，對移動設(shè)備支持更好、地址分配靈活、首部更簡化、安全性也有所提升。

尤其是地址空間：IPv6 約 3.4×103? 個地址——常被打趣為“每一粒沙子都能分到一個地址”。與 IPv4 相比，規(guī)模天差地別，足以覆蓋面向未來的連接增長。

然而，現(xiàn)實有點“骨感”。據(jù) Google 統(tǒng)計，截至 2024 年 1 月 15 日，**IPv6 使用占比僅 41.23%**，距離過半仍有差距。

Paul 將原因主要歸結(jié)為兩點：

• ISP（運營商）支持不足；
• 工具鏈支持欠缺。

4.運營商支持不充分

“你的寬帶/移動運營商支持 IPv6 嗎？”

在域名解析層面，傳統(tǒng)上域名會解析到 IPv4：example.com → 93.184.216.34而轉(zhuǎn)向 IPv6 后，則會解析到 IPv6：example.com → 2607:f8b0:4006:819::200e。

ISP 需要把流量路由到正確目的地。但許多運營商尚未準(zhǔn)備充分：交換機/軟件需升級、IPv4/IPv6 互通要打通，這些都意味著投入，而在過去十年里，投入的性價比并未被廣泛認(rèn)可。

如果 ISP 不支持 IPv6，當(dāng)域名/服務(wù)開始優(yōu)先解析 IPv6 時，可能出現(xiàn)如下影響與報錯：

• 在 AWS 上架了 Web 服務(wù)器，卻無法通過 SSH 連接；
• 從本地直連 Supabase 數(shù)據(jù)庫時，需要用連接池來回落至 IPv4（供應(yīng)商要為這些 IPv4 買單）；
• 從 Vercel 連接到任一 AWS 服務(wù)器，若未配置 IPv4，連接會迅速失敗。

5.工具鏈支持缺位

不少開發(fā)工具尚未對 IPv6 做好準(zhǔn)備。以 Supabase 為例，想讓數(shù)據(jù)團隊的工具鏈 完整支持 IPv6，需要逐步改造：

• VPC 網(wǎng)絡(luò) 增加 IPv6；
• Airflow 虛機 增加 IPv6；
• Docker 與 Compose 開啟 IPv6。

看似幾步，但實際落地并不省心。以 Docker 為例，常見流程：

• 修改 /etc/docker/daemon.json：

"ipv6": true,
"fixed-cidr-v6": "fd00:ffff::/80",
"ip6tables": true,
"experimental": true

• 重啟 Docker：systemctl restart docker
• 建臨時 IPv6 網(wǎng)絡(luò)并測試：

docker network create --ipv6 --subnet fd00:ffff::/80 ip6net
docker run --rm -it --network ip6net busybox ping6 google.com -c3

• 檢查 ip6tables（FORWARD）：ip6tables -L
• 在 Compose 中開啟 IPv6：

networks:
  default:
    enable_ipv6: true
    ipam:
      config:
        - subnet: fd00:c16a:601e::/80
          gateway: fd00:c16a:601e::1

• 進入容器驗證：

docker exec -it "airflow_airflow-worker_1" bash
curl -6 https://ifconfig.co/ip

對于如 Docker 這類“標(biāo)配工具”，這套配置仍顯復(fù)雜且易踩坑。

6.邁向 IPv6：現(xiàn)實處處是坎

在實操層面，DevOps 工程師 Mathew Duggan 的經(jīng)歷頗具代表性：

“幾乎沒有任何東西能 out-of-the-box 地直接跑起來。關(guān)鍵依賴立刻失效，臨時方案也不足以支撐生產(chǎn)。我們之所以如此艱難，是因為做這件事的人太少、經(jīng)驗稀缺；多年沒做，現(xiàn)在只能補課?！?/span>

他嘗試將個人博客（https://matduggan.com/ipv6-is-a-disaster-and-its-our-fault/）接入 IPv6，并用 CDN 管理 IPv4 流量。

“起步看起來很簡單。我在 Debian 上選了 ‘IPv6’，結(jié)果第一個驚喜是：設(shè)備沒有拿到單個 IPv6 地址，而是拿到一個 /64（18,446,744,073,709,551,616）。好消息是：我這臺小小的 ARM 服務(wù)器，理論上能跑下我工作過的所有公司的公網(wǎng)網(wǎng)絡(luò)基礎(chǔ)設(shè)施?！?/span>

但把它當(dāng)“常規(guī)服務(wù)器”來配，很快就遇到一串問題。

問題 1：SSH 登不上由于工作/家庭 ISP 不支持 IPv6，他不得不先掛上 IPv4，用 SSH 登進去，再用 Cloudflared 跑隧道。 然而 Cloudflare 默認(rèn)并不會自動做雙棧轉(zhuǎn)換；去掉 IPv4 后，隧道直接崩。 他只好修改 systemd 服務(wù)配置，給 Cloudflared 增加 --edge-ip-version 6，隧道才正常，SSH 也恢復(fù)可用。

問題 2：GitHub 用不了

他執(zhí)行服務(wù)器初始化腳本時，腳本需要從 GitHub 拉取 hishtory 的安裝文件，卻一直失敗。 “這不可能吧，GitHub 總該支持 IPv6 吧？” 現(xiàn)實是——GitHub 仍未對外提供完整的 IPv6 支持。 他轉(zhuǎn)而使用 TransIP Github proxy 才繞過去；但隨后 Python 又報 urllib.error.URLError: <urlopen error [Errno 101] Network is unreachable>。

“算了吧，估計 Debian 上的 Python 3 對 IPv6 有點挑，我現(xiàn)在不想再深挖了。”

問題 3：Datadog 裝不起來接著他安裝 Datadog 做監(jiān)控：登錄、操作，系統(tǒng)立刻崩潰。 他用的是：curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh。既然 S3 已支持 IPv6，那問題在哪？ 排查后，確認(rèn)既不是 S3 也不是服務(wù)器，因為 AWS 的 S3 連通性測試一切正常。最后他只能通過 apt 手工修復(fù)。 此時他意識到：純 IPv6 的道路不現(xiàn)實；沒有代理與額外“打補丁”，幾乎什么都跑不順。 后來，為了讓 IPv6 端能訪問 IPv4 資源，他接入了 NAT64（https://nat64.net/）做過渡。

此外，他搜羅的一些輔助工具幾乎都年久失修：Dresel 列表里的若干鏈接不可用；Trex 測試有問題；August Internet 直接“消失”；多數(shù) Go5lab 測試設(shè)備離線；Tuxis 能用但貌似自 2019 年 上線后幾乎沒再升級；Kasper Dupont 的服務(wù)則仍在維持。

7.IPv6 普及：任重而道遠(yuǎn)

雖然時間節(jié)點已到，但大量基礎(chǔ)設(shè)施與軟件仍未為 IPv6 做好準(zhǔn)備。 對于數(shù)字從業(yè)者而言，培訓(xùn)與演練會是一項長期投入。

不少開發(fā)者表達(dá)了相同的挫敗感，HN 用戶的聲音頗具代表性：

“我至今還在抱怨：IPv6 設(shè)計為何不向下兼容 IPv4。IPv6 的技術(shù)設(shè)計確實先進，但缺乏兼容性讓遷移變得異常艱難。設(shè)計者或許以為過渡只需幾年，可已近 30 年……我們?nèi)岳г谶@里?！?/span>

“在 IPv6 未成為一等公民 之前，它并不能真正解決地址枯竭；只有當(dāng)我們不再依賴 IPv4 時，這個問題才算畫上句號。”

“如果不遷 IPv6，繼續(xù)抱著 IPv4，不僅無法滿足增長需求，還會引發(fā)性能下滑與服務(wù)不穩(wěn)定。很多組織被迫用 NAT 分享有限 IPv4，這加大了網(wǎng)絡(luò)管理復(fù)雜度，也可能限制某些應(yīng)用/服務(wù)的功能?！?/span>

正因如此，越來越多的組織加入了 IPv6 遷移 的隊伍——盡管路途崎嶇。

總結(jié)

• 短期成本：IPv4 計費已成定局，預(yù)算應(yīng)單列并量化到服務(wù)維度；
• 中期策略：優(yōu)先落實 NAT/代理 與 雙棧過渡，對外暴露盡量少量 IPv4 + 統(tǒng)一代理出口；
• 長期方向：分階段推進 純 IPv6 能力（VPC、容器網(wǎng)絡(luò)、CI/CD、監(jiān)控/日志），建立遷移檢查清單與回退預(yù)案；
• 工具與依賴：對關(guān)鍵第三方（GitHub、監(jiān)控、對象存儲、CDN）逐一驗證 IPv6 連通性 與 客戶端支持，必要時準(zhǔn)備 NAT64 / 代理 方案；
• 運營商協(xié)同：與 ISP 明確升級時間表與互通方案，避免解析策略調(diào)整后鏈路斷檔；
• 可觀測性建設(shè)：在過渡期提升對 DNS 解析、雙棧握手、連接失敗 的觀測與告警，縮短故障定位時間。

就現(xiàn)在而言，“能跑、穩(wěn)跑” 仍需依賴雙棧與過渡技術(shù)；而 “全棧 IPv6” 則是一個必須投入、但需要耐心的系統(tǒng)工程。當(dāng)生態(tài)真正補齊，IPv6 的價值才會被充分釋放。