[Dnsmasq-discuss] Network booting with stateful IPv6 addressing

Simon Kelley simon at thekelleys.org.uk
Tue Feb 28 18:24:45 GMT 2017

Hash: SHA256

On 28/02/17 17:10, Derek Higgins wrote:
> On 28 February 2017 at 16:43, Simon Kelley
> <simon at thekelleys.org.uk> wrote: Could you post (or send to me) you
> complete dnsmasq configuration. I'd
>> Here you go http://paste.openstack.org/show/600808/
> expect, if the IP address associated with the MAC address is in
> use, for dnsmasq to log that and use a dynamically allocated
> address instead.
>> Looking at it now, the addition of the static keyword in
>> dhcp-range would be preventing this happening

Indeed. That explains that effect.
> Why not nail the IP address using the client-id of the final OS 
> booted, rather thna using MAC addresses?
>> I've been trying to get this to work within the constraints of
>> how openstack neutron starts dnsmasq, when neutron starts a new
>> instance it doesn't know (if I understand things correctly) what
>> the client-id will be, so MAC would be the only way it can
>> associate a particular VM to a IP address.

Sigh. This has always been a problem, and it's got worse, not better,
in the move to IPv6.

For DHCPv4, where MAC addresses are pretty much compulsory, there's a
hack where client is allowed to either present or not a client-id, as
long as the MAC address is identical. (It's not allowed to present two
different client-ids, however.)

For DHCPv6, it's difficult to rely on the MAC address, since it's only
made available at all by using nasty ARP-snooping hacks. Plus the MAC
address to client-id function is less well defined. Then we have the
problem that provisioning systems know about MAC addresses, but not

The only possible solution I can come up with is to add filtering of
dhcp-host lines by tag. You could thereby arrange that the dhcp-host
line only applied to the final OS boot, and the earlier steps could be
left to get dynamically allocated addresses. That would require a
way to set a tag on the final (OS) dhcp request, but that's almost
certainly possible; you're halfway there with the ipxe6 tag.



> Cheers,
> Simon.
> On 28/02/17 10:07, Derek Higgins wrote:
>>>> On 27 February 2017 at 21:51, Simon Kelley 
>>>> <simon at thekelleys.org.uk> wrote: I'm slightly confused as to
>>>> the problem here. The identity of a lease if defined by the
>>>> Client-ID and IAID, if those change then dnsmasq will
>>>> allocate a new address. That means that your boot process
>>>> will go through three different addresses, but should end up
>>>> with a usable and stable address. It's not as if there is a
>>>> shortage of IPv6 addresses, you can afford a couple of
>>>> disposable addresses that only get used during the boot.
>>>> What have I missed?
>>>>> IPs are being allocated to the MAC addresses in question
>>>>> via a hostfile (see below), so I guess dnsmasq is
>>>>> attempting to allocate the same IP address mutiple times,
>>>>> as its the same MAC but can't because of the changing IDs.
>>>>> This is dnsmasq as configured be openstack newtron
>>>>> bash-4.2$ cat 
>>>>> /var/lib/neutron/dhcp/5cf3b57b-72a3-4044-9528-1f5019e21826/host
>>>>> fa:16:3e:d8:9e:dd,host-fc00-101--3,[fc00:101::3] 
>>>>> fa:16:3e:d2:03:61,host-fc00-101--8,[fc00:101::8],set:ccbc492d-7b5d
- -4f
> fa:16:3e:69:89:d5,host-fc00-101--b,[fc00:101::b],set:ea1e2384-7ed7-495
>>>> Cheers,
>>>> Simon.
>>>> On 27/02/17 16:04, Derek Higgins wrote:
>>>>>>> I've recently been trying to use dnsmasq IPv6 to
>>>>>>> network boot, after a number of hurdles the last
>>>>>>> problem I've been having is that during the boot
>>>>>>> process (after dnsmasq initially hands out an IP
>>>>>>> address as part of PXE boot), it starts responding with
>>>>>>> "no addresses available".
>>>>>>> The problem I'm hitting is that the IAID and the
>>>>>>> ClientID in the dhcp request changes during the
>>>>>>> process, - the IAID being used in PXE generated by the
>>>>>>> OVMF UEFI firmware is a function including a time based
>>>>>>> seed[1] - this chain loads(in my case) to an iPXE image
>>>>>>> that is using a crc of the mac address to generate the
>>>>>>> IAID[2], - dhclient on the OS then uses the last 4
>>>>>>> octets of the MAC address for the IAID[3]
>>>>>>> I have similar problems with ClientID but I havn't
>>>>>>> looked into them in as much detail
>>>>>>> check_address in dnsmasq/src/rfc3315.c is asserting
>>>>>>> that the ID's can't change, and the only way I've
>>>>>>> gotten the boot process to work locally is to comment
>>>>>>> out the checks in check_address
>>>>>>> As best I can see RFC 3315 does say that the IAID MUST 
>>>>>>> remain consistent across restarts of the DHCP client,
>>>>>>> but then recognizes that "There may be no way for a
>>>>>>> client to maintain consistency of the IAIDs if it does
>>>>>>> not have non-volatile storage and the client's hardware
>>>>>>> configuration changes"
>>>>>>> Is there a way to allow these IDs to change? and if
>>>>>>> not should this check be in dnsmasq? or would a patch
>>>>>>> to optionally disable the check be acceptable?
>>>>>>> thanks, Derek.
>>>>>>> [1] - 
>>>>>>> https://github.com/tianocore/edk2/blob/418373a1cd97abc0c0e3557f7
> 291829e6f/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c#L866
>>>> [2] - 
>>>> https://github.com/qemu/ipxe/blob/c34d151/src/net/udp/dhcpv6.c#L97
>>>>>>> [3] - 
>>>>>>> https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=blob;f=cl
> hc6.c;h=be604ac988a983b2829f76fe2bff6a5f036d8019;hb=HEAD#l1716
>>>>>>> _______________________________________________ 
>>>>>>> Dnsmasq-discuss mailing list 
>>>>>>> Dnsmasq-discuss at lists.thekelleys.org.uk 
>>>>>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>>> Dnsmasq-discuss mailing list 
>>>>> Dnsmasq-discuss at lists.thekelleys.org.uk 
>>>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Version: GnuPG v2.0.22 (GNU/Linux)


More information about the Dnsmasq-discuss mailing list