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