Over-utilisation of v6 neighbour slots

[Andrew Yourtchenko]

On 10/21/13, Phil Mayers <p.mayers at imperial.ac.uk> wrote:

> Some questions:
>
>   1. Has anyone else run into this sort of thing (neighbour table
> exhaustion) and what kind of approach did you take to solving or
> ameliorating it? DHCPv6?
>

yeah DHCPv6 would address this (also with turning off the A-bit or
omitting the prefix, of course). I did not hit this form of exhaustion
directly for various reasons.

>   2. Does anyone know if Apple (and other vendors) understand the
> negative consequences of their aggressive rotation of IPv6 privacy
> addresses, and are going to address it?

We did have discussions with various people. One possible solution on
the client side is to spend the non-volatile storage to store the past
temporary addresses, and somehow remember them per link.
But even if someone would find the development cycles to do this (who
is willing to pay the money for it ?) then of course this will be
abused to be represented as an evil world domination plot or something
like that. Especially in the wake of recent events.

So, yes, "Let's learn to deal with it".

FWIW, this kind of behavior is advocated for the other OSes as well,
as an update to the core spec:

http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-08

Feel free to comment on the relevant maillist. ipv6 at ietf.org

>
>   3. Does anyone know if any equipment vendors have more intelligent
> strategies for handling this kind of situation - LRU expiry of v6
> neighbours at >90% util rather than self-destructing FIB overflow, for
> example ;o)

Or DAD on STALE addresses when over 60% of the per-host table is full,
and to those who insist on privacy, provide a quiet solitary
confinement by blocking all the traffic from the excess addresses :-)
(7.3+ WLC does just this).

>
> [We're aware the sup720 is old, but it seems like this could be an issue
> even for more recent devices at sufficient scale]

Yeah, this is a valid problem indeed. Did you have a lot of entries in
STALE state at all on c6k ?

there is a knob "ipv6 nd cache expire <seconds>", which could have
been of help if you have had many stale entries - shortening this
value would allow to clean up the old addresses from the cache.

For better or worse,  it does not affect at all the entries in
REACHABLE state, so if all of your entries were in REACHABLE, it would
be useless.

FHS ipv6 snooping allows to limit the % of entries per host (mac),
though do not know off top of my head if it does kick the neighbor
cache upon deleting the unresponsive entry. And even then, you need to
spend even more CPU time inspecting ND, which would not work too well
if it is already a constraint.

Between the Android not supporting DHCPv6 at all, iOS being so
aggressive about the privacy addresses, and the restricted resources
on the first hop, I suspect DHCPv6-only approach is the only sane
option in this scenario, even if at the expense of lower share of
IPv6.

--a

>
> Cheers,
> Phil
>