摘要

  • RFC 1127 记录了 IETF 主机要求工作组如何把互操作性置于架构纯粹性之前，并将已经形成共识的问题写成明确的要求或建议。
  • 如果相反阵营同样坚决地要求 MUST 与 MUST NOT，RFC 1122 和 RFC 1123 就保留 MAY 或 OPTIONAL；另一些有争议的功能则只能在明确边界内启用。
  • MUST 判断的是软件实现是否符合规范，它不会说明一台主机采用了什么配置，更不能证明运行值、对端互通或应用结果。

这是一份决策说明，不是第三份标准

RFC 1127 一开头便限定自己的权威：它是信息性文件，不定义协议，也不处于任何标准成熟度等级。它解释的是两份规范如何形成——RFC 1122 规定通信层要求，RFC 1123 处理应用与支持功能。

正因为不承担列出全部规范条款的任务，它才能公开决策背后的摩擦。哪些问题已经定论，哪些只能妥协，哪些仍需实验，文件都没有假装成同一种确定性。RFC Editor 的 RFC 1127 记录和 IETF Datatracker 记录固定了出版身份，正文则保存了形成要求时欠下的推理账本。

这不是一次轻量整理。大约二十位核心专家持续参与，另有约二十人作出重要贡献；二十个月内举行七次正式会议，电子邮件约三兆字节，前后产生约二十个草案。数量并不保证结论永远正确，却说明大写关键词来自对既有实现、相互冲突目标和故障经验的长期协调，而不是编辑随手写出的清单。

互操作性排在优雅之前

工作组列出五项目标：互操作性、可扩展性、功能、效率和架构纯粹性。互操作性最高，架构纯粹性最低。这并不是放弃架构，而是明确在整洁设计与已经接入互联网的机器发生冲突时，首先避免陌生主机彼此失语。

不少条款只是重申更早协议文本已经表达或暗示的内容，有人戏称它们为“去读手册”条款。工作组仍然保留它们，因为至少已有一种实现作出错误选择，造成互操作、性能或稳健性问题。一句看似重复的话因此获得了新的制度价值：它把真实失败模式变成可测试的明确责任。

RFC 1122 和 RFC 1123 还反复警告，简表本身很危险。完整要求包括基础协议、勘误、说明与实现背景。在一个封闭局域网中工作正常的主机，走上多样化互联网路径后可能立刻失败。合约针对的是任意主机之间的互通，而不是实验室里精心挑选的一对机器。

规范强度来自共识强度

RFC 1122 为关键词规定了不同重量。MUST 或 REQUIRED 是绝对要求；SHOULD 或 RECOMMENDED 只允许在充分理解并仔细权衡后偏离；MAY 或 OPTIONAL 才表示一种实现可以具备而另一种可以省略。

它还区分合规层级。遗漏所实现协议中的任何 MUST，便是不合规；全部满足 MUST 和 SHOULD 是“无条件合规”，满足全部 MUST、但未满足所有 SHOULD，则是“有条件合规”。这些判定比较的是代码与文本，并不是给某台已经部署的机器或某次连接颁发证书。

RFC 1127 揭示了分歧如何塑造这些词。已有结论的问题得到坚定要求或建议。开放问题上，一方主张 MUST 或 SHOULD，另一方同样强烈地主张 MUST NOT 或 SHOULD NOT；工作组记录双方理由，不冒充已经达成共识，最终使用 MAY 或 OPTIONAL。这里的可选并不表示每种选择同样安全，而是标出了集体权威能够到达的边界。

第三类问题采用有边界的许可。主机转发、trailer 封装、延迟确认、TCP keep-alive、可省略的 UDP 校验和，以及若干 Telnet 行为，并未被简单放行或禁止。它们受到条件、安全默认值或开关的约束。妥协缩小了影响面，却没有掩盖争议。

能够配置不等于已经配置

RFC 1127 最容易被忽略的一句话，是工作对象为软件实现，而不是软件如何配置和应用。行政与配置问题在属于本地权力时被有意排除。

RFC 1122 解释了这种边界为何必要。完全自配置的协议栈仍是遥远理想。参数可能取决于主机规模、流量分布、邻近拓扑或管理要求；最佳值可能尚无定论；自动调节算法也可能根本不存在。

更棘手的是遗留兼容性。正确系统有时必须为没有源码、行为错误的旧对端提供覆盖项，管理员甚至要故意把它“配错”才能通信。文件承认这笔现实债务，同时坚持默认值仍应符合官方协议。否则，临时绕行就会固化为新一代默认错误。

因此，要求参数可配置只能证明一种能力。厂商要提供开关并说明影响，规范可能指定默认值，现场仍决定是否覆盖。仅凭“符合 RFC 1122”，调查者无法知道 14:03 实际运行什么值、是谁改动、哪个对端触发例外，甚至无法知道该选项是否曾被使用。

未完成的问题没有藏进含糊的 MUST

RFC 1127 坦率列出未来工作：统一主机初始化、失效网关检测、网关与 MTU 发现、动态 TTL、重组计时，以及性能算法间的相互作用。有的方案没有足够文档，有的全网探测制造了过量流量，有的代码没有经过测试，还有的要等待网关端普遍部署。

工作组本可以给每个空白写一句听来权威的命令，却选择公布知识边界，把任务交给后续实验或工作组。纸面上的标准因此显得不那么完整，作为运行契约却更诚实。

RFC 1123 同样提醒，协议软件必须随着规范演变而维护。合规属于特定版本和时间，不能永久附着在一个产品名称上。

规范发布以后，证据链才开始延伸

后来的 RFC 2119 将这些大写关键词推广为互联网规范的通用词汇；RFC Editor 的 RFC 2119 记录保留了它作为 BCP 的历史。统一词汇并没有让文字获得执行配置的能力。

判断一台真实主机，首先要确认适用规范、协议集合、代码与构建版本；随后记录官方默认值、厂商出厂值、安装覆盖项、实时值，以及每次变更的权力、时间和理由；再观察对端能力、协商与实际交换；最后才是应用结果。

“符合 RFC 1122”可以是一条重要证据。没有后续各层，它仍只是对预期软件属性的描述。主机要求工程把这种描述变得更可靠，RFC 1127 则诚实地画出了它不能替代什么。

来源