<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>On 27 Mar 2013, at 08:16, Marco Sommani <<a href="mailto:marco.sommani@cnr.it">marco.sommani@cnr.it</a>> wrote:</div><div><br></div><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div><div>On 27/mar/2013, at 08:47, Erik Kline <<a href="mailto:ek@google.com">ek@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On 27 March 2013 16:31, Fernando Gont <span dir="ltr"><<a href="mailto:fernando@gont.com.ar" target="_blank">fernando@gont.com.ar</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 03/26/2013 09:29 AM, Marco Sommani wrote:<br>
> Phil,<br>
><br>
> when everything works according to standards, temporary addresses are<br>
> regenerated just before the preferred lifetime times out, so you have<br>
> the possibility to alter the frequency of renewals by changing the<br>
> preferred-lifetime of the prefix in the Router-Advertisements.<br>
<br>
</div>Privacy addresses will very likely regenerate before such timer expires.<br>
-- Actually, such timer shouldn't expire if you continue receiving RAs...<br></blockquote><div><br></div><div style="">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).</div>
<div style=""><br></div><div style="">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.</div>
</div></div></div>
</blockquote></div><div><br></div>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.<div><br></div><div>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.</div></blockquote><div><br></div>Or quirky 'first hop security' implementations.<div><br></div><div>Tim<br><blockquote type="cite"><div><div apple-content-edited="true">
</div>
<br></div></blockquote></div></body></html>