GRAND：解决IPv6首包延迟难题
Closing the IPv6 First-Packet Gap with Grand
IPv6邻居发现协议中存在一个微妙不对称：主机知道如何到达路由器，但路由器可能还不知道如何回传数据给主机。这导致连接建立时的首包可能因地址解析而延迟甚至丢失。我在FreeBSD中实现了GRAND机制，让主机主动广播其IPv6地址和链路层地址，而非等待路由器被动发现。通过遵循RFC 9131及RFC 4861的延迟与随机化规则，GRAND在不引发组播风暴的前提下，将首包地址解析从关键路径中移除。这不仅优化了IPv6部署体验，也揭示了协议设计与工程落地之间的细微差距。
GRAND将反应式的邻居发现转变为主动的信息广播，让路由器在需要转发流量前就已知晓如何到达主机。
HN 评论区
20- mort96
等等，我没看懂。
如果我的理解没错，传统的 IPv6 流程是：
* 主机通过 SLAAC 配置自己的 IP 地址
* 主机向网关发送一个带有目标地址的数据包
* 网关将数据包转发到互联网
* 最终，响应数据包到达网关
* 此时，网关执行邻居发现（ND），试图弄清楚如何将数据包发送给主机
* 网关可能会丢弃该数据包，或者在邻居发现完成之前延迟转发
为什么我们不能把流程改成：
* 主机通过 SLAAC 配置自己的 IP 地址
* 主机向网关发送一个带有目标地址的数据包
* 网关转发数据包，同时启动邻居发现，因为几乎所有发送出站数据包的主机最终都会收到一些入站数据包
* 当响应数据包到达时，邻居发现很可能已经完成了，或者至少已经抢先跑了一大截
这难道不是显而易见的解决方案吗？它不需要修改主机或引入新协议，只需要对路由器做一点小调整。通常，当一个现实问题看似有一个显而易见的简单解决方案，而从事网络标准的聪明人们却都没有实现它时，往往是有原因的，而且这个解决方案并不像看起来那么简单。所以我到底漏掉了什么？
- happyPersonR
最近在处理一个环境时，看到所有这些行为挺有意思的，那个环境期望：
1) SLAAC/静态 IP
2) 多个默认网关，然后通过 BGP 导入路由（包括多个默认网关的路由），并启动 BFD 来确定哪个是活动的
3) 接着你开始通过 BGP 广播自己的地址
我希望能有一个 systemd 守护进程可以配置来做这些。对于那些不了解其工作原理的人来说，这听起来很荒谬，但在数据中心里，这确实是一个相当有趣的流程。
我希望在 Kubernetes/普通 Linux 世界里也有一个等价方案，但我能理解其中的可扩展性顾虑 :)
我知道 BIRD 存在，但我希望这类功能能内置一些……让我看看 systemd 是否支持扩展……加上去会很酷 :)
我相信会有更多人想要这个功能。