摘要

  • RFC 8092 把 Large Community 定义为三个 32 位字段，解决了四字节 ASN 与完整本地数据的表达问题；它没有给数值签名，也不证明左侧 ASN 写入过该值。
  • 真正的操作权来自接收网络：它把某一邻居、关系类型、函数与参数映射为 LOCAL_PREF、出口、next-hop 或 prepend 等动作。证据必须从原始 UPDATE 一直走到 RIB、FIB 和实际流量。
  • 安全部署要区分信息与命令，清理未获准使用的本方命名空间，保留有用的外部上下文，规定集合冲突与聚合语义，并用授权和未授权 canary 同时验证迁移。

三个接收者，三种现实

设想一家多宿主客户 AS 4200004100。它同时连接两家 transit provider，并通过一个 IXP route server 交换路由。第一家供应商公布了一份 Large Community 字典：一项函数用于在指定地区降低 LOCAL_PREF，另一项用于禁止向某类 peer 出口。客户为一个安全的测试前缀写入对应值，希望把流量从拥塞链路移走。

供应商甲先判断这条 session 是否属于获准使用函数的客户，再检查地区参数和禁止出口对象是否在合同范围内。Adj-RIB-In 保留收到的原值，policy trace 记录授权命中，Loc-RIB 显示 preference 变化，逐邻居 Adj-RIB-Out 展示出口边界，FIB 与探针共同证明流量已经转移。

供应商乙正处于半完成迁移。边缘设备能解析 Large Communities，旧导入规则却在进入公共策略前删掉整个属性。Session 一直是 Established，prefix count 也正常，路由仍然可达，但请求从未进入决策程序。只看 BGP 邻居健康的监控会把它判成成功。

供应商丙的问题恰好相反。它只匹配自己 ASN 开头的数值，却不先检查哪个 peer-group 可以调用这项函数。于是普通 peer、甚至客户的下游，也能合成一条格式完美的命令。对方没有攻破编码；接收者把一个公开的名字误做成了 capability。

这三条路径都可以符合 RFC 8092 的 wire format。差异发生在“能表示”“谁写入”“谁获准”“本地怎么解释”“是否真的执行”之间。任何一层的成功，都不能替后一层作证。

十二字节究竟修复了什么

RFC 1997 的传统 Community 只有四字节。业界常把高低各 16 位读作 ASN:本地值。这种习惯简单有效，但 ASN 扩展到四字节后，高半区无法容纳完整号码。

Extended Community 带来类型和八字节空间。RFC 5668 提供四字节 ASN 专用格式，不过 Global Administrator 占四字节后，Local Administrator 只剩两字节。它适合自身定义的有类型用途，却无法同时承载完整 ASN、完整函数和完整参数。

RFC 8092 采用三个四字节字段：Global Administrator、Local Data Part 1、Local Data Part 2；IANA 为它登记 path attribute type code 32。RFC 8195 给出容易理解的运行约定：ASN:Function:Parameter。

这份设计刻意没有建立全球统一函数表。每个网络可以声明入口位置、关系等级、选择性出口、prepend 次数或 preference 请求。最小初始规范让采用者先在本地形成可运行约定，再通过自愿协调扩展。但自由也意味着：协议只搬运容器，命令的权力只能由接收者的运行策略产生。

命名所有者不是认证作者

RFC 8092 建议 Global Administrator 使用 ASN；当它这样使用时，ASN 持有人负责解释后两个字段。这是一条命名规则，不是一条密码学断言。

看到 64497:9:3，不能推出 AS 64497 亲自添加了它。它可能来自 origin、某个中间 AS 或当前邻居；中间网络也可能增加、删除或改变值。规范明确允许这些处理，并指出属性没有完整性保护。

数字看似合理，也不等于主体验证。规范不鼓励用 0、65535 和 4294967295 作为 Global Administrator，但保留、未分配或未注册的号码不会自动使十二字节变成 malformed。Parser 回答编码是否成立；字典回答本地如何解释；授权表回答这个邻居是否可以造成相应动作。三种判断必须留下三种证据。

单跳 session protection 能帮助识别眼前的 peer，却不能证明一个 transitive attribute 最初由谁创建、途中是否保持不变。RPKI origin validation 也只回答 origin AS 是否在可用 ROA 下有权起源某个前缀；它不验证 community 作者，更不授予修改另一 AS 内部 LOCAL_PREF 的权力。

同一格式装着事实与命令

RFC 8195 把常见用途分成 informational 与 action。信息值可以记录从哪里学到路线、邻居关系、预期受众；动作值会要求改变传播、LOCAL_PREF、next-hop 或 AS_PATH prepending。

比特本身没有风险标签。同一 tuple 在一个版本里可能只是 telemetry，在另一台设备上却触发路由变化。若字典未公开、没有版本、或平台间不一致，问题并不表现为语法错误，而是相同符号拥有不同权力。

命名空间应给信息和动作划分不同区间。每个动作需要负责人、允许发送者、参数域、冲突优先级、AFI/SAFI、失效规则与 rollback。所谓“地区 3”必须对应明确的设备和出口集合；prepend 次数要有上限；只对直连客户开放的函数不能因为共享配置片段而落到所有 peer-group。

