man 8 dnsmasq: ---- -F, --dhcp-range=[tag:<tag>[,tag:<tag>],][set:<tag>,]<start-IPv6addr>[,<end-IPv6addr>|constructor:<interface>][,<mode>][,<prefix-len>][,<lease time>] ... For IPv6, the parameters are slightly different: instead of netmask and broadcast address, there is an optional prefix length which must be equal to *or larger th[a]n* the prefix length on the local interface. If not given, this defaults to 64. Unlike the IPv4 case, the prefix length is not automatically derived from the interface configuration. The minimum size of the prefix length is 64.
IPv6 (only) supports another type of range. In this, the start address and optional end address contain only the network part (ie ::1) and they are followed by constructor:<interface>. ... ---- But, instead: ---- $ dnsmasq --test dnsmasq: prefix length must be exactly 64 for subnet constructors at line 266 of /etc/dnsmasq.conf ---- Alternatively, just leaving this <prefix-len> null gives: ---- $ dnsmasq --test dnsmasq: prefix length must be at least 64 at line 266 of /etc/dnsmasq.conf ---- And then, even changing the prefix length on the actual interface, and only then, setting the dnsmasq constructor interface prefix length configuration to match, there is the same error reported: ---- prefix length must be exactly 64 for subnet constructors at line 266 of /etc/dnsmasq.conf ---- Even worse, with the dnsmasq constructor interface prefix length configuration set to "64", but with the actual interface prefix length set to, for instance, "112", DHCPv6 *will not work*, with every request leaving a warning in the log file: ---- no address range available for DHCPv6 request via enp4s0 ---- Is this behavior, when using the "constructor" mechanism, a bug? The documentation seems to suggest that the "constructor" mechanism *should* work with any prefix length, and not just "exactly 64". But then also, manually configuring the DHCPv6 range addresses manually does seem to work just fine. I missed that, the first time around. And, dnsmasq does not determine the DHCPv6 prefix length from the *actual* interface prefix length, which would be the behavior that seems to make the most sense. This automatic "constructor" failure, instead using manual configuration, *after* an ISP Prefix Delegation, is an unfortunate inconvenience, for elaborate reasons, derived from the definitions of "link", "router", and "interface", and their implications, in RFC 4861, and the consequent function of layer 3 IP "forwarding" between multiple interfaces in the linux kernel. IP forwarding between interfaces, by default, only works between *distinct* subnets. In practice, with a /64 prefix delegation, for instance, it is very *unlikely* that all 2^64 nodes in the /64 subnet will be attached to the same, single, layer 2 "link" - of course! But then, there will be no router forwarding of packets between distinct subnets, unless these subnets have prefix lengths *longer* than /64. And, neither will there be successful link-layer Neighbor Discovery, since actually distinct subnets are not truly "onlink", unless they are subsequently bridged. To complicate things, for instance, when running the WIDE dhcp6c client to request a Prefix Delegation, dhcp6c will automatically configure a combined IPv6 prefix and interface address to a designated interface, along with - specifically - the effective prefix length that was requested and delegated. But then, that effective Prefix Delegation prefix length - something between "64" and "48" - is *not* what should be applied to any practical local subnet. The local subnets are going to have to be smaller - much smaller - in size, with longer prefix lengths "on site", than implied by the ISP delegated prefix length. And so, the interface address, applied automatically by the dhcp6c client, must be modified to have a longer prefix. Practically, with the dhcp6c client, the automatic dhcp6c address can be applied to a "dummy" interface, and then however many derived addresses would then be applied to the actual on site subnet interfaces, by another process. For now, dnsmasq DHCPv6 just cannot do the job *automatically*, using the "constructor" mechanism. But it would be nice, if it could. Could we make that a "feature request"? _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
