<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>