IPv8 草案试图一次性解决路由表膨胀、地址分配和身份认证，但一位社区网络运营者逐条审视后发现：每个 ASN 一条路由行不通、路由验证不是路径验证、OSI 分层模型被无视。
（社区贡献者 · 8 分钟阅读）
IPv8 提案将路由、身份和网络管理整合为一个统一设计，但它是否留下了太多未回答的运营问题？
---
我读了 IPv8 草案，有很多想法涌现。简短版：
- 我欣赏有人将路由表、地址分配、管理、认证和运营复杂性作为一个整体问题来思考。这部分可能是好的，但这也意味着该提案已经积累了巨大的复杂性，而试图一次性解决所有问题并不是互联网应有的演进方式。
- 我认为这份草案远未达到描述一个可用且可投产互联网协议的程度。它读起来不像一份协议规范，更像一份庞大的架构愿望清单。其中一些想法很有趣，但许多对像我这样的网络运营者来说至关重要的运营细节是缺失的。
- 草案称 IPv8 是一个受管网络协议套件，设备通过 OAuth2 JWT 令牌授权，服务通过 DHCP8 交付，数据包通过 DNS8 和 WHOIS8 验证，路由在结构上被限定为每个 ASN 一条全局路由。它还声称每个 ASN 持有者可获得 4,294,967,296 个主机地址。这在纸面上听起来简单而结构化，但在生产网络中，很多内容要么行不通，要么根本不会发生。
90 万条路由已经过时了
草案的动机之一是路由表增长。它提到 BGP 在 2024 年超过了 90 万条 IPv4 前缀。
这个数字让人感觉草案是很久以前写的，只是现在才发表。如今，根据观测点不同，我们已经达到甚至超过了 100 万条 IPv4 路由。APNIC 数据显示，广告的 IPv4 前缀从 2011 年的约 30 万条增长到 2026 年初的约 120 万条。另一个测量数据在 2025 年已经超过了 1,002,006 条路由。
这并不否定论点本身，但确实表明草案与当前数据不同步。如果在 2026 年提出一个新的互联网协议，底层数据却是大约四年前的，这感觉很奇怪。从那之后我们又发展出了什么，而草案没有包含？
每个 ASN 一条路由行不通
草案称全局路由表在结构上被限定为每个 ASN 一条记录。
这可能是最让我恼火的一点。前缀不仅仅是一个地址块，前缀也是一种运营工具。网络运营者使用更具体的路由前缀来进行流量工程、DDoS 缓解、区域路由、任播路由、被动备份路径与维护窗口、容量均衡、选择性公告、客户隔离和商业优化。如果每个 ASN 只拥有一条全局可见路由，我如何还能做到这些？
假设一个运营者同时在苏黎世、法兰克福、赫尔辛基和阿姆斯特丹提供服务。这些不是同一个市场。它们有不同的上游、不同的 IXP、不同的客户、不同的延迟、不同的容量和不同的商业协议。有时我希望某个服务的流量走法兰克福；有时我希望芬兰的用户流量留在芬兰；有时我需要为维护隔离或拆分一个接入点；也许我需要向 DDoS 清洗服务商发布一条更具体的路由；有人可能需要任播，但不是在所有地方。
在"每个 ASN 一条全局路由"的约束下，所有这些都变得不可能。草案引入了 CF（复合转发）度量来选择路径，但单一度量不是路由策略的替代品。路由策略不仅仅是"最佳路径"，它还关乎意图、流量工程和精细调优。
这是否意味着每个位置一个 ASN？
如果答案是"每个位置用一个 ASN"，那么我们并没有简化互联网。
这不过是在别处制造了另一种膨胀。大型运营者将开始使用多个 ASN 来维持路由策略的正常运作。拥有不同站点的企业需要更多 ASN。任播网络需要全新设计。RIR 政策和费用需要再次改变。IRR、PeeringDB、ASPA、对等互联、AS-PATH 路由决策——全部需要改变。
路由验证不是路径验证
草案谈到通过 WHOIS8 注册的活跃路由来验证数据包，但我没有读到路径验证模型。除非我漏掉了？
验证一个 ASN 是否有权发起某条路由，与验证 AS 路径是否合法/正确是两回事。我们已经在 RPKI 中实现了前者并持续改进。ROA 有助于来源验证，但它们不能解决 AS 劫持或伪造路径问题。
ASPA 正是为了解决这一问题而存在的。它正在 IETF SIDROPS 中标准化，描述了使用 RPKI 中 ASPA 对象进行 AS_PATH 验证。RIPE NCC 也有相关描述。
IPv8 似乎计划了自己的路由验证，但没有涉及路径验证。这感觉像是一个学术练习，缺乏对生产网络发展和挑战的深入理解。
如果在 2026 年设计一个新的全局路由架构，你不应该忽略 RPKI 和 ASPA，然后用一个类似 WHOIS 的机制替换它们，却没有真正解释为什么它更好、如何保障安全、信任锚如何工作等。目前，该提案只是声明它们将被替换。
关于 CF 度量
CF 度量值得关注。它描述了一种可能包含 RTT、丢包率、拥塞、稳定性、容量、经济偏好和距离的度量。
但如果你写了这样一个度量，我可以想象还有很多其他度量是缺失的：
- 链路负载——这既不是拥塞也不是容量，而是链路的实际使用率，这样负载均衡才真正是均衡，而不是等到一条链路满了才优选另一条。
- 多路径——如果一条路径满了，路由切换到新链路，是否所有新流都应该走新链路，直到新链路的容量也满了？这份提案感觉会导致链路之间持续震荡：每次一条链路满了，就填充新链路，而旧链路（因不再是"最佳路径"）在所有流过期后被排空。
- 草案提到了针对更大报头的路径 MTU 发现，但我没有看到 MTU 被作为路由度量来处理。
向后兼容听起来过于乐观
草案称 IPv4 是 IPv8 的一个真子集，无需修改任何现有设备、应用或网络，没有标志日。
这既是福音也是问题。如果没有标志日且有向后兼容性，那么几乎没有任何动力从 IPv4 迁移到 IPv8——既然向后兼容，不需要任何操作，一切将继续"照常运行"。
我的问题是：它试图从路由表中清除冗余，却引入了极其庞大的运营复杂性。
如今，更具体的前缀是浪费的，但它们也可能是有用的。BGP 社区属性是复杂的，但它们非常有用。去聚合是令人头疼的，但它给了运营者完全的控制权。RPKI 已经部署并被广泛理解。ASPA 仍在兴起，它解决的是一项缺失的安全特性。
草案中我还缺失的一些东西——运营层面：
- 路径验证，而不仅仅是路由验证
- 多站点流量工程
- 任播
- DDoS 缓解工作流
- MTU 感知的路径选择
- 清晰的 CF 溢出和均衡处理
- 与 RPKI 和 ASPA 的互动——既然这是一个渐进过程，子集应当被集成，而非被忽略
- 当前工具链的未来
- 如何调试出错或无法工作的情况（例如强制性的 DHCP8 服务器）
- 路由策略控制（例如仅在某一政治区域公告前缀）
OSI 分层模型
将基于 JWT 的认证、DNS 命名、DHCP 配置和路由语义直接嵌入到本应是一个新第三层协议的设计中，从根本上无视了 OSI 模型所依赖的层次分离原则。
第三层的设计目标是提供尽力而为的数据包交付，而不是身份、策略、服务发现和生命周期管理。如果意图是将这些层合并为一个单一网络栈，那么这不仅仅是一个新的 IP 协议，而是对所有第 3 到第 7 层的实质性替代——这需要从传输层到应用层重新规范一切，以及配套的联合运营工具。
如果这不是设计意图，那么该提案就是在跨层越界，却没有明确界定。
无论哪种情况，草案都显得不完整：要么作者低估了替换分层模型的巨大范围，要么他们还没有说清楚为什么打破这些边界能带来更好、更安全的系统。
我乐于接受对我观点的纠正，但就我而言，这整个提案更像是一个思想实验，而不是一个面向真实世界的提案。