摘要

  • RFC 4861 的基本模型在连续探测无回应达到上限后删除邻居缓存条目。
  • RFC 7048 改用 UNREACHABLE：替代邻居可以获得优先权，而原有链路层地址仍可在多播探测和指数退避下保留。

从“没有回应”到“不可继续偏好”

邻居不可达检测并不会持续询问所有已知邻居。上层协议提供的正向传输进展，或对 Neighbor Solicitation 的 Neighbor Advertisement 响应，都可以证明路径仍在工作。对于实际使用的条目，典型过程是 REACHABLE、STALE、DELAY、PROBE；进入 PROBE 后，节点向缓存中的链路层地址发送单播请求。

RFC 4861 的终点很直接：达到配置的无回应重传次数后，删除 Neighbor Cache Entry。RFC 7048 所描述的常见默认值是每隔一秒发送一次，共三次。存在其他默认路由时，这种快速判断有助于及时改选路径；Redirect 创建的条目也可以被放弃。

但在没有替代邻居时，删除并不会产生新的路由。后续数据包必须重新进行地址解析，因而可能在链路层短暂故障期间制造更多多播请求。

保留记录，不保留优先权

RFC 7048 在原本的删除位置引入 UNREACHABLE。节点增加重传超时并发送多播 Neighbor Solicitation。普通条目仍保留链路层地址，IPv6 数据包可以继续尝试发送到该地址；可是它不再被视为“已知可达”，下一跳选择因此可以优先考虑其他邻居。

Redirect 创建的条目有特殊规则：可以删除，而且处于 UNREACHABLE 时不应继续作为转发选择。保留也不是永久占用内存；实现仍可进行垃圾回收，甚至优先回收这些条目。

探测范围扩大，节奏放慢

即使最初的 UNREACHABLE 探测仍采用单播，节点也必须在初始重传后的 60 秒内切换到多播。这样，链路层地址已经变化的邻居仍有机会回应。更长时间的重传应采用指数退避，并可把间隔限制在合理上限，例如 60 秒。若没有数据包继续使用该条目，探测应暂停，直到重新使用或条目被回收。

RFC 7048 的示例计时用于说明算法，并不是所有实现都必须采用的统一计划。RFC 6583 则说明了运行环境：大量解析未分配地址可能耗尽 Neighbor Discovery 的队列和缓存，但它并不规定 UNREACHABLE 状态。

这项修改的历史意义不是简单地“等待更久”，而是拆开两个判断：是否继续偏好邻居，以及是否摧毁最后的映射证据。不可达描述的是当前状态，不是对曾经记录的彻底否定。

来源