摘要

  • RFC 4620 为 IPv6 诊断工具提供了直接询问节点名称或地址的方式，尤其适用于缺少 DNS 或全局路由的链路。
  • 节点可以拒绝回答；返回内容只是本地自述，不是经过认证的身份，也不是权威目录记录。

分析

自动配置出的 IPv6 地址可以正常工作，却不容易让人判断它对应哪台设备。工程师启用一条链路或排查故障时，本地网段未必有 DNS；链路本地地址也未必进入任何公共 DNS 区域。但此时询问正在响应的节点：它把什么名称或其他地址与自己关联起来，仍可能有助于诊断。

2006 年 8 月，Michael Crawford 和 Brian Haberman 在 RFC 4620 中描述了这种直接查询。该文档被标为 Experimental，适用范围限定为诊断、调试和网络管理。它还明确保留了 DNS 的权威角色：对于全球互联网中的名称和地址，DNS 仍是权威来源。节点信息查询不是另建一个全球命名系统，而是在 DNS 或全局路由缺席时，为本地链路上的排障提供工具。

查询和响应分别使用 ICMPv6 类型 139 和 140。请求指定接收查询的节点以及所询问的对象，两者地址可以不同。协议定义的信息类型包括空操作、节点名称、IPv6 地址和 IPv4 地址；地址查询的标志位可以选择所需地址范围以及是否请求全部地址。这样，诊断工具能询问在线端点报告了什么，而不必把 DNS 或注册表结果误当成设备全部本地接口的完整描述。

拒绝是协议内的正式结果。响应代码区分成功、拒绝和不认识的查询类型；即使成功响应也可以不含数据。因此，无响应、拒绝、不支持的查询和空结果不是同一件事，也不能单独证明设备不存在。响应端还要先检查目的地址是否属于自己的单播或任播地址，或自己已加入的链路本地组播地址；本地策略可以直接丢弃查询。

请求中有一个 64 位 nonce，响应端原样复制，以便请求方配对两条消息并降低盲目伪造响应的机会。作者也限定了这个保护的能力：能够监听请求或响应的人仍可能绕过它。如果需要真正的通信安全，文档建议使用 IPsec；若要作安全相关决定，则须有协议范围之外的认证机制。

披露范围也被限制。默认配置必须拒绝来自全局范围地址的查询；实现应限制响应速率，并允许运营者控制 IPv6 隐私地址的披露。IANA 目前仍登记类型 139 和 140，这说明协议编号仍在注册表中，不代表任意主机都会作答。RFC 4620 提到 KAME、USAGI 等 IPv6 实现中的 ping6 诊断工具；Nmap 现在也记录了可使用这些查询的发现脚本。这些例子能证明工具具备相关能力，却不能证明有多少网络开放了查询。

RFC 4620 的历史意义相当克制：它让调试工具可以读取节点对自身信息的声明，同时明确节点有权不提供信息，而且该声明的证据等级低于权威记录。回答本身不能证明设备由谁控制，不能把名称归属于一家机构，也不应被自动升级成身份或资产事实。

来源