编译 | 苏宓
出品 | CSDN（ID：CSDNnews）
IPv4 即将迎来付费时代：
去年 7 月，亚马逊云科技宣布自 2024 年 2 月 1 日起，所有公共 IPv4 地址将按每小时 0.005 美元的价格收费，约合每月 4 美元，而且无论其是否附加到服务中，都要收费；
基于容器的部署平台 Fly.io 也在不久前更新社区公告，称会在 2 月 1 日之后，对每个专用 IPv4 每月收取约 2 美元的费用；
开源数据处理服务平台 Supabase 计划推出一个 IPv4 的付费附加服务，每月费用为 4 美元。
随着时间一天天临近，围绕「IPv4 收费，迁移到 IPv6」的讨论愈发激烈。
近日，开源数据处理服务平台 Supabase CEO 兼联合创始人 Paul Copplestone 也发起一则关于“做好准备，IPv6 即将到来”的呼吁。然而，由于 IPv4 讯息和 IPv6 讯息标头有很大不同，因此这两种协议无法互操作，同时升级到 IPv6 之路也面临多重挑战，甚至在有开发者进行了尝试使用，最终得出一个结论：IPv6 是一场“灾难”，我们未来虽可以解决困难，但目前准备仍然不足。
全球 IPv4 地址消耗殆尽，升级到 IPv6 提上日程
众所周知，随着互联网的不断发展，设备的数量急剧增加，导致 2019 年负责英国、欧洲、中东和部分中亚地区互联网资源分配的欧洲网络协调中心（RIPE NCC）无奈宣布，其最后的 IPv4 地址空间储备池在 2019 年 11 月 25 日 UTC + 1 15:35 完全耗尽，全球 42 亿个 IPv4 地址已分配完毕。
耗尽之后，对于想要继续使用公共 IPv4 地址的用户而言，他们主要靠回收和未使用地址段的释放才能用上 IPv4，其中这些地址要么来自倒闭的组织，要么来自于那些已经迁移到 IPv6 时不再需要的地址。
不难想象，获取日益稀缺的 IPv4 中间过程变得复杂，成本自然而然涨起来了。
此前，亚马逊云科技也曾透露过，在过去五年中，由于难以获得公共 IPv4 地址，单个地址的获取成本上涨了 300% 以上。
所以正如文章伊始所述，各大公司不得不采取收费政策，一方面为了鼓励大家在使用公共 IPv4 地址时更加节俭，另一方面，想要借此推动行业内采用 IPv6。
Paul Copplestone 表示，“虽然亚马逊云科技每月收取约 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 让全球每一粒沙子都有地址”，其数量远远超过 IPv4，从而满足未来互联网设备的增长需求。
IPv6 的到来显然是件好事，但是据 Google 统计的数据显示，IPv6 推出十多年时间，截至 2024 年 1 月 15 日，互联网上使用 IPv6 的用户未达五成，占比 41.23%。
至于其中原因，Paul Copplestone 将其归因为两个方面：
ISP 支持力不足
“你的互联网服务提供商支持 IPv6 吗？”
在 Paul Copplestone 看来，全球采用 IPv6 的最大挑战是 ISP（互联网服务提供商，Internet Service Provider）的支持。
简单来看，当你输入一个网站的域名时，它会被转换成一个 IP 地址。传统上，这些地址都是 IPv4 地址：
example.com → 93.184.216.34
这些域名最终将被转换为 IPv6：
example.com → 2607:f8b0:4006:819::200e
ISP 收到该地址后，负责把所有流量路由到正确的目的地。
遗憾的是，许多 ISP 还没有为此做好准备——它们需要更新的交换机、更新的软件以及与 IPv4 的互操作性。所有这些都需要花钱，而在过去 10 年中，这种投资并不值得。
如果你的互联网服务供应商不支持 IPv6，当域名/服务器开始解析为 IPv6 而不是 IPv4 时，你将会受到以下影响，以及报一些错误：
你在 AWS 中设置了 Web 服务器吗？是的话，你将无法通过 SSH 连接到它。
你是否使用直接连接从本地计算机连接到 Supabase 数据库？是的话，你需要使用连接池，它将解析为 IPv4（供应商将为这些 IPv4 地址付费）。
你是从 Vercel 连接到任何 AWS 服务器的吗？如果不为服务器设置 IPv4 地址，连接很快就会失败。
缺乏工具支持
此外，许多开发者工具都还没有针对 IPv6 进行设置。Paul Copplestone 使用自家的开源 Firebase 替代方案 Supabase 来举例说明，他们的数据团队要想他们的工具链支持 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 ip6netdocker run --rm -it --network ip6net busybox ping6 google.com -c3
4. 检查 IPv6 iptables 配置（FORWARD）
ip6tables -L
5. 添加 IPv6 网络配置到组成配置文件 docker-compose.yaml 中
# enable IPv6 to default networknetworks:default:enable_ipv6: trueipam:config:- subnet: fd00:c16a:601e::/80gateway: 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 尝试将自己的博客（https://matduggan.com/ipv6-is-a-disaster-and-its-our-fault/）迁移到 IPv6，使用 CDN 管理 IPv4 流量。
他表示，“实际设置过程很简单。我配置了一个 Debian 设备，并选择了 ‘IPv6’。然后，我得到了第一个‘惊喜’。这台设备没有获得 IPv6 地址，只是得到了一个 /64 的地址，即 18,446,744,073,709,551,616。好消息是，我的小型 ARM 服务器可以通过扩展，在所有公共地址上运行我曾工作过的每家公司所有网络基础设施。“
然而当他尝试像普通服务器一样设置它时，问题来了。
问题一：无法通过 SSH（Secure Shell Protocol）登录
「这是一个可以预见的问题」，Mathew Duggan 说道，这是因为他工作或家里的 ISP 都不支持 IPv6，所以才需要设置自己的服务器，但现在却完全不起作用。
于是，Mathew Duggan 只能先附加一个 IPv4 地址，然后通过 SSH 登录，再设置 Cloudflared 来运行隧道。
让他失望的是，Cloudflare 系统并不会自行处理其中的转换工作。所以删除 IPv4 地址时，隧道意外崩溃了。
默认情况下，Cloudflared 工具使用的是 IPv4，我们需要编辑 systemd 服务文件，添加：--edge-ip-version 6。这样，隧道才能正常启动，Mathew Duggan 也能通过 SSH 登录了。
问题 2：无法使用 GitHub
当 Mathew Duggan 的服务器开始运行后，他尝试运行服务器设置脚本时，结果立刻就报错了。它正在尝试访问 hishtory 的安装脚本，这是一个很棒的 shell 历史工具。它试图从 GitHub 提取安装文件，但失败了。
Mathew Duggan 产生了疑惑，“这肯定不对。GitHub 一定支持 IPv6？”。
结果意外发现这个整个互联网都在用的发布软件服务 GitHub 竟然不支持 IPv6。
最后迫于无奈，Mathew Duggan 使用了 TransIP Github 代理服务器，效果还不错。但是随后 Python 出现了 urllib.error.URLError 错误：<urlopen error [Errno 101] Network is unreachable>。
“好吧，我放弃了。我猜 Debian 中的 Python 3 版本不喜欢 IPv6，但我现在没心情排查它”，Mathew Duggan 说道。
问题 3 ：无法设置 Datadog
接下来，Mathew Duggan 想设置 Datadog 来监控这台服务器。
Bug 再次出现，当他访问 Datadog，登录并开始操作时，系统立即崩溃了。他只是简单设置是运行 curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh，现在 S3 支持 IPv6，那么问题究竟出在哪里？
经过排查，Mathew Duggan 发现问题不是出现在 S3 或服务器上，因为他可以正常使用 AWS 提供的 S3 连接测试。后来他通过 apt 手动操作解决了问题。
直至此时，Mathew Duggan 清晰地感知到，纯使用 IPv6 根本没有前途。如果不上代理和技术补丁，那几乎没有什么东西能正常工作。
后来，为了从 IPv6 访问 IPv4 资源，他选用了NAT64 服务（https://nat64.net/）作为支持。
此外，他也查找了很多工具，结果发现大多数工具都已经失效，如下列表单中的 Dresel 链接无法工作；Trex 在测试中出现了问题；August Internet 彻底消失；大多数 Go5lab 测试设备离线；Tuxis 倒是可以工作，但在 2019 年推出之后似乎就没升级过。只有一个 Kasper Dupont 支持度还是可以的。
IPv6 的普及任重而道远
在 Paul Copplestone 和 Mathew Duggan 看来，现在虽然已经到了向 IPv6 迁移的时期，但是大多数基础设施和软件还没有为这种变化做好准备。Duggan 警告称，需要针对 IPv6 进行培训和准备，这将是数字专业人员面临的重大挑战。
对此，也有不少开发者感同身受，来自 HN 上的网友纷纷吐槽道：
那么不迁移到 IPv6，停留在 IPv4 上，它可能无法满足日益增长的需求，导致性能下降和服务不稳定，同时许多组织采用 NAT 技术来共享有限的 IPv4 地址，这也为其增加了网络管理的复杂性，可能导致一些应用程序或服务的功能受限。
基于此，越来越多的组织加入到实施 IPv6 迁移的浪潮之中。
来源：
https://supabase.com/blog/ipv6
https://matduggan.com/ipv6-is-a-disaster-and-its-our-fault/
https://news.ycombinator.com/item?id=39032665
转自：https://csdnnews.blog.csdn.net/article/details/135761716
该文章在 2024/1/27 16:26:07 编辑过
400 186 1886
