[Dnsmasq-discuss] Clarification of prefix length field in dhcp-range

[Simon Kelley]

On 06/10/13 09:28, Kevin Darbyshire-Bryant wrote:
> On 05/10/2013 22:43, Quintus wrote:
>> Am Sat, 5 Oct 2013 14:21:26 +0100
>> schrieb Kevin Darbyshire-Bryant<kevin at darbyshire-bryant.me.uk>:
>>
>>> Hi All,
>> Hi Kevin,
>>
>>> dnsmasq2.67rc3 - possibly odd behaviour, probably I misunderstand :-)
>>>
>>> I have an interface that has a /64 on it.  dnsmasq.conf has amongst
>>> other things
>>> "
>>> dhcp-range=::100, ::F:FFFF:FFFF, constructor:br0, ra-names, 64, 12h
>>> enable-ra
>>> "
>> ra-names is useless in a DHCPv6 context as it tells clients to use
>> SLAAC (IPv6 stateless autoconfiguration) and *not* DHCPv6. You probably
>> want to remove it (enable-ra does the router advertisements for you).
>
> Not all clients support DHCPv6 and do SLAAC instead, so in that case AND
> assuming they're dual stack and use DHCPv4 to obtain an IPv4 address,
> I'd quite like dnsmasq to see if they're using a non-privacy obscured
> SLAAC IPv6 address and make a note of it in DNS if they are. So I'll
> keep my 'ra-names' if that's ok with you :-)
>
>>
>>> Now, if I change said interface to be a /48 (restarting dnsmasq), the
>>> logfile says it's built a constructed range as before, but it no
>>> longer does RA and in fact DHCPv6 requests get rebuffed with a 'no
>>> valid range'.  Shouldn't the ', 64' force this to behave as a /64 for
>>> the constructed range?  And shouldn't it do RA?
>> If you want dnsmasq to serve IPs from a /48 net, your *interface* needs
>> to have a /48 address assigned. You can’t have your network interface
>> have a /64 address and have dnsmasq delivering addresses with a
>> different prefix.
> I've not been clear. Provider has given me a /48 prefix. If I
> artificially subnet that /48 to a /64 on the interface, and the 'subnet'
> uses all zeros, then 1111:2222:3333:0000::/64 is functionally equivalent
> to 1111:2222:3333::/48 that the ISP gave me, from their perspective at
> least. Dnsmasq works fine when the interface is set to /64. Where it
> doesn't work fine is if I keep the /48 prefix length on the interface.
> The man page implies I can tell dnsmasq to use a different prefix length
> for the leases, and in fact the logfile entries suggest dnsmasq is happy
> with the syntax, has found a suitable prefix, says it's going to do
> RA's, says it's going to do DHCPv6 but actually does none of those things.
>
> So to clarify, I don't want to advertise a /48 from a /64, rather I want
> to advertise a /64 from a /48 (ie in IPv4 terms a subnet)
>
>
> With a /64 assigned to the interface (so logically 2001:470:6b99:0000::)
> Works
> Oct 4 19:41:26 Router daemon.info dnsmasq-dhcp[4518]: DHCPv6, IP range
> 2001:470:6b99::100 -- 2001:470:6b99::f:ffff:ffff, lease time
> 12h,constructed for br0
> Oct 4 19:41:26 Router daemon.info dnsmasq-dhcp[4518]: DHCPv4-derived
> IPv6 names on 2001:470:6b99::, constructed for br0
> Oct 4 19:41:26 Router daemon.info dnsmasq-dhcp[4518]: router
> advertisement on 2001:470:6b99::, constructed for br0
>
> With a /48 assigned to the interface: Doesn't work (2000:470:6b99::)
> Oct 6 09:18:12 Router daemon.info dnsmasq-dhcp[25953]: DHCPv6, IP range
> 2001:470:6b99::100 -- 2001:470:6b99::f:ffff:ffff, lease time 12h,
> constructed for br0
> Oct 6 09:18:12 Router daemon.info dnsmasq-dhcp[25953]: DHCPv4-derived
> IPv6 names on 2001:470:6b99::, constructed for br0
> Oct 6 09:18:12 Router daemon.info dnsmasq-dhcp[25953]: router
> advertisement on 2001:470:6b99::, constructed for br0
>
> Spot the difference 'cos I can't :-) Hopefully that's explained it better.
>

This is definitely a bug.

Historically, the prefix-length in the dhcp-range has had to match the 
prefix length configured into the interface. This was carried over from 
DHCPv4. If, as an experiment, you stop using constructed ranges and just 
configure the whole address in the dhcp-range, you'll find the same 
effect. If the  prefix length in the range is 64 (it can't be 
smaller....) and the prefix length in the interface is 48 then things 
will break in the same way: no DHCPv6 and no RA.

To add insult to injury, the code which "contructs" DHCP ranges doesn't 
check the prefix length. It will happy construct a DHCP range based on 
an address configured into an interface, even if the prefix-length of 
that address is smaller. The constructed dhcp-range has its prefix 
length copied from the template, so it's useless for actually doing 
DHCPv6 or RA.

To make things consistent, the constructor code should not contruct 
dhcp-ranges unless the prefix lengths match.

It's also at least arguable that the RA and DHCP code should not insist 
on the prefix lengths being the same: as you say, a prefix-length on the 
interface less-then or equal to the one in the dhcp-range would make 
some sense. One has to be careful though: which of the two prefix ranges 
should actually be advertised in the Router Advertisements?


Cheers,

Simon.