[Dnsmasq-discuss] Network booting with stateful IPv6 addressing

Derek Higgins derekh at redhat.com
Tue Feb 28 10:07:03 GMT 2017

On 27 February 2017 at 21:51, Simon Kelley <simon at thekelleys.org.uk> wrote:
> Hash: SHA256
> 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

> 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/418373a1cd97abc0c0e3557f7a00105
> 291829e6f/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c#L866
> [2] - https://github.com/qemu/ipxe/blob/c34d151/src/net/udp/dhcpv6.c#L97
> 2
>> [3] -
>> https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=blob;f=client/d
> 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
> Version: GnuPG v2.0.22 (GNU/Linux)
> QyHEop+9EZU2FPDBycp0bSBsPeM02Z5ZRfuVslqk/mPZke1WDFqp88Xo5m2wTi09
> SIPhk8P8ONAgYcxWy8SYUTPzYWFxTx6R7xyjZaM/gUbBYlzqvCf4KFNDrHsIw9eg
> M+5M/pSvLHdA2ELAl1OaGgdC8UWgRIRKoBriSkcl17FwmT7UeLzWVB64NOxYxxGl
> pxLjqZVOymfuY5XbjN6DMs431Z/sGIwsY8SBRWU8y1Sm++/Gb55JEYydu1+KXEyW
> gx9yrdMH43D6uHp8g+o0C+xTWtoddJx93CwOHLeSRughe24f13Z3xsKbUQRycZRa
> UJPKOHSmkO38e6tbGqAMDFtsmoXwXRBElYls32TcS1ai/YzSvkcapKYZh6oiX83Z
> fo4+Iklyb87Dft5gj9TsBdr4A1C7Hf9W+A8FR8XL6V05/KT5Z9OS7UTH5vqGM+l/
> 1bYQsHk7rnNwGrSUyI+QJDLfhjibwwlYs0IeTPhUqexSwRXDiRd0uLH1ZhmLHBRm
> 8T81sV4S7NErqp3daUdXJdK6GFSp7i8jDMHZujo9Wju9x7fGl2ROVW6oJqQX+lN2
> v05zFaXePJR+78gEKVEQP38QNDYnKct8dVHRvoSb+B6pjAWuTM2HgsF0y+x0phNv
> =oMah
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

More information about the Dnsmasq-discuss mailing list