摘要

  • 1992 年 1 月发布的 RFC 1293 为 ARP 增加 Inverse Address Resolution Protocol。它让已知硬件地址的站点请求相应协议地址；其 Frame Relay 动机是已建立 PVC 的 DLCI 已知，但远端站点的协议地址未知。
  • InARP 不广播，因为目标硬件地址已经知道。接收站点可以给出合适答复，也可以在不能或不愿答复时忽略请求；请求者可以补全本地 ARP 表，但 InARP 学到的信息会老化或失效。

RFC 1293 的起点不是“网络有没有”，而是“哪一种知道还不够”。通过信令，网络可能宣布一个新的虚电路及其 Data Link Connection Identifier。DLCI 在广域网中标识一条虚连接，是 Frame Relay 的硬件地址等价物。可是该宣布没有携带对端的协议地址。收到通知的站点知道一条线路的把手，却还不知道在协议层该向谁寻址。

因此，文档所说的电路“不可用”有很窄的含义：在没有新配置或发现机制时，不能用它给另一端寻址。这不是线路不存在、远端失效、服务中断或身份伪造的判断。它只保留一个缺口：链路层标识已经有了，协议层地址还没有。InARP 的工作是把缺口显式送到已知目标，而不是假装缺口已被填上。

DLCI 知道的是路径，不是对端协议身份

PVC 以及最终的 SVC 由 DLCI 标识。这个事实可以让本地设备把帧送往一条指定虚连接，却不能自动给出另一端的协议地址。把“连接被宣布”压缩成“对端已知”，会混掉不同的记录：信令宣布、已知硬件地址、InARP 请求、远端答复、本地缓存与后续数据传输。

每一项都比后一项窄。电路宣布并不记录请求已发出；请求已发出并不记录答复已到达；答复填入 ARP 表也不记录 IP 路由、授权或数据包交付。RFC 1293 的价值在于不跳过这些空档。已知 DLCI 是可以开始提问的条件，不是可以停止验证的结论。

反向的是问题方向，不是任意机制的对称性

InARP 从硬件地址开始，请求相应协议地址；它沿用 ARP 格式，InARP request 的操作码为 8，reply 为 9。RFC 1293 特意说明为何没有使用 RARP：RARP 的答复给的是请求者自身的协议地址，而这里需要的是接收请求、位于电路另一侧的站点地址。

名称相近不等于问题相同。“我是谁”的答复不能替代“这个已知硬件目的地是谁”的答复。文档也没有采用只面向 IP 的机制，因为目标是为多个协议解析地址。InARP 不是 IP 所有权目录、路由权威或一般身份登记；它限定在已知目标硬件地址与尚未知晓的协议地址之间。

目标协议字段为零，是对未知的诚实记录

普通 ARP 不知道目的硬件地址，因而广播。InARP 已知目的硬件地址，所以不广播。请求者写入自己的硬件和协议地址、已知目标硬件地址，把目标协议地址字段置零，再为具体网络封装并直接发送。

这个零不是给远端编造的值，而是消息最重要的边界：本地知道足以定向送达问题的内容，却不知道所求协议地址。直接发送可以避免用多份相同消息模拟广播，也比静态配置更灵活；它仍是发现过程。它不证明远端支持 InARP、具有合适地址、当前愿意答复或会永久保持该映射。

定向并没有消除不确定性，只是收窄了询问的范围。操作记录应写成“某站点向某已知硬件地址发送此 InARP 请求”，而不是“电路已解析”。只有答复到来，才会新增一个事实；没有答复时，RFC 允许保留的是沉默，而不是替远端补上一个身份。

回复或沉默的控制权仍在接收端

接收站点可以像处理 ARP 请求一样，把请求者的协议地址/硬件地址映射放进自己的 ARP 缓存；它可以利用请求的源地址作为回复的目标地址。如果站点不能或不愿答复，RFC 说它忽略请求。没有为“未能答复”规定一个肯定替身。

所以，只有请求的抓包不等于映射已经存在。沉默可能与能力、意愿、配置、可用性或其他未记录条件有关；RFC 1293 不足以将它归为其中任何一种。反过来，收到回复时，请求者可以补全自己的 ARP 表并使用所给地址。这仍只是本地学习到的映射事实，而不是一份独立认证、永久绑定或服务成功报告。

文档特别说明，经 InARP 学到的信息可能老化或失效。缓存记录的是本地此时选择保留的答案，不是对拓扑、远端身份、访问许可或未来传输结果的永恒声明。若后来发生数据面失败，还需要独立记录目的地、路由、权限、时间和响应。

多地址主机必须按提问者的网络作答

一台接口上有多个协议地址的主机，不能随便返回其中一个。它必须先查看请求者的协议地址，再选择与请求者网络相对应的地址。以 IP 为例，如果接收站点没有属于所请求子网的接口地址，就不应答复。多地址主机可为同一接口定义的每个地址发出请求；接收侧可以按配置回答其中一些，或一个也不答。

这条规则说明，答复不是远端主机脱离关系的属性。同一主机可能“有地址”，却没有适合这一个请求者的地址。一张地址清单也不足以确定应写入哪条 ARP 表项。正确映射取决于发问者、网络上下文、接收端配置和实际答复。

缓存映射不是安全或运行结果

RFC 1293 的 Security Considerations 明说安全问题没有被讨论。因此，InARP 回复不证明认证、完整性、授权或任何抗攻击性质。它也不证明一条特定 Frame Relay 电路仍存在、对端可达、映射正确、路由可用、数据包被交付，或组织获得了服务结果。

需要保留的证据链应包括：电路或 DLCI 的公告、请求者和目标硬件地址、请求时刻、回复或沉默、选中的协议地址、本地表项、老化或失效事件。把这一链条分开，并非削弱协议；恰好让人知道它解决了什么——以直接、条件性的交换减少了一个地址未知——又没有解决什么。

来源与证据边界

本文使用 RFC 1293 — Inverse Address Resolution Protocol。它支持 1992 年标准轨道地位、DLCI/PVC 动机、缺少远端协议地址、拒绝 RARP 和仅 IP 方案、操作码、非广播的直接请求、回复或忽略、缓存与老化/失效、多地址选择以及安全未处理的声明。

它不支持任何现实电路、对端配置、正确或获授权映射、当前可达性、缓存持久性、IP 路由、数据交付、安全特性、商业服务或用户结果的主张。将已知 DLCI 理解为受限协调事实而不是可用邻居裁决，是对机制的编辑性分析，不是部署观察。