摘要

  • RFC 9798 允许接收端 ETR 在 LISP 核心底层支持 IP 多播时，把多播地址写入 Receiver RLOC；“选一个自己能加入的组”仍是 ETR 的本地决定。
  • 根 ITR 要为每个唯一的底层多播映射分配一项出接口列表状态；若需追踪发起 Join 的 ETR，依据是 Join/Prune 的源 IP，而且该地址必须是 ETR RLOC。
  • 认证可以帮助确认请求的来源与完整性，但不会顺带证明组地址权属、底层能力、成员存在、数据转发或最终交付。

同一条消息里有两个不同的问题

设想根 ITR 收到一条 PIM Join/Prune：Transport 为 0，Receiver RLOC 是一个多播地址。这个地址回答的是“接收端 ETR 希望在哪个底层组上收到封装流”。它没有列出提出请求的 ETR，也没有列出 ETR 后面的主机。

RFC 9798 为前一个身份问题指定了另一处证据：如果 ITR 需要追踪 Join 来自哪些 ETR，就必须使用传入 Join/Prune 的源 IP；该源 IP 必须是 ETR 的 RLOC。于是，组值与发送者身份即便在一条控制消息中出现，也不能合并成一个“接收者”字段。

这份 RFC 于 2025 年 6 月以 Experimental 身份发布，更新 RFC 8059。更新范围很窄：它不改变既有 Transport Attribute 的语法或语义，只处理 Transport=0 的多播情形。单播 Receiver RLOC 仍表示单播封装的接收地址；多播 Receiver RLOC 则表示多播封装的接收组，而且只有 LISP 核心底层支持 IP 多播传输时才能使用。

“支持”在这里是规范条件，不是远程证明机制。RFC 9798 没有规定根端怎样验证某个接收站点确实具备能力。它明确把后续选择留给 ETR：ETR 选择一个自己能加入的底层多播组，确定底层树应扎根的上游 LISP 站点，再依照 RFC 8059 构造 Join/Prune。实际系统要证明这项选择，就得保留能力观测、配置版本、范围策略和本地决策记录；一个组地址无法替代它们。

映射比例决定成本落在哪里

RFC 6831 的基本模型把站点内的 (S-EID,G) 状态与核心中的 (S-RLOC,G) 状态分开。ITR 封装，核心多播树可以在途中完成复制，接收端 ETR 解封装后再检查内部源与组状态。

RFC 9798 列出三种覆盖层到底层的关系。多个 (root-EID,G) 流可以汇入一个 (root-RLOC,G-u)；一个覆盖层流也可因下游 xTR 要求而拆成多个底层流；或者每个覆盖层流保持唯一底层映射。

三种选择不是单纯的地址编排。多对一节省核心树状态，却可能把某个源的封装流量送到没有订阅该源的站点。RFC 6831 说明，ETR 只能在解封装、检查内部 (S-EID,G) 后丢弃它。一个对多个可以跨越不同组地址范围，但会让根端产生更多复制。一个对一个提高隔离度，同时增加映射与转发状态。

根 ITR 的责任单位很明确：每收到一个唯一的底层多播映射，就在出接口列表中分配一个新条目。ITR 可以用本地策略限制它需要制作的副本数；RFC 9798 不替运营者设定配额或优先级。因此，容量证据必须记录映射键、OIF 条目、请求副本数、准入副本数和限速原因，不能只写“使用多播后更省带宽”。

组地址范围也会把一个覆盖层流拆开。PxTR 连接站点侧与外部 LISP 核心时，两侧可能使用不同范围。硬件资源限制也可能让平台只能支持某段底层多播地址。组的可用性来自特定边界、平台和策略时期，不是地址本身携带的永恒属性。

能解析属性，不等于发现了能力

RFC 5384 定义 PIM Join Attribute 的通用 TLV 载体，并指出：如果属性会影响树的建立，它只有在合作域内预先确认沿途设备理解编码和具体属性时才有用。普通 PIM 用 Hello 选项避免把特殊编码送给不理解的邻居。

LISP 的接口处不同。RFC 8059 明说 xTR 不交换 PIM Hello，因此没有 Hello 选项为这些属性协商支持；支持单播头端复制的系统被假定支持这些属性。Transport 和 Receiver RLOC 都是非传递属性。RFC 9798 把使用范围扩展到多播底层，却没有新增统一的能力发现或全球组分配协议。

这正适合用最小初始规范来理解：只标准化互操作所需的信号，把确实属于本地的未来选择留在本地。但本地决定必须留下可核验的收据。属性解析成功只证明表达层；范围配置只证明意图；OIF 条目证明控制状态；运行计数器证明数据路径发生过活动；接收端记录才证明结果。把这些层压成一个绿色“有效”标志，会丢掉最重要的信息。

认证只能收窄一类不确定性

RFC 8059 指出，Join Attribute 的安全性取决于承载它的 PIM 报文，属性本身不增加真实性。RFC 9798 又指出，大量使用不同或重叠组地址的 Join 可能干扰合法流量，并因复制请求造成资源耗尽。它说可以采用 RFC 5796 的 PIM 认证验证请求，也可考虑跟踪机制或按源 ETR RLOC 设置最大组数。

这里的“可以”不能改写成强制授权制度。RFC 5796 针对 PIM-SM 链路本地消息给出基于 IPsec 的保护以及密钥、对等方认证要求。在正确配置并能读回安全关联的环境中，它能支持“这条消息由谁发出、途中是否被改动”的判断。它不能证明发送者拥有该组、每段底层都支持该组、存在真实成员，或数据已经抵达。

完整证据链应按时间和关联键串起：Join/Prune 原始字节、解析后的两个属性、认证与安全关联、源 ETR RLOC、ETR 本地组选择、根站点、映射比例、OIF 状态、限速结果、核心树与计数、ETR 解封装、内部转发和应用接收。哪一段缺失，就只对哪一段保持不确定。

来源