<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><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><div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">-- <br>Marco Sommani<br>Consiglio Nazionale delle Ricerche<br>Istituto di Informatica e Telematica<br>Via Giuseppe Moruzzi 1<br>56124 Pisa - Italia<br>work: +390506212127 (PSTN and <a href="http://nrenum.net">nrenum.net</a>)<br>mobile: +393487981019<br>fax: +390503158327<br><a href="mailto:marco.sommani@cnr.it">mailto:marco.sommani@cnr.it</a></div></span></div></span></span>
</div>
<br></div></body></html>