摘要

  • RFC 2042 将 BGP 属性类型值 255 保留给开发阶段。准备在互联网中正式使用的新属性，应写入 RFC、由 IANA 分配唯一 type code，随后把文档与代码库一并改成获准号码。
  • 该文明确否定把属性码空间划成 public/private 或 Internet/OSI 区段。因此，看到 255 既不能证明它是厂商私有扩展，也不能证明互操作、部署、采用、安全、兼容或授权。

把 255 想成开发工位上的黑色圆片，会比把它想成一块私有领地更接近 RFC 2042。

工位上的几件实验装置都可以贴同样的圆片，因为周围的人知道各自正在做什么。圆片只表示“尚在开发”，并不负责告诉陌生人装置的结构、语义或所有者。只要实验留在受控环境里，这种刻意的非唯一性能够节省公共号码，也允许设计反复变化。一旦离开本地上下文，同一标签就会暴露它的局限：陌生接收者无从仅凭 255 判断后续字节应按哪一种属性格式解释。

RFC 2042 所解决的正是这个出门时刻。它不是一篇泛论 BGP 路由选择的文章，也没有给实验流量颁发某种私有通行证。它描述的是协议扩展如何从本地约定变成公共可辨认身份。

1997 年的一条窄边界

RFC 2042 于 1997 年 1 月以 Informational RFC 发布。RFC Editor 现在把它归入 Legacy stream；IETF Datatracker 还明确提示，它未获 IETF 背书，在 IETF 标准流程中没有正式地位。因此，今天重读这份文档，首先要尊重其历史身份：它记录了一套协调办法，而不是可随意扩张的现代标准授权。

当时的 RFC 1771 描述了 BGP-4 以及路径属性机制。RFC 2042 的问题很具体：一个新的属性类型，怎样从开发代码里使用的临时值，变成互联网中不会与其他公共属性冲突的号码？

文档给出的流程包含三个动作。开发期间使用保留的单字节值 255；准备正式使用时，以 RFC 记录该属性，并向 IANA 取得唯一 type code；完成分配后，再把文档和代码库更新为获准号码。

这不是一串可以互相替代的手续。RFC 让公开语义可查；IANA 分配让号码在相应注册表内唯一；代码更新让实现开始发出那个公共身份。任何一步都不能自动证明另外两步已经发生，更不能证明软件实际部署、对端正确处理或网络运营者认可了该行为。

文档随后排除了两种分区思路：无意把属性码空间切成 public 与 private，也无意按 Internet、OSI 或其他协议家族切块。这句话直接否定了“255 是 BGP 厂商私有扩展号”的说法。255 是一个所有开发工作都可暂用的值，不是一段由某家企业自行占用的号码空间。

共用占位符为何不能证明互操作

假设实验 A 把 255 后面的载荷定义成四字节计数器，实验 B 则把它定义成变长策略结构。双方都遵守“开发时用 255”的规则，却没有因此获得共同语法。若测试记录、构建版本和对端约定缺失，抓包里出现的 255 最多只能证明发送方在那个观察点发出了该值。

它不能证明接收方识别了实验；不能证明两个实现对 flags、长度或载荷含义达成一致；不能证明属性已经获得全球唯一号码；也不能证明该行为经过部署审批。事实上，不同实验碰撞在同一个 255 上，恰好说明这个值应该被限制在事先约定的开发边界内。

这种弱身份并非设计失败。开发者不必为每个可能废弃的原型占用公共号码，注册表也不会被短命分支填满。但代价是上下文必须由本地控制面保存：实验名称、格式版本、参与对端、代码提交、测试期限和抓包位置缺一不可。离开这些材料，“属性 255”不是完整证据。

今日注册表仍保留了这层含义

目前的 IANA BGP Path Attributes 注册表仍把 255 列为“Reserved for development”，参考文献正是 RFC 2042。该路径属性表没有 Private Use 区间。

IANA 的 BGP Parameters 集合中，其他具名子注册表可能存在 vendor-specific 或 private-use 范围。这并不矛盾，因为分配政策属于具体注册表，而不是由“BGP”三个字整体继承。引用号码时若不说明注册表名称，就可能把别处的政策错误移植到 Path Attributes 表上。

今天的路径属性注册表还显示 Standards Action 程序，并以后来取代 RFC 1771 的 Standards Track 文档 RFC 4271 为依据；RFC 8126 又对这类现代注册政策术语作了定义。这些是理解当前治理状态所需的材料，却不是 RFC 2042 在 1997 年使用的原话。历史叙述应同时保存“当时怎样写”和“现在怎样管”，不能用后来的制度语言改写早期文档。

同样，IANA 分配所证明的也很有限：在适用程序下，某个号码已有记录的含义。它不是运行代码，不是互操作报告，也不是上线证据。注册表能够解决公共身份冲突，却不能替实现、测试与运营做决定。

文档与代码必须同时离开 255

RFC 2042 要求分配后同步修改文档和 code base，这一处短句揭示了最实际的失效面。

若文档已经写入新号码，而程序仍发出 255，规范与线上的字节就分离了。若程序先改，测试向量、抓包解析器或对端仍按开发值工作，新的合法号码也可能被当成未知属性。若两个项目都迟迟不退出 255，它们在类型码层面看似相同，载荷却可能完全不兼容。

一次可审计的转换至少需要五类证据：IANA 记录、稳定的属性说明、包含新常量的构建、与新号码一致的测试材料、以及实际运行版本的观测。之后还要单独验证接收实现如何处理。把这些层次写清，才不会把“已分配”偷换成“已生效”。

这里可以借用 Heng Lu 的 running-code 视角，但必须说明这是编辑分析，不是 RFC 2042 的规范要求。文档和注册表属于公共协调与制度记录；二进制构建属于可执行现实；部署、对端接受和运营结果属于运行现实。三者相互关联，却不会因为其中一项完成而自动同步。

正式勘误没有改变核心规则

RFC 2042 目前有一条官方勘误。Errata ID 3681 指出参考文献 [3] 的编号写错：BGP Route Reflection 文档应为 RFC 1966，而不是 RFC 1998。该项被列为 Editorial，并处于 Held for Document Update 状态。

它不改变 255 的开发用途，不改变 RFC 加 IANA 分配的流程，也不改变“不划 public/private 区段”的表述。原文中 “documentation” 的明显拼写错误并不是这条官方勘误的内容。严谨的史料工作应报告勘误系统实际确认了什么，而不是用更显眼的错字替代记录。

公共身份从唯一分配开始，运行事实仍要另证

RFC 2042 的治理设计非常克制：共用层只承担一个足够小、可确定的任务。开发占位符把未完成工作标出来；RFC 使语义可查；IANA 唯一号码避免公共冲突；实现者负责让代码跟上；运营者再决定是否部署。

255 的价值正来自它不够强。它允许试验，却不授予全球身份；它方便本地协作，却不向陌生实现承诺语义；它能出现在包里，却不是授权凭证。若把它称作私有扩展空间，便会把一种必须尽快退出的临时状态，误写成可以长期依赖的制度权利。

注册表可以告诉世界“哪个号码指向哪个属性”。它不能告诉世界该属性是否真正运行。至于 255，设计本身甚至不允许它单独告诉世界“这里是哪一个实验”。

来源