Internet Protocol Version 8 (IPv8) 中文专业译读：draft-thain-ipv8-02核心内容整理

Internet Protocol Version 8 (IPv8) 中文专业译读：draft-thain-ipv8-02核心内容整理

译者说明：本文依据 2026 年 4 月 17 日版本的 draft-thain-ipv8-02 整理翻译。为保证阅读连续性，保留技术正文主干，省略 Status of This Memo（文档状态声明）、版权模板和参考文献等非技术性段落。该文档目前仍是 Internet-Draft（互联网草案），并非 IETF 已定稿标准。

摘要

Internet Protocol Version 8 (IPv8) 被定义为一套“可管理的网络协议族”，目标是统一各种规模网络的运行、保护与监控方式。按照草案的设想，在 IPv8 网络中：

  • 每一个可管理元素都通过本地缓存提供的 OAuth2 JWT 令牌完成授权；
  • 每一台设备所需的全部服务，都可以在一次 DHCP8 租约响应中下发；
  • 每一个出网分组，都要在出口处同时接受 DNS8 查询结果和 WHOIS8 已注册活动路由的联合校验；
  • 网络遥测、认证、名称解析、时间同步、访问控制与地址转换，被统一进一个一致的 Zone Server 平台。

草案同时声称：IPv4 是 IPv8 的真子集。只要 IPv8 地址的路由前缀字段为零，该地址就按 IPv4 处理；现有设备、应用和网络无需修改即可继续参与通信，因此不需要“切换日”，也不要求强制双栈迁移。

1. 引言：作者到底想解决什么问题

草案认为，现有网络世界最大的结构性问题不是单一协议缺陷，而是管理碎片化。

今天的 DHCP、DNS、NTP、日志、监控和认证系统往往分别存在、分别授权、分别维护，彼此之间既没有统一的身份模型，也没有统一的遥测格式。设备接入网络后，常常还需要继续补齐多个独立服务的配置，才能真正进入可运营状态。对小网络来说，这意味着复杂度太高；对大网络来说，这意味着不一致性难以控制。

作者进一步指出，IPv6 虽然缓解了地址耗尽问题，但并没有触碰运维碎片化。部署二十五年后，IPv6 仍然只承载全球互联网流量中的一部分，其商业阻力恰恰来自它只解决了地址长度，却没有显著改善管理模型。

IPv8 的基本立场是：下一代网络协议不能只扩地址，还必须顺手改写控制面。

2. IPv8 的管理哲学：Zone Server 作为统一控制点

草案把 Zone Server 设定为 IPv8 的中心运行节点。它不是传统意义上单一功能的服务器，而是一对主主工作的综合平台，负责：

  • DHCP8 地址分配
  • DNS8 名称解析
  • NTP8 时间同步
  • NetLog8 遥测收集
  • OAuth8 本地认证缓存
  • WHOIS8 路由验证解析
  • ACL8 访问控制
  • XLATE8 IPv4/IPv8 转换

设备接入网络时，只需发送一次 DHCP8 Discover，就能在响应中拿到全部必需服务端点。也就是说，设备在第一次用户交互之前，理论上就已经处于“已认证、已记录、已同步时间、已受策略约束”的状态。

认证方面，草案要求所有可管理元素都通过 OAuth2 JWT 令牌工作。Zone Server 通过 OAuth8 在本地缓存公钥并校验签名，因此即使远端云身份源短暂不可达，设备仍能继续完成本地认证。

更新方面，草案又引入 Update8。它规定固件和软件更新应通过由 Zone Server 验证的 DNS 名称来源进行，默认禁止直接连接裸 IP 地址获取更新。

3. 冗余与分流：奇偶网关模型

草案要求每个 IPv8 网络段部署两台 Zone Server，分别占用子网最高两个地址：.254 和 .253。这两台节点同时作为默认网关下发给终端。

流量分配逻辑采用一个非常鲜明的“奇偶亲和模型”：

  • 偶地址主机优先走偶网关 .254
  • 奇地址主机优先走奇网关 .253
  • 双网卡主机建议一边拿偶地址、一边拿奇地址，以同时利用两条物理路径

草案认为，这样可以在不增加额外复杂配置的前提下，同时获得负载分担与故障切换能力。

