I just committed


which suppresses construction of a dhcp-range if there's an explict
dhcp-range already.

Testing would be very useful.



On 19/04/18 03:38, Luis Marsano wrote:
> Simon Kelley <si...@thekelleys.org.uk> wrote:
>> Apologies, there's no way to sue the solution I suggested in current
>> dnsmasq, it was a possible future enhancement.
>> On 17/04/18 00:16, Luis Marsano wrote:
>>> Yes, I’d expect that to work, though I’d only know after testing.
>>> Is there a way to do that?
>>> I was using the constructor option to handle dynamic prefixes, which
>>> also need to be advertised.
>>> The option
>>>> dhcp-range=set:lan,::,constructor:br-lan,ra-stateless,ra-names,12h
>>> advertises dynamic prefixes **and** static prefixes: whatever is bound
>>> to the interface, which seems an all or none proposition to me.
>>> If I could exclude the static prefix from the constructed
>>> advertisements, that would work.
>> How would you tell which prefixes were static, and which dynamic?
> I'd know from having to explicitly setup the static prefixes myself rather 
> than getting them automatically.
> IPv6 prefixes from the 6in4 tunnel broker are static: 6in4 is a static 
> mechanism and the tunnel broker gave me static addresses and prefixes to set 
> up.
> The other global IPv6 addresses and prefixes are potentially dynamic, and 
> automatically appear by enabling IPv6 on the WAN interface: DHCPv6-PD gets a 
> prefix from my ISP, and the openWRT/LEDE router automatically assigns a 
> subnet from that to its LAN interfaces.
> Though I could write out the current prefixes, I have no assurance they'll 
> remain the same later.
>>> If I could simply pass an additional option for the static prefix, that
>>> would also work.
>>> Is there a way to do either?
>>> I’m sorry if I missed it in the manual.
>> You didn't. I don't think there's any way to do what you want in the
>> current release of dnsmasq. We have to invent a new function to do it.
> With the approach you postulated, I might try something like
> dhcp-range=set:lan,::,constructor:br-lan,exclude:2001:db8::,ra-stateless,ra-names,12h
> dhcp-range=set:lan,2001:db8::,ra-stateless,ra-names,deprecated
> I was imagining an approach like
> dhcp-range=set:lan,::,constructor:br-lan,ra-stateless,ra-names,12h
> dhcp-range=set:lan,2001:db8::,ra-stateless,ra-names,deprecated
> that merges options and overrides according to some precedence like order or 
> specificity.
> I'm not sure about the best design for a new feature: according to 
> https://tools.ietf.org/html/rfc4861#section-6.2.3 router advertisements allow 
> each prefix to have its own options, so either design might suffice.
> I was also considering an alternative based on the tag system, though I'm not 
> sure it's meant for that.
> Your project is great: whatever solution you think is best is probably a good 
> one.
>> Cheers,
>> Simon.
> Thanks
>>> Thanks,
>>> Luis
>>> *From: *Simon Kelley <mailto:si...@thekelleys.org.uk>
>>> *Sent: *Monday, April 16, 2018 6:37 PM
>>> *To: *dnsmasq-discuss@lists.thekelleys.org.uk
>>> <mailto:dnsmasq-discuss@lists.thekelleys.org.uk>
>>> *Subject: *Re: [Dnsmasq-discuss] Router Advertisement: Prefix-Specific
>>> Options?
>>> Would this be solved by not constructing a prefix advertisement for
>>> 2001:db8:: when it's already explicitly configured?
>>> Cheers,
>>> Simon.
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Dnsmasq-discuss mailing list

Reply via email to