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

[Simon Kelley]

On 25/07/13 11:59, Uwe Schindler wrote:
> Hi again,
>
> In addition, I found a relic from the time when the RA_INTERVAL value
> was hardcoded into radv.c. There is still one:
>
> Line 294: put_opt6_long(1800); /* lifetime - twice RA retransmit */
>
> Should be: put_opt6_long(RA_INTERVAL * 2); /* lifetime - twice RA
> retransmit */

Yes, that's a bug.
>
> I am currently looking into the code to find an easy way how to make
> the RA_INTERVAL configureable, maybe I can provide a patch. But if
> it's easy for you, it would be really nice to have this in future
> versions. So the deprecation of addresses no longer used on the
> network interface is not my primary concern, more I would prefer to
> work around the bugs in certain android phones not receiving ICMPv6
> messages in standby mode, so the RA_INTERVAL should be configureable
> (I want to set it to much lower values than 600s, I have a patched
> version with 6s retransmit running on my debian testing box).
>

Note that RA_INTERVAL is used in the code for two related things.

1) It sets the lifetime values for parameters being sent. At the moment, 
the router advertisement is set to three times RA_INTERVAL, the DNS 
server and domain-search params are twice RA_INTERVAL, and prefixes are 
set to (at least RA_INTERVAL)

2) It sets how often unsolicited RA's are sent.

Clearly these are related, the lifetime of parameters must be at least 
until they can be renewed by another RA, and preferably longer, to allow 
for packet loss.

You probably don't want to reduce the lifetimes, that would be 
counter-productive for the Android bug. you do want to send RAs more often.


The relevant code for that is here:

if (difftime(param->now, context->ra_short_period_start) < 60.0)
	  /* range 5 - 20 */
	  context->ra_time = param->now + 5 + (rand16()/4400);
else
	  /* range 3/4 - 1 times RA_INTERVAL */
           context->ra_time = param->now + (3 * RA_INTERVAL)/4 + 
((RA_INTERVAL * (unsigned int)rand16()) >> 18);
	

Which says that for the first minute after an configuration change, we 
send RAs every 5- 20 seconds, the actual delay is random. Once the first 
minute is up, we wait 3/4 of RA_INTERVAL to RA_INTERVAL.


It seems to me that the simplest solution might be lock the "fast" RA 
mode, and never drop back to the full RA_INTERVAL delay. on a config 
flag as "Android workaround mode"


Another solution might be to derive the RA retransmit rate from the RA 
lifetimes, At the moment if you declare a RA prefix with a short 
lifetime, the lifetime gets extended to be as long as RA_INTERVAL, 
instead, we could reduce RA_INTERVAL to be the shortest configure 
lifetime (or actually half of that to allow for lost packets).

Cheers,

Simon.



> Uwe
>
> ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de eMail: uwe at thetaphi.de
>
>
>> -----Original Message----- From:
>> dnsmasq-discuss-bounces at lists.thekelleys.org.uk [mailto:dnsmasq-
>> discuss-bounces at lists.thekelleys.org.uk] On Behalf Of Uwe
>> Schindler Sent: Wednesday, July 24, 2013 8:17 PM To:
>> dnsmasq-discuss at lists.thekelleys.org.uk Subject: Re:
>> [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old
>> prefixes?
>>
>> 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).
>>
>> Uwe
>>
>>
>> _______________________________________________ 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