RA & DHCP problem...

[Nick Hilliard]

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.  It also means that whatever
solution is put in place needs to scale well

Separate to this, it would be ideal to have host autoconfiguration both
centrally managed and have a single configuration mechanism because doing
it any other way is a pain.  For me, that is.  If you want to run
medium-scale deployments like this with host autoconfiguration stuff in
multiple places, then I'm ok with that because it's your network and I
don't mind.

>     The alternative is to advertise RAs at the rfc-specified minimum interval
>     of 3s, giving a failover time of 10s.  This isn't compatible with many
>     business cases.
> 
> Why 10s? Have two routers send out RAs every 3 seconds and give them a
> lifetime of 5 seconds. That should give you maximum 5s failover (average
> 2.5s), because after 5s the RA will expire.

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.

In other words, I don't want to set my network up with a default gateway
that times out by policy every 5s because that is not a stable configuration.

There's another issue: my intended deployment scenario is medium-scale
third party vm hosting.  If you have routers churning out RA packets, each
host needs to process these packets simultaneously across all vms, network
wide.  This will increase cpu usage and resident memory requirement, maybe
not by much per host, but bear in mind that this is intended to scale
across tens of thousands of hosts.

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

>     4. there is no way for RAs to deploy different gateways to different hosts:
>     all hosts on the network must be configured in the same way.
> 
> You can use unicast RA replies for that.

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.

>     5. there is no way to specify anything other than a default gateway.
> 
> What do you mean? If you mean there's no way to configure more specific
> routes, RFC 4191 has allowed that since 2005.

As Phillipp Kern kindly pointed out, I got this wrong.

>     6. the failover characteristics of RAs are very poor by modern standards.
> 
> 
> 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.

Nick