摘要

  • RFC 6709 中的“常规”不是指补丁很小或代码行数很少。只有基础协议和已部署实现能够安全忽略某项扩展，它才可能属于这一类；如果既有软件需要改变，即便传输格式几乎没动，这项修改仍可能是重大变化。
  • 这个分类不会自动免除专家审查。RFC 6709 建议谨慎使用低审查流程，并明确指出常规扩展也可能受益于专家意见；RFC 4775 则解释了为什么新增 RADIUS 属性需要熟悉其架构和既有用法的人参与讨论。

一个词背后其实有两项判断

协议评审常把两个问题混在一起问：这项扩展会怎样影响协议及已经运行的系统？在别人依赖它之前，提案应经过怎样的审查？“常规”好像同时回答了两者。RFC 6709 表明，它并没有这样的效力。

互联网架构委员会（IAB）于 2012 年 9 月发布 RFC 6709，类别为 Informational。文件面向基础协议和扩展的设计者。它承认，扩展机制有助于渐进演进，也可能引发互操作、运行和安全问题。常规与重大扩展的区分，意在把提案可能造成的影响与所需审视程度联系起来。这是架构指导，不是互联网标准，也不是适用于所有提案的批准规则。

RFC 6709 把自己放在更长的讨论脉络中。它提到 1991 年的 RFC 1263《TCP Extensions Considered Harmful》，将其视为较早讨论扩展成本的警示。但 RFC 1263 有自己的历史论点：RFC 6709 并没有重新裁决 TCP 应该在哪里划出版本边界。它所说的是，关于协议扩展的一般设计考量此前还没有被系统汇集。2006 年发布为 BCP 125 的 RFC 4775 已经规定 IETF 协议扩展的流程；RFC 6709 则试图说明应当用什么架构判据来考量这些工作。

“重大”看的是后果，不是报文大小

RFC 6709 提出了八类检查。底层协议实现是否必须改变？提案是否改变了架构假设，例如给原本无状态的协议引入会话状态？新用途或新规模是否会增加流量、报文尺寸或处理负荷，超过既有系统的能力？扩展是否符合基础协议原先设计的扩展模型？它是否改变语法、牵连多个协议、改变安全模型，或者影响现有部署的性能？

其中任何一项都可能使扩展成为重大变化。新的消息类型或传输方式，可能要求已经部署的软件升级，即便那些系统并不需要新功能。线上的字节可以完全没变，新的规模却可能让旧算法承受不起。如果基础协议没有为未知扩展定义一致且安全的处理方式，一个表面上微小的提案也可能自动落入重大一类。这些是 RFC 6709 提出的设计测试，不是量化评分，也不是对当前某个产品的结论。

真正的问题是：谁需要改变？不改变的一方会遇到什么？代码改动的大小并不能回答这两个问题。一个短字段可能改变接收端解析报文的方式；较长的厂商自定义值则可能对基础协议完全透明。按照 RFC 6709 的标准，前者可能属于重大变化，后者可能属于常规扩展，但前提是实际满足兼容条件。

“常规”有清楚的边界

只有在不符合重大扩展判据、且基础协议把其处理过程视为不透明的情况下，某项扩展才可能被称为常规。它不应实质改变消息与响应的模式。基础规范和已部署实现不应需要修改，除非它们主动选择使用该扩展。其他实现也不应受到影响；通常，它们应能忽略扩展而不产生副作用。

RFC 6709 举出的例子包括 DHCP 厂商特定选项、RADIUS 厂商特定属性、MIB 模块使用的企业对象标识符，以及厂商 MIME 类型。关键并非这些新增内容很小，而是它们能够放在基础协议预留的扩展位置，不会改变未参与系统必须履行的行为。

同一段文字也防止读者把“常规”理解得过于宽松。RFC 6709 说，允许极少或无需审查的扩展流程（例如先到先得分配）应谨慎使用，只能用于不太可能造成互操作、安全或运行问题的情况。它接着指出，常规扩展也可能需要专家审视：即使 DHCP 把选项数据当作不透明内容，完全没有结构的数据仍会让客户端和服务器难以处理。

RADIUS 说明为什么分类和审查必须分开

作为流程配套文件，RFC 4775 把两类问题的区别说得更具体。对于基础规范已经写清 IANA 注意事项的常规参数分配，它允许在既有指引内处理；超出这类范围，就需要 IETF 专家进行明确的协议审查。它还指出，新增 RADIUS 属性应由熟悉协议架构和现有用法的专家讨论，因为缺少这类讨论会增加互操作或功能失败的风险。

RFC 6709 却把 RADIUS 厂商特定属性列作常规扩展的例子。两份文件并不矛盾：它们回答的不是同一个问题。“常规”关注扩展是否符合架构，以及不采用它的系统能否安全忽略它。RFC 4775 关注提案应经过什么流程、需要哪些专业知识。RFC 6709 明确允许一项通过“常规”测试的扩展仍接受专家审查。

这一区分很重要：发布一份文件或分配一个参数值，本身不能证明扩展无害、已经实现或已被运营方采用。审查可以在提案进入下一步前暴露问题，却不能替代对实际实现的测试，也不能证明运营部署已经发生。

一个标签不够，至少要留下三项记录

有用的评审记录应分别回答三件事。第一，扩展改变了基础协议、架构假设、消息行为或资源需求的哪些部分？第二，不采用该扩展的既有实现能否安全忽略它？第三，前两项事实分别要求怎样的协议、安全和运行审查？

如果既有软件需要升级、消息次序改变、引入了新状态、多个协议彼此牵连，或安全假设发生移动，那么把扩展称为常规就需要更有力的解释。如果它确实不为基础协议所见，也不会影响未参与者，那么这支持常规分类，却仍不排斥专家审查。测试用例还须揭示实现的实际行为；登记一个值不能证明某条已部署路径能够正确承载它。

RFC 6709 还提醒设计者，协议一开始不应比合理需要更具扩展性。它承认后续用途可能无法预知，却不要求初始设计预先装下所有想象得到的需求。由此得到一条克制的原则：为变更留出安全空间，但不要假定以后任何用途都会适配。

这些记录能说明什么，不能说明什么

RFC 6709 记录的是 IAB 对扩展设计的指导，不是对实现状况的实证普查。RFC 4775 记录的是流程，并不能证明每个提案都遵循了该流程。这些来源能证明文件提出了哪些判据和提醒，却不能说明有多少扩展已经部署、某个网络是否采用了某项扩展，或特定扩展是否引发过事故。

Heng Lu 的 Note 64 提供另一种编辑视角：只把互操作所必需的规则写入初始规范；可能时把后续选择留给参与者；只有实际实现和采用才让变化在运行中成立。这是 BTW 后来采用的分析框架，不是 IAB 意图的说明。沿着这一视角，“常规”描述兼容边界；发布、登记或评审结果不等于已被采用。

RFC 6709 的历史价值，在于它让一个问题变得难以回避：旧系统可以安全忽略这项扩展，还是被要求改变？回答清楚之后，才可以有意识地决定审查强度。“常规”不是“无害”的代称，“重大”也不是代码行数的统计。

来源