4. 安全模型：把横向隔离和出网校验都写进协议

IPv8 把安全问题分成两类。

4.1 东西向安全

也就是内网设备之间的横向通信。

草案希望通过 ACL8 分区隔离，让设备只和指定服务网关通信，服务网关再和指定云服务通信，从结构上减少横向移动的可能。它提出三层防护叠加：

  • 网卡固件层 ACL8
  • Zone Server 网关层 ACL8
  • 交换机端口基于 OAuth2 的硬件 VLAN 强制绑定

4.2 南北向安全

也就是设备访问互联网时的出口控制。

这里草案提出两条强制规则：

  1. 每次出站连接都必须有相应的 DNS8 查询；
  2. 目的前缀必须能在 WHOIS8 中验证为由合法 ASN 持有者注册的活动路由。

如果没有 DNS 查询，或者目的路由不合法，分组都应在出口处被丢弃。作者明确把这种设计与恶意软件的命令控制通道联系起来，认为这样可以压缩“直接连接硬编码 IP 地址”的攻击路径。

在更高层面上，草案还要求 BGP8 路由在安装进路由表前先经过 WHOIS8 校验。验证失败的路由不应被安装。

5. 地址格式：IPv8 地址到底长什么样

IPv8 地址是一个 64 位值，写成：

r.r.r.r.n.n.n.n

其中：

  • r.r.r.r：32 位 ASN Routing Prefix（自治系统路由前缀）
  • n.n.n.n：32 位 Host Address（主机地址），语义与 IPv4 保持一致

因此，整个 IPv8 地址空间等于：

  • 2^64 个唯一地址
  • 也可以理解为 2^32 个 ASN 前缀，每个前缀下再挂 2^32 个主机地址

5.1 IPv4 在 IPv8 中的表达

当 r.r.r.r = 0.0.0.0 时，地址写作：

0.0.0.0.n.n.n.n

这时它就被视为一个 IPv4 地址，按普通 IPv4 规则处理 n.n.n.n。草案由此得出核心结论：IPv4 是 IPv8 的真子集。

5.2 ASN 如何编码到前 32 位

草案直接把 32 位 ASN 以网络字节序编码到 r.r.r.r 中。例如：

  • ASN 64496 = 0.0.251.240
  • ASN 64497 = 0.0.251.241
  • ASN 64498 = 0.0.251.242

这意味着公网可路由身份与地址前缀在模型上被直接绑定。

5.3 几类关键保留地址空间

草案预留了多组有强烈场景意味的地址：

  • 127.0.0.0/8：内部区域前缀空间，只能在组织内部使用，不得出现在公网边界
  • 127.127.0.0：企业间互通 DMZ
  • 100.0.0.0/8：RINE 对等互联织构地址
  • 222.0.0.0/8：内部路由器链路地址约定
  • 0.0.255.254.x.x.x.x：私有 BGP8 对等互联
  • <own-asn>.n.n.n.n：显式对公网开放的服务地址
  • 0.0.0.0.n.n.n.n：IPv4 兼容地址

其中，草案特别强调：大多数设备默认都应使用 127.x.x.x 内部区地址，而不是直接用公网 ASN 前缀地址暴露自己。

6. ARP8：协议版本选择不是全网统一，而是逐跳决定

IPv8 的兼容逻辑建立在 ARP8 之上。

草案规定：IPv8 主机或路由器在同一链路上向邻居发包时，必须根据 ARP8 缓存中记录的邻居能力，决定发 IPv8 还是发 IPv4。

首次接触一个邻居时，设备要发两次探测：

  • t=0ms：先发 ARP8 probe
  • t=50ms：如果还没有回应，再发 ARP4 probe

哪种回应先回来，就把邻居能力记录成哪种，并在缓存有效期内持续沿用。

6.1 发包时的规则

如果邻居被记录为 IPv8 capable（支持 IPv8），就发完整 IPv8 报文：

  • 版本号为 8
  • 源地址和目的地址都带完整的 r.r.r.r.n.n.n.n

如果邻居被记录为 IPv4 only（仅支持 IPv4），就发标准 IPv4 报文：

  • 版本号为 4
  • 线上只保留 n.n.n.n
  • r.r.r.r 不出现在该跳链路上

