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

Uwe Schindler uwe at thetaphi.de
Thu Jul 25 22:32:06 BST 2013


Hi,

reading https://datatracker.ietf.org/doc/rfc6204/?include_text=1, the requirements for home routers are listed here:

   L-13:  If the delegated prefix changes, i.e., the current prefix is
          replaced with a new prefix without any overlapping time
          period, then the IPv6 CE router MUST immediately advertise the
          old prefix with a Preferred Lifetime of zero and a Valid
          Lifetime of the lower of the current Valid Lifetime and 2
          hours (which must be decremented in real time) in a Router
          Advertisement message as described in Section 5.5.3, (e) of
          [RFC4862].

This was my original proposal. I agree that this should be done by the PPP/WAN interface and the DHCPv6 cleint on the WAN interface, so the old prefix gets deprecated, but with current software available (ISC dhcpd does not work on PPP interfaces but would support that using a shell script applying the prefix delegation - and wide-dhcpc supports PPP interfaces, but it allows not to configure prefix delegation, so in deprecates addresses after PPP reconnect or a change of the prefix).

So I would be very happy, if dnsmasq (as router advertisement daemon would provide support for this). Radvd does it - see DeprecatePrefix options in radvd.

Uwe

> > >>> 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.
> > >
> > > Indeed ist more complicated but effect ist he same: For DSL lines
> > > you ahev in most cases the following setup: - PPP connection
> > > (PPPoE), creating network adaptor "ppp0" - this adaptor is coming on
> > > going when connections are created/released - LAN interface (on
> > > which dnsmasq is listening), "eth0", with a static IPv4 address and
> > > a dynamic IPv6 address prefix - wide-dhcpc client listening on the
> > > ppp0 interface and requesting prefix delegation. The delegated
> > > prefix is assigned as new address with given suffix (::1 or from mac
> > > address) to the eth0 interface.
> > >
> > > In fact, as you say: When ppp0 disconnects or reconnects, the
> > > wide-dhcp client should not actually remove the delegated prefix
> > > from the eth0 interface, but unfortunately it does. The reason for
> > > this is the following: the dhcp client stops when the ppp0 interface
> > > disappears, so it is restarted in the ifup scripts after the ppp
> > > connection was reconnected. When the wide-dhcpc client exits, it
> > > will "clean up" so it removes all addresses assigned ->  that's the
> > > problem.
> >
> > I think this is even more broken than that. Surely, what should happen
> > if the PPPoE link goes down and then comes up again is that the DHCP
> > client should attempt to renew existing DHCP leases, including prefix
> > delegations. Any sensible DHCP server at the ISP should give back the
> > same prefix delegations, so not only should the prefixes not be
> > removed from eth0 just because ppp0 goes down, they will probably not
> > even be deprecated once the PPP link is back. Using dnsmasq to
> > deprecate them once the PPP link goes is the last thing you should do.
> 
> Indeed! From my feeling the use of DHCP on a PPP interface is a horrible
> idea. Not even ISC's client supports it, but the providers seem to use it all,
> see https://datatracker.ietf.org/doc/rfc6204/ - So a fix in ISC's dhcp is long
> overdue to work with PPP - but e.g.,
> https://bugzilla.redhat.com/show_bug.cgi?id=626514 is open since years! In
> contrast, wide-DHCP is dead, so no updates since 2008!
> 
> To me this looks wrong altogether. The prefix should be assigned through
> the PPP protocol, like nameservers and addresses on IPv4. Using DHCP is just
> one more player in the whole game making it complicated. And this makes
> setup horrible. I have no more comments, I just need one more beer here in
> warm Germany :-)
> 
> > > Maybe this is different with ISC dhcp (because you can script the
> > > whole prefix delegation), but ISC dhcp is never used, because
> > > current versions of isc-dhcp cannot listen on ppp interfaces
> > > (refuses to start). There is no reason for this, on the mailing list
> > > they say it’s a relic from earlier IPv4 days. There is nothing
> > > against listening for DHCP on a ppp interface. Because of this most
> > > consumer routers (like the Fritzbox) use wide-dhcpc as client for
> > > prefix delegation on ppp interfaces (and easier to setup).
> > > Unfortunately wide-dhcp seems dead, son unless ISC updates their
> > > DHCP client to allow listening on ppp interfaces, too, we cannot use
> > > it. With ISC dhcp you could script the prefix delegation and indeed
> > > keep the address on eth0, but deprecated (preferred_lifetime==0).
> >
> > Unless you can renew the delegation, see comments above.
> 
> You cannot. In Germany everybody is braindead with privacy, so all careers
> randomize everything everywhere. Not only interface address
> randomization, also prefix randomization. In general the connection is
> renewed every 24 hrs for Deutsche Telekom PPP connections like in old IPv4
> days. I have another provider and I agreed to do the IPv6 tests for them, so I
> can report them back how braindead it is to use DHCP...
> 
> > I think we're coming to the conclusion that this is not a dnsmasq
> > problem, and we should be cautious in bending dnsmasq to try and fix it.
> >
> >
> > Cheers,
> >
> > Simon.
> >
> >
> >
> > >
> > >>> 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
> > >>
> > >>
> > >> _______________________________________________ Dnsmasq-
> > discuss
> > >> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk
> > >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> > >
> > >
> > > _______________________________________________ Dnsmasq-
> > discuss
> > > mailing list Dnsmasq-discuss at lists.thekelleys.org.uk
> > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
> >
> > _______________________________________________
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss at lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss




More information about the Dnsmasq-discuss mailing list