RA for a different router

Nick Hilliard nick-lists at netability.ie
Sun Dec 20 21:56:32 CET 2009


On 20/12/2009 10:01, Alexander Clouter wrote:
> I probably missed the memo but *why* would you want to send the default 
> gateway in a DHCPv6 response when the local network topology would 
> *know* far more accurately what is going on.  Especially when you 
> consider gateway failover and that in theory you do *not* need anything 
> like VRRP/HSRP as the glue to do this.

RA gateway fail-over takes $client_ra_timeout seconds for clients to
realise that the gateway has disappeared, where $client_ra_timeout is
substantially greater than $ra_announcement_interval (probably by a factor
of at least 3 in order to cope with packet loss, etc).  Typically,
$ra_announcement_interval will measured in seconds, possibly tens of
seconds.  This leads to fail-over times of tens of seconds to possibly
minutes.   vrrp / hsrp / glbp will typically provide fail-over in an order
of magnitude less time.

As a network operator, I would be much happier depending for network
stability on vrrp & friends (which I can control) rather than waiting for
each client machine on a potentially large network to reconfigure its
default gateway (which I can't control, or at least control well or easily).

Also, on this particular argument, if you have a network where your
dhcp(v4|v6)-announced gateway is unavailable, you either have a broken
network design or a network which is broken to the extent that the use of
RA probably wouldn't have made much difference in the first place.  I have
seen otherwise very smart people argue that because they have seen
anecdotal problems with default gateways disappearing on a dhcp-managed
network, that therefore DHCP+default gateway announcements are therefore a
broken design, concluding that RA is superior.

Charitably, this argument is about as convincing as "Monsieur, (a+bn)/n =
x; donc Dieu existe! Répondez!".

> Well if the world, the network sysadmin's and venduh's learnt about SRV 
> records and SLP, we would not be in this situation.  You can already get 
> a feel of how things Should Work(tm) with multicast NTP and SAP/SDP, we 
> just need the rest of the world to wake up.

Well, maybe, maybe not.  There's never been a shortage of ideas about L4-L7
service availability / auto-provisioning throughout the years, whether
based on SRV records or SLP or even ACAP (rfc2244, not the more recent DRM
abomination) or any of the other protocols scattered like bones in the
graveyard section of the RFCs.  The internet community never went down that
road, which in some ways is quite the pity - at a certain stage, I remember
thinking how useful some of these things might be.  But the service
provider IP access model diverged from the early-days
service-provider-provides-all model, and we have quite a different internet
now than what the original authors of those protocols probably ever
envisaged.  This is certainly a good topic of discussion for a long evening
over lots of beer.  That, and the problems of the world.

> *sigh*
> 
> Bear in mind as a *organisation* network monkey I do not need DHCP-PD, 
> but that's what stateless DHCPv6 is all about.

grief, don't get me started on stateless vs stateful dhcpv6. :-(

Nick


More information about the ipv6-ops mailing list