Too-frequent change of privacy address / ND monitoring

[Dale W. Carder]

Thus spake Phil Mayers (p.mayers at imperial.ac.uk) on Tue, Mar 26, 2013 at 12:14:38PM +0000:
> 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.
 
mysql> select count(v6addr) as frequency, substring(macaddr,1,6) as oui
from physaddrv6 group by macaddr order by frequency desc limit 10;
+-----------+--------+
| frequency | oui    |
+-----------+--------+
|      8694 | c82a14 | 
|      7731 | 406c8f | 
|      4227 | 406c8f | 
|      3783 | a82066 | 
|      2763 | c82a14 | 
|      2433 | 000c29 | 
|      2422 | 0026b9 | 
|      2319 | a4badb | 
|      1948 | 002219 | 
|      1835 | a82066 | 
+-----------+--------+
10 rows in set (0.77 sec)

I don't see anything as bad as you mention as this dataset contains a
year's worth of data.  These oui's are all apple or dell.  The top one
is vmware, so who knows what it's doing.  Disclaimer: this data is only 
for our wired networks, so iDevices wouldn't necessarily be represented 
here.

Dale