导读：

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 迁移会遇到什么样的挑战以及各个企业会拿出什么样的策略。

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 迁移的浪潮之中。

原文链接：

https://medium.com/stackademic/global-ipv4-depletion-charges-begin-next-month-011c914c5737