Too-frequent change of privacy address / ND monitoring

[Phil Mayers]

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