On 10/21/13, Phil Mayers <[email protected]> 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. [email protected] > > 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 >
