<div dir="ltr"><div dir="ltr" class="gmail_attr"><div>On Wed, Apr 19, 2023 at 12:55 PM Petr Menšík <<a href="mailto:pemensik@redhat.com">pemensik@redhat.com</a>> wrote:</div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Are you aware that 80 on the end of dhcp-range is lease time, not any <br>
prefix size? Consider using of constructor:tapvm4qyj3a instead of manual <br>
end address. If I see correctly the end address is the same as the start <br>
address. Not sure how this should behave, but I would not be surprised <br>
if it did not work.<br></blockquote><div><br></div><div><div>Hmm, my read of the manual page suggests it should be the prefix length? <br></div><div><br></div><div>       -F,            --dhcp-range=[tag:<tag>[,tag:<tag>],][set:<tag>,]<start-</div>       IPv6addr>[,<end-IPv6addr>|constructor:<interface>][,<mode>][,<prefix-<br><div>       len>][,<lease time>]</div><div><br></div></div><div>As far as I can tell, it worked as expected, though I was experimenting with a few things so I am not sure at this time.</div><div><br></div><div><div dir="ltr"><div>I thought about 
using the constructor feature, but I was trying to figure out if there 
was some way to get dnsmasq to respond to the DHCP query without 
occupying space in the /64 I'd like the VM to use (e.g. by listening and responding to DHCP via link local addresses. In such a case the address range would have to be 
telegraphed rather than read from the interface. As seen in my example, one address suffices for the one VM that is free to bind anything in the /80.<br></div></div></div></div></div>