摘要

  • RFC 1088（STD 48）规定用 NetBIOS 数据报承载 IP 数据报，并将目的 IP 地址直接写成 IP.XX.XX.XX.XX 形式的 NetBIOS 名称。
  • 这个规则不需要为该名称做一次 ARP 式物理地址查询；但它不发现路由、不证明端点归属或身份、不支持 IP 组播，也不证明应用层结果。

名称的可读性很容易让人误判它的地位。IP.0A.00.00.01 看上去像一条关于机器的陈述，实际上只是 RFC 1088 为一种本地数据报服务规定的收件标签。该 RFC 的目标是使 IP 数据报能够在 NetBIOS 网络上传输。发送端把 IP 数据报放进 NetBIOS 数据报数据中，并依据目的 IP 地址得出要使用的 NetBIOS 名称。

这个得名过程是机械的，不是发现过程。NetBIOS 名称可由 16 个字节组成；RFC 为 IP 应用选择 IP. 加四个地址字节的 ASCII 十六进制写法。因为名称由 IP 地址直接导出，RFC 说无需进行物理地址查询，例如 ARP。这里“无需”的对象很明确：为了取得此约定下的 NetBIOS 名称，无需再提出查询。它不是说网络从此不再有链路层、拓扑、下一跳或可达性问题。

RFC 791 对此提供了更长久的词汇纪律：名称说明寻找什么，地址说明它在哪里，路由说明怎样到达。RFC 1088 实际完成的是地址到本地数据报名称的映射。它并未因一串名称看起来清楚，就接管“怎样到达”的工作。更不能把这串名称解释成地址的权利凭证、组织归属，或运行中端点的身份证。

两项注册，一种持续接收状态

RFC 的初始化步骤把这条边界写得很具体。主机对每个要支持的 IP 地址，将其 IP.XX.XX.XX.XX 名称加入 NetBIOS 名称表；同时加入组名 IP.FF.FF.FF.FF。随后，主机分别为这两个名称提交接收 NetBIOS 数据报的请求。任何一个名称收到数据报后，协议栈处理它，并重新提交接收请求。停止 IP 支持时，取消未完成的接收，并删除这两个名称。

这是主机上的登记、接收、续挂和撤销。它不是为多个 LAN 揭示隐藏位置的发现协议。与 RFC 950 所讨论的透明子网相比，差别尤其明显：透明子网中的桥可能要发现主机在哪条 LAN 上，广播查询并维持缓存。RFC 1088 不承诺这种代理发现。它预先规定，在它定义的承载中，地址应写成哪个接收名称。

因此，它和 RFC 826 中 ARP 的关系也不能被夸大。ARP 在其以太网语境中处理协议地址到以太网地址的解析。RFC 1088 并没有重写 ARP，也没有提出普适替代品；它只说明在 NetBIOS 数据报的本约定下，IP 地址已经给出了服务所需的名称。少了一步查询，并不等于少了所有网络不确定性。

广播有一个组名，组播没有被假装实现

对于 IP 广播，RFC 使用组名 IP.FF.FF.FF.FF。但文本立即划出一条负面边界：它不尝试用 NetBIOS 组名支持 IP 组播地址。这句话阻止了一个常见的倒推：有一个广播组名，并不意味着所有 IP 组地址都已被表示或投递。

同样具体的是 512 字节的 MTU。NetBIOS 数据报的数据最大就是 512 字节，因此 IP-over-NetBIOS 的 MTU 也是 512 字节；与此类主机通信的一方可能需要重组分片。导出的名称、已发送的数据报、出现的分片和最终重组的 IP 数据报是四类不同证据。它们不应被观察系统压缩成一句“目标已验证”。

RFC 1088 对路由器的表述也必须按条件阅读：如果一台路由器既能用普通数据链路协议封装 IP，又能用 NetBIOS 数据报封装 IP，那么这些 NetBIOS 主机就能与更广泛的 Internet 通信。这描述的是一个具备双重封装能力的路由器会带来的可能性。它没有证明某个路由器已部署、某个地址有路径、某个主机可达或某人有权使用该地址。

这正是这段历史值得保留的地方。一个简洁的接口可以消除一项局部协调成本，而不假装解决其他层面的责任。RFC 1088 让地址在一种数据报服务中成为可计算的名称；它没有让可计算性变成控制权。

来源与证据边界

下列 RFC 支持 1989 年的封装与名称规则、主机状态、广播/组播边界、MTU 以及 IP、子网和 ARP 的相关区别。它们不支持当前部署、特定主机配置、地址归属、身份、授权、已观测的路由、实际投递或应用成功。