On 25/07/13 12:36, Uwe Schindler wrote:
Hi again,
one addition, because its too hot here... The reality is again
different (very complicated with IPv6):
Hot there too? Reply at the end.
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.
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.
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@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________ Dnsmasq-discuss
mailing list Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________ Dnsmasq-discuss
mailing list Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
