摘要

  • RFC 2097 让终端逐项请求对端把指定 NetBIOS 名称加入远端网络；同一次协商中，一些名称可以成功，另一些名称则返回具体错误。
  • NBFCP 还暴露对端类别、组播转发周期与优先级，以及是否要求每个数据报携带十二字节 IEEE MAC 头。这些是准入条件，不是链路已通之后的装饰信息。
  • Opened 或 Added=0 都只是局部证据，不能证明全局名称唯一、端点身份、授权、LAN 到 LAN 连通、完整组播送达、后续会话成功或安全。

一条远程接入链路可以已经有电，PPP 的链路控制阶段可以结束，Network-Layer Protocol 阶段也可以开始，但应用依赖的名称仍未在远端网络取得立足点。RFC 2097 把这个缺口变成了可观察事件。

这份 1997 年 1 月发布的标准为 NBFCP 控制包指定 0x803f，为 NBF 数据报指定 0x003f。它明确限制拓扑：终端只能连接一个对端系统，或连接该系统所在的 LAN。由于 NetBIOS 名称限制与名称防御机制，它不适合把两个 LAN 接在一起。

载体开放与名称获准是两件事

PPP 把职责分成多个阶段。LCP 建立、配置并测试数据链路，之后还可能进行认证和链路质量判断。只有进入网络层协议阶段后，双方才能交换 NBFCP；过早到达的控制包应被静默丢弃。NBFCP 到达 Opened 后，NBF 数据报才可以发送。

然而，对终端实现而言，RFC 2097 还强制协商 Name-Projection。请求者列出希望对端加入远端网络的十六字节 NetBIOS 名称，并为每一项标明它是唯一名称还是组名称。由于 Length 字段只有一个字节，单个选项最多容纳十四个名称；更多名称必须拆进多个选项。

这不是一句“终端支持 NetBIOS”的笼统声明。一台机器可能用不同名称承载不同服务或角色。对端需要逐一尝试，让这些名称在自己一侧获得可用的网络存在。

部分接纳必须留下完整清单

如果接收方不能加入所有名称，它必须用 Configure-Nak 返回请求中的完整列表。成功加入的名称以 Added=0 表示；失败项要携带非零结果。规范列出了本地名称表重复、名称表已满、远端 NetBIOS 中名称正被使用、检测到名称冲突、名称由另一环境定义、系统资源耗尽等不同结果。

这张列表同时是提案和收据。同一个请求中的两个名称可以得到不同命运。请求方随后应重新提交已经成功加入的名称，也可以判断完整名称集合不可缺少，从而发送 Terminate-Request 终止 NBFCP。网络对部分名称的接纳，不能替应用决定缺少的名称是否关键。

时间也是证据的一部分。加入 NetBIOS 名称通常至少需要约三秒，而 PPP 的默认重启计时也可能是三秒。RFC 2097 建议名称配置期间把超时提高到十秒。过快的重试可能证明的是控制循环缺乏耐心，而不是远端系统不存在。

因此，Added=0 只支持一个边界清楚的陈述：在这次交换中，这个对端报告自己能够加入这个请求名称。它不证明其他网段、名称服务器或网桥拥有一致视图。RFC 1001 本身也承认，故障可能造成名称信息不一致。

对端自报类别不等于身份认证

Peer-Information 可以携带实现类别、主版本与次版本，以及可选的对端名称。初始类别区分 PPP NetBIOS 网关服务器、仅提供本地访问的服务器、NBF 网桥与终端系统。

这种区分很有操作价值：网桥能提供的转发面，与不会把包继续传给其他服务器的本地访问服务器不同。但该选项只被建议使用，并非强制；类别和名称也由对端自己提供。RFC 2097 没有把这些字节与经过验证的机器、组织或运营者建立认证绑定。

组播策略能让已可达的服务看起来失效

不同 NetBIOS 应用对组播的依赖不同。有些必须收到组播才能工作，另一些完全不需要。Multicast-Filtering 因而协商最大转发周期与优先级位。

周期为零表示所有组播包都应转发。普通值最大为六十秒，规定转发频率不得高于该间隔一次。0xFFFF 在 Request 和 Nak 中分别表达请求对端给出值，或双方同意不存在可用值。优先级决定组播包还是定向包先发送。

带宽策略由此成为应用行为。链路可能开放，名称可能已经投射，定向包也能通过，但依赖频繁组播的应用仍会显得“坏了”。协商出一个周期，只证明对端承诺采用这种处理方式，不证明每个组播都实际到达。

多出的十二字节改变了可接受包形

NBF 历史上存在 802.3 Ethernet、802.5 Token Ring、DIX Ethernet 与 FDDI 等多种 MAC 头实现。有些 PPP 实现要靠完整介质头进行桥接，有些只需要 IEEE 地址，另一些网关完全不需要 MAC 字段。

IEEE-MAC-Address-Required 把这种依赖变成布尔选项。默认不携带 MAC 头。一旦协商成功，每个 NBF 数据报都必须在信息字段前加十二字节的目的与源 IEEE MAC 地址。由于这个决定发生在 LCP 协商 MRU 之后，接受该选项的实现还必须接收比 PPP MRU 大十二字节的 NBF 包。

这说明底层给出的长度数字并不是完整包契约。观察到 MAC 头，只能证明所用封装形式，不能证明网桥完成转发，更不能证明具名目的端已经收到。

Opened 是发送许可，不是结果证书

RFC 2097 的四个选项拆开了常被监控面板压成一个绿灯的事实：哪些名称获准、对端自称是什么角色、组播将怎样处理、帧需要什么形式。只有这些条件完成后，Opened 才允许 NBF 在这条点对点链路上传输。

规范同样清楚地保留了证据上限。Security Considerations 只说安全问题不在本文讨论范围。NBFCP 不认证人或机器，不授权名称，不加密数据，也不证明完整性。它明确排除 LAN 到 LAN 的用途，没有把局部名称投射伪装成通用路由网络。

IANA 当前仍登记这两个 PPP 协议值、四类 NBFCP 选项、名称返回码和对端类别。这证明编号保持稳定，不证明现今部署、产品符合性或互操作成功。RFC Editor 没有登记勘误，也只是勘误表的状态，不是实现测量。

与 RFC 1088 的对比尤其重要。RFC 1088 从 IPv4 地址机械生成用于 IP-over-NetBIOS 的名称；RFC 2097 不生成名称，而是把对端选择的一组名称带到远程准入点，再逐项返回结果。前者解决目的名称如何构造，后者解决一个具名存在能否跨过远程接入边界。

从 Lu Heng 后来的“最小初始规范”和“运行代码优先”框架看，NBFCP 像是一个只规定端点互操作所需共同承诺的薄层，同时把应用选择留在本地。这是后来的编辑性解读，并非 RFC 作者意图的证据。历史事实已经足够：当名称、对端角色、组播策略与帧形都拥有自己的收据之后，链路开放便不再能代表访问已经成立。

来源