哈喽大家好，我是咸鱼
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 迁移的浪潮之中。