Comment 3 for bug 1257446

I worked around this (i.e. stopped the exception from happening) by simply recreating the IPv6 subnet with DHCP disabled.

However, IPv4 DHCP continued to fail for new instances while the IPv6 subnet was present. When I turned on dnsmasq logging I saw this for the relevant MAC address:
Jan 7 14:30:39 dnsmasq-dhcp[9339]: 3868772679 DHCPDISCOVER(tapae8bbcd2-d7) fa:16:3e:f8:d7:98 no address available

It occurred to me that perhaps this is because there are two lines starting with fa:16:3e:f8:d7:98 written to the relevant dhcp host file - one for IPv4 and one for IPv6. Perhaps dnsmasq couldn't work out how to choose between them? If I hacked the code in dhcp.py to not write IPv6 addresses to the host file, it allowed DHCP to start working for IPv4.

I'm using dnsmasq 2.48, so I'd be interested to know whether this happens to people at a supported version, when they disable DHCP on IPv6 (I can't upgrade right now, though maybe soon).

Let me know if you'd like this new issue spawned into a new bug.