Discussion:
[Dnsmasq-discuss] Network booting with stateful IPv6 addressing
Derek Higgins
2017-02-27 16:04:14 UTC
Permalink
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/418373a1cd97abc0c0e3557f7a00105291829e6f/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c#L866
[2] - https://github.com/qemu/ipxe/blob/c34d151/src/net/udp/dhcpv6.c#L972
[3] - https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=blob;f=client/dhc6.c;h=be604ac988a983b2829f76fe2bff6a5f036d8019;hb=HEAD#l1716
Simon Kelley
2017-02-27 21:51:02 UTC
Permalink
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?


Cheers,

Simon.
Post by Derek Higgins
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
Post by Derek Higgins
[3] -
https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=blob;f=client/d
hc6.c;h=be604ac988a983b2829f76fe2bff6a5f036d8019;hb=HEAD#l1716
Post by Derek Higgins
_______________________________________________ Dnsmasq-discuss
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Derek Higgins
2017-02-28 10:07:03 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
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
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-4f9a-891c-92d66828f6dd
fa:16:3e:69:89:d5,host-fc00-101--b,[fc00:101::b],set:ea1e2384-7ed7-4956-bae0-d653c86c840c
Cheers,
Simon.
Post by Derek Higgins
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
Post by Derek Higgins
[3] -
https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=blob;f=client/d
hc6.c;h=be604ac988a983b2829f76fe2bff6a5f036d8019;hb=HEAD#l1716
Post by Derek Higgins
_______________________________________________ Dnsmasq-discuss
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCAAGBQJYtJ9GAAoJEBXN2mrhkTWiXAwP/RZ+BE+gchcHXwz/wsGmz2gV
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
JQQXY6kIaOIsjEDROC7q
=oMah
-----END PGP SIGNATURE-----
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Simon Kelley
2017-02-28 16:43:03 UTC
Permalink
Could you post (or send to me) you complete dnsmasq configuration. I'd
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.

Why not nail the IP address using the client-id of the final OS
booted, rather thna using MAC addresses?


Cheers,

Simon.
On 27 February 2017 at 21:51, Simon Kelley
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?
Post by Derek Higgins
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-4956-
bae0-d653c86c840c
Cheers,
Simon.
Post by Derek Higgins
Post by Derek Higgins
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/418373a1cd97abc0c0e3557f7a00
105
291829e6f/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c#L866
[2] -
https://github.com/qemu/ipxe/blob/c34d151/src/net/udp/dhcpv6.c#L97
2
Post by Derek Higgins
Post by Derek Higgins
[3] -
https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=blob;f=clien
t/d
hc6.c;h=be604ac988a983b2829f76fe2bff6a5f036d8019;hb=HEAD#l1716
Post by Derek Higgins
Post by Derek Higgins
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Post by Derek Higgins
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Derek Higgins
2017-02-28 17:10:20 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
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.
Cheers,
Simon.
On 27 February 2017 at 21:51, Simon Kelley
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?
Post by Derek Higgins
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-4956-
bae0-d653c86c840c
Cheers,
Simon.
Post by Derek Higgins
Post by Derek Higgins
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/418373a1cd97abc0c0e3557f7a00
105
291829e6f/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c#L866
[2] -
https://github.com/qemu/ipxe/blob/c34d151/src/net/udp/dhcpv6.c#L97
2
Post by Derek Higgins
Post by Derek Higgins
[3] -
https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=blob;f=clien
t/d
hc6.c;h=be604ac988a983b2829f76fe2bff6a5f036d8019;hb=HEAD#l1716
Post by Derek Higgins
Post by Derek Higgins
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Post by Derek Higgins
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCAAGBQJYtaiXAAoJEBXN2mrhkTWiYIUP/RUa5YJQN44BI7BkwsGnwsYi
SdeE27igfC9MVjGUcN2MgIfpqkucNX8QkG69axsaaeA6vK9ARDr+qo8myUFymfH3
XBdwFOfxCBWWUvyocyrGgQi+JLeMwNcNal4TRLMGp2s7xXrqpy7FPhpLYgVfGnC0
5326U+lVBHqQ8z4JP/Hyl9COvWmhNTTzG6XmZTumoY7dcXqMGgDwezWp3qyQ8oSV
F6FrjbN56v7Hf6QphyYmHupjN8HTnjIAl0jWrxDtYvh1YUejlZnYN1c5kpfuSzsB
XCfSTJVwgK/ld12ysSwYAjyPtrQySjxJBvXlysVTC06NQret8wK/esz9l2UCmA3X
5STa8eQ5biSyVtFcmbl+uLUP4taztc6NihFQY3DTVUq37ZoNqHK47nmOY2ZsU0wm
Xs46Gvh9bNjSVpT41lTCLg0TnLqHcqZ9cENE3cTflkIC2TumRLTqEelRT/TptxRo
iKH97kjblK/x+DGiWor9Yyu4fl28xpJoZDGuNe2oPN9ewF5+blitpRu3Q135tbf1
b4vseR3hDvwxN2SEyeeZn5xk2bFjZ8GNlNrpLQF2rt5gu2l0F3bzU6zX/EcGc2OG
Y9pzs0IYk27E22nkl1SgNU1GB6jUOtDxUz8Y7celEjm9jM1JoDNlumz+tJ1ZVF0y
zGdG+wRErpJjIk70yUvA
=o5bq
-----END PGP SIGNATURE-----
Simon Kelley
2017-02-28 18:24:45 UTC
Permalink
This post might be inappropriate. Click to display it.
Derek Higgins
2017-03-01 15:27:05 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 28 February 2017 at 16:43, Simon Kelley
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 27 February 2017 at 21:51, Simon Kelley
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?
Post by Derek Higgins
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]
Post by Derek Higgins
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.
Post by Derek Higgins
Post by Derek Higgins
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
Post by Derek Higgins
Post by Derek Higgins
[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
Post by Derek Higgins
Post by Derek Higgins
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Post by Derek Higgins
Dnsmasq-discuss mailing list
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-----
Simon Kelley
2017-03-06 22:42:06 UTC
Permalink
Post by Simon Kelley
Post by Derek Higgins
On 28 February 2017 at 16:43, Simon Kelley
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.
Post by Derek Higgins
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.
Post by Derek Higgins
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.
Post by Simon Kelley
Cheers,
Simon.
Post by Derek Higgins
Cheers,
Simon.
On 27 February 2017 at 21:51, Simon Kelley
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?
Post by Derek Higgins
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]
Post by Derek Higgins
Post by Derek Higgins
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
Post by Derek Higgins
fa:16:3e:69:89:d5,host-fc00-101--b,[fc00:101::b],set:ea1e2384-7ed7-495
6-
bae0-d653c86c840c
Post by Derek Higgins
Cheers,
Simon.
Post by Derek Higgins
Post by Derek Higgins
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
Post by Derek Higgins
291829e6f/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c#L866
[2] -
https://github.com/qemu/ipxe/blob/c34d151/src/net/udp/dhcpv6.c#L97
2
Post by Derek Higgins
Post by Derek Higgins
Post by Derek Higgins
[3] -
https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=blob;f=cl
ien
t/d
Post by Derek Higgins
hc6.c;h=be604ac988a983b2829f76fe2bff6a5f036d8019;hb=HEAD#l1716
Post by Derek Higgins
Post by Derek Higgins
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Post by Derek Higgins
Post by Derek Higgins
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Loading...