[Dnsmasq-discuss] IPv6 constructor option - confused!

Simon Kelley simon at thekelleys.org.uk
Mon May 13 17:51:20 BST 2013

On 02/05/13 17:54, Kevin Darbyshire-Bryant wrote:
> On 02/05/2013 17:00, Simon Kelley wrote:
>> It is how I expected it to work, exactly.
>> DHCP-PD client gets prefix, and assigns<prefix>::1 to LAN interface.
>> dnsmasq gives addresses between
>> <prefix>::2 and<prefix>::<whateveryouwant>
>> to clients on the LAN.
> Which (contrived case) isn't ideal if for some reason the DHCP-PD client
> assigns prefix:FFFF:FFFF:FFFF:FFFF to the lan interface,
> 'cos the constructor has nowhere to go.  The constructor will go up from
> the lowest address, it doesn't appear to work down,
> though it does sort the addresses in syslog from lowest to highest.  But
> this is VERY contrived :-)

Nevertheless, it makes a point. There's nothing to stop dnsmasq using 
the constructor  is an address appears with either the start or end 
addresses, instead of just the start address, as at the moment. That 
would address the case where the local address is <prefix>:<highest 
usable address plus one>

>>> So is this an oversight or some tomato based wierdness...either way, how
>>> can I help to sort it out?
>> Suggest an alternative, given that constructing a DHCP range based on
>> any address in a prefix is not desirable.
> Hmmmm, what about seeing if the interface in question has an address
> inside the DHCP constructed range and if it does then use the prefix?
> Or is that excluded by your above statement?
> Perhaps if I explain what I'm trying to do it may help.  I'm trying to
> remove the requirement for RADVD in the tomato router
> environment.  There are a number of potential benefits, not least having
> an equivalent local DNS service to the IPv4 dhcp/dns service (privacy
> extensions not helping but)  My thought was that the 'constructor'
> option was ideal, in that I could assign a constructor range of ::0
> -::FFFF:FFFF:FFFF:FFFF and it would pick up the prefix and start serving
> addresses through RA&  DHCPv6.  Unfortunately it looks like what I would
> like isn't quite what 'constructor' actually gives me.

This goes back to the reason for insisting a particular address appears 
on the interface, which is that the interface can easily pick up a SLAAC 
address from its OWN router advertisements.

So PD arrives for <Prefix>, local interface gets addresss <prefix>::1, 
dnsmasq notices and contructs the range <prefix>::1 to 
<prefix>::ffff:ffff:ffff:fff and starts to advertise prefix. The 
advertisements are noted in the kernel, which adds 
<prefix>:211:25ff:fea1:91c5 SLAAC address as well as <prefix>::1. Later 
the lease on <prefix> expires, and the DHCP client removes <prefix>::1 
Without the rule that <prefix>::<first address in range> must exist, the 
SLAAC address is enough to keep the constructed range in being, and the 
prefix never, ever, dies.

Changing the rule to "any address in the range" doesn't help, since that 
includes the all the potential SLAAC addresses.

I'm still not clear exactly what address you DHCPv6 client is 
constructing for local use from a delegated prefix, and why it can't be 
aligned with what dnsmasq is configured to expect.


> Kevin
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

More information about the Dnsmasq-discuss mailing list