<div dir="ltr">On 27 March 2013 16:31, Fernando Gont <span dir="ltr">&lt;<a href="mailto:fernando@gont.com.ar" target="_blank">fernando@gont.com.ar</a>&gt;</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>
&gt; Phil,<br>
&gt;<br>
&gt; when everything works according to standards, temporary addresses are<br>
&gt; regenerated just before the preferred lifetime times out, so you have<br>
&gt; the possibility to alter the frequency of renewals by changing the<br>
&gt; 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&#39;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 &quot;new&quot; unicast RA arrives.</div>

</div></div></div>