[Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues

[Simon Kelley]

On 24/03/12 15:38, Vladislav Grishenko wrote:

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

Of course, RA is  not right yet and your suggestions are good ones.
> 
>> 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.
> 

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


Same prefix

dhcp-range = 1234::1,1234::100
dhcp-range = 1234::, ra-only


does the same as

dhcp-range = 1234::1,1234::100
enable-ra

_except_ that the managed bits won't be set in the RA replies. It's not
pretty, but is does work.

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

Something like that. There's a trade-off between having something that's
simple (ie pick one keyword) and the fact that there are several
independent things to configure (DHCP-addresses, DHCP-other, SLAAC,
SLAAC names from DHCPv4)


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

In the damon->dhcp || daemon->dhcp6 case, send_alarm is called from
lease_update_file, since the first event in the future might be a lease
expiry, or it might be an RA multicast.

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

It shouldn't. There'd a check in lease_update_file of the file_dirty flag.


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

Got it. Thank you.
> 
>>> 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.

Agreed, I'm in touch with the Bufferbloat/CeroWRT people, who are
working on next-gen CPE implementations, but we've not go around to
talking much about this yet. I know that Comcast, in the 'states, is
talking about delegating prefixes for 6 months at a time, so renumbering
is not a "must have" just yet. It's one of those things that add lost of
bloat to the spec, but it's not clear how useful it really will be. The
6to4 case, maybe more useful. But is 6to4 going to be used much in the
real world?


I'm thinking about adding a "deprecated" keyword to dhcp-range, to set
the preferred lifetime to zero.
> 
>>> 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?
> 


Yes. It would be unacceptable if the leases turned out shorter than
promised, but this can only  make the leases longer. When a client gets
a lease, it gets a promise that the address ins available for x hours.
Increasing the time before the lease expires can only be a problem if
there's a shortage of addresses, so that addresses cannot be reused. In
most cases, the DHCP server will be up much longer than the lease time,
so the effect is small. If the DHCP server goes down often, the solution
is to reduce the lease time. Reducing the frequency of writes to flash
is important.

Cheers,

Simon.

> Best Regards, Vladislav Grishenko
> 
>