摘要

  • RFC 1256 的默认通告寿命是 1,800 秒：主机在没有收到刷新通告时，最多等待这么久才忘记动态学到的路由器；它不承诺三十分钟内完成流量切换。
  • RFC 明言，默认的 7.5 至 10 分钟通告节奏不足以在传输会话超时前发现首跳黑洞；RFC 1122 则把死网关检测交给另一项主机功能。

网关故障令人不安的部分，有时并不是故障本身，而是主机仍把它留在列表里的那段时间。路由器可能已经无法转发，主机却尚未忘记它。

1991 年 9 月，RFC 1256 为主机提供了发现邻近路由器的办法，不必手工维护地址清单，也不必依赖某一种路由协议。路由器定期发送 ICMP Router Advertisement；接口启动时，主机也可以发出少量 Router Solicitation。这个机制解决了“谁在附近宣告自己是路由器”，而它最值得注意的设计决定，是这份宣告可以被相信多久。

默认值刻意压低了通信频率。最大通告间隔为 600 秒，默认最小间隔是它的 75%，即 450 秒。每次下一间隔从区间内随机选择，因此通告大约每 7 分半至 10 分钟出现一次，而不是所有路由器同时发送。寿命则默认为最大间隔的三倍：1,800 秒，也就是半小时。

这段寿命是一项本地状态的租期。主机收到邻近路由器的有效通告后，会把地址加入默认路由器列表，并以通告中的寿命启动计时器；后续通告会刷新计时器。计时器到期时，主机删除动态学到的条目。静态配置的路由器则不同：它不会仅仅因为被配置就自动获得这个过期计时器。

把“三十分钟”看成故障切换设置很容易，但 RFC 明确否定了这种读法。它解释说，默认频率和寿命的目标，是即使链路上存在许多路由器，也尽量减少链路与主机负担；同时也承认这些默认值不足以在传输会话超时前发现首跳黑洞。管理员可以缩短间隔和寿命，但标准并未声称他们都这样做。

关键在于，发现与存活性是两个不同问题。通告表达的是：“这个地址作为邻近路由器可供使用，在没有刷新时最多保留这么久。”它并不验证发往某个目的地的数据包此刻是否能经由该路由器到达。RFC 1256 也说，Router Discovery 不是路由协议：它不会为每个目的地选出最佳路径。ICMP Redirect 处理的是另一类情况——数据包已经经由某台路由器发出后，是否存在更合适的下一跳。

RFC 1122 写明了架构的另一半：IP 层必须检测下一跳网关是否失效，并选择备用网关；但 1989 年的标准也承认，当时没有完全令人满意的通用算法。持续 ping 网关既昂贵，也无法良好扩展，因此不应这样做。相反，传输层和链路层可以向 IP 提供线索：TCP 收到确认是正面证据；反复重传失败或链路层告警则可能是负面证据。RFC 1256 的计时器从未打算取代这些判断。

启动时的 Solicitation 可以更快取得初始信息，但它不是永久心跳。主机最多发送三次 Solicitation，间隔三秒；收到有效通告后就必须停止。之后由周期性通告维持列表的新鲜度。沉默最终会让条目消失，却不会单凭沉默确定路径从何时起已不可用。

因此，这段历史讲的是两种证据的分工，而不是“半小时故障”。Router Discovery 降低配置负担，并保存一份有期限的路由器宣告记录；死网关检测则要判断当前转发状态，并综合流量与其他协议层的信号。若把过期计时器说成服务恢复承诺，就混淆了两项工作，也替 RFC 增添了它明确没有给出的保证。

依据是 RFC 1256 和主机要求 RFC 1122 第 3.3.1.4 节。它们规定的是默认值与设计边界，不是某个操作系统、网络或用户在真实网关故障后的恢复速度。