草案把这句话写得非常绝对：IPv8 设备永远只能向 IPv4 设备发送 IPv4 报文，不存在例外。

6.2 路由器转发时的规则

如果 IPv8 路由器收到的是 IPv8 报文，但下一跳只支持 IPv4，那么它必须在出接口处“降级转发”：

  • 入接口：IPv8，完整 64 位源/目的地址
  • 出接口：IPv4，只保留 n.n.n.n

被剥离的 r.r.r.r 信息，由 Zone Server 上的 XLATE8 保存状态，用于回包时重建。

6.3 过渡模型的结论

草案由此总结出几条过渡属性：

  • IPv4-only 终端无需修改
  • 与 IPv8 终端混接的 IPv4 设备无需重新配置
  • IPv8 路由器背后的 IPv4 设备仍然可以继续工作
  • IPv4 应用可以依赖 XLATE8 继续运行
  • 没有任何 IPv4 设备会在线路上收到 version 8 报文

作者甚至进一步宣称：四行配置就足以在路由器上启用 IPv8。

7. 报头与应用兼容

IPv8 报头基本沿用了 IPv4 的格式，只是把源和目的地址扩展成：

  • 源 ASN 前缀
  • 源主机地址
  • 目的 ASN 前缀
  • 目的主机地址

草案指出，与 IPv4 相比，IPv8 报头仅增加了 8 个字节。

应用兼容方面，它保留了两条路径：

  • 旧应用继续使用 AF_INET 和 sockaddr_in，由兼容层透明处理
  • 新应用可以使用 AF_INET8 和 sockaddr_in8

草案给出的 sockaddr_in8 结构体中，显式增加了 sin8_asn 字段，用于存放 r.r.r.r 前缀。

8. DNS8 与 A8 记录

草案提出新的 DNS A8 资源记录类型，用于存放 64 位 IPv8 地址。其基本规则包括：

  • 记录类型为 A8
  • 数据格式为网络字节序的 64 位 IPv8 地址
  • 公共 DNS 中不得发布 RFC1918 私有地址
  • IPv8 解析器应同时查询 A 和 A8

对于仍使用 IPv4 API 的应用，解析器可以只返回 n.n.n.n 主机地址，r.r.r.r 由协议栈透明补上。

草案还建议：A8 响应应当成对返回，一个偶地址、一个奇地址，以便客户端天然利用奇偶网关分流。

9. 路由行为：BGP8、OSPF8 与两级路由表

草案规定以下协议为 IPv8 的核心路由组件：

  • eBGP8：公网 Inter-AS 必选
  • IBGP8：区间内部路由必选
  • OSPF8：区内路由必选
  • IS-IS8：必须可用，但可由运营者自主选择是否部署
  • Static：静态路由仍然必须支持

同时，它把 RIP/RIPv2 和 EIGRP 标为 DEPRECATED（弃用）。

9.1 /16 最小可注入前缀

在跨 AS 边界上，草案要求最小可注入前缀是 /16。比 /16 更具体的前缀不得向外通告。

9.2 两级路由表

它进一步提出一个 Two-Tier Routing Table（两级路由表）模型：

  • Tier 1：全局表，以 r.r.r.r 为索引，用来找到目标 ASN 的边界路由器
  • Tier 2：本地表，以 n.n.n.n 为索引，本质上与现有 IPv4 主机路由表相同

如果 r.r.r.r = 0.0.0.0，则直接绕过 Tier 1 查找。

9.3 Cost Factor

草案还定义了统一路径质量指标 CF（Cost Factor），它由七个组成部分累计而成：

  • 往返时延
  • 丢包
  • 拥塞窗口状态
  • 会话稳定性
  • 链路容量
  • 经济策略
  • 地理距离

它希望 CF 能跨越自治系统边界，形成从源到目的的累计路径质量判断。

10. 多播、任播与广播

在多播部分，草案把 r.r.r.r = 0.0.0.0 且 n.n.n.n 落在多播区间的流量定义为 Intra-ASN Multicast（自治系统内多播），不得越过本地 ASN 边界。

跨 ASN 多播则使用 ff.ff.00.xx.n.n.n.n 这样的前缀格式，并给 OSPF8、BGP8 peer discovery 等协议流量预留了具体范围。

