[Dnsmasq-discuss] Network booting with stateful IPv6 addressing

Mon Mar 6 22:42:06 GMT 2017

On 01/03/17 15:27, Derek Higgins wrote:
> On 28 February 2017 at 18:24, Simon Kelley <simon at thekelleys.org.uk> wrote:
> 
> 
> 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.
> 
> 

Allowing the IDs to change is a bad idea, since in DHCPv6 they are the
only thing that identifies a client. If you lease an address to a
CLID/IAID combo, then you can't lease it to another CLID/IAID until that
lease has expired. The same applies to DHCPv4, but in some cases,
because MAC addresses are much more strongly associated with clients in
DHCPv4 land, you can get away with it, as I explained.

The solution I'm proposing is to allow dhcp-host to be conditional on a
tag that can be set only when the final OS boots, so that the
intermediate boot stages can dynamically allocated addresses and the
leases for those just expire. The trick is to find a way of
distinguishing the PXE/bootloader DHCP requests from the OS ones, using
dhcp-match and/or tag-if to do the inspection and logic. As you have the
test harness there, that would be a useful thing to look at. The patch
to dnsmasq to allow dhcp-host to be conditional on a tag is trivial.

Cheers,

Simon.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20170306/9ae95652/attachment.sig>