[Dnsmasq-discuss] Network booting with stateful IPv6 addressing

Tue Feb 28 18:24:45 GMT 2017

-----BEGIN PGP SIGNED MESSAGE-----
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
client-ids.

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.

> 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:59:ef:60,host-fc00-101--2,[fc00:101::2]
>>>>> 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
>
>>>>> 
9a-891c-92d66828f6dd
>>>>> 
>>>>> 
> fa:16:3e:69:89:d5,host-fc00-101--b,[fc00:101::b],set:ea1e2384-7ed7-495
6-
>
> 
bae0-d653c86c840c
>>>> 
>>>> 
>>>> 
>>>> 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
a00
>
>>>>>>> 
105
>>>> 
>>>>>>> 
> 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=cl
ien
>
>>>>>>> 
t/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
>>>>>>>
>>>>>
>>>>>
>>>>>>>
>
>>>>>>> 
_______________________________________________
>>>>> Dnsmasq-discuss mailing list 
>>>>> Dnsmasq-discuss at lists.thekelleys.org.uk 
>>>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYtcBtAAoJEBXN2mrhkTWi/VcQAJ8u8qoC/XSnYKbZb9LeZStu
BUVGlsw4zwj53Gr/UaV7o5HOh9V4sV7qmp5/sehg9U+gYJ6Fr51ylRCLroBTVlVF
WUssiZhBum4dWCuGUo8nAMkghplkl2y75mS6rkjHW3iH14SAP6997iCYtrdvnog3
ZKFRN3BqIwnUXPzqWLvlodGpuSmCiIag+F4dWC0X0aoqFYbi1oF9VhrfvK34JFk3
Mfsgeq+LPY6I1AmgmuY6o5plrqN+tPa1DO/sVRQHrAjLrYd2LTAN6wOpQhZBG6GP
LRfvy7q4D7Pf2R9Y82DN92nZc0IhwlEAoNXSytvwhMb5Pm1FX0t32sb9F+9jr6rY
s3crAfqzpv1KA0tRO+Bb6M1kdC6MZqdgqzXKhzCKmsmjDicPqsmgSP3v+HNO6tdO
mRwQxKrDk+lGpzECFZljluW4ZchDKZnru7GNTpu/ZgvcSbO4dEPZTrMgs0tCtIgS
nGExGLBpSEm1M5vWCOYFq5uOjdK4zj1WHVtIqgVPVZU0twDyXrThXDz0H9E+vpBO
BEB6rNrQxjHfOlqpBPn9F5KL2VYXlNggX2HSQvRsJMQlClt9iTsD7j3KXAhyz6KE
ucgvmJJzzu6Cc6tX2dStNxToDn/6+cBwdJfnku8nQPOlJqnmmtgUUDKdJLR/BT1x
wYqWSvAlqb/qsf63hRuK
=rB5p
-----END PGP SIGNATURE-----