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