RFC 8195 鼓励运营商公开它支持或传播的含义。公开字典解决的是协作层。当前路由器加载哪个版本、收到哪条路由、命中哪条规则、产生何种转发变化，才属于运行现实。

清理自己的命令，别抹去他人的上下文

RFC 7454 提供了一条精确边界：入站时清理使用本网络 ASN 的 communities，只保留该客户或 peer 被允许发送的信号；同时不要无差别删除外部 communities，因为客户可能用它们同更远网络通信。

应用到 Large Communities，至少需要四类集合。第一类是这个邻居获准调用的本方 action；第二类是按合同可接受或由本方附加的 informational value；第三类是本网络不解释、但下游可能需要的外部值；第四类是未授权、弃用、关系不适用或组合危险的值。

“全部保留”会让 outsider 伪造 provider-owned action；“全部删除”会破坏合法的跨网协调。为了添加本地标记而替换整个集合，也会擦掉之前的证据。Additive 方式能保留上下文，却需要显式清除过期版本和处理互斥值，不能任由历史无限堆积。

Route server 是有意开放控制面的特殊服务。RFC 7948 描述客户按接收者控制出口的环境，RFC 8195 也列出 announce-to-all、announce-to-none 与特定例外。客户影响 per-client Adj-RIB-Out 正是契约内容，并非天然漏洞。运营方仍要认证 session，把函数限定到对应客户，定义冲突规则并逐接收者证明结果。为这种 broker 设计的例外不应复制到普通 transit 策略组。

集合没有“第一条命令”

RFC 8092 把属性定义为无序集合。编码顺序没有语义。若策略以“第一个值优先”解决冲突，它依赖的是实现偶然性，而不是协议保证。

发送方不应发送重复值，接收方会静默去重。因此两个相同 tuple 不能表示两次投票或两个作者背书。匹配语义也要明确：contains、match-any、match-every 与 exact-set 不是同一个问题。Cisco IOS XR 文档展示了匹配、additive set、delete 和过滤能力；FRRouting 可以输出值与 exact set，并支持 JSON。这些工具提供 readback，不替运营方选择安全规则。

聚合进一步削弱直觉。规范要求 aggregate 携带各 contributing route 的 Large Community 并集。它保存信息，却不表示所有 more-specific 一致同意。一个贡献者要求地区备份，另一个要求选择性出口，aggregate 可能同时继承两项。只有单独定义哪些动作可穿越聚合，并保留贡献来源，才能避免把 union 当成 consensus。

Malformed 与 unauthorized 是两条故障线

Large Communities attribute 的 value length 必须是非零的十二字节倍数。否则 RFC 8092 依据 RFC 7606 执行 treat-as-withdraw。

这种处理避免整条 BGP session reset，却也会藏在绿色监控后。KEEPALIVE 继续、peer 仍为 Established、无关路线照常存在，只有受影响 NLRI 从 Adj-RIB-In 消失。必须把原始 attribute error、路由变化与服务影响关联起来。

格式正确但发送者无权的 tuple 则应该进入授权判定并得到可审计结果。合同可以要求剥离本方 action 后保留路线，也可以拒绝或隔离。若把所有权限失败都叫“malformed”，就无法辨认是 parser、字典还是 principal boundary 出错。

迁移的是分布式程序，不是一列数字

从传统 Community 迁到 Large Community 时，生产者、edge policy、route reflector、route server、collector、客户文档与事故工具必须共享一个策略 epoch。只升级 parser 远远不够。

双重标记能兼容旧邻居，也会在两套规则都执行时造成重复动作；若旧值与新值的参数映射漂移，还会产生相反结果。Collector 收到新 tuple 只证明 transport path，没有证明 decision process 已采用它。

Canary 应使用结果安全且可独立测量的前缀。记录入站 legacy 与 large 集合、scrub 后的 normalized set、确切 policy version、属性变化、相关 Adj-RIB-Out、best path、FIB next-hop 和 packet behavior。授权发送者与未授权发送者都要测试；非法长度留在实验室；服务会聚合就必须测试 union。

Rollback 必须写明状态恢复。删掉新规则后，早先改变的 LOCAL_PREF 可能继续影响选择，直到 policy re-evaluation。Route refresh 可以重建视图，但必须控制范围和时机；hard reset 的收敛代价更大。若多方已经落入 RFC 4264 所说的 BGP wedgie，单机配置恢复并不保证流量回到目标状态，可能需要协调动作。

一份不越级的证据账本

每条接收路线都应保留 peer、关系类型、prefix、AFI/SAFI、session epoch、原始集合、解析结果、normalized set、被删与本地新增值、字典版本、授权结果、命中规则和产生的属性。再连接 Loc-RIB 选择理由、逐类 Adj-RIB-Out、FIB next-hop 与 packet probe。

这样可以分别回答：值是否被搬运；编码是否成立；主体是否有权；在当时版本里是什么意思；规则是否执行；转发是否改变；意义是否继续传到下游。

公共 collector 只能提供某个观察点的出口证据。它无法重建所有中间改写，无法认证第一个作者，也看不到只在别家 AS 内部执行的 preference 动作。缺席可能来自清理、best-path、聚合或不同出口视图，不能被提升成唯一因果证据。

Sources