Is there a chance this discussion can be captured in http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6-comparison-00 , or in some other "problem statement" document for potential issues re configuring routing with RAs?
There has been a few discussion recently on this topic, and hence it does seem there is pain, however it doesn't seem there is a consensus on what all the pain points exactly are, as well as that DHCP is necessarily the right cure for that pain. To me it seems that capturing pain points in a document, which by going through the standard IETF process would (or would not) gather consensus on the problem statement, could be a productive way to move forward toward a solution. ________________________________ From: [email protected] <[email protected]> on behalf of Lorenzo Colitti <[email protected]> Sent: Sunday, December 29, 2013 2:25 PM To: Nick Hilliard Cc: IPv6 Ops list Subject: Re: RA & DHCP problem... On Sun, Dec 29, 2013 at 10:18 PM, Nick Hilliard <[email protected]<mailto:[email protected]>> wrote: On 29/12/2013 20:48, Lorenzo Colitti wrote: > Is the size an issue here? Is there something about having tens of > thousands of IPv6 hosts that makes RAs unsuitable? yes, size is an issue: it means that tweaking ns-interval is not feasible as a mechanism for dropping failover times. Agreed, using NUD timers for failover (aka "hammer the first-hop router") doesn't scale. and if your hosts miss a packet, you get traffic swinging to your other default. You may like to debug this sort of thing, but I operate in companies with non-telephone number cost constraints and have a strong need for operational simplicity and consistency. It depends on how much loss there is and how many hosts switch. But yes, you probably want some margin. > The operator can drop a protocol, but the host implementer needs to > handle yep, exactly, but please bear in mind that networks are provisioned by operators for end-users. Network stacks are not written by host implementers for their own gratification. True, but the party that pays the cost is always the end user. doesn't scale. Routers are routers, not policy management engines. DHCP is for policy management and there is just no scalable way of handling this on routers. There's nothing stopping the routers from getting this information via RADIUS. > DHCP doesn't help there. If you want better than that, you need to use > something like VRRP anyway. Yes, I know: DHCPv6 + a first-hop routing protocol. This is the scenario I am interested in deploying. You know what? It works really well in practice. Well, but so does RA + VRRPv3. In addition to working in practice, it's a standard.
