Re: nd6 'stale' timer unreasonably long?

[Timo Buhrmester <timo%math.uni-bonn.de@localhost>]

Digging somewhat deeper, in 2015 the IPv6 neighbor cache was turned into a per-interface structure: (apologies for using the git mirror)

| commit ecd5b23eefe434386585c21203c3e3c122d4d399
| Author: ozaki-r <ozaki-r%NetBSD.org@localhost>
| Date:   Wed Nov 25 06:21:26 2015 +0000
| 
| [...]
|     the change brings one degradation; the old GC mechanism
|     dropped exceeded packets based on LRU while the new implementation drops
|     packets in order from the beginning of lltable (a hash table + linked
|     lists). It would be improved in the future.
| [...]

(Is the future here yet?)

Another commit a year later added quite some insanity (IMHO) to "fix unstable test results of ndp_neighborgcthresh" which strikes me as very questionable -- it essentially adds another argument to the GC routine with the semantics of "please do not remove this one particular address so our tests don't blow up".

What I suspect should be done is:
  a) implementing the promised LRU GC -- IMHO it's not an issue if that is a relatively costly operation, because of b).  

  b) If the nd6 stale timer wasn't so extremely long (24h), the default neighbor cache limit of 2048 would most likely never be reached except in very busy networks.  If a DoS attempt is made which this limit then mitigates, performance is (due to the DoS) likely already crappy, so a O(n) or O(logN) or so operation *that actually removes a substantial chunk of the cache instead of 10 entries* wouldn't hurt too much, I think.

  c) I think a sysctl for that GC timer might be appropriate.