摘要

  • RFC 7067 和 RFC 8171 让 TRILL 边缘设备以 Push 或 Pull 目录映射替代部分未知单播、ARP 与 ND 泛洪，但“不知道这个地址”和“确认这个地址不存在”只有在不完整与完整目录之间才有清楚边界。
  • RFC 8302 与 RFC 8380 进一步让映射参与缓存、代理应答和预封装。目录越早影响转发，错误映射的破坏面越大；认证、完整性声明、相对置信度、缓存寿命与运行中观测不能互相替代。

分析

最危险的不是没有答案

没有答案时，网络还会继续寻找。最危险的是目录给出一个看似充分的旧答案，让接收者不再寻找。虚拟机从 RB1 迁到 RB2 后，IP 地址和 MAC 地址可以不变，真正变化的是可达位置。此时，缓存里指向 RB1 的记录在语法上仍然成立，在运行意义上却已经失真。

传统泛洪的缺点是昂贵：一个边缘不知道目的地址，就要让更大范围的网络共同参与发现。目录辅助的价值在于把重复询问换成明确映射。Push 模式预先分发地址与位置；Pull 模式在遇到未知地址时查询，并允许客户端保留回答。数据中心规模越大、虚拟机变动越频繁，减少未知单播、ARP 和 IPv6 Neighbor Discovery 泛洪的吸引力就越大。

RFC 7067 在 2013 年 11 月提出问题与高层设计，作者为 Linda Dunbar、Donald Eastlake、Radia Perlman 和 Igor Gashinsky。它是 IETF 的 Informational 文档，不是 Internet Standards Track 规范。RFC 8171 则由 Donald Eastlake 3rd、Linda Dunbar、Radia Perlman 和 Yizhou Li 合著，于 2017 年 6 月进入 Standards Track，给出具体的 Push、Pull、查询、响应、更新和确认机制。

Linda Dunbar 还与 Yizhou Li、Donald Eastlake 3rd、Radia Perlman、Muhammad Umair 合著了 2018 年 1 月的 RFC 8302，并与 Donald Eastlake 3rd、Radia Perlman 合著了 2018 年 5 月的 RFC 8380。两者同属 Standards Track。她的 IETF Datatracker 记录能够证明参与，不能把集体工作改写成个人发明，更不能证明任何具体部署的效果。

“查不到”有两种含义

目录覆盖不完整时，查不到一个地址，只能说明当前目录没有记录。目录确实覆盖某个 Data Label 的全部相关端点时，查不到才可能支持更强的判断。RFC 8171 让 Push 服务器声明自己是否拥有完整信息，并使这种声明直接改变接收者的动作。

如果一个 RBridge 已经收到完整映射，它面对目录中不存在的单播目的地址时，可以不再泛洪，而是丢弃帧。这个动作正是规模收益的一部分。可一旦所谓“完整”实际上仍有缺口，同一个优化便会丢掉本来可达的流量。

因此，完整性不是数据库的宣传标签，而是一项会授权执行的主张。不完整目录里的缺席意味着“此处未知”；经过证明的完整目录里的缺席才接近“在这个范围内不存在”。若接口只返回一个统一的 not found，接收者就无法知道应当继续发现还是停止发送。

RFC 8171 还保留了另一个重要界面。Primary server 必须通过旨在保证新鲜度的可靠机制获得数据，但这一机制本身不在规范范围内。协议可以忠实地分发一条映射，却不能凭协议格式证明编排系统已经看见最新迁移。Secondary server 也可能准确复制 primary 的过时信息。

这正说明，传递真实性与事实真实性不是同一件事。认证能说明回答来自预期会话；加密能保护途中内容；二者都不能证明终点仍在原来的边缘。目录记录必须允许外部观测纠正它，而不是靠来源身份抵抗纠正。

负缓存也会过期

Pull 回答之所以有价值，是因为客户端能缓存它。于是系统出现两个时间：服务器里的当前信息，与各客户端仍可能保留的旧信息。正缓存会在端点移动后指向旧位置；负缓存会在新端点创建后继续宣称没有数据。后者不会把报文送错地方，却可能让新服务持续不可见。

