摘要

  • DRAP 把“每台工作站都是一个 DLSw 对等体”的拓扑，改成大量轻量客户端共享一台服务器及其一条面向中心站点的 DLSw 对等连接。
  • 服务器可以分配或缓存 MAC 地址、回答可达性探测、协商能力、生成会话标识，并在 TCP 暂停时继续保留电路。
  • 这些信号都不能证明人的身份、授权、真实来源或端到端交付；RFC 2106 没有规定认证机制，而且只是 Informational 文档，不是互联网标准。

被压缩的不是复杂性，而是连接数量

RFC 2106 最值得注意的地方，不是某个报文格式，而是它对规模问题的诊断。如果每台远程工作站都运行完整 DLSw，那么通往中心站点的 TCP 会话会随工作站数量增加。原本面向交换设备之间的协议，被一路推到了个人终端。

DRAP 改写了这张拓扑图。远程工作站只作为附近 DRAP 服务器的客户端；真正面对中心路由器维持 DLSw 对等关系的，是服务器。大量边缘连接因而可以汇聚到一条骨干侧关系上。复杂性没有消失，它只是从每个终端迁移到一个代表终端记忆和发言的边界节点。

这也是本文与既有研究的分界：RFC 1434 讨论两条本地 LLC 链路如何共用传输，RFC 2024 讨论 DLSw 的目录、缓存、传输和电路管理行，RFC 2043 讨论 PPP 上两套独立的 SNA 准入，RFC 2097 讨论 NetBIOS 名称的逐项准入。RFC 2106 的独特问题是：当网关替大量工作站保存状态时，谁掌握了地址分配、可达性声明和会话延续的权力。

虚拟 MAC 是定位工具，不是身份证明

通过 PPP 接入的工作站可能只有 IP 地址，没有局域网 MAC。DRAP 允许服务器分配一个虚拟 MAC；如果客户端提交非零 MAC，服务器检查是否重复并将其缓存。为了让服务器主动发起会话，客户端还可以预先登记 MAC 与 IP，使服务器知道之后应向哪里重连。

这套机制很实用，但它的含义必须收窄。MAC 在协议的运行模型里选定一个端点，却没有说明是哪一个人在控制终端，也没有说明此人是否有权访问某项应用，更没有证明登记信息来自可信来源。服务器缓存的是可操作的地址主张，不是身份权威。

服务器选择也遵循同一界限。客户端如果配置了多个服务器地址，可以同时发出请求并采用最先答复者。“第一个回答”证明了时延和当时的可用性，却不证明对方就是正确的行政或信任主体。

报文证明状态变化，不证明更多

DRAP 的报文名称恰好展示了操作证据的边界。CAN_U_REACH 询问服务器能否到达目标，I_CAN_REACH 返回服务器的判断；START_DL 请求建立链路站，DL_STARTED 表示服务器完成了相应状态变化；发起方和接收方会话标识区分不同电路；能力交换则确认客户端 MAC、NetBIOS 支持、SAP 列表以及客户端是否能监听新的 TCP 连接。

每个信号都能证明一件具体的事。肯定的可达性响应说明服务器愿意声称存在路径；链路启动响应说明本地协议转换成功；会话标识给一段内部状态命名。它们都没有单独证明应用数据已经送达、使用者获得授权，或消息之外的来源链真实可靠。

传输层的界限更微妙。RFC 2106 让每个客户端—服务器对使用一条双向 TCP 连接，并指定端口 1973。关闭对等体时可以选择“暂停”：TCP 断开，数据链路电路却继续保持；出现新的用户数据后，客户端重新连接，而且无需再次做能力交换。可选 keepalive 用来测试对端是否仍响应；连续三次失败后，建议关闭 TCP 和所有电路。

这是很漂亮的运行设计，也意味着“连接着”从来不是单层事实：套接字可以不存在，而逻辑电路仍然活着；keepalive 可以证明对端会回答，却不能证明事务抵达目标应用。协议状态机本身没有混淆这些概念，后来的运营和审计也不该混淆。

RFC 编号不等于标准共识

RFC 2106 于 1997 年 2 月以 Informational 身份发布，并明确声明它不规定互联网标准。文本没有认证机制，也没有 Security Considerations 章节。应当按历史语境准确理解这一点：它规定的是远程接入适配和状态转换，而不是身份或授权体系。

同月发布的 RFC 2114 很快取代了 RFC 2106，把方案改称 DCAP，并在保留客户端—服务器核心模型的同时加入发现选项。这种快速更替本身就是提醒：端口登记、实现互通或一个 RFC 编号可以让系统更容易运行和被发现，却不能独自证明长期标准共识。

资料来源