I just committed
which suppresses construction of a dhcp-range if there's an explict
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
>>> 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
> 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
> I was imagining an approach like
> that merges options and overrides according to some precedence like order or
> 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
>>> *From: *Simon Kelley <mailto:si...@thekelleys.org.uk>
>>> *Sent: *Monday, April 16, 2018 6:37 PM
>>> *To: *firstname.lastname@example.org
>>> *Subject: *Re: [Dnsmasq-discuss] Router Advertisement: Prefix-Specific
>>> Would this be solved by not constructing a prefix advertisement for
>>> 2001:db8:: when it's already explicitly configured?
> Dnsmasq-discuss mailing list
Dnsmasq-discuss mailing list