摘要

  • RFC 9647 为 Babel 定义了标准化的 YANG 1.1 管理模型，使网络管理系统能够以结构化方式观察和配置 Babel 的关键对象，包括启用状态、常量、接口、MAC 密钥集合、DTLS 对象以及路由状态，而不是依赖设备私有表示。
  • 一个 selected 路由状态并不是独立的转发成功证明。它只是管理模型中对实现状态的投影，运营者仍需要连接接口策略、认证结果、邻居时间线、RIB/FIB 安装以及真实数据包可达性，形成完整证据链。
  • RFC 9647 明确限制了 YANG 模型本身的能力：YANG 无法强制实现必须填充只读信息模型中的必备属性，相关数据需要由实现主动提供。因此，缺失状态字段本身可能成为审计问题。
  • 对 Babel 的运营验证应采用多收据链方法：确认模型版本与能力、数据存储来源和时间、只读状态存在性、接口分类、默认与覆盖策略、密钥和 DTLS 绑定、认证结果、邻居与路由演进、RIB/FIB 安装，以及最终的数据平面验证。

Babel 的管理难点长期存在于“协议知道什么”和“运营者能够证明什么”之间。路由表中出现一条已选择路径，并不意味着所有中间环节都已经被验证。管理系统可能看到某个前缀被选择，然而该状态是否来自正确的数据存储来源，接口是否采用了符合预期的参数，邻居是否完成了真实认证，转发平面是否安装了对应下一跳，以及故障之后是否能够恢复，仍然需要独立检查。

RFC 9647《A YANG Data Model for Babel》试图解决的是可见性和控制接口问题。该标准于 2024 年 10 月作为 Standards Track RFC 发布，定义了 ietf-babel YANG 1.1 模块，兼容 NMDA（Network Management Datastore Architecture），并建立在 RFC 9046 的模型基础上，用于 Babel over IPv6 的管理。标准正文可见于 RFC 9647，相关出版信息见 RFC 9647 Info 页面，工作记录见 Datatracker RFC 9647 页面。

从“路由存在”到“证据链存在”

传统网络运维容易把路由选择状态当作最终答案。对于 Babel，这种做法尤其危险，因为一个管理视角中的状态字段只代表模型能够表达的部分事实。

RFC 9647 中的路由状态包含多个关键字段，例如前缀、路由器 ID、邻居、接收或计算得到的 metric、序列号、下一跳、feasible 和 selected。这些字段能够帮助管理系统回答“实现报告了什么”，但不能单独回答“数据包是否真的按照预期路径到达”。

例如，一个路由条目显示 selected，可能意味着 Babel 实现认为该路径符合选择条件。但完整运营证明还需要确认：

  1. YANG 数据来自正确的数据存储和正确时间点；
  2. 相关接口实际启用了预期 Babel 行为；
  3. 邻居交换经过预期认证机制；
  4. 路由进入系统后确实安装到了转发路径；
  5. 数据包级测试证明端到端可达；
  6. 链路变化或故障后恢复行为符合预期。

因此，RFC 9647 提供的是观察窗口，而不是自动生成的可信证明。

RFC 9647 把哪些对象变成可管理对象

该模型覆盖 Babel 管理生命周期中的多个层面。

首先是管理意图和运行状态。enable 叶节点表达管理员是否希望启用 Babel。在 running/intended 数据存储中，它体现的是行政意图；在 operational 数据存储中，它代表实际运行状态。两者之间的差异本身就是重要信号：配置被提交，并不意味着系统已经按照该配置运行。

其次是接口行为。RFC 9647 为接口级 Babel 配置提供模型基础，使运营者能够检查哪些接口参与协议运行，以及相关参数如何应用。但接口分类仍然需要验证。无线接口、有线接口、隧道接口、计量链路以及特殊回退链路可能具有不同风险和策略需求。

第三是安全相关对象。模型包括 MAC key sets 和 DTLS 对象，用于描述安全配置结构。RFC 9647 允许通过管理模型表达这些对象，但敏感材料并不是普通状态数据。MAC 密钥和 DTLS 私钥受到 NACM（Network Configuration Access Control Model）保护机制约束，相关访问控制能力来自 RFC 8341。

默认值不是事实，必须验证实际生效结果

