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