RFC 8171 要求：只要 Pull 服务器发出的回答 Lifetime 不是零，就必须通过 Update 消息尽量缩短客户端继续使用过时信息的时间。规范给出三种一致性记录方法。最粗粒度的方法只按 Data Label 记住回答何时到期，变化时可能需要大范围清空。最细粒度的方法追踪哪些客户端可能缓存了哪条正面或负面回答，以及预计到期时间，从而定向更新，但服务器要承担更多状态。

这是一项真实的资源交换。服务器保存得少，就要让更多客户端重查并接受更大范围的失效；服务器保存得细，就要维护关于远端缓存的缓存。即使机制完全实现，RFC 仍承认目录内容已变化、客户端旧数据尚未更新或删除的短暂窗口。

所以 Lifetime 不是“在此期间必然正确”，而是“在此期限内允许依赖”。值越长，查询越少，移动后错误持续的窗口越长；值越短，纠错更快，控制流量和服务负担更重。具体选择必须面对环境里的真实移动频率，而不能只追求缓存命中率。

置信度表达判断，不生产事实

RFC 8302 让 IP、MAC 与 Data Label 绑定进入 ARP/ND 优化缓存。这些绑定可能来自管理系统、目录或其他控制平面，也可能来自数据平面学习。不同来源会冲突：未使用 SEND 的 ARP 与 ND 容易伪造，受保护的管理记录也可能配置错误或更新滞后。

置信度机制允许 RBridge 为来源配置相对可靠性。目录信息若已经证明完整且可信，就能限制伪造 ARP/ND 在本地链路上的破坏。若目录不完整或可靠性有限，就可与数据平面学习并存，由置信度仲裁。规范没有规定全世界统一的优先级，如何分配由实现决定。

这项本地选择很关键。把“来自目录”直接等同于高置信度，只是把权威藏进默认值。可审计的策略应说明为什么某类来源胜出、什么新证据可以推翻它、优先级维持多久，以及发生冲突时是否保留可达性。

端点移动提供了最直接的检验。RFC 8302 要求本地动态项在学习它的链路失效后移除，并建议未刷新绑定按时老化。当终端从一个边缘迁移到另一个边缘，新位置应替代旧位置，其他边缘也应更新。目录是否可信，不取决于它有多集中，而取决于它能否追上这一可观测变化。

越早据此行动，错误越昂贵

RFC 8380 允许受信任的非 RBridge 节点借助目录信息预先封装 TRILL 流量。节点提前知道目的端所在的 egress RBridge，便可减少中间发现与泛洪，也把一部分边缘工作推向更靠近源的位置。

规范同时明确写出代价。不受信的辅助节点可以伪造 ingress 或 egress nickname，也能伪造内外层 MAC 地址，并可能获知大量 TRILL 拓扑信息。若目录到辅助节点之间的路径遭攻击，虚假映射可把报文引向错误终点，甚至违反哪些端点应接收哪些数据的安全策略。RFC 因此建议双方认证与加密，同时维持补丁、合理配置和最小访问权限。

但加密只能保证旧答案安全抵达，不能把旧答案变新。认证回答“谁说的”，完整性回答“声称覆盖多少”，置信度回答“接收者如何排序”，Lifetime 回答“最多相信多久”，Update 回答“变化如何扩散”，实时流量回答“现在是否仍然如此”。把其中任何一个当成全部证明，都会让一个保护良好的错误获得更大影响力。

目录必须服从它描述的网络

Lu Heng 后来提出的最小初始规范、本地化未来决策与自愿采纳，为 Sofia Ren 提供了一种阅读这套机制的视角。共同层只需要表达互操作所必需的地址、位置、范围、模式和更新语义；置信度策略、缓存时长、回退方式与风险接受仍留在承担结果的本地系统。这是后来的编辑分析，不是对 RFC 作者思想的归因。

运行代码优先则给出更严的证据标准。目录之所以有意义，是因为运行系统会依据它转发；也正因为如此，运行结果必须能反驳它。若链路、迁移事件或报文路径与记录不符，记录应当过期、降级、纠正或被绕过。记录员可以描述可达性，不能获得否定可达性的特权。

四份 RFC 没有提供厂商覆盖、部署普及、实际泛洪降幅、收敛时间、丢包率或安全事件结果。它们能证明的是另一件事：只要目录回答开始替代网络发现，就必须保留“信息来自哪里、覆盖多少、谁还缓存、何时过期、怎样纠错、真实转发是否同意”这些界面。

好的目录让网络少问一次。可信的目录必须允许网络在它错时重新发问。

来源