Too-frequent change of privacy address / ND monitoring

[Eric Vyncke (evyncke)]

Others have also noticed that over wireless, iPads are going in sleep mode quite often and always generate a new SLAAC when they wake up... Dozens of addresses per day...

> -----Original Message-----
> From: ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de [mailto:ipv6-ops-
> bounces+evyncke=cisco.com at lists.cluenet.de] On Behalf Of Phil Mayers
> Sent: mardi 26 mars 2013 13:15
> To: ipv6-ops at lists.cluenet.de
> Subject: Too-frequent change of privacy address / ND monitoring
> 
> 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