[Dnsmasq-discuss] IPv6 constructor option - confused!
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.
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
More information about the Dnsmasq-discuss