Too-frequent change of privacy address / ND monitoring

[Marco Sommani]

Phil,

when everything works according to standards, temporary addresses are regenerated just before the preferred lifetime times out, so you have the possibility to alter the frequency of renewals by changing the preferred-lifetime of the prefix in the Router-Advertisements. On a Cisco Router the command (to be issued under "interface") is:

ipv6 nd prefix-advertisement ipv6-prefix/prefix-length valid-lifetime preferred-lifetime

Values are expressed in seconds and valid-lifetime must be greater than preferred-lifetime.

If you are observing something different, I'd suspect that there is some bug somewhere. On my site we have more than 1.000 ipv6-enabled hosts, all configured via SLAAC, and we also collect data from ND messages, but we never observed the problem that you are mentioning.

Marco

On 26/mar/2013, at 13:14, Phil Mayers <p.mayers at imperial.ac.uk> wrote:

> All,
> 
> When rollout out IPv6, we deployed using SLAAC, and extended our IPv4 ARP monitoring to include IPv6 neighbour tables, giving us accounting of who had what IP.
> 
> This works pretty well, except for a couple of problems, one minor, one major.
> 
> The minor problem is that IPv6 privacy addresses from Win7 machines change very frequently, much more so than the IPv4 addresses. This means our data volume has gone up by a large fraction - nearly 100 (26 weeks * 1 address a week * 4x IPv4 storage size). This is tolerable because the total volume is stll pretty small and the DB is architected with a "live" and "old" table, so the in-memory size is sane.
> 
> However, the more serious issue we've faced is (presumably broken) hosts who re-generate their privacy addresses EXTREMELY frequently - on the order of minutes. I have one host (a Mac, I believe) that has 15,000 addresses in the last 6 months, all on the same subnet. Another PC with 12,600, and so on. And these are just the ones I can see - for all I know, it's changing once a second.
> 
> These few hosts account for a huge amount of our IPv6 ND tracking. I can't see any obvious reason a host would do this - the port they're on is stable, no errors, no flapping, and our IPv6 ND timers are reasonable though a fair bit shorter than defaults - 900 max and 600 preferred (they're set short to "auto remove" IPv6 if something explodes; this was precautionary when we were rolling out, but maybe we should increase them now?)
> 
> Has anyone seen this behaviour? Any idea as to the cause? Presumably it will be causing the host problems, if it can't maintain long-lived IPv6 connections.
> 
> To forestall a couple of suggestions:
> 
> DHCPv6 is not an option due to missing/buggy DHCPv6 relay functionality on 6500/sup720 (output interface is selected as Null0 when using L3VPN with LSP as a next hop - cisco claim this "works as intended"!).
> 
> And turning off privacy addresses is not a widely available solution, as many of these machines are unmanaged.
> 
> Cheers,
> Phil

-- 
Marco Sommani
Consiglio Nazionale delle Ricerche
Istituto di Informatica e Telematica
Via Giuseppe Moruzzi 1
56124 Pisa - Italia
work: +390506212127 (PSTN and nrenum.net)
mobile: +393487981019
fax: +390503158327
mailto:marco.sommani at cnr.it