RA & DHCP problem...

Dmitry Anipko Dmitry.Anipko at microsoft.com
Mon Dec 30 04:29:58 CET 2013


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: ipv6-ops-bounces+dmitry.anipko=microsoft.com at lists.cluenet.de <ipv6-ops-bounces+dmitry.anipko=microsoft.com at lists.cluenet.de> on behalf of Lorenzo Colitti <lorenzo at google.com>
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 <nick at foobar.org<mailto:nick at foobar.org>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20131230/0dc12637/attachment.htm>


More information about the ipv6-ops mailing list