[Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues

Simon Kelley simon at thekelleys.org.uk
Sat Mar 24 14:30:55 GMT 2012


On 23/03/12 22:36, Vladislav Grishenko wrote:
> Hi Simon,
>
> Latets git (2.61test7) brings several RA issues,
>
> My configuration (simplified):
>
> HAVE_DHCP, HAVE_DHCPv6, HAVE_BROKEN_RTC
>
> interface=br0
>
> dhcp-range=192.168.1.101,192.168.1.254,86400
>
> dhcp-range=2001:470:xxxx:xxxx::,ra-only,64,2h
>
> dhcp-option=option6:23,[::]
>
> I was trying to setup dual-stack environment with IPv6 SLAAC and DNS via
> DHCPv6
>
> 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.

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.

> 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.

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

> 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

> 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?
>
> 4.Router Solicitation messages doesn’t trigger send RA, due 2 reasons:
> icmp6fd isn’t in read fdset , and icmp6fd socket isn’t joined to
> ALL_ROUTERS group.
>
Ah, yes, thanks, that's a real bug, for sure.

> All this because there’s no dhcp6 context configured for ra-only/ra-names
>
> 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.
>
> 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.

Cheers,

Simon.



More information about the Dnsmasq-discuss mailing list