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