摘要

  • RFC 6666 把 100::/64 指定为 IPv6 Discard-Only Address Block。运营者可以在一个自治系统内传播它，并把它递归到 null 接口，但不应向第三方 AS 宣告，也不应从第三方接收。
  • 这个地址块不是受害前缀，不是 BLACKHOLE community，更不是数据包已被丢弃的回执。有效证据必须串起授权、路由接收、递归解析、FIB、入口丢弃计数、对外隔离与撤销恢复。
  • 该 Informational RFC 由 Nick Hilliard 与 David Freedman 合著。其价值是协作形成的操作清晰度：用全球唯一的名字描述严格受限的本地动作，而不是创造全球服务或强制部署命令。

控制面先宣布了成功

设想一个 IPv6 服务遭到大流量攻击。获授权的操作员向 iBGP 注入受攻击地址的 /128，把下一跳设为 100::/64 中的一个地址。各边界路由器都显示已接收，自动化系统随即把事件标为“黑洞已生效”。

这个结论早了一层。在三个入口，递归查找命中通往 null 接口的静态路由，数据包确实终止。第四个入口没有那条静态路由，BGP 对象没有成为可用的转发表项。第五个入口的出口策略又把丢弃前缀泄漏给邻居。控制面看见同一个对象，数据面却给出三种结果。

这不是对真实事故的描述，而是用一个合成场景划清 RFC 6666 能协调什么，以及它单独无法证明什么。

为本地动作准备一个全球唯一地址

目的地址 RTBH 会改写受攻击主机或网段的下一跳，让攻击流量在更靠近入口的位置被丢弃，避免继续占用内部链路和系统。早期 IPv4 做法常把受害路由指向私有地址，并在边缘设备上把该私有地址静态递归到 null 接口。这可以工作，却借用了原本承担其他含义的地址空间。拿文档示例地址做生产控制更不合适：示例不该变成故障处置的依赖。

RFC 6666 因此要求一个专用 IPv6 地址块。IANA 把 0100::/64 的规范写法 100::/64 登记为 Discard-Only Address Block，没有任何终端主体获得该前缀的分配。当前注册表把它标为可作为源、可作为目的、可转发，同时标为不可全球到达。

这些字段并不冲突。“可转发”让路由器在受控域内通过普通路由和递归查找使用它；“不可全球到达”则规定外部边界。它必须足够像单播地址，才能成为内部下一跳；又必须被禁止成为跨域目的地。

这里的注册表只做一件窄而重要的事：统一语义。IANA 不安装静态路由，不选择攻击入口，不批准受害前缀，不执行丢弃，也不承担合法用户断连的代价。记录负责可辨识性，运营者负责执行。

三种控制不能压成一个“黑洞”

目的地址 RTBH 与源地址 RTBH 不是一回事。前者牺牲目标地址的可达性以保护更大范围；后者把路由状态与 uRPF 结合，拒绝那些声称来自应当解析到丢弃路径的源地址。两者的授权、影响和失败模式不同，任何一边的成功都不能替另一边背书。

null 接口也不同于 sinkhole。前者销毁数据包，后者把流量引向分析设备，并可能按设计把部分流量重新送回正常路径。如果只用“黑洞”概括，就会看不见是否留存了证据、合法流量是否仍有后续路径，以及分析设备是否成为新的容量瓶颈。

100::/64 也不是 RFC 7999 的 BLACKHOLE community。地址块在一个路由域内提供稳定的递归下一跳；community 是附着在受害前缀上的建议性信号。邻居是否执行取决于双方约定和本地策略，还必须核验宣告方确实有权宣告这个前缀。设备不能仅因看见某个 community 值就自动丢弃。

因此，community 回执只能证明意图抵达。它不能证明对方接收了路由、写入了丢弃动作或限制了传播。反过来，一个 AS 可以只在内部使用 100::/64，完全不要求外部邻居理解 BLACKHOLE。前者稳定本地递归，后者跨越组织关系传递政策意图。

正确状态：内部存在，外部不存在

RFC 6666 允许在 AS 内通过动态路由传播 100::/64 的全部或部分，并在部分或全部 IPv6 路由器上把它指向 discard/null 接口。“部分”留下了真实设计选择：只在已知入口丢弃，还是在更多节点保留一致的内部兜底。答案取决于拓扑、硬件与处置目标。

到了跨域边界，要求恰好相反。这个前缀及其子网不应向第三方 AS 宣告，也不应从第三方接收；以它为目的的数据包也不应跨越第三方边界。泄漏会把额外流量吸向一个已经承压的网络，让减载工具反而扩大攻击面。

所以健康状态天然不对称：内部按需可解析，对外始终被过滤。一个“路由存在”的总开关无法表达这种状态，因为同一路由在边界一侧必须存在，在另一侧必须不存在。

六张相连的回执

第一张是授权回执：谁批准、精确受害前缀、允许范围、原因、开始时间和过期时间。它防止客户丢弃不属于自己的空间，也防止旧告警生成永久路由。

第二张是控制面回执：触发路由、community、下一跳、接收设备和策略判定。前缀长度、起源校验、RPKI 或畸形属性都可能让动作无法落地。被接收仍然只是 RIB 事件。

第三张是递归与 FIB 回执。每个预定入口都要证明受害前缀经由 100::/64 中的地址解析到预期丢弃接口。控制器、路由反射器或 RIB 中可见的路由，可能在优选中落败、递归失败，或根本没有写入硬件。

第四张是数据包回执。接口、转发或平台计数器应在指定入口显示丢弃，干净的探针则验证预期损失。零计数既可能说明没有流量抵达，也可能是入口判断错、遥测失灵或 FIB 从未生效。

第五张是边界回执。Adj-RIB-Out、邻居策略和前缀过滤要证明 100::/64 与未经授权的触发路由没有逃出域外。某个公共采集器沉默，不等于全球都没有泄漏；本地出口视图不可替代。

第六张是恢复回执：撤回触发、清除 FIB、恢复普通路由与终止授权都要分别留时间戳。历史累计丢弃只能证明过去发生过丢弃，不能说明黑洞现在仍在，也不能证明服务已经恢复。

合法用户的损失不是脚注

目的地址黑洞用目标地址的可用性换取更大系统的存续。攻击者与合法用户都会失去到该地址的连接，这正是机制本身的交易。把受害前缀收窄到能操作的最小粒度，可以降低连带损失，却不能把丢弃改写成可用性。

激活之后，团队应检查什么被保住了：共享接入链路是否降载，同一聚合中的邻近服务是否仍可达，攻击是否迁移到其他地址，源地址规则是否误把损失范围扩大。只看“流量下降”没有意义，因为这个工具本来就以销毁流量来制造下降。

Hilliard 的贡献是精度，不是所有权

Nick Hilliard 的 IETF 资料页列出六份 RFC。RFC 6666 与 David Freedman 合著，经 IETF 审议，以 Informational 发布。它不是个人标准，更不是所有网络都必须执行的命令。

真正耐久的思想更克制：生产控制应拥有自己的命名空间，而不应借用私有地址或文档地址；这个名字还必须让行动边界清晰可见。100::/64 的价值，既在于人人能识别其用途，也在于没有人应把它当作全球可达的服务。

注册表让动作可读。明确授权、运行中的系统与数据包证据才决定动作是否成功。

来源