摘要

  • RFC 7999 定义了知名 BLACKHOLE 社区，注册值为 65535:666，使源网络能够请求邻网丢弃发往特定前缀的流量。
  • 这个标签是建议，不会自行产生授权：接收方只有在事先同意、发送方有权通告该地址空间、本地策略明确启用且传播范围受控时，才应执行。

这个信号请求的是一次有意失败

多数路由信号追求可达性，BLACKHOLE 要求的却相反。DDoS 攻击若持续涌向一个目标地址，可能先堵满跨网链路，让更大范围的服务受损。受害方或服务提供商因此可能选择牺牲目标地址的可达性，让攻击流量在瓶颈之前被丢弃。

RFC 7999 为此定义统一的 BGP 社区。IANA 将 BLACKHOLE 登记为十六进制 0xFFFF029A，通常写作 65535:666。源 AS 可以把它附在覆盖受害地址的前缀上；参与机制的邻网可以把标签解释为丢弃发往该前缀数据包的请求。

简单代码背后是明确的权力分配。发送方指出哪一个目的地址可以被牺牲，接收方拥有真正执行丢弃的设备。如果标签被视为无条件命令，邻居就可能把普通路由通告变成远程制造丢包的控制面。RFC 7999 并没有授予这种权力。

执行之前必须先有授权

在双边对等关系中，双方必须先约定使用 BLACKHOLE，之后发送方才能通告它。接收网络还必须显式配置设备予以识别；如果没有运营者指令，设备不应仅因看见标签就丢弃流量。

这是第一条授权边界：识别一个标准值，不等于同意执行。接收方决定哪些会话具备这项能力、哪条策略触发它，以及本域采取什么动作。多边对等场景中，是否接受仍由各运营者的路由策略决定。

第二条边界是地址权。接收方只有在该黑洞前缀被邻居有权通告的等长或更短前缀覆盖时，才可以执行。事先协议并不允许客户、对等方或路由服务器参与者黑洞任意地址空间。请求必须留在发送方已经建立的路由授权范围内。

前缀精度决定谁承担代价

黑洞前缀应尽可能具体。RFC 7999 指出，典型选择是 IPv4 /32 或 IPv6 /128。这不是格式偏好。过宽的聚合会让未受攻击的相邻地址一并失联；最大限度具体的前缀能把有意中断限制在最小目标。

受益者不只有受害主机。攻击流量在瓶颈前被丢弃后，上游容量、相邻服务和其他用户可能继续可用；未受影响的地址也受益于严格范围。但成本同样真实：目标地址的合法流量会与攻击流量一起丢失。BLACKHOLE 是受控牺牲，不是恢复服务。

规范没有证明全网部署率、厂商默认行为，也没有证明任何具名运营者在哪个会话上执行该社区。它也不验证请求背后的攻击叙事。真实授权来自 BGP 会话关系、前缀过滤和接收方策略，而不是 65535:666 这个数字本身。

传播必须默认留在本地范围

接收方应根据本地策略附加 NO_ADVERTISE、NO_EXPORT 或类似控制，避免黑洞路由越过预定路由域。更具体的丢弃路由若意外泄漏，可能影响从未同意该能力、并采用不同过滤规则的网络。

因此授权之后还需要第二类证明：路由只在预定位置被接受，没有继续扩散。RFC 7999 鼓励长期保存携带 BLACKHOLE 的更新以供分析或审计。一条可用记录应把请求邻居、前缀、覆盖授权、会话协议、策略动作、传播控制、启用时间和撤销动作串在一起。

证据与边界

RFC 7999 支撑的是明确而有限的事实：建议型社区、双边协议、覆盖前缀检查、显式配置、尽可能具体的前缀、本地传播控制和更新留存。RFC 1997 提供社区属性语义，RFC 4271 提供 BGP 上下文，IANA 登记具体代码点。

领导力结论属于推论：BLACKHOLE 应被治理为窄范围、可撤销的应急授权。规范不能证明任何网络正确部署，也不能证明某个前缀正在遭受攻击或黑洞操作取得成功。本文不对任何运营者或厂商提出指控。

来源