Babel 的接口参数存在根据介质类型设计的默认行为。RFC 9647 描述了不同接口环境下的默认策略：有线接口默认采用“两取三”（two-out-of-three）机制并启用 split horizon；无线接口默认采用 ETX，并不启用 split horizon。

这些默认值降低了初始配置成本，但也产生了审计要求。网络环境并不总是简单分类。例如，无线电设备可能通过有线端口接入，隧道可能承载类似无线链路的动态特征，计量回退链路可能需要不同的定时器和策略。

因此，“接口存在”不是足够证据。运营者需要确认：

  • 实际接口分类是否符合模型假设；
  • 默认值是否被覆盖；
  • 覆盖值是否真正进入 operational 状态；
  • 定时器选择是否与故障恢复目标匹配。

一个配置文件中的参数不是最终运行事实，最终运行事实必须来自生效状态和行为观察。

自动应用机制带来的隐藏连接点

RFC 9647 还涉及 MAC 和 DTLS 默认应用设置。这类默认设置可以为新创建接口提供引用关系，从而减少重复配置。

然而，自动引用并不等于自动验证。

运营环境需要证明：

  • 新接口是否继承了预期安全对象；
  • 默认应用规则是否覆盖了错误范围；
  • 每个接口最终引用的是哪个 MAC 或 DTLS 对象；
  • 实际认证交换是否使用了这些身份材料。

尤其是在动态接口数量变化时，配置层面的便利可能增加状态关系的复杂度。

YANG 能描述安全模型，但不能替代协议安全验证

RFC 9647 的安全章节明确限定范围：它讨论的是 YANG 模型本身的安全问题，而不是完整 Babel 协议安全分析。Babel 协议、MAC 机制和 DTLS 相关安全考虑分别由 RFC 8966、RFC 8967 和 RFC 8968 处理。

这一区分非常关键。

YANG 模型可以告诉运营者：

  • 存在某个 MAC key set；
  • 存在某个 DTLS 对象；
  • 接口引用了某个安全配置。

但它不能单独证明：

  • 对端真正使用了相同身份；
  • 握手成功；
  • 邻居关系未被异常建立；
  • 数据包受到预期保护。

管理模型提供可见性，协议运行提供真实性，两者需要结合。

十个收据：从模型状态到网络事实

一个成熟的 Babel 审计流程应避免单点判断，而建立十个连续收据：

第一，模块修订与能力收据。 确认加载的是正确版本的 ietf-babel YANG 1.1 模块，并确认实现声明的 feature 能力。

第二，数据存储来源与时间收据。 记录状态来自 intended、running 还是 operational 数据存储，并保存采集时间。

第三，只读状态完整性收据。 确认实现是否填充了 RFC 9647 要求观察的只读状态。

这一点尤其重要，因为 RFC 9647 明确指出，YANG 本身不能强制实现提供信息模型中的 mandatory read-only 属性。缺少数据可能不是协议失败，但可能意味着实现或部署验证不足。

第四，接口分类收据。 证明接口类型判断正确，而不是假设某个接口必然属于有线或无线类别。

第五，默认和覆盖收据。 确认最终生效参数，而不是只检查配置输入。

第六，MAC/DTLS 身份和绑定收据。 确认安全对象存在、引用关系正确，并受到适当访问控制。

第七，认证和握手结果收据。 证明邻居关系建立经过预期认证过程。

第八，邻居和路由时间线收据。 结合邻居变化、序列号、metric、feasible 和 selected 状态观察演进过程。

第九，RIB/FIB 安装收据。 证明管理模型中的路由状态进入实际路由和转发系统。

第十，数据平面与独立可达性收据。 通过实际流量测试、故障切换测试或外部观测验证最终效果。

这十个收据连接起来，才构成从管理状态到网络事实的证明链。

证据边界：RFC 9647 不承诺什么

RFC 9647 不承诺所有实现都会暴露完整状态，也不承诺所有管理系统都能够自动发现配置错误。标准定义的是模型，不是统一实现质量。

同样，RFC 9647 中的 selected 字段不是独立的网络测量结果。它表达的是实现状态中的选择结果，而不是一个外部验证过的数据平面结论。

运营者需要避免三个常见误区：

第一，把 YANG 数据当作网络现实的替代品。 第二，把默认配置当作实际生效配置。 第三，把路由选择状态当作可达性证明。

正确的方法是把 RFC 9647 作为审计入口，然后通过协议、安全、转发和测试证据完成闭环。

Sources