[Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?

[Uwe Schindler]

> On 24/07/13 19:16, Uwe Schindler wrote:
> > Hi,
> >
> >> RA's are not the same as DHCP, there's no such thing as a "lease 
> >> time". What there is, is preferred and valid lifetimes. What should 
> >> happen is that when old address is about to go away, the address 
> >> for that prefix on the network adaptor should have its preferred 
> >> lifetime set to zero, and dnsmasq will then notice that and send 
> >> RA's with the preferred lifetime also set to zero.
> >
> > I meant the life time, it was just a typo somehow :-) The idea here 
> > was to send preferred_lifetime=0 in RAs for prefixes that 
> > disappeared from the interface to "inform" the clients that they are 
> > no longer useable (my provider does not route old prefixes after a 
> > reconnect with PPP). Currently you have to set the lifetime very low 
> > (which produces more traffic on the wire) or manually delete or 
> > switch on/off the network adaptors once the router reconnects or the 
> > prefix changes for some reason.
> >
> > My proposal is to keep a list of "previous prefixes" from the 
> > constructor:ethX code and also send those prefixes, but with
> > lifetime=0 to inform all client to no longer use that address. Those 
> > 0-lifetime RAs should be sent at least for the length of the 
> > original lifetime. Radvd has code to handle this (although it’s a bit buggy).
> >
> 
> 
> My understanding of this is that it's something that should happen in 
> the DHCP client and/or ISP DHCP server.
> 
> Ie, when the prefix has to change, the ISP's DHCP server renews the 
> existing prefix delegation, but with the preferred lifetime==0. It 
> also offers a new prefix delegation. The old and new prefixes get 
> installed in the network adaptor with the preferred lifetime values. 
> Dnsmasq starts to advertise the new prefix and continues to advertise 
> the old prefix, but with the pref- lifetime at zero taken from the value in the adaptor.

The problem is different in most cases: When you have a dhcp client waiting on an PPPoE connection (e.g. wide-dhcpc, like most consumer routers use - ISC dhcp cannot listen on ppp interfaces unfortunately) and the PPPoE connection gets reconnected/disconnected, the ppp interface is disappears and is later recreated. When its disappearing, the whole set of IP addresses gets lost and they are not deprecated, so dnsmasq will not recognize any deprecation. I have seen your code that propagates the deprecation of existing interfaces in the RAs, but this only works if the prefix/IP address is still existing on the interface, just with preferred lifetime==0. With PPP interfaces disappearing and being recreated, this does not help, because the address is gone (it’s a new instance of the network interface, just with same name). As dnsmasq is mainly for consumer routers which are mostly working with PPP connections, it would be nice to have.

> Again, this is new territory, I'm not saying has to be done like that, 
> but that's the process I was thinking of when I wrote the existing code.

That's fine!

See also: http://manpages.ubuntu.com/manpages/precise/man5/radvd.conf.5.html

DeprecatePrefix on|off

              Upon  shutdown,  this  option  will cause radvd to deprecate the
              prefix by announcing it in the radvd shutdown  RA  with  a  zero
              preferred  lifetime and a valid lifetime slightly greater than 2
              hours. This  will  encourage  end-nodes  using  this  prefix  to
              deprecate  any  associated addresses immediately. Note that this
              option should only be used when only one  router  is  announcing
              the  prefix  onto  the  link, otherwise end-nodes will deprecate
              associated addresses despite the prefix still  being  valid  for
              preferred use.

              See  RFC4862, section 5.5.3., "Router Advertisement Processing",
              part (e).

              Default: off

Shutdown means in that case shutdown of interface, too. At least this is how it works for radvd.

Uwe

> Cheers,
> 
> Simon.
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss