<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Dec 29, 2013 at 10:18 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 29/12/2013 20:48, Lorenzo Colitti wrote:<br>
> Is the size an issue here? Is there something about having tens of<br>
> thousands of IPv6 hosts that makes RAs unsuitable?<br>
<br>
</div>yes, size is an issue: it means that tweaking ns-interval is not feasible<br>
as a mechanism for dropping failover times.<br></blockquote><div><br></div><div>Agreed, using NUD timers for failover (aka "hammer the first-hop router") doesn't scale.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and if your hosts miss a packet, you get traffic swinging to your other<br>
default. You may like to debug this sort of thing, but I operate in<br>
companies with non-telephone number cost constraints and have a strong need for operational simplicity and consistency.<br></blockquote><div><br></div><div>It depends on how much loss there is and how many hosts switch. But yes, you probably want some margin.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> The operator can drop a protocol, but the host implementer needs to<br>
> handle<br>
<br>
</div>yep, exactly, but please bear in mind that networks are provisioned by<br>
operators for end-users. Network stacks are not written by host<br>
implementers for their own gratification.<br></blockquote><div><br></div><div>True, but the party that pays the cost is always the end user.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)">doesn't scale. Routers are routers, not policy management engines. DHCP </span><span style="color:rgb(34,34,34)">is for policy management and there is just no scalable way of handling this </span><span style="color:rgb(34,34,34)">on routers.</span></div>
</blockquote><div><br></div><div>There's nothing stopping the routers from getting this information via RADIUS.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> DHCP doesn't help there. If you want better than that, you need to use<br></div><div class="im">
> something like VRRP anyway.<br>
<br>
</div>Yes, I know: DHCPv6 + a first-hop routing protocol. This is the scenario<br>
I am interested in deploying. You know what? It works really well in<br>
practice.<br></blockquote><div><br></div><div>Well, but so does RA + VRRPv3. In addition to working in practice, it's a standard.</div></div></div></div>