編譯 | 蘇宓
出品 | CSDN（ID：CSDNnews）
IPv4 即將迎來付費時代：
去年 7 月，亞馬遜云科技宣布自 2024 年 2 月 1 日起，所有公共 IPv4 地址將按每小時 0.005 美元的價格收費，約合每月 4 美元，而且無論其是否附加到服務中，都要收費；
基于容器的部署平臺 Fly.io 也在不久前更新社區公告，稱會在 2 月 1 日之后，對每個專用 IPv4 每月收取約 2 美元的費用；
開源數據處理服務平臺 Supabase 計劃推出一個 IPv4 的付費附加服務，每月費用為 4 美元。
隨著時間一天天臨近，圍繞「IPv4 收費，遷移到 IPv6」的討論愈發激烈。
近日，開源數據處理服務平臺 Supabase CEO 兼聯合創始人 Paul Copplestone 也發起一則關于“做好準備，IPv6 即將到來”的呼吁。然而，由于 IPv4 訊息和 IPv6 訊息標頭有很大不同，因此這兩種協議無法互操作，同時升級到 IPv6 之路也面臨多重挑戰，甚至在有開發者進行了嘗試使用，最終得出一個結論：IPv6 是一場“災難”，我們未來雖可以解決困難，但目前準備仍然不足。
全球 IPv4 地址消耗殆盡，升級到 IPv6 提上日程
眾所周知，隨著互聯網的不斷發展，設備的數量急劇增加，導致 2019 年負責英國、歐洲、中東和部分中亞地區互聯網資源分配的歐洲網絡協調中心（RIPE NCC）無奈宣布，其最后的 IPv4 地址空間儲備池在 2019 年 11 月 25 日 UTC + 1 15:35 完全耗盡，全球 42 億個 IPv4 地址已分配完畢。
耗盡之后，對于想要繼續使用公共 IPv4 地址的用戶而言，他們主要靠回收和未使用地址段的釋放才能用上 IPv4，其中這些地址要么來自倒閉的組織，要么來自于那些已經遷移到 IPv6 時不再需要的地址。
不難想象，獲取日益稀缺的 IPv4 中間過程變得復雜，成本自然而然漲起來了。
此前，亞馬遜云科技也曾透露過，在過去五年中，由于難以獲得公共 IPv4 地址，單個地址的獲取成本上漲了 300% 以上。
所以正如文章伊始所述，各大公司不得不采取收費政策，一方面為了鼓勵大家在使用公共 IPv4 地址時更加節儉，另一方面，想要借此推動行業內采用 IPv6。
Paul Copplestone 表示，“雖然亞馬遜云科技每月收取約 4 美元，對個人來說相對較少，但我的假設是，AWS 是許多基礎設施公司（如 Supabase）的基礎層——我們為每個 Postgres 數據庫提供完整的 EC2 實例，因此這將使我們的 AWS 賬單增加數百萬美元。”
也有一些分析師表示，對于任何規模的 AWS 客戶來說，這些費用都可以忽略不計，他們也許都不會在自己的賬單上注意到這筆新增的支出。然而，對于許多中小企業和初創企業來說，這筆費用很容易就占到賬單的 10-30%。
三種選擇
那么在避不開這筆費用時，公司又有什么樣的方法來盡可能地減少支出？
對此，Paul Copplestone 分享了 AWS 上的基礎設施公司的三種選擇：
將成本轉嫁給客戶頭上。這一點其實很好理解，就如 AWS、Fly.io 所做的，當涉及到租用或者購買 IPv4 地址時，制定新的收費政策，讓客戶為此付費買單。對于一個 IPv4 地址，AWS 新的收費金額為每年 43.80 美元（0.05*一天 24 小時*一年 365 天）。
提供變通辦法（例如代理）。此外，相關企業也可以為客戶提供 IPv4 代理服務，通過代理將 IPv6 流量映射為 IPv4 流量。這種方式允許 IPv6 設備訪問 IPv4 資源，同時減少對 IPv4 地址的直接需求；或者通過網絡地址轉換（NAT）技術優化 IPv4 地址的利用。共享一個 IPv4 地址，同時使用不同的端口來區分不同的服務或用戶。
只提供 IPv6，希望所有人都能跟上使用。
IPv6 普及存在的挑戰
從長遠角度來看，第三種方式即“只提供 IPv6”是最節約成本、解決后顧之憂的方案。因為作為 IPv4 的替代者，IPv6 提供了更好的支持移動設備、更靈活的地址分配、更簡化的頭部結構以及更好的安全性。
更為值得注意的是，IPv6 的地址空間極其龐大，可以提供大約 3.4 x 10^38 個地址，也有不少人調侃道——“IPv6 讓全球每一粒沙子都有地址”，其數量遠遠超過 IPv4，從而滿足未來互聯網設備的增長需求。
IPv6 的到來顯然是件好事，但是據 Google 統計的數據顯示，IPv6 推出十多年時間，截至 2024 年 1 月 15 日，互聯網上使用 IPv6 的用戶未達五成，占比 41.23%。
至于其中原因，Paul Copplestone 將其歸因為兩個方面：
ISP 支持力不足
“你的互聯網服務提供商支持 IPv6 嗎？”
在 Paul Copplestone 看來，全球采用 IPv6 的最大挑戰是 ISP（互聯網服務提供商，Internet Service Provider）的支持。
簡單來看，當你輸入一個網站的域名時，它會被轉換成一個 IP 地址。傳統上，這些地址都是 IPv4 地址：
example.com → 93.184.216.34
這些域名最終將被轉換為 IPv6：
example.com → 2607:f8b0:4006:819::200e
ISP 收到該地址后，負責把所有流量路由到正確的目的地。
遺憾的是，許多 ISP 還沒有為此做好準備——它們需要更新的交換機、更新的軟件以及與 IPv4 的互操作性。所有這些都需要花錢，而在過去 10 年中，這種投資并不值得。
如果你的互聯網服務供應商不支持 IPv6，當域名/服務器開始解析為 IPv6 而不是 IPv4 時，你將會受到以下影響，以及報一些錯誤：
你在 AWS 中設置了 Web 服務器嗎？是的話，你將無法通過 SSH 連接到它。
你是否使用直接連接從本地計算機連接到 Supabase 數據庫？是的話，你需要使用連接池，它將解析為 IPv4（供應商將為這些 IPv4 地址付費）。
你是從 Vercel 連接到任何 AWS 服務器的嗎？如果不為服務器設置 IPv4 地址，連接很快就會失敗。
缺乏工具支持
此外，許多開發者工具都還沒有針對 IPv6 進行設置。Paul Copplestone 使用自家的開源 Firebase 替代方案 Supabase 來舉例說明，他們的數據團隊要想他們的工具鏈支持 IPv6，需要進行以下更改：
這些看起來都很簡單的一句話，但要真正地實現，非常麻煩。下面是配置 Docker 的步驟：
1. 更新 /etc/docker/daemon.json：
"ipv6": true,"fixed-cidr-v6": "fd00:ffff::/80","ip6tables": true,"experimental": true
2. 重新啟動 Docker 服務：
systemctl restart docker
3. 創建一個臨時 IPv6 網絡并進行測試：
docker network create --ipv6 --subnet fd00:ffff::/80 ip6netdocker run --rm -it --network ip6net busybox ping6 google.com -c3
4. 檢查 IPv6 iptables 配置（FORWARD）
ip6tables -L
5. 添加 IPv6 網絡配置到組成配置文件 docker-compose.yaml 中
# enable IPv6 to default networknetworks:default:enable_ipv6: trueipam:config:- subnet: fd00:c16a:601e::/80gateway: fd00:c16a:601e::1
6. 檢查是否在容器中運行
docker exec -it "airflow_airflow-worker_1" bashcurl -6 https://ifconfig.co/ip
對于像 Docker 這樣無處不在的工具來說，這實在是太復雜了。
遷移到 IPv6，困難重重
話雖如此，在真實嘗試過程中，DevOps 工程師 Mathew Duggan 坦言，還是被遷移到 IPv6 所遇見困難嚇到了：“幾乎沒有任何東西可以開箱即用。主要的依賴程序立即停止運行，而變通方法也無法滿足生產需要。團隊向 IPv6 遷移的過程非常坎坷，這主要是因為幾乎沒有人做過這項工作。我們多年來都沒有做這項工作，現在我們需要付出代價。”
Mathew Duggan 嘗試將自己的博客（https://matduggan.com/ipv6-is-a-disaster-and-its-our-fault/）遷移到 IPv6，使用 CDN 管理 IPv4 流量。
他表示，“實際設置過程很簡單。我配置了一個 Debian 設備，并選擇了 ‘IPv6’。然后，我得到了第一個‘驚喜’。這臺設備沒有獲得 IPv6 地址，只是得到了一個 /64 的地址，即 18,446,744,073,709,551,616。好消息是，我的小型 ARM 服務器可以通過擴展，在所有公共地址上運行我曾工作過的每家公司所有網絡基礎設施。“
然而當他嘗試像普通服務器一樣設置它時，問題來了。
問題一：無法通過 SSH（Secure Shell Protocol）登錄
「這是一個可以預見的問題」，Mathew Duggan 說道，這是因為他工作或家里的 ISP 都不支持 IPv6，所以才需要設置自己的服務器，但現在卻完全不起作用。
于是，Mathew Duggan 只能先附加一個 IPv4 地址，然后通過 SSH 登錄，再設置 Cloudflared 來運行隧道。
讓他失望的是，Cloudflare 系統并不會自行處理其中的轉換工作。所以刪除 IPv4 地址時，隧道意外崩潰了。
默認情況下，Cloudflared 工具使用的是 IPv4，我們需要編輯 systemd 服務文件，添加：--edge-ip-version 6。這樣，隧道才能正常啟動，Mathew Duggan 也能通過 SSH 登錄了。
問題 2：無法使用 GitHub
當 Mathew Duggan 的服務器開始運行后，他嘗試運行服務器設置腳本時，結果立刻就報錯了。它正在嘗試訪問 hishtory 的安裝腳本，這是一個很棒的 shell 歷史工具。它試圖從 GitHub 提取安裝文件，但失敗了。
Mathew Duggan 產生了疑惑，“這肯定不對。GitHub 一定支持 IPv6？”。
結果意外發現這個整個互聯網都在用的發布軟件服務 GitHub 竟然不支持 IPv6。
最后迫于無奈，Mathew Duggan 使用了 TransIP Github 代理服務器，效果還不錯。但是隨后 Python 出現了 urllib.error.URLError 錯誤：<urlopen error [Errno 101] Network is unreachable>。
“好吧，我放棄了。我猜 Debian 中的 Python 3 版本不喜歡 IPv6，但我現在沒心情排查它”，Mathew Duggan 說道。
問題 3 ：無法設置 Datadog
接下來，Mathew Duggan 想設置 Datadog 來監控這臺服務器。
Bug 再次出現，當他訪問 Datadog，登錄并開始操作時，系統立即崩潰了。他只是簡單設置是運行 curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh，現在 S3 支持 IPv6，那么問題究竟出在哪里？
經過排查，Mathew Duggan 發現問題不是出現在 S3 或服務器上，因為他可以正常使用 AWS 提供的 S3 連接測試。后來他通過 apt 手動操作解決了問題。
直至此時，Mathew Duggan 清晰地感知到，純使用 IPv6 根本沒有前途。如果不上代理和技術補丁，那幾乎沒有什么東西能正常工作。
后來，為了從 IPv6 訪問 IPv4 資源，他選用了NAT64 服務（https://nat64.net/）作為支持。
此外，他也查找了很多工具，結果發現大多數工具都已經失效，如下列表單中的 Dresel 鏈接無法工作；Trex 在測試中出現了問題；August Internet 徹底消失；大多數 Go5lab 測試設備離線；Tuxis 倒是可以工作，但在 2019 年推出之后似乎就沒升級過。只有一個 Kasper Dupont 支持度還是可以的。
IPv6 的普及任重而道遠
在 Paul Copplestone 和 Mathew Duggan 看來，現在雖然已經到了向 IPv6 遷移的時期，但是大多數基礎設施和軟件還沒有為這種變化做好準備。Duggan 警告稱，需要針對 IPv6 進行培訓和準備，這將是數字專業人員面臨的重大挑戰。
對此，也有不少開發者感同身受，來自 HN 上的網友紛紛吐槽道：
那么不遷移到 IPv6，停留在 IPv4 上，它可能無法滿足日益增長的需求，導致性能下降和服務不穩定，同時許多組織采用 NAT 技術來共享有限的 IPv4 地址，這也為其增加了網絡管理的復雜性，可能導致一些應用程序或服務的功能受限。
基于此，越來越多的組織加入到實施 IPv6 遷移的浪潮之中。
來源：
https://supabase.com/blog/ipv6
https://matduggan.com/ipv6-is-a-disaster-and-its-our-fault/
https://news.ycombinator.com/item?id=39032665
轉自：https://csdnnews.blog.csdn.net/article/details/135761716
該文章在 2024/1/27 16:26:07 編輯過
400 186 1886
