哈嘍大家好，我是鹹魚
IPv4（Internet Protocol version 4）是互聯網上使用最廣泛的網絡層協議之一，於1981年在 RFC 791 中發佈，它定義了 32 位的IP地址結構和基本的協議操作。
由於 IPv4 使用 32 位的地址，因此只有四十億（4,294,967,296，2^32）個地址。
這就導致隨着地址不斷被分配，IPv4 地址開始面臨枯竭問題：
- 2011 年，互聯網分配與分配機構（IANA）正式宣佈IPv4地址用盡
- 由於 IPv4 地址短缺，一些機構開始收費分配IPv4地址，推動更多組織採用 IPv6
IPv 4 枯竭，升級 IPv6 任重道遠。
今天我們來看一篇文章，看看向 IPv6 遷移會遇到什麼樣的挑戰以及各個企業會拿出什麼樣的策略。
原文鏈接：https://medium.com/stackademic/global-ipv4-depletion-charges-begin-next-month-011c914c5737
IPv4 即將迎來支付時代：
- 去年 7 月，亞馬遜雲科技宣佈，從 2024 年 2 月 1 日起，所有公有 IPv4 地址將按每小時 0.005 美元（約每月 4 美元）的費率收費，無論它們是否與服務綁定。
- 基於容器的部署平台 Fly.io 最近也更新了其社區公告，表示 2 月 1 日之後，將對每個專用 IPv4 每月收取約 2 美元的費用。
- 開源數據處理服務平台 Supabase 計劃推出 IPv4 的付費附加服務，月費為 4 美元。
隨着時間流逝，圍繞 "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 賬單增加數百萬美元。”
一些分析人士認為，對於規模較大的 AWS 客户來説，這些費用可以完全忽略，可能在他們的賬單上不值一提。然而，對於很多中小企業和初創公司來説，這些費用很容易就佔到他們賬單的 10-30%。
三個選擇
當涉及到處理這些成本時，公司有哪些選擇來最小化成本呢 ?
對此，Paul Copplestone 分享了 AWS 基礎設施公司的三種選擇：
- 將成本轉移給客户：類似於 AWS 和 Fly.io 那樣，在租用或購買 IPv4 地址時，制定新的定價政策，讓客户為此付費。對於單個 IPv4 地址，AWS 的新費用為每年 43.80 美元（0.05 * 24 小時 * 365 天）
- 提供替代解決方案（如代理）：企業可以為客户提供 IPv4 代理服務，通過代理將 IPv6 流量映射到 IPv4 流量。這種方法允許 IPv6 設備訪問 IPv4 資源，同時減少對 IPv4 地址的直接需求；或者通過 NAT 技術來優化 IPv4 地址的利用率：共享一個IPv4地址，使用不同的端口來區分不同的業務或用户。
- 只提供 IPv6：希望大家能跟上它。
ipv6 面臨的挑戰
長期來看，第三種選擇 ——“只提供 IPv6” 是最經濟有效的解決方案。作為 IPv4 的繼任者，IPv6 對移動設備的支持更好，地址分配更靈活，報頭結構更簡化，安全性更高。
IPv6 的地址空間非常大，大約有 3.4 x 10^38 個地址，能夠滿足未來互聯網連接設備不斷增長的需求。。可以説 “IPv6 為每一粒沙子提供了一個唯一的地址”。
IPv6 的出現無疑是一件好事，然而根據谷歌的統計，截至 2024年1月15日，IPv6 引入十多年來，互聯網用户使用 IPv6 的佔比還沒有達到 50%，僅僅是 41.23%。
關於這背後的原因，Paul Copplestone 認為有兩點：
- 互聯網服務提供商 （ISP） 支持不足
- 缺乏相關工具支持
ISP 支持不足
問題來了：你的互聯網服務提供商（ISP）是否支持 IPv6？
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 服務
systemctl restart docker
3、創建臨時 IPv6 網絡並測試
docker network create --ipv6 --subnet fd00:ffff::/80 ip6net
docker run --rm -it --network ip6net busybox ping6 google.com -c3
4、檢查 IPv6 iptables 配置
ip6tables -L
5、將 IPv6 網絡配置添加到 Docker Compose 文件
# enable IPv6 to default network
networks:
default:
enable_ipv6: true
ipam:
config:
- subnet: fd00:c16a:601e::/80
gateway: fd00:c16a:601e::1
6、檢查是否正常運行
docker exec -it "airflow_airflow-worker_1" bash
curl -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 服務器可以通過擴展，在所有公共地址上運行我曾工作過的每家公司所有網絡基礎設施。
然而，當他試圖像普通服務器一樣設置它時，問題出現了。
- 無法 SSH 登錄
因為他的工作或家庭的 ISP 不支持 IPV6，所以需要他手動設置，否則根本無法正常工作。因此，他必須先添加一個 IPv4 地址，通過 SSH 登錄，然後設置 Cloudflared 來運行隧道（tunnel）。
但是 Cloudflare 系統本身不能處理轉換。當他刪除 IPv4 地址時，隧道意外崩潰了。因為 Cloudflared 默認使用 IPv4，如果想要支持 IPv6，要編輯 systemd 服務文件添加： —-edge-ip-version 6，這樣隧道才能正常使用。
- 無法使用 GitHub
當 Mathew Duggan 的服務器開始運行時，他嘗試去執行一個服務器設置腳本，這個腳本會去 GitHub 獲取安裝文件，但是報錯了。
他感到困惑，GitHub 確定支持 IPv6 嗎？最後他意外發現 GitHub 不支持 IPv6
最後他使用了 TransIP Github 代理服務器，運行良好。但隨後 Python 遇到了 urllib.error.URLError
“好吧，我放棄了。我猜 Debian 中的 Python 3 版本不喜歡 IPv6，但我現在不想排查了，“ Mathew Duggan 説。
- 無法設置 Datadog
接下來，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 的設計者，因為他們沒有使 IPv6 向後兼容 IPv4。IPv6 的設計無疑是優越的，但由於缺乏向後兼容性，過渡到 IPv6 是一個絕對的挑戰。我知道設計師們認為這種轉變只需要幾年的時間，但它已經持續了近 30 年……我們還在原地踏步。
- 除非 IPv6 地址成為一等公民，否則 IPv6 並不能真正解決地址耗盡的問題。只有當我們不再需要依賴 IPv4 地址時，才會發生這種情況。
如果不遷移到IPv6，繼續使用IPv4，可能無法滿足日益增長的需求，導致性能下降和業務不穩定。現在許多組織採用 NAT 技術來共享有限的 IPv4 地址，但是這會增加網絡管理的複雜性，還可能使某些程序或服務的功能受限。
鑑於此，越來越多的組織開始加入到實施 IPv6 遷移的浪潮之中。
