[Dnsmasq-discuss] Network booting with stateful IPv6 addressing

Derek Higgins derekh at redhat.com
Wed Mar 1 15:27:05 GMT 2017


On 28 February 2017 at 18:24, Simon Kelley <simon at thekelleys.org.uk> wrote:
> -----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.

I'll take a look into getting this to work in the env I'm using.

I'd imagine this is a common enough case, is there a argument here to
add a dnsmasq flag to allow the IDs to change? If so I'd be happy to
work on a patch.


>
> 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-----



More information about the Dnsmasq-discuss mailing list