IPv4（Internet Protocol version 4）是互聯(lián)網(wǎng)上使用最廣泛的網(wǎng)絡(luò)層協(xié)議之一，于1981年在 RFC 791 中發(fā)布，它定義了 32 位的IP地址結(jié)構(gòu)和基本的協(xié)議操作。由于 IPv4 使用 32 位的地址，因此只有四十億（4,294,967,296，2^32）個(gè)地址。這就導(dǎo)致隨著地址不斷被分配，IPv4 地址開(kāi)始面臨枯竭問(wèn)題：
IPv 4 枯竭，升級(jí) IPv6 任重道遠(yuǎn)。
今天我們來(lái)看一篇文章，看看向 IPv6 遷移會(huì)遇到什么樣的挑戰(zhàn)以及各個(gè)企業(yè)會(huì)拿出什么樣的策略。
IPv4 即將迎來(lái)支付時(shí)代：
隨著時(shí)間流逝，圍繞 “IPv4 收費(fèi)，遷移到 IPv6” 的討論越來(lái)越激烈。最近，開(kāi)源數(shù)據(jù)處理服務(wù)平臺(tái) Supabase 的首席執(zhí)行官兼聯(lián)合創(chuàng)始人 Paul Copplestone 呼吁大家：“做好準(zhǔn)備，IPv6 即將到來(lái)。”然而，由于 IPv4 和 IPv6 報(bào)文頭之間的顯著差異，這兩個(gè)協(xié)議不能互操作。升級(jí)到 IPv6 的道路也面臨著多重挑戰(zhàn)。
一些開(kāi)發(fā)人員已經(jīng)嘗試使用 IPv6，但得出的結(jié)論是：IPv6 是一個(gè)“災(zāi)難”。雖然我們可能在未來(lái)會(huì)解決這些困難，但目前的準(zhǔn)備仍然不夠。
IPv4 耗盡，IPv6 升級(jí)成為焦點(diǎn)
據(jù)負(fù)責(zé)英國(guó)、歐洲、中東和中亞部分地區(qū)互聯(lián)網(wǎng)資源分配的 Réseaux IP Européens Network Coordination Centre (RIPE NCC)宣布：隨著互聯(lián)網(wǎng)規(guī)模的不斷擴(kuò)大，設(shè)備數(shù)量的快速增加導(dǎo)致最后一個(gè) IPv4 地址空間儲(chǔ)備池于 2019年11月25日15:35 耗盡，全球 42 億個(gè) IPv4 地址已經(jīng)分配完畢。公網(wǎng) IPv4 地址耗盡后，我們使用的公網(wǎng) IPv4 地址主要靠回收和釋放未被用的地址范圍來(lái)獲取。這些地址有的可能是來(lái)自解散的公司，有的可能是那些搬遷到 IPv6 后不再需要的。獲取日益緊缺的 IPv4 地址成為一個(gè)復(fù)雜的過(guò)程，這導(dǎo)致了成本自然增加。亞馬遜（AWS）此前透露，過(guò)去五年來(lái)，由于獲取難度增加，單個(gè)公網(wǎng) IPv4 地址的獲取成本增加了300%以上。所以大公司不得不采取收費(fèi)政策，希望大家更有效地利用公 共IPv4 地址，同時(shí)促進(jìn) IPv6 在行業(yè)內(nèi)的采用。Paul Copplestone 表示：“雖然 AWS 每月收費(fèi)約 4 美元，對(duì)個(gè)人來(lái)說(shuō)不算昂貴，但 AWS 是許多基礎(chǔ)設(shè)施公司的基礎(chǔ)設(shè)施層，比如 Supabase。我們需要為每個(gè) Postgres 數(shù)據(jù)庫(kù)提供完整的 EC2 實(shí)例，這將使我們的 AWS 賬單增加數(shù)百萬(wàn)美元。”一些分析人士認(rèn)為，對(duì)于規(guī)模較大的客戶來(lái)說(shuō)，這些費(fèi)用可以完全忽略，可能在他們的賬單上不值一提。然而，對(duì)于很多中小企業(yè)和初創(chuàng)公司來(lái)說(shuō)，這些費(fèi)用很容易就占到他們賬單的 10-30%。
三個(gè)選擇
當(dāng)涉及到處理這些成本時(shí)，公司有哪些選擇來(lái)最小化成本呢?
對(duì)此，Paul Copplestone 分享了基礎(chǔ)設(shè)施公司的三種選擇：
- 將成本轉(zhuǎn)移給客戶：類似于 AWS 和 Fly.io 那樣，在租用或購(gòu)買 IPv4 地址時(shí)，制定新的定價(jià)政策，讓客戶為此付費(fèi)。對(duì)于單個(gè) IPv4 地址，AWS 的新費(fèi)用為每年 43.80 美元（0.05 * 24 小時(shí) * 365 天）
- 提供替代解決方案（如代理）：企業(yè)可以為客戶提供 IPv4 代理服務(wù)，通過(guò)代理將 IPv6 流量映射到 IPv4 流量。這種方法允許 IPv6 設(shè)備訪問(wèn) IPv4 資源，同時(shí)減少對(duì) IPv4 地址的直接需求；或者通過(guò) NAT 技術(shù)來(lái)優(yōu)化 IPv4 地址的利用率：共享一個(gè)IPv4地址，使用不同的端口來(lái)區(qū)分不同的業(yè)務(wù)或用戶。
ipv6 面臨的挑戰(zhàn)
長(zhǎng)期來(lái)看，第三種選擇 ——“只提供 IPv6” 是最經(jīng)濟(jì)有效的解決方案。作為 IPv4 的繼任者，IPv6 對(duì)移動(dòng)設(shè)備的支持更好，地址分配更靈活，報(bào)頭結(jié)構(gòu)更簡(jiǎn)化，安全性更高。
IPv6 的地址空間非常大，大約有 3.4 x 10^38 個(gè)地址，能夠滿足未來(lái)互聯(lián)網(wǎng)連接設(shè)備不斷增長(zhǎng)的需求。。可以說(shuō) “IPv6 為每一粒沙子提供了一個(gè)唯一的地址”，
IPv6 的出現(xiàn)無(wú)疑是一件好事，然而根據(jù)谷歌的統(tǒng)計(jì)，截至 2024年1月15日，IPv6 引入十多年來(lái)，互聯(lián)網(wǎng)用戶使用 IPv6 的占比還沒(méi)有達(dá)到 50%，僅僅是 41.23%。
關(guān)于這背后的原因，Paul Copplestone 認(rèn)為有兩點(diǎn)：
- 互聯(lián)網(wǎng)服務(wù)提供商 （ISP） 支持不足
ISP 支持不足
Paul Copplestone認(rèn)為，全球 IPv6 面臨的最大挑戰(zhàn)在于 ISP 的支持。簡(jiǎn)單來(lái)說(shuō)，當(dāng)輸入網(wǎng)站的域名時(shí)，它會(huì)被轉(zhuǎn)換為 IPv4 地址：example.com → 93.184.216.34
如果采用 IPV6，這些域名最終將被解析成：
example.com → 2607:f8b0:4006:819::200e
一旦 ISP 收到此地址，它就負(fù)責(zé)將所有流量路由到正確的目的地。不幸的是，許多 ISP 沒(méi)有為域名解析成 IPv6 地址做好充分的準(zhǔn)備。它們需要更新的交換機(jī)、更新的軟件以及與 IPv4 的互操作性——這些都會(huì)產(chǎn)生成本，而在過(guò)去十年中，這些成本似乎并不合理。如果你的 ISP 不支持 IPv6，則當(dāng)域名/服務(wù)器開(kāi)始解析為 IPv6 而不是 IPv4 地址時(shí)，可能會(huì)遇到以下問(wèn)題：
如果在 AWS 中設(shè)置了 Web 服務(wù)器，則無(wú)法通過(guò) SSH 連接到該服務(wù)器。
如果直接從本地計(jì)算機(jī)連接到 Supabase 數(shù)據(jù)庫(kù)，則需要使用連接池，該連接池將解析為 IPv4（提供商需要為這些 IPv4 地址付費(fèi)）
如果通過(guò) Vercel 連接到任何 AWS 服務(wù)器，并且沒(méi)有為服務(wù)器設(shè)置 IPv4 地址，則會(huì)連接失敗。
缺乏工具支持
除了上面 ISP 支持不足的原因之外，許多開(kāi)發(fā)工具還沒(méi)有針對(duì) IPv6 進(jìn)行配置兼容。Paul Copplestone 以他的開(kāi)源 Firebase 替代品 Supabase 為例解釋說(shuō)，為了讓他們的數(shù)據(jù)團(tuán)隊(duì)的工具與 IPv6 兼容，他們需要進(jìn)行以下更改：
雖然這些步驟看起來(lái)很簡(jiǎn)單，但實(shí)現(xiàn)它們實(shí)際上是相當(dāng)具有挑戰(zhàn)性的。
以配置 Docker 的步驟為例：
1、更新 /etc/docker/daemon.json
"ipv6": true,"fixed-cidr-v6": "fd00:ffff::/80","ip6tables": true,"experimental": true
2、重啟 Docker 服務(wù)
3、創(chuàng)建臨時(shí) IPv6 網(wǎng)絡(luò)并測(cè)試
docker network create --ipv6 --subnet fd00:ffff::/80 ip6netdocker run --rm -it --network ip6net busybox ping6 google.com -c3
4、檢查 IPv6 iptables 配置
5、將 IPv6 網(wǎng)絡(luò)配置添加到 Docker Compose 文件
# enable IPv6 to default networknetworks: default: enable_ipv6: true ipam: config: - subnet: fd00:c16a:601e::/80 gateway: fd00:c16a:601e::1
6、檢查是否正常運(yùn)行
docker exec -it "airflow_airflow-worker_1" bashcurl -6 https://ifconfig.co/ip
可以看到，這些配置還是很繁雜的，尤其是對(duì)于 docker 這樣無(wú)處不在的工具。
向 IPv6 邁進(jìn)，挑戰(zhàn)重重
DevOps 工程師 Mathew Duggan 吐槽遷移到 IPv6 困難重重：“幾乎沒(méi)有什么是開(kāi)箱操作的。主要依賴項(xiàng)會(huì)立即停止工作，并且解決方法不足以滿足生產(chǎn)需求。我們團(tuán)隊(duì)的 IPv6 遷移過(guò)程相當(dāng)艱難，主要是因?yàn)楹苌儆腥顺袚?dān)這項(xiàng)工作，我們已經(jīng)很多年沒(méi)有做這項(xiàng)工作了，現(xiàn)在正在付出代價(jià)。”
Mathew Duggan 嘗試使用 CDN 將他的博客 （https://matduggan.com/ipv6-is-a-disaster-and-its-our-fault/） 遷移到 IPv6 以管理 IPv4 流量。
他說(shuō)：“實(shí)際的設(shè)置很簡(jiǎn)單。我配置了一個(gè) Debian 設(shè)備并選擇了 IPv6。然后我得到了第一個(gè)驚喜：設(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)題出現(xiàn)了。
因?yàn)樗墓ぷ骰蚣彝サ?ISP 不支持 IPV6，所以需要他手動(dòng)設(shè)置，否則根本無(wú)法正常工作。因此，他必須先添加一個(gè) IPv4 地址，通過(guò) SSH 登錄，然后設(shè)置 Cloudflared 來(lái)運(yùn)行隧道（tunnel）。但是 Cloudflare 系統(tǒng)本身不能處理轉(zhuǎn)換。當(dāng)他刪除 IPv4 地址時(shí)，隧道意外崩潰了。因?yàn)?Cloudflared 默認(rèn)使用 IPv4，如果想要支持 IPv6，要編輯 systemd 服務(wù)文件添加：—-edge-ip-version 6，這樣隧道才能正常使用。
當(dāng) Mathew Duggan 的服務(wù)器開(kāi)始運(yùn)行時(shí)，他嘗試去執(zhí)行一個(gè)服務(wù)器設(shè)置腳本，這個(gè)腳本會(huì)去 GitHub 獲取安裝文件，但是報(bào)錯(cuò)了。
他感到困惑，GitHub 確定支持 IPv6 嗎？最后他意外發(fā)現(xiàn) GitHub 不支持 IPv6。
最后他使用了 TransIP Github 代理服務(wù)器，運(yùn)行良好。但隨后 Python 遇到了 urllib.error.URLError“好吧，我放棄了。我猜 Debian 中的 Python 3 版本不喜歡 IPv6，但我現(xiàn)在不想排查了，“ Mathew Duggan 說(shuō)。
接下來(lái)，Mathew Duggan 想要設(shè)置 Datadog 來(lái)監(jiān)控服務(wù)器，當(dāng)他訪問(wèn) Datadog、登錄并開(kāi)始工作時(shí)，系統(tǒng)立即崩潰。他只是通過(guò)運(yùn)行 curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh 進(jìn)行設(shè)置，但是現(xiàn)在 S3 支持 IPv6，問(wèn)題可能出在哪里？經(jīng)過(guò)故障排除后，他發(fā)現(xiàn)問(wèn)題不在于 S3 或服務(wù)器，因?yàn)樗梢允褂?AWS 提供的 S3 連接測(cè)試而不會(huì)出現(xiàn)任何問(wèn)題。后來(lái)，他通過(guò) apt 手動(dòng)修復(fù)了這個(gè)問(wèn)題。他開(kāi)始意識(shí)到純 IPv6 的使用沒(méi)有未來(lái)。如果沒(méi)有代理和技術(shù)補(bǔ)丁，那幾乎沒(méi)有什么東西能正常工作后來(lái)，為了從 IPv6 訪問(wèn) IPv4 資源，他選擇了 NAT64 服務(wù) （https://nat64.net/） 作為支持。不但如此，他還搜索了許多工具，發(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)
雖然向 IPv6 過(guò)渡的時(shí)機(jī)已經(jīng)到來(lái)，但大多數(shù)基礎(chǔ)設(shè)施和軟件仍然沒(méi)有為這種變化做好準(zhǔn)備。而且 IPv6 的培訓(xùn)和準(zhǔn)備對(duì)數(shù)字專業(yè)人員來(lái)說(shuō)將是一項(xiàng)重大挑戰(zhàn)。不但許多開(kāi)發(fā)人員這么認(rèn)為，來(lái)自 HN 上的網(wǎng)友也紛紛訴苦：
我仍然在詛咒 IPv6 的設(shè)計(jì)者，因?yàn)樗麄儧](méi)有使 IPv6 向后兼容 IPv4。IPv6 的設(shè)計(jì)無(wú)疑是優(yōu)越的，但由于缺乏向后兼容性，過(guò)渡到 IPv6 是一個(gè)絕對(duì)的挑戰(zhàn)。
- 我知道設(shè)計(jì)師們認(rèn)為這種轉(zhuǎn)變只需要幾年的時(shí)間，但它已經(jīng)持續(xù)了近 30 年……我們還在原地踏步。
除非 IPv6 地址成為一等公民，否則 IPv6 并不能真正解決地址耗盡的問(wèn)題。只有當(dāng)我們不再需要依賴 IPv4 地址時(shí)，才會(huì)發(fā)生這種情況。
如果不遷移到IPv6，繼續(xù)使用IPv4，可能無(wú)法滿足日益增長(zhǎng)的需求，導(dǎo)致性能下降和業(yè)務(wù)不穩(wěn)定。現(xiàn)在許多組織采用 NAT 技術(shù)來(lái)共享有限的 IPv4 地址，但是這會(huì)增加網(wǎng)絡(luò)管理的復(fù)雜性，還可能使某些程序或服務(wù)的功能受限。
鑒于此，越來(lái)越多的組織開(kāi)始加入到實(shí)施 IPv6 遷移的浪潮之中。
該文章在 2024/6/12 9:18:56 編輯過(guò)
400 186 1886
