RA & DHCP problem...
Lorenzo Colitti
lorenzo at google.com
Sun Dec 29 23:25:21 CET 2013
On Sun, Dec 29, 2013 at 10:18 PM, Nick Hilliard <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/20131229/051f3262/attachment.htm>
More information about the ipv6-ops
mailing list