[Dnsmasq-discuss] gatway

[Simon Kelley]

On 12/10/13 10:48, Vladislav Grishenko wrote:
> Hi, Simon,
>
> Thanks for the implementation, works well with one issue is still there
> RDNSS&  DNS Search List RA options contain lifetimes calculated from
> MaxRtrAdvInterval, where MaxRtrAdvInterval =<ra-interval>, and
> MinRtrAdvInterval = 3/4*<ra-interval>
> Since, there's no way to specify MinRtrAdvInterval&  MaxRtrAdvInterval (as I
> proposed before), RDNSS&  DNS Search List lifetimes always equal
> 2*<ra-interval>.
> So, if<ra-interval>  is small, like 10sec, that lifetimes are small too,
> just 20sec, without any connection to<router lifetime>. Hosts may refresh
> RDNSS info with RS packets and trigger solicited RA answers in addition to
> existing unsolicited RA packets.
> In the same time, with working DHCPv6 stateless/full lifetime is taken from
> dhcp-range, 600 sec as min.
>
> In radvd, MinRtrAdvInterval, MaxRtrAdvInterval, DefaultLifetime and other
> lifetimes can be set via conf file,
> In dnsmasq they are automatic, guess automatic needs to be tuned up.
> What do you think?

I think you're right that it needs tuning. The calculation for prefix 
valid times is a good model. That's based on the lifetime in the 
DHCP-range, but with a minimum of 3 * RA_interval as an imposed minimum.

The problem with that is that RDNSS and DNSSL are per interface, not 
per-prefix. Maybe the calculation should the maximum valid time of any 
prefix advertised on the interface?

Cheers,

Simon.


>
> Best Regards, Vladislav Grishenko
>
>> -----Original Message-----
>> From: Simon Kelley [mailto:simon at thekelleys.org.uk]
>> Sent: Friday, October 11, 2013 2:01 AM
>> To: Vladislav Grishenko
>> Cc: dnsmasq-discuss at lists.thekelleys.org.uk
>> Subject: Re: [Dnsmasq-discuss] gatway
>>
>> On 08/10/13 12:09, Vladislav Grishenko wrote:
>>>> From: Simon Kelley
>>>> Sent: Tuesday, October 08, 2013 4:20 PM On 06/10/13 11:32, Vladislav
>>>> Grishenko wrote:
>>>>> Hi, RFC4861 says:
>>>>>
>>>>>       A router might want to send Router Advertisements without
>>> advertising
>>>>>       itself as a default router.  For instance, a router might
> advertise
>>>>>       prefixes for stateless address autoconfiguration while not
>>>>> wishing
>>> to
>>>>>       forward packets.  Such a router sets the Router Lifetime field in
>>>>>       outgoing advertisements to zero.
>>>>>
>>>>>>> is it possible to tell dnsmasq not to announce itself as router?
>>>>> So , yes, it's theoretically possible.
>>>>
>>>> That's good information, thanks. In answer to the next question, no,
>>>> it's
>>> not
>>>> possible to configure dnsmasq to send Router Lifetime == 0.
>>>>
>>>> The lifetime, in dhcp-range is used to calculate the lifetimes for
>>> prefixes, no
>>>> the router lifetime. In fact the router lifetime is always advertised
>>>> as
>>> 1800
>>>> seconds, I think.
>>>>
>>>> Since this is a per-broadcast domain thing, and not per prefix thing,
>>>> it
>>> needs
>>>> to be associated with an interface.
>>>>
>>>> Simplest would be
>>>>
>>>> no-router-interface=<interface>[,<interface>,....]
>>>>
>>>> to set the interfaces that get router lifetime of zero.
>>>>
>>>> More complex would be to allow explict setting of the router lifetime
>>>> per interface, that would have to be linked to the RA frequency: you
>>>> wouldn't want a router expiring before it could be re-advertised.
>>>>
>>>
>>> No-router-interface is simplest, and adds more option to control RA.
>>> Currently we have already:
>>> --dhcp-range=...ra-only|slaac|ra-names...
>>> --enable-ra
>>> --force-fast-ra
>>>
>>> What if to logically split options to dhcp*-related and to
> slaac-related?
>>> --dhcp-range=
>>> Sets only DHCP range/RA prefix parameters (including
>>> lease/prefix/rdnss/domain lifetimes), but not RA timeouts
>>>
>>> --enable-ra=<interface>[,<interface>,...][,AdvDefaultLifetime][,MinRtr
>>> AdvInt
>>> erval,MaxRtrAdvInterval]
>>> Sets only RA timouts, if params absent - use defaults, 600 as max,
>>> 1/3*600 as min.
>>> With this, both min&   max can be configured, As per RFC,
>>> 	max should be in range 4-1800 secodns, default 600
>>> 	min should be in range 3-3/4*max, default 1/3*max, if max>=9,
>>> otherwise equal to max
>>>
>>> With this approach, --no-router-interface will be alias of
>>> --enable-ra=interface,0
>>> And --force-fast-ra will be an alias of
>>> --enable-ra=interface,1800,5,20
>>>
>>> Also, current code uses 600 as max, and 3/4*max as min ra intervals,
>>> what fits RFC, bit, guessб isn't optimal, too big min delay.
>>> As for startup advertisements and force-fast-ra, interval is 5-20, but
>>> can be limited to range
>>> MIN_DELAY_BETWEEN_RAS-MAX_INITIAL_RTR_ADVERT_INTERVAL, 3 and
>> 16
>>> respectively as RFC suggests Since RA can be very frequent, is it ever
>>> worth to log with LOG_INFO level every unsolicited RTR-ADVERT? It just
>>> floods syslog and has no other meaning in my opinion.
>>>
>>> Best Regards, Vladislav Grishenko
>>>
>>>
>>>
>>
>> OK, I just committed my take on this, which is --ra-param option, and
>> removed --force-fast-ra
>>
>>
>>    --ra-param=<interface>,[high|low],[[<ra-interval>],<router
>>          lifetime>]
>>                 Set non-default values for router advertisements  sent
>>                 via  an  interface.  The priority field for the router
>>                 may be altered from the  default  of  medium  with  eg
>>                 --ra-param=eth0,high.   The  interval  between  router
>>                 advertisements may be  set  (in  seconds)  with  --ra-
>>                 param=eth0,60.   The  lifetime  of  the  route  may be
>>                 changed or set to  zero,  which  allows  a  router  to
>>                 advertise  prefixes but not a route via itself.  --ra-
>>                 parm=eth0,0,0 (A value of zero for the interval  means
>>                 the default value.) All three parameters may be set at
>>                 once.  --ra-param=low,60,1200 The interface field  may
>>                 include a wildcard.
>>
>>
>>
>> I even added control of router priority as a bonus!
>>
>>
>> Cheers,
>>
>> Simon.
>
>