Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
Dear Harald, Am 27.01.20 um 10:05 schrieb Harald Jensås: > On Sun, 2020-01-26 at 20:01 +0100, Oliver Freyermuth wrote: >> I also like this new approach. "Wasting" 4 addresses for one host >> seems to be the only way >> to solve this while conforming to RFCs. >> >> However, there's one issue I can't find a good solution for in this >> scheme - >> how to solve the "DNS problem" if dnsmasq is only used for DHCP, but >> DNS is provided by other means? >> >> The "range reservation", as highlighted, means the final address is >> not well predictable (may depend on hardware, >> other parts of the boot process etc.). >> When dnsmasq is also doing the DNS part, that's not a problem, since >> it will use the final / "most recently leased" address for DNS. >> Does anybody have a good proposal for the case when DHCP is provided >> by dnsmasq but DNS is maintained separately >> (i.e. the "final address" needs to be fixed)? >> >> Cheers, >> Oliver > > I think adding tag support for dhcp-host entries as follow up. > > The idea would be to have a config like this: > > # OPTION_CLIENT_ARCH_TYPE (61) > dhcp-match=set:efi6,option6:61,0007 > dhcp-match=set:efi6,option6:61,0009 > dhcp-match=set:efi6,option6:61,0011 > # User class is iPXE > dhcp-userclass=set:ipxe6,iPXE > > dhcp-host=tag:efi6,tag:ipxe6,52:54:00:bc:c3:fd,[fd12:3456:789a:1::bb00/126],host2 > dhcp-host=tag:!efi6,tag:!ipxe6,52:54:00:bc:c3:fd,[fd12:3456:789a:1::bb05],host2 > > The "temporary addresses" in [fd12:3456:789a:1::bb00/126] are only used > when architecture type is one of the UEFI types or the userclass option > have "iPXE". The dhcp client in the final OS should always end up with > fd12:3456:789a:1::bb05. nice! Really helpful, that looks like it should work - I was just not clever enough to come up with that :-). Our setup is sadly a bit clumsy - we have "Web-GUI-access" (no API :-( ) to one central DHCP/DNS appliance which can do DNS for v4/v6 and DHCPv4, but not DHCPv6 (due to other network components in between). So while we want to keep the information and DNS at that one central place, we have to use dnsmasq for DHCPv6 for now and manually sync information. Using the tag-based approach, this should work fine. We'll likely get to test this at larger scale in the upcoming months, and I may be able to do a test at small scale in the next weeks based on your patch (need to find a time-slot first...). Cheers and thanks, Oliver > > > Another possible solution would be to use a dhcp-script which run's > nsupdate to dynamically update the dns server. > > > > -- > Harald > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
On Sun, 2020-01-26 at 20:01 +0100, Oliver Freyermuth wrote: > I also like this new approach. "Wasting" 4 addresses for one host > seems to be the only way > to solve this while conforming to RFCs. > > However, there's one issue I can't find a good solution for in this > scheme - > how to solve the "DNS problem" if dnsmasq is only used for DHCP, but > DNS is provided by other means? > > The "range reservation", as highlighted, means the final address is > not well predictable (may depend on hardware, > other parts of the boot process etc.). > When dnsmasq is also doing the DNS part, that's not a problem, since > it will use the final / "most recently leased" address for DNS. > Does anybody have a good proposal for the case when DHCP is provided > by dnsmasq but DNS is maintained separately > (i.e. the "final address" needs to be fixed)? > > Cheers, > Oliver I think adding tag support for dhcp-host entries as follow up. The idea would be to have a config like this: # OPTION_CLIENT_ARCH_TYPE (61) dhcp-match=set:efi6,option6:61,0007 dhcp-match=set:efi6,option6:61,0009 dhcp-match=set:efi6,option6:61,0011 # User class is iPXE dhcp-userclass=set:ipxe6,iPXE dhcp-host=tag:efi6,tag:ipxe6,52:54:00:bc:c3:fd,[fd12:3456:789a:1::bb00/126],host2 dhcp-host=tag:!efi6,tag:!ipxe6,52:54:00:bc:c3:fd,[fd12:3456:789a:1::bb05],host2 The "temporary addresses" in [fd12:3456:789a:1::bb00/126] are only used when architecture type is one of the UEFI types or the userclass option have "iPXE". The dhcp client in the final OS should always end up with fd12:3456:789a:1::bb05. Another possible solution would be to use a dhcp-script which run's nsupdate to dynamically update the dns server. -- Harald ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
Am 07.01.20 um 22:51 schrieb Simon Kelley: > On 23/12/2019 11:24, Harald Jensas wrote: >> Hi, >> >> The patch below is a slight alteration to a possible solution >> discussed in >> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011289.html. >> >> My approach here does not require making dhcp-host conditional on a >> tag. However, making dhcp-host conditional on a tag would be a nice >> addition that could be introduced as a follow up to this to have a >> match on the tag of the final OS to keep the provisioned system >> consistently configured with a specific address can be very handy. For >> the Openstack use-case I am working in, this however is'nt necessary. >> >> I have confirmed that the patch below together with a small change in >> Openstack Ironic (see: https://review.opendev.org/72) solved the >> long standing issue when doing network booting and node provisioning >> in combination with static only dhcp configuration. >> >> We are looking forward to comments and feedback regarding this approach. >> >> Thank you! >> > > If I've understood correctly, this looks like it might be a viable > solution. Question: how many addresses do you configure for each host, > and is this fragile if the boot process changes, for instance to add new > steps? Could we add new syntax to dhcp-host which allows it to configure > a range of addresses, rather than having a number of dhcp-host entries > for each stage of the boot process? That would be a bigger change, but > might be a neater solution? > > I guess that the final adddress that the host ends up with depends on > the number of addresses allocated by other parts of the boot process, > but as the DNS entry ends up pointing to that final address (does it? - > need to check this) that's not a problem. I also like this new approach. "Wasting" 4 addresses for one host seems to be the only way to solve this while conforming to RFCs. However, there's one issue I can't find a good solution for in this scheme - how to solve the "DNS problem" if dnsmasq is only used for DHCP, but DNS is provided by other means? The "range reservation", as highlighted, means the final address is not well predictable (may depend on hardware, other parts of the boot process etc.). When dnsmasq is also doing the DNS part, that's not a problem, since it will use the final / "most recently leased" address for DNS. Does anybody have a good proposal for the case when DHCP is provided by dnsmasq but DNS is maintained separately (i.e. the "final address" needs to be fixed)? Cheers, Oliver > > Simon. > > > > > Simon. > > > > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
On Friday 10 January 2020 21:25:22 Simon Kelley wrote: > On 08/01/2020 09:32, Harald Jensås wrote: > > On Tue, 2020-01-07 at 21:51 +, Simon Kelley wrote: > >> On 23/12/2019 11:24, Harald Jensas wrote: > >>> Hi, > >>> > >>> The patch below is a slight alteration to a possible solution > >>> discussed in > >>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011289.html > >>> . > >>> > >>> My approach here does not require making dhcp-host conditional on a > >>> tag. However, making dhcp-host conditional on a tag would be a nice > >>> addition that could be introduced as a follow up to this to have a > >>> match on the tag of the final OS to keep the provisioned system > >>> consistently configured with a specific address can be very handy. > >>> For > >>> the Openstack use-case I am working in, this however is'nt > >>> necessary. > >>> > >>> I have confirmed that the patch below together with a small change > >>> in > >>> Openstack Ironic (see: https://review.opendev.org/72) solved > >>> the > >>> long standing issue when doing network booting and node > >>> provisioning > >>> in combination with static only dhcp configuration. > >>> > >>> We are looking forward to comments and feedback regarding this > >>> approach. > >>> > >>> Thank you! > >>> > >> > >> If I've understood correctly, this looks like it might be a viable > >> solution. Question: how many addresses do you configure for each > >> host, > >> and is this fragile if the boot process changes, for instance to add > >> new > >> steps? > > > > Thank you for reviewing this! > > > > I have tested using 4 addresses in total, I should be able to do with 2 > > addresses with the workflow I tested with which is OVMF-UEFI->iPXE- > >> LinuxDeployRamdisk->Final OS. OVMF-UEFI uses two addresses just to do > > PXE, but it is kind enough to release both addresses before executing > > the network boot program. Then iPXE uses one, and the deploy ramdisk > > one. Depending on wheater the deploy ramdisk does a release or not > > before rebooting a third address would be used by the final OS. (This > > is where dhcp-host conditional on a tag would be handy to control the > > address of the final OS.) > > > > In the openstack use case the dhcp-config is changed to have just a > > single dhcp-host entry prior to booting into the final os, openstack's > > networking service takes care of issuing a release during this step > > making sure the leased addresses are released. (This is why the dhcp- > > host conditional on a tag is'nt required in the openstack use case. > > > > The number of addresses is indeed fragile, adding another bootstep > > could increase the number of addresses needed. Also an unexpected reset > > of the booting system would lock up addresses that where not released, > > mainly problem with UEFI firmware that likes to generate new IAID's > > every time it boots ... > > > > As digression, Pali Rohár `honor assignment based on MAC address` > > patch is less fragile for this use case. I recognize it breaks other > > parts of the DHCPv6 RFC, see my comments on a previous post in this > > thread. Should we consider his approach if the patch can be re-worked > > to be an opt-in via configuration and a note in docs that the behaviour > > is not following RFC? > > Pali has done good work on this and I appreciate it. The objection to > that approach is both the RFC non-compliance, and also the fact that it > absolutely depends on dnsmasq being able to determine the MAC address > of a client. Hi Simon! You are right. We can write into documentation that such setup is non-RFC-compliant. But even that is is non-compliant it is useful in such environment. Openstack is one. Another example is small home network with dual-boot computers. Every reinstallation of OS or rebooting computer to other OS would lead to changing of IAID and DUID. DHCP server can identify computer only by MAC address. There is nothing more which can be used generally. And static DHCPv6 leases is the only way how to configure firewall for particular service on specific host. And in the end, if dnsmasq provides a way for specifying in configuration file assigning IPv6 address based on MAC address, it should implement it the best possible way. Even if it is fragile or not-RFC-compliant. All these information could be put into documentation, so administrators can decide. If they want to use non-compliant configuration or not. Important is that this is optional feature and nobody is forced to use this feature. Standard way for assigning IPv6 address based on DUID as described in RFC is still supported, primary used and not changed. But current implementation of IPv6 address assignment from MAC address in dnsmasq is basically unusable. As these options are sometimes ignored by dnsmasq and sometimes not. I think this is a bigger problem then that behavior is non-compliant. > Doing that is fragile, and it would be good to have a > mechanism which didn't rely
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
On Fri, 2020-01-10 at 21:25 +, Simon Kelley wrote: > On 08/01/2020 09:32, Harald Jensås wrote: > > On Tue, 2020-01-07 at 21:51 +, Simon Kelley wrote: > > > On 23/12/2019 11:24, Harald Jensas wrote: > > > > Hi, > > > > > > > > The patch below is a slight alteration to a possible solution > > > > discussed in > > > > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011289.html > > > > . > > > > > > > > My approach here does not require making dhcp-host conditional > > > > on a > > > > tag. However, making dhcp-host conditional on a tag would be a > > > > nice > > > > addition that could be introduced as a follow up to this to > > > > have a > > > > match on the tag of the final OS to keep the provisioned system > > > > consistently configured with a specific address can be very > > > > handy. > > > > For > > > > the Openstack use-case I am working in, this however is'nt > > > > necessary. > > > > > > > > I have confirmed that the patch below together with a small > > > > change > > > > in > > > > Openstack Ironic (see: https://review.opendev.org/72) > > > > solved > > > > the > > > > long standing issue when doing network booting and node > > > > provisioning > > > > in combination with static only dhcp configuration. > > > > > > > > We are looking forward to comments and feedback regarding this > > > > approach. > > > > > > > > Thank you! > > > > > > > > > > If I've understood correctly, this looks like it might be a > > > viable > > > solution. Question: how many addresses do you configure for each > > > host, > > > and is this fragile if the boot process changes, for instance to > > > add > > > new > > > steps? > > > > Thank you for reviewing this! > > > > I have tested using 4 addresses in total, I should be able to do > > with 2 > > addresses with the workflow I tested with which is OVMF-UEFI->iPXE- > > > LinuxDeployRamdisk->Final OS. OVMF-UEFI uses two addresses just > > > to do > > PXE, but it is kind enough to release both addresses before > > executing > > the network boot program. Then iPXE uses one, and the deploy > > ramdisk > > one. Depending on wheater the deploy ramdisk does a release or not > > before rebooting a third address would be used by the final OS. > > (This > > is where dhcp-host conditional on a tag would be handy to control > > the > > address of the final OS.) > > > > In the openstack use case the dhcp-config is changed to have just a > > single dhcp-host entry prior to booting into the final os, > > openstack's > > networking service takes care of issuing a release during this step > > making sure the leased addresses are released. (This is why the > > dhcp- > > host conditional on a tag is'nt required in the openstack use case. > > > > The number of addresses is indeed fragile, adding another bootstep > > could increase the number of addresses needed. Also an unexpected > > reset > > of the booting system would lock up addresses that where not > > released, > > mainly problem with UEFI firmware that likes to generate new IAID's > > every time it boots ... > > > > As digression, Pali Rohár `honor assignment based on MAC address` > > patch is less fragile for this use case. I recognize it breaks > > other > > parts of the DHCPv6 RFC, see my comments on a previous post in this > > thread. Should we consider his approach if the patch can be re- > > worked > > to be an opt-in via configuration and a note in docs that the > > behaviour > > is not following RFC? > > Pali has done good work on this and I appreciate it. The objection to > that approach is both the RFC non-compliance, and also the fact that > it > absolutely depends on dnsmasq being able to determine the MAC > address > of a client. Doing that is fragile, and it would be good to have a > mechanism which didn't rely on it. ack, if you ask me I think it is unfortunate that when rfc6939 was written it defines that the relay agent and servers obtain the link- layer address from the link-layer header of the DHCPv6 message. It implies that relay agents would have to operate on raw sockets, with all the security implications. But ... here we are and I shall refrain ranting about it more. > Does openstack rely on identifying a > host by MAC address, or could it be made to work if the DHCP server > didn't know the MAC address of a client? Even if openstack relies on > MAC > addresses (and I understand the provisioning reasons for doing that), > a > mechanism to support chain-netbooting without knowing MAC addresses > is a > more generally useful thing that one which only works when the MAC > address is determinable. > Yes, openstack does rely on the MAC address. Openstack cannot know the client id since an image booted is the users image, the cloud provider should'nt meddle with the users image. Using a dynamic range is also not a good option, due to the fact that openstack allow configuring dhcp highly available. With multiple dhcp servers on the same network we need to use
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
On 08/01/2020 09:32, Harald Jensås wrote: > On Tue, 2020-01-07 at 21:51 +, Simon Kelley wrote: >> On 23/12/2019 11:24, Harald Jensas wrote: >>> Hi, >>> >>> The patch below is a slight alteration to a possible solution >>> discussed in >>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011289.html >>> . >>> >>> My approach here does not require making dhcp-host conditional on a >>> tag. However, making dhcp-host conditional on a tag would be a nice >>> addition that could be introduced as a follow up to this to have a >>> match on the tag of the final OS to keep the provisioned system >>> consistently configured with a specific address can be very handy. >>> For >>> the Openstack use-case I am working in, this however is'nt >>> necessary. >>> >>> I have confirmed that the patch below together with a small change >>> in >>> Openstack Ironic (see: https://review.opendev.org/72) solved >>> the >>> long standing issue when doing network booting and node >>> provisioning >>> in combination with static only dhcp configuration. >>> >>> We are looking forward to comments and feedback regarding this >>> approach. >>> >>> Thank you! >>> >> >> If I've understood correctly, this looks like it might be a viable >> solution. Question: how many addresses do you configure for each >> host, >> and is this fragile if the boot process changes, for instance to add >> new >> steps? > > Thank you for reviewing this! > > I have tested using 4 addresses in total, I should be able to do with 2 > addresses with the workflow I tested with which is OVMF-UEFI->iPXE- >> LinuxDeployRamdisk->Final OS. OVMF-UEFI uses two addresses just to do > PXE, but it is kind enough to release both addresses before executing > the network boot program. Then iPXE uses one, and the deploy ramdisk > one. Depending on wheater the deploy ramdisk does a release or not > before rebooting a third address would be used by the final OS. (This > is where dhcp-host conditional on a tag would be handy to control the > address of the final OS.) > > In the openstack use case the dhcp-config is changed to have just a > single dhcp-host entry prior to booting into the final os, openstack's > networking service takes care of issuing a release during this step > making sure the leased addresses are released. (This is why the dhcp- > host conditional on a tag is'nt required in the openstack use case. > > The number of addresses is indeed fragile, adding another bootstep > could increase the number of addresses needed. Also an unexpected reset > of the booting system would lock up addresses that where not released, > mainly problem with UEFI firmware that likes to generate new IAID's > every time it boots ... > > As digression, Pali Rohár `honor assignment based on MAC address` > patch is less fragile for this use case. I recognize it breaks other > parts of the DHCPv6 RFC, see my comments on a previous post in this > thread. Should we consider his approach if the patch can be re-worked > to be an opt-in via configuration and a note in docs that the behaviour > is not following RFC? Pali has done good work on this and I appreciate it. The objection to that approach is both the RFC non-compliance, and also the fact that it absolutely depends on dnsmasq being able to determine the MAC address of a client. Doing that is fragile, and it would be good to have a mechanism which didn't rely on it. Does openstack rely on identifying a host by MAC address, or could it be made to work if the DHCP server didn't know the MAC address of a client? Even if openstack relies on MAC addresses (and I understand the provisioning reasons for doing that), a mechanism to support chain-netbooting without knowing MAC addresses is a more generally useful thing that one which only works when the MAC address is determinable. > >> Could we add new syntax to dhcp-host which allows it to configure >> a range of addresses, rather than having a number of dhcp-host >> entries >> for each stage of the boot process? That would be a bigger change, >> but >> might be a neater solution? >> > > I went for multiple dhcp-host entries because that accidentally happens > to be what openstack neutron already write in the dnsmasq configuration > when multiple ip addresses are added to a port in openstack. > > Supporting either a list of addresses or a range of addresses in the > dhcp-host syntax might be neater. (I am biased to keeping it to > multiple dhcp-host entries due to how openstack currently works, but it > would be reasonably small work to change|fix openstack in case ...) > > If we add dhcp-host conditional on a tag, one could use short lease > time, like 1m, on entries without a tag that the boot process uses. And > a longer lease time on the entry tagged for the final os. Doing so > could ease the issue of leases being held after an unexpected reset > during boot process. An argument to keep the multiple dhcp-host > entries? The best of all possible worlds might
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
On Tue, 2020-01-07 at 21:51 +, Simon Kelley wrote: > On 23/12/2019 11:24, Harald Jensas wrote: > > Hi, > > > > The patch below is a slight alteration to a possible solution > > discussed in > > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011289.html > > . > > > > My approach here does not require making dhcp-host conditional on a > > tag. However, making dhcp-host conditional on a tag would be a nice > > addition that could be introduced as a follow up to this to have a > > match on the tag of the final OS to keep the provisioned system > > consistently configured with a specific address can be very handy. > > For > > the Openstack use-case I am working in, this however is'nt > > necessary. > > > > I have confirmed that the patch below together with a small change > > in > > Openstack Ironic (see: https://review.opendev.org/72) solved > > the > > long standing issue when doing network booting and node > > provisioning > > in combination with static only dhcp configuration. > > > > We are looking forward to comments and feedback regarding this > > approach. > > > > Thank you! > > > > If I've understood correctly, this looks like it might be a viable > solution. Question: how many addresses do you configure for each > host, > and is this fragile if the boot process changes, for instance to add > new > steps? Thank you for reviewing this! I have tested using 4 addresses in total, I should be able to do with 2 addresses with the workflow I tested with which is OVMF-UEFI->iPXE- >LinuxDeployRamdisk->Final OS. OVMF-UEFI uses two addresses just to do PXE, but it is kind enough to release both addresses before executing the network boot program. Then iPXE uses one, and the deploy ramdisk one. Depending on wheater the deploy ramdisk does a release or not before rebooting a third address would be used by the final OS. (This is where dhcp-host conditional on a tag would be handy to control the address of the final OS.) In the openstack use case the dhcp-config is changed to have just a single dhcp-host entry prior to booting into the final os, openstack's networking service takes care of issuing a release during this step making sure the leased addresses are released. (This is why the dhcp- host conditional on a tag is'nt required in the openstack use case. The number of addresses is indeed fragile, adding another bootstep could increase the number of addresses needed. Also an unexpected reset of the booting system would lock up addresses that where not released, mainly problem with UEFI firmware that likes to generate new IAID's every time it boots ... As digression, Pali Rohár `honor assignment based on MAC address` patch is less fragile for this use case. I recognize it breaks other parts of the DHCPv6 RFC, see my comments on a previous post in this thread. Should we consider his approach if the patch can be re-worked to be an opt-in via configuration and a note in docs that the behaviour is not following RFC? > Could we add new syntax to dhcp-host which allows it to configure > a range of addresses, rather than having a number of dhcp-host > entries > for each stage of the boot process? That would be a bigger change, > but > might be a neater solution? > I went for multiple dhcp-host entries because that accidentally happens to be what openstack neutron already write in the dnsmasq configuration when multiple ip addresses are added to a port in openstack. Supporting either a list of addresses or a range of addresses in the dhcp-host syntax might be neater. (I am biased to keeping it to multiple dhcp-host entries due to how openstack currently works, but it would be reasonably small work to change|fix openstack in case ...) If we add dhcp-host conditional on a tag, one could use short lease time, like 1m, on entries without a tag that the boot process uses. And a longer lease time on the entry tagged for the final os. Doing so could ease the issue of leases being held after an unexpected reset during boot process. An argument to keep the multiple dhcp-host entries? > I guess that the final adddress that the host ends up with depends on > the number of addresses allocated by other parts of the boot process, > but as the DNS entry ends up pointing to that final address (does it? > - > need to check this) that's not a problem. > Yes, the final address of the host depend on the number of address that where allocated during the boot process. Good point regarding DNS, I did'nt check how DNS entries are maintained before you mentioned it. Your assumption that the DNS entry point to the last address leased is correct. See annotated log below. Jan 08 10:02:03 server.example.com systemd[1]: Started DNS caching server.. Jan 08 10:02:03 server.example.com dnsmasq[1444]: started, version 2.80-102-g7d04e17 cachesize 150 Jan 08 10:02:03 server.example.com dnsmasq[1444]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
On Tuesday 07 January 2020 13:57:02 Harald Jensås wrote: > On Tue, 2020-01-07 at 10:51 +0100, Pali Rohár wrote: > > Hi Harald! What are differences between your patch and mine which > > adds > > support for it too (plus honor assignment based on MAC address)? > > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q4/013545.html > > > > My patch allow creating multiple IPv6 address reservations for the same > host (MAC address), your patch allow a single IPv6 address to be > reserved for multiple MAC addresses? Yes! Now I see difference :-) I misread your description. > Also, Your patch allow dnsmasq to abandon a lease if a new request > using the same MAC address but a different IAID comes. My patch instead > makes it possible to configure multiple IPv6 addresses for a single MAC > address. The first request matching MAC will get leased to that > CLID/IAID combo. Another request from the same MAC using a different > CLID/IAID combo get's a lease using the second reservation, and so on. > No lease is abandoned before either the client does a release or the > lease_time is reached without the client renewing. > > I came up with this approach after realizing Simon already expressed > that the approach of allowing the server to abandon a lease is a bad > idea. Quoting Simon from [1]: > > """ 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. """ > > > As I understand the RFC's your approach of allowing a lease to be > abandoned is not allowed. Theoretically it is not according to RFC, but also whole assignment based on MAC address is not according to RFC. And there are usecases for assignment based on MAC address even it is against RFC. One example is multi OS laptop or another example is PXE booting which will always would use different IAID in PXE and in then booted system. > Personally and practically I like the `honor > assignment based on MAC address` patch, but it would also break > compatibility with a client that intentionally ask for multiple leases. > A client is allowed to do so according to RFC. Maby the `honor > assignment based on MAC address` patch need's an iteration that adds a > configuration flag enabling the behaviour + doc update that clarifies > the behaviour is breaking RFC complience? Assignment based on MAC address is useless and does not work without my patch which honors this option. Basically currently whole option for assigning IPv6 based on MAC address is broken and dnsmasq does not respect this option. I have no problem with updating documentation or patch itself, but I have not got any comment for whole year that something is wrong in that patch or that documentation needs to be updated. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
On 23/12/2019 11:24, Harald Jensas wrote: > Hi, > > The patch below is a slight alteration to a possible solution > discussed in > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011289.html. > > My approach here does not require making dhcp-host conditional on a > tag. However, making dhcp-host conditional on a tag would be a nice > addition that could be introduced as a follow up to this to have a > match on the tag of the final OS to keep the provisioned system > consistently configured with a specific address can be very handy. For > the Openstack use-case I am working in, this however is'nt necessary. > > I have confirmed that the patch below together with a small change in > Openstack Ironic (see: https://review.opendev.org/72) solved the > long standing issue when doing network booting and node provisioning > in combination with static only dhcp configuration. > > We are looking forward to comments and feedback regarding this approach. > > Thank you! > If I've understood correctly, this looks like it might be a viable solution. Question: how many addresses do you configure for each host, and is this fragile if the boot process changes, for instance to add new steps? Could we add new syntax to dhcp-host which allows it to configure a range of addresses, rather than having a number of dhcp-host entries for each stage of the boot process? That would be a bigger change, but might be a neater solution? I guess that the final adddress that the host ends up with depends on the number of addresses allocated by other parts of the boot process, but as the DNS entry ends up pointing to that final address (does it? - need to check this) that's not a problem. Simon. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
On Tue, 2020-01-07 at 10:51 +0100, Pali Rohár wrote: > Hi Harald! What are differences between your patch and mine which > adds > support for it too (plus honor assignment based on MAC address)? > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q4/013545.html > My patch allow creating multiple IPv6 address reservations for the same host (MAC address), your patch allow a single IPv6 address to be reserved for multiple MAC addresses? Also, Your patch allow dnsmasq to abandon a lease if a new request using the same MAC address but a different IAID comes. My patch instead makes it possible to configure multiple IPv6 addresses for a single MAC address. The first request matching MAC will get leased to that CLID/IAID combo. Another request from the same MAC using a different CLID/IAID combo get's a lease using the second reservation, and so on. No lease is abandoned before either the client does a release or the lease_time is reached without the client renewing. I came up with this approach after realizing Simon already expressed that the approach of allowing the server to abandon a lease is a bad idea. Quoting Simon from [1]: """ 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. """ As I understand the RFC's your approach of allowing a lease to be abandoned is not allowed. Personally and practically I like the `honor assignment based on MAC address` patch, but it would also break compatibility with a client that intentionally ask for multiple leases. A client is allowed to do so according to RFC. Maby the `honor assignment based on MAC address` patch need's an iteration that adds a configuration flag enabling the behaviour + doc update that clarifies the behaviour is breaking RFC complience? -- Harald [1] http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011289.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
Hi Harald! What are differences between your patch and mine which adds
support for it too (plus honor assignment based on MAC address)?
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q4/013545.html
On Tuesday 07 January 2020 10:01:59 Harald Jensås wrote:
> Reposting this, as it seems my e-mail client mangled the patch by
> inserting line-breaks etc.
>
> On Mon, 2019-12-23 at 12:24 +0100, Harald Jensas wrote:
> > Hi,
> >
> > The patch below is a slight alteration to a possible solution
> > discussed in
> > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011289.html
> > .
> >
> > My approach here does not require making dhcp-host conditional on a
> > tag. However, making dhcp-host conditional on a tag would be a nice
> > addition that could be introduced as a follow up to this to have a
> > match on the tag of the final OS to keep the provisioned system
> > consistently configured with a specific address can be very handy.
> > For
> > the Openstack use-case I am working in, this however is'nt necessary.
> >
> > I have confirmed that the patch below together with a small change in
> > Openstack Ironic (see: https://review.opendev.org/72) solved the
> > long standing issue when doing network booting and node provisioning
> > in combination with static only dhcp configuration.
> >
> > We are looking forward to comments and feedback regarding this
> > approach.
> >
> > Thank you!
> >
> > Regards
> > Harald Jensås
> >
>
> From 8b238dcf99dcf3332ec1c76fbb5af283db65a637 Mon Sep 17 00:00:00 2001
> From: Harald Jensås
> Date: Wed, 18 Dec 2019 23:59:11 +0100
> Subject: [PATCH] DHCPv6 - Multiple reservations for single host
>
> This change adds support for multiple dhcpv6 host
> reservations. The same clid or hwaddr can be used in
> multiple --dhcp-host entries.
>
> When receiving a request and a config containing an ip
> address is found, a test is done to see if the address is
> already leased to a different CLID/IAID. In case the ip
> address in the config was already used, skip_entry is
> incremented and find_config() is re-executed. find_config()
> will now skip the first config it finds, and continue
> looking for another config entry to return. This repeats
> until all possible config entries has been exhausted.
>
> Using multiple reservations for a single host makes it
> possible to maintain a static leases only configuration
> which support network booting systems with UEFI firmware
> that request a new address (a new SOLICIT with a new IA_NA
> option using a new IAID) for different boot modes, for
> instance 'PXE over IPv6', and HTTP-Boot over IPv6. Open
> Virtual Machine Firmware (OVMF) and most UEFI firmware
> build on the EDK2 code base exhibit this behaviour.
>
> RFC 8415 which updates RFC 3315 describes a single client
> request multiple IA's of any kind. These clients do this,
> using a new SOLICIT to request each IA. The clients could
> pack all IA's in one SOLICIT, but doing it individually as
> the above mentioned implementations do should not be a
> problem.
> ---
> src/dhcp-common.c | 19 ---
> src/dnsmasq.h | 3 ++-
> src/lease.c | 2 +-
> src/rfc2131.c | 6 +++---
> src/rfc3315.c | 29 +++--
> 5 files changed, 45 insertions(+), 14 deletions(-)
>
> diff --git a/src/dhcp-common.c b/src/dhcp-common.c
> index 602873e..5e770de 100644
> --- a/src/dhcp-common.c
> +++ b/src/dhcp-common.c
> @@ -299,7 +299,8 @@ struct dhcp_config *find_config(struct dhcp_config
> *configs,
> struct dhcp_context *context,
> unsigned char *clid, int clid_len,
> unsigned char *hwaddr, int hw_len,
> - int hw_type, char *hostname)
> + int hw_type, char *hostname,
> + int skip_entries)
> {
>int count, new;
>struct dhcp_config *config, *candidate;
> @@ -312,15 +313,23 @@ struct dhcp_config *find_config(struct dhcp_config
> *configs,
> if (config->clid_len == clid_len &&
> memcmp(config->clid, clid, clid_len) == 0 &&
> is_config_in_context(context, config))
> + {
> + if (--skip_entries > 0)
> + continue;
> return config;
> -
> + }
> +
> /* dhcpcd prefixes ASCII client IDs by zero which is wrong, but we
> try and
>cope with that here. This is IPv4 only. context==NULL implies
> IPv4,
>see lease_update_from_configs() */
> if ((!context || !(context->flags & CONTEXT_V6)) && *clid == 0 &&
> config->clid_len == clid_len-1 &&
> memcmp(config->clid, clid+1, clid_len-1) == 0 &&
> is_config_in_context(context, config))
> + {
> + if (--skip_entries > 0)
> + continue;
> return config;
> + }
> }
>
>
> @@ -328,7 +337,11 @@ struct dhcp_config
Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - Multiple reservations for single host
Reposting this, as it seems my e-mail client mangled the patch by
inserting line-breaks etc.
On Mon, 2019-12-23 at 12:24 +0100, Harald Jensas wrote:
> Hi,
>
> The patch below is a slight alteration to a possible solution
> discussed in
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011289.html
> .
>
> My approach here does not require making dhcp-host conditional on a
> tag. However, making dhcp-host conditional on a tag would be a nice
> addition that could be introduced as a follow up to this to have a
> match on the tag of the final OS to keep the provisioned system
> consistently configured with a specific address can be very handy.
> For
> the Openstack use-case I am working in, this however is'nt necessary.
>
> I have confirmed that the patch below together with a small change in
> Openstack Ironic (see: https://review.opendev.org/72) solved the
> long standing issue when doing network booting and node provisioning
> in combination with static only dhcp configuration.
>
> We are looking forward to comments and feedback regarding this
> approach.
>
> Thank you!
>
> Regards
> Harald Jensås
>
From 8b238dcf99dcf3332ec1c76fbb5af283db65a637 Mon Sep 17 00:00:00 2001
From: Harald Jensås
Date: Wed, 18 Dec 2019 23:59:11 +0100
Subject: [PATCH] DHCPv6 - Multiple reservations for single host
This change adds support for multiple dhcpv6 host
reservations. The same clid or hwaddr can be used in
multiple --dhcp-host entries.
When receiving a request and a config containing an ip
address is found, a test is done to see if the address is
already leased to a different CLID/IAID. In case the ip
address in the config was already used, skip_entry is
incremented and find_config() is re-executed. find_config()
will now skip the first config it finds, and continue
looking for another config entry to return. This repeats
until all possible config entries has been exhausted.
Using multiple reservations for a single host makes it
possible to maintain a static leases only configuration
which support network booting systems with UEFI firmware
that request a new address (a new SOLICIT with a new IA_NA
option using a new IAID) for different boot modes, for
instance 'PXE over IPv6', and HTTP-Boot over IPv6. Open
Virtual Machine Firmware (OVMF) and most UEFI firmware
build on the EDK2 code base exhibit this behaviour.
RFC 8415 which updates RFC 3315 describes a single client
request multiple IA's of any kind. These clients do this,
using a new SOLICIT to request each IA. The clients could
pack all IA's in one SOLICIT, but doing it individually as
the above mentioned implementations do should not be a
problem.
---
src/dhcp-common.c | 19 ---
src/dnsmasq.h | 3 ++-
src/lease.c | 2 +-
src/rfc2131.c | 6 +++---
src/rfc3315.c | 29 +++--
5 files changed, 45 insertions(+), 14 deletions(-)
diff --git a/src/dhcp-common.c b/src/dhcp-common.c
index 602873e..5e770de 100644
--- a/src/dhcp-common.c
+++ b/src/dhcp-common.c
@@ -299,7 +299,8 @@ struct dhcp_config *find_config(struct dhcp_config *configs,
struct dhcp_context *context,
unsigned char *clid, int clid_len,
unsigned char *hwaddr, int hw_len,
- int hw_type, char *hostname)
+ int hw_type, char *hostname,
+ int skip_entries)
{
int count, new;
struct dhcp_config *config, *candidate;
@@ -312,15 +313,23 @@ struct dhcp_config *find_config(struct dhcp_config
*configs,
if (config->clid_len == clid_len &&
memcmp(config->clid, clid, clid_len) == 0 &&
is_config_in_context(context, config))
+ {
+ if (--skip_entries > 0)
+ continue;
return config;
-
+ }
+
/* dhcpcd prefixes ASCII client IDs by zero which is wrong, but we
try and
cope with that here. This is IPv4 only. context==NULL implies
IPv4,
see lease_update_from_configs() */
if ((!context || !(context->flags & CONTEXT_V6)) && *clid == 0 &&
config->clid_len == clid_len-1 &&
memcmp(config->clid, clid+1, clid_len-1) == 0 &&
is_config_in_context(context, config))
+ {
+ if (--skip_entries > 0)
+ continue;
return config;
+ }
}
@@ -328,7 +337,11 @@ struct dhcp_config *find_config(struct dhcp_config
*configs,
for (config = configs; config; config = config->next)
if (config_has_mac(config, hwaddr, hw_len, hw_type) &&
is_config_in_context(context, config))
- return config;
+ {
+if (--skip_entries > 0)
+ continue;
+return config;
+ }
if (hostname && context)
for (config = configs; config; config = config->next)
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
