Re: nd6 'stale' timer unreasonably long?

> Update: The issue with the massive packet loss seems to be an independent 
> problem on our end, which is only exaggerated but not caused by the 
> ND cache overflowing (NetBSD forgets a neighbor due to the cache overflow, 
> and the subsequent Neighbor Solicitation happens to get lost in 
> a different way, causing sort of a black out moment).  Anyway for 
> NetBSD's purposes that part of the issue can be disregarded.

To elaborate on this: We got reports of massive packet loss in the 
eduroam WiFi.

We tracked this down to an interaction of ND cache overflow and multicast 
packet loss on the WiFi: since the ND cache overflows, the gateway sends 
out an ns, which never arrives at the station, causing the packet the ns 
was sent for to also get lost.

Another question that arose is why the gateway sends an ns in the first 
place. The setup is a laptop (both on WiFi and cable for test purposes) 
ping-in an outside host (which reports massive loss in the WiFi, but not 
in the cable case). There is exactly one hop (our gw) between the laptop 
and the outside world.

The gw recieves the icmp6 echo request from the laptop (via the Access 
Point, which acts as a bridge, not a router), which should cause the 
nd cache to gain the laptop's MAC. I then routes the echo request out, 
nearly immediatly receives an echo reply and wants to route that to the 
laptop. But why on earth does it now send out an ns for the laptop? 
I think this should only happen when the laptops's entry happened to be 
removed from the nd cache in the some milliseconds between the 
echo request and the echo reply, which shouldn't be the case frequently.