RA & DHCP problem...

Hannes Frederic Sowa hannes at stressinduktion.org
Sun Dec 29 22:58:20 CET 2013


On Sun, Dec 29, 2013 at 09:18:13PM +0000, Nick Hilliard 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.  It also means that whatever
> solution is put in place needs to scale well

I guess you are talking about a client network? Isn't mld and dad multicast
traffic becoming a problem much earlier on?

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

Especially if the default route does not swing back to the high-pref
one once it is reachable again (that was an issue in linux land). ;)

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

Is this really becoming a problem? Do you have numbers for this?

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

I guess the people behind dibbler did this for a valid reason. And before
using first-hop routing protocols it seems better to extend DHCPv6.

The IETF homenet WG has a draft (and I already have seen
implementations) of AHCP. They intend to replace RA and/or DHCPv6
with that (I heard they plan to use OSPF on the first-hop, too):
http://tools.ietf.org/search/draft-chroboczek-ahcp-00

Maybe a bit more collaboration would be helpful here, I don't know?

So, I guess your concerns are valid, but you need to have some reasonable
proposal and reason to convince the IETF 6man folks to consider such an
option (given that it was rejected once before).

Greetings,

  Hannes



More information about the ipv6-ops mailing list