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

[Kevin Darbyshire-Bryant]

On 08/10/2013 11:42, Simon Kelley wrote:
>
> This is definitely a bug.
Sorry Simon!
>
> 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.
I tried exactly that and found exactly the same behaviour but then got
diverted into my paid work before I could update you.
>
> 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?
>
Well speaking from a purely selfish point of view, and wanting to do the
least amount of work in terms of integration with 'Tomato', I'd like it
to construct, RA & DHCPv6 the /64 and ignore the fact that the interface
is configured with a /48.  ie. take note of the ',64' parameter in the
dhcp-range.

You have a much, much better idea of how this IPv6 stuff is supposed to
work than me so my idea is probably pants!

Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3768 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20131008/359a65ff/attachment.bin>