任播方面，草案并没有单独定义特殊前缀，而是把任播视为路由属性，由 eBGP8 和 CF 路由到“度量最低的最近实例”。

广播方面，r.r.r.r = ff.ff.ff.ff 被永久保留为广播地址，并映射到二层广播地址，不得越过本地网络段。

11. 兼容与过渡：8to4 的再定义

草案特别强调，IPv8 不要求双栈。

对于仍然是 IPv4-only 的传输核心，它提出了 8to4 模型，但和传统预配置隧道不同，它的思路是“基于 ASN 的任播封装”。

具体做法是：

  1. 每个 ASN 在 WHOIS8 记录里公布一个 IPv4 任播地址；
  2. 该 ASN 的所有 BGP8 边界路由器把这个 IPv4 地址通告进现有 BGP4 网络；
  3. 当一个 BGP8 路由器需要跨越纯 IPv4 域去找目标 ASN 时，就查询 WHOIS8 拿到这个任播地址；
  4. 再把原始 IPv8 分组封装进一个标准 IPv4 外壳，发往该任播地址；
  5. 现有 IPv4 核心继续按普通 BGP4 转发；
  6. 离目标 ASN 最近的 IPv8 边界再解封装并递送。

草案认为，这样做可以避免海量预配置隧道，并允许任何阶段的部署与未部署阶段互通。

12. CGNAT、应用、云与设备分级

12.1 CGNAT

草案要求 CGNAT 在 IPv8 环境下只能改写 n.n.n.n，不得改动 r.r.r.r。如果运营者自己没有 ASN，则应使用 r.r.r.r = 0.0.0.0。

12.2 应用兼容

旧的 IPv4 应用不需要修改；协议栈兼容层通过 DNS8 拦截和 XLATE8 透明处理 r.r.r.r。新应用则可以显式使用 AF_INET8。

12.3 云场景

草案认为，IPv8 可以借助 ASN 前缀和内部区前缀解决：

  • VPC 地址重叠
  • VPC 对等互联复杂度
  • 多云路由冲突

它的逻辑是：每个客户 VPC 分配一个独立的 127.x.x.x 区前缀，即使内部继续复用 RFC1918 地址，也不会在更高层面发生地址冲突。

12.4 设备分级

草案把设备分成 Tier 1、Tier 2、Tier 3：

  • Tier 1：终端设备，要求支持 DHCP8、ARP8、ICMPv8、双默认网关、NetLog8、管理 VRF、OOB VRF 等
  • Tier 2：二层设备，要求支持 802.1Q、自动 VLAN 创建、端口 OAuth2 绑定、PVRST 等
  • Tier 3：三层设备，要求额外支持 eBGP8、IBGP8、OSPF8、IS-IS8、WHOIS8 解析、边界 XLATE8 等

草案甚至明确提出：所有 IPv8 认证网卡都应在固件级别限制广播和未认证控制报文速率。

13. 安全注意事项

草案最后列出一组边界规则，核心包括：

  • 入站过滤必须验证收到分组的 r.r.r.r 是否与对端 BGP8 邻居 ASN 一致
  • 127.x.x.x 内部区前缀不得出现在 WAN 接口
  • 100.x.x.x 的 RINE 前缀不得出现在公网通告或非对等互联接口
  • 222.0.0.0/8 内部链路地址不得被当成外部可达地址接受
  • RFC1918 地址在 n.n.n.n 字段中仍保持公网不可路由
  • 保留的跨 ASN 路由协议多播前缀必须在边界过滤
  • 比 /16 更具体的外部前缀通告必须拒绝并记录

14. 结语

从翻译角度看，这份草案最特殊的地方不是它把地址变成了 64 位，而是它试图把“寻址、身份、日志、策略、路由验证和过渡机制”捆成一套统一秩序。

如果只把它看成一个“IPv6 之后的新版本 IP”，很容易低估它；它真正想做的是，把过去分散在网络边缘的各种补丁系统，重新纳入协议中心。

至于这套设想在现实里是否可落地，那是另一回事。但至少从文本本身看，它已经不再满足于做一个“更大的地址协议”，而是试图做一个新的网络控制面骨架。

原始来源