[Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues

Vladislav Grishenko themiron at mail.ru
Sat Mar 24 15:38:09 GMT 2012


> From: dnsmasq-discuss-bounces at lists.thekelleys.org.uk [mailto:dnsmasq-
> discuss-bounces at lists.thekelleys.org.uk] On Behalf Of Simon Kelley
> Sent: Saturday, March 24, 2012 8:31 PM
> 
> On 23/03/12 22:36, Vladislav Grishenko wrote:
> >
> > Usually it's done by specifying Other bit in RA, while Managed is
> > switched off. This allows host to configure address from the prefix,
> > but ask DNS, Domain, etc via DHCPv6.
> >
> 
> Thanks for your issues list below: I'll go through them in the next day or
two,
> but I can already see that 4) at least is a real bug.
> 
> It's worth saying that the RA support in dnsmasq is _not_ meant to be a
> complete implementation. It started as  an easy way to do the minimum
> required to be able to to DHCP, and has expanded a bit since then, but for
a
> completely flexible RA implementation, it's intended that radv or similar
will
> be used.
>
> Also, IPv6 is quite new to most people, me included, and so we're still
> learning what actual features will be used in practice. This is not really
known
> yet by anyone (see the IETF homenet working group for details). I don't
want
> to implement the whole of every possible facility that's been defined by
the
> rampant second system effect. that would bloat dnsmasq to much and it's
> supposed to be small.

More than agree, I respect your position and thanks for the effort.
But, it was quite expected that RA support improvement is about to be asked
just because it exists already in sub-minimal form,
So, just a matter of time, I guess.

> That said, I think SLAAC+stateless DHCPv6 is a mode I want to support, and
it
> isn't supported at the moment, you're right.

Ok, this solution is quite common until all possible clients/hosts are
dhcpv6-statful-aware.

> > Unfortunately, this config is quite impossible now, refer issues list:
> >
> > 1.M+O bits are set if dhcv6 enabled only, and no bits set, if disabled.
> > That means bits is always cleared with ra-only/ra-names, no matter set
> > dhcp6 options or not.
> >
> > 2.Dhcp6 options without range will not create contexts, therefore
> > dnsmasq doesn't listen dhcp6 requests. So, without this pt.1
> > enhancement is pointless.
> >
> 
> A way to do this is is have a "real" dhcp range, as well as the ra-only
one. The
> will  solve at least some of these problems. The M+O bits will both be
set, but
> DHCPv6 requests for stateless options will be honoured.

You mean different prefixes? Hosts should ignore RA prefix if there's
managed bit set.

> There's no way to set only the O bit, I'll think about how to do that.

Probably, ra-only/ra-names syntax can could be replaced with
slaac/dhcp6-stateless/dhcp-statefull form..
Can't say about the best solution which natively fits conf syntax.

> > 3.Periodic RA isn't working, because alarm code goes into (dhcp ||
> > dhcp6) path and don't trigger RA alarms
> 
> This code does that, I think.
> 
> #ifdef HAVE_DHCP6
>          else if (daemon->ra_contexts)
>            /* Not doing DHCP, so no lease system, manage alarms for ra
only */
>              send_alarm(periodic_ra(now), now); #endif

Yes, but it "else" condition of (damon->dhcp || daemon->dhcp6).
In my case and example, damon->dhcp is enabled, so periodic_ra will not be
executed as expected several times while first minute.

> > Only other netlink/dhcpv4 events could trigger it. Also, even if fixed
> > event logic leads to DHCP leases rewrite on every RA event by design.
> 
> I'm not sure I follow that. How?

In ra_init first next event(s) are set to now or a bit ahead of ra_time.
At the dhcp/netlink alarm moment they could be in the past and therefore
just executed without any new ra alarm rearm.
This causes only post-check of ra conext timers.

> > About prefix lifetimes, you refer rfc2462 in the code which is
> > obsoleted by rfc4862.
> > 2 hours rules is only about Valid Lifetime, but Preferred Lifetime
> > might be and usually is much smaller in dynamic v6 prefix environments.
> > The problem is dnsmasq doesn't use separate valid/preferred values,
> > this leads to default gateway lost issue due some "server"
> > reconfiguration when client still threat 2h prefix is valid and
preferred.
> 
> This is a bigger problem: how to support hitless network re-numbering.
> I'll tackle it if it becomes clear that it's actually needed for the sort
of
> applications dnsmasq gets used for. At the moment it's not clear it will
be.

I can say that dnsmasq is widely used in embedded CPEs with wide range of
IPv6 upstream types.
Two cases really require the inner network renumbering support - 6to4 tunnel
with dynamic ipv4 external address and dhcpv6 with dynamic IA_PD.
IPv6 world has no NAT (in traditional meaning), so it's quite pointless to
setup private unrouted IPv6 ranges for local networks.
Transparent renumbering is a big deal, to force client to treat old prefix
as expired, its lifetimes should be dropped to zero, if not (not possible) -
administrator may set preferred lifetime to small value. This will force new
connection to be originated from the new address. When valid lifetime is
over - all existing connections should be disconnected by the stack
immediately.

> > Not related to subject, but have to say.
> >
> > With HAVE_BROKEN_RTC lease file doesn't contain expire time, but
> > length, which is constant.
> >
> > So, after restart/reload all leases get prolonged lease time, and
> > possibly never expired then.
> >
> > Solution is quite simple - store not only lease length, but calculated
> > remaining time too. With this values it's possible to correct count
> > all previous timings.
> >
> 
> But to do that the file has to be re-written at regular intervals to keep
the
> remaining time as it changes. One of the reasons for HAVE_BROKEN_RTC is
> to reduce the frequency of writes to the leases file so it can be kept in
flash
> memory without wearing it too fast.

Yes, it's known.
Don't you find this trade-off between totally inaccurate lease time and
almost accurate with expections - as acceptable?

Best Regards, Vladislav Grishenko




More information about the Dnsmasq-discuss mailing list