摘要

  • 发送端可以在 32 位 HYPERchannel 头中设置 SRC，表示 FROM 地址能在反向传输时作为 TO 使用；中途适配器发现这个条件不成立时可以清除该比特。
  • SRC 最终仍为 1，精确证明的是交换 TO 与 FROM 后可回到发起消息的进程。它不检查内容，不识别人，也不授予应用动作权限；CRC、服务选择与物理边界各有职责。

1988 年 2 月发布的 RFC 1044，记录了如何在 Network Systems HYPERchannel 上承载 IP。文档既要收束已经存在的 16 位地址实践，又要引入兼容的 32 位扩展，还要登记消息类型，并让地址解析从本机文件逐步走向集中服务器与未来的广播 ARP。

这份规格最有意思的地方，不是某一种硬件曾经多快，而是它把一条消息里的多种证据拆开。地址可以指向进程，类型可以影响中途处理，CRC 可以检查字节，SRC 可以保留回程断言。没有一个字段天然继承其他字段的权力。

FROM 最初是给回答使用的地址

在基本头部里，网络按照 TO 投递消息。FROM 不参与去程的物理转发，而是随消息交给接收主机，使对方能够回复。RFC 1044 说明，一般情况下，对调 16 位 TO、FROM 与相应 trunk 掩码，便能把回答可靠送回来源。

这种对称性解决了“回哪里”的工程问题，却不构成主体身份。一个进程可以拥有完全有效的回程地址，同时由错误账号、被入侵程序或未经批准的自动任务控制。地址位于载体的投递体系，人的身份与动作权限位于更高的治理体系。

完整 TO 地址中的逻辑部分还负责选择最终协议服务器。消息类型可以让中间设备采取某种处理，却不能在最终目的地把消息改投给另一个服务器。也就是说，RFC 1044 已经把最终接收者与沿途分类分开，随后又把来源回程与内容完整性分开。

SRC 是一项可被路径扣除的声明

32 位头部加入 GNA、CRC 与 SRC。GNA 表示使用扩展地址。CRC 对应具备能力的适配器所做的端到端消息校验。SRC 的全称是 Source FROM Address Correct，表示声明的来源地址适合反向送达。

声明由发送主机开始。驱动若已尽力写入实际使用接口的正确 FROM，就可以设置 SRC。传输路径上的每个中间适配器，都有权在发现该地址不能作为反向消息的 TO、无法送回发起者时，把比特清零。

因此，路径不会给身份逐层盖章。它最多保留或撤销发送端的初始说法。比特消失后，接收端不能再宣称强回程条件成立；比特仍在，则表示实际参与这套规则的设备没有发现规范所定义的反向地址缺陷。

这不是密码学证明。发送端可以写入比特；设备也可能没有实现检查。比特缺失同样不能自动证明攻击，因为发送端可能没设置，旧设备可能不支持，适配器也可能因真实拓扑问题正确清除。SRC 最适合成为边界清楚的证据，而不是一票决定。

“正确”的定义只到原发进程

RFC 1044 对“来源地址正确”给出可验证含义：若 SRC 到达时仍存在，对调 TO 与 FROM 后，消息会投递到真正发起原消息的进程。它不是模糊的“看起来可信”，而是一项明确的载体行为。

但原发进程仍不是经过认证的人。被攻陷的程序也会接收回答；位于预期物理位置的机器也能提交越权请求；反向通信成功也不说明去程内容新鲜、合法或已经执行。回程性维持对话，授权决定影响。

文档同时指出，若仔细保护适配器与中间链路的物理安全，系统可以依据 FROM 地址建立较高程度的安全。这句话把前提写在机制外：设备、链路和配置必须处在可问责的保管范围内。SRC 自身无法证明这些设备确实安全，也无法证明组织边界仍与物理拓扑一致。

CRC 保护字节，不识别请求者

CRC 使用独立比特，是最直接的职责分离。具备能力的适配器可以添加 32 位 CRC，让最终适配器检查消息在多个网络、链路和内部硬件中是否被破坏。

CRC 成功，不保证 FROM 能反向送达；SRC 成功，不保证相关数据未被修改。二者都不识别人，也不让应用获得执行命令的理由。如果日志只写“来源验证通过”，后来的人将无法知道当时通过的是回程地址、字节校验、协议服务器选择，还是业务权限。

RFC 791 定义的 IPv4 数据报在载体内部还有自己的源地址、目的地址、协议、总长度与头校验和。HYPERchannel 地址与 IP 地址一致，可以增加配置可信度；两层都一致，也仍只是地址证据，不是主体认证。

地址解析产生映射，不产生所有者

RFC 1044 依次描述低位截取、本机配置表、已知 ARP 服务器，以及未来有广播能力时的分布式 ARP。RFC 826 提供了协议地址与链路地址之间的通用查询格式。

这些方法的来源并不相同：静态表由某人生成，集中服务器维护一份数据库，广播回答来自本地交换。它们都能告诉驱动“下一跳应使用什么 HYPERchannel 头”，却不能单独证明映射新鲜、设备归谁控制或请求有权执行。

错误映射也可能完全可逆。SRC 只能证明回答回到那份映射指向的进程，不能把一致的错误改造成事实。

接收驱动当时不应据此自动行动

IP 驱动部分留下一个重要限制。发送驱动若已尽力给出完全正确的 FROM，应设置 SRC；接收 IP 驱动当时则不应对该比特采取特定动作。若比特缺失，面对真实或想象中的“安全违规”究竟怎么办，文档明确说仍需进一步研究。

这条保留意见避免把新信号立刻变成入口闸门。无 SRC 就一律拒绝，会把兼容性差异变成中断；有 SRC 就一律放行，会把物理回程变成应用权限。真正的策略还必须知道路径能力、设备保管、地址管理与动作后果。

RFC 1044 的历史价值在于：它没有把一个有用比特吹成万能信任根。它让路径能够撤销一项具体断言，并把其余决定留给拥有相应证据与责任的层次。

来源与证据边界

RFC 1044 给出 HYPERchannel 头部、地址反转、各标志位、物理安全前提、驱动限制与解析阶段。RFC 791 定义内层 IPv4 边界。RFC 826 定义 RFC 1044 复用的地址解析模型。

它们能证明规范内容，不能证明某台历史设备正确实现 SRC，不能证明某个现场的物理边界，也不能把观察到的请求归因给获准操作者。