Too-frequent change of privacy address / ND monitoring

[Tim Chown]

On 27 Mar 2013, at 08:16, Marco Sommani <marco.sommani at cnr.it> wrote:

> On 27/mar/2013, at 08:47, Erik Kline <ek at google.com> wrote:
> 
>> On 27 March 2013 16:31, Fernando Gont <fernando at gont.com.ar> wrote:
>>> On 03/26/2013 09:29 AM, Marco Sommani wrote:
>>> > 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.
>>> 
>>> Privacy addresses will very likely regenerate before such timer expires.
>>> -- Actually, such timer shouldn't expire if you continue receiving RAs...
>> 
>> I have in the past seen firewalls that dropped some critical packets but allowed others through (in one case: RS/RA were fine but ND was filtered, which led to IPv4 working in 3 second spurts, i.e. until NUD kicked in).
>> 
>> Totally random crazy idea: could there be firewalls on some of these machines that are causing multicast RAs to be filtered but unicast RAs are fine (e.g. a unicast RA reply to an RS)?  It could cause a machine to think the network went away after a unicast RA response, re-issue an RS and create a new tempaddr after the "new" unicast RA arrives.
> 
> 
> From my experience: I don't know about firewalls, but loss of multicast RAs sometimes is coaused by buggy implementations of igmp-snooping or mld-snooping on Ethernet switches. I have encountered some switches where igmp-sooping blocked all L2 multicasts with destination 33:33:xx:xx:xx:xx.
> 
> More recently, I have found switches where mld-snooping blocks all IPv6 multicasts directed to ff02::1. I presume that the implementors did not know that mld-registers are not required for that particular group. As a turn-around, I had to enable explicitly group ff02::1 on all ports via manual configuration.

Or quirky 'first hop security' implementations.

Tim
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20130327/ddd6e0d7/attachment.htm>