全球 IPv4 耗尽,下个月开始收费!

时间:2024-01-26 09:48:32

哈喽大家好,我是咸鱼

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 为每一粒沙子提供了一个唯一的地址”。

image
IPv6 的出现无疑是一件好事,然而根据谷歌的统计,截至 2024年1月15日,IPv6 引入十多年来,互联网用户使用 IPv6 的占比还没有达到 50%,仅仅是 41.23%。

image
关于这背后的原因,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 迁移的浪潮之中。