On 18/04/2023 09:40, Daniel Farina wrote:
Hello everyone,
I have been trying to set up an IPv6-only network for a virtual machine
with route advertisements and DHCP configuration. I've had some success,
but I have a question.
I have a dnsmasq.conf that looks like this, to delegate a /80 chunk of a
/64 network to a virtual machine:
interface=tapvm4qyj3a
enable-ra
dhcp-authoritative
leasefile-ro
ra-param=tapvm4qyj3a,mtu:1280,high,60,1200
dhcp-range=2a01:4f9:2b:35a:7df2::2,2a01:4f9:2b:35a:7df2::2,80
If I have an address configuration like this on the host outside the
virtual machine, it works well:
3: tapvm4qyj3a: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
fq_codel state UP group default qlen 1000
link/ether 82:d6:93:69:72:82 brd ff:ff:ff:ff:ff:ff
inet6 2a01:4f9:2b:35a:7df2::1/80 scope global
valid_lft forever preferred_lft forever
inet6 fe80::80d6:93ff:fe69:7282/64 scope link
valid_lft forever preferred_lft forever
The thing I find dissatisfying about this is that the VM is not able to
listen on 2a01:4f9:2b:35a:7df2::1 anymore once I've done this, is my
understanding: the host will process the traffic, right? If I remove the
address on the guest's network, dnsmasq warns me repeatedly, and does
not work:
ip addr del 2a01:4f9:2b:35a:7df2::1/80 dev tapvm4qyj3a
dnsmasq-dhcp: no address range available for DHCPv6 request via tapvm4qyj3a
dnsmasq-dhcp: no address range available for DHCPv6 request via tapvm4qyj3a
dnsmasq-dhcp: no address range available for DHCPv6 request via tapvm4qyj3a
...
My question is partially that of norms: is it normal to squat on a bit
of the guest's address space like this? Is there a preferred way that
avoids this, or does something different still? I know that a number of
non-SLAAC configurations tend to sit on ::2 as the first unicast
address, is this related to the reason why?
I will be expanding my use of dnsmasq to DNS, so this may figure in the
answer.
Interesting question.
The short answer is no. Dnsmasq relies on matching the addresses in a
dhcp-range with the address on an interface to map from an arrival
interface to a suitable address range. This design started when the DHCP
support only handled IPv4, and DHCPv4 requires that the server has a
globally routable address, so there was no conflict. The same system was
adopted for IPv6 for consistency.
DHCPv6 uses link-local multicast, so I think you're right, a DHCPv6
server can issue leases for addresses on a subnet without having an
address on that subnet. Dnsmasq can't do it because it has no way to
associate the subnet with the address on which the request arrived,
because of the configuration design inherited from the DHCPv4 server.
I'm not sure there's much incentive to change this: it's not as if
addresses are scarce in the IPv6 world.
Cheers,
Simon.
Thank you for considering my question.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
