<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Dec 29, 2013 at 1:04 PM, Nick Hilliard <span dir="ltr"><<a href="mailto:nick@foobar.org" target="_blank">nick@foobar.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">rather than depending on </span><span style="color:rgb(34,34,34)">vendor hacks which might or might not be supported, depending on phase of moon / the specific FHRP used / etc.</span></div>
</blockquote><div><br></div><div>Why is this a hack? Per RFC 5798:</div><div><br></div><div><div> IPv6_Addresses One or more IPv6 addresses associated</div><div> with this virtual router. Configured</div>
<div> item with no default. The first address</div><div> must be the Link-Local address associated</div><div> with the virtual router.</div>
</div><div><br></div><div>While the RFC doesn't say explicitly that this address needs to be the one sending the RA, I don't see how you could implement it differently.</div><div><br></div><div>However, if there are indeed implementations that don't allow sending RAs from the link-local address of the virtual router, then writing a document saying that VRRP must allow the implementation to be configured to do so is likely to be a lot less controversial than attempting to standardize routing in DHCPv6.</div>
</div></div></div>