Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
Can you cheat and just set the lease expiration to be measured in seconds? I suspect that you can have different lease times, so if you can discriminate between first state and second state systems, you can provide more reasonable lease durations once the systems are stage two... ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
Am 06.06.2018 um 10:36 schrieb Roy Marples: > On 06/06/2018 09:14, Oliver Freyermuth wrote: >> I finally managed to test this in my testing setup - it works perfectly fine! > > Awesome :D > >> Could you let me know once it's integrated upstream? > > I *am* the upstream for dhcpcd :) > It will be in the next dhcpcd release for sure. Oh! I noted the manpages were authored by you, but I did not investigate you're much more than the manpage author - nice. Then, even more thanks for noticing my issue on the dnsmasq-discuss list here and taking care of it at the more correct place :-). > >> I plan to open issues for dhclient, systemd-networkd etc. then and could >> reference that RFC6355 is already handled fine >> in a very portable way on a wide range of OS by dhcpcd. >> >> In a later step, I'll then ping the debian-installer and kickstart >> developers, since they should also adopt this (I think they use dhclient, >> but I may be wrong). >> >> It's nice to see that dhcpcd is first on this :-). > > Generally, dhcpcd is the first to support new stuff. I know. Sadly, the most widespread distros (Debian, Ubuntu, RHEL, CentOS) have adoped dhclient (via NetworkManager) or systemd-networkd by default, even though I'm not convinced this is a good move, but I won't enter philosophical discussions with them (with Gentoo, I can easily choose myself ;-) ). > Thanks for testing and taking it to other upstreams. Thanks to you for being really quick in adding well-tested portable support for this! Cheers, Oliver > > Roy ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
On 06/06/2018 09:14, Oliver Freyermuth wrote: I finally managed to test this in my testing setup - it works perfectly fine! Awesome :D Could you let me know once it's integrated upstream? I *am* the upstream for dhcpcd :) It will be in the next dhcpcd release for sure. I plan to open issues for dhclient, systemd-networkd etc. then and could reference that RFC6355 is already handled fine in a very portable way on a wide range of OS by dhcpcd. In a later step, I'll then ping the debian-installer and kickstart developers, since they should also adopt this (I think they use dhclient, but I may be wrong). It's nice to see that dhcpcd is first on this :-). Generally, dhcpcd is the first to support new stuff. Thanks for testing and taking it to other upstreams. Roy ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
Dear Roy, Am 05.06.2018 um 13:34 schrieb Roy Marples: > On 04/06/2018 11:49, Roy Marples wrote: >> These problems are very nicely solved with RFC 6355 which adds DUID-UUID >> where UUID is taken from the hosts firmware. The UUID can then be displayed >> on the node alongside the MAC address for provisioning. >> https://tools.ietf.org/html/rfc6355 >> >> The downside is that no client I know of supports this and I keep meaning to >> add support to dhcpcd for it. >> The other downside is that not all hosts have a retrievable UUID as it >> depends on both the OS and host itself - for example some OS's present a >> UUID based on the CPUID. Of course this only works if all OS's generate the >> same UUID from the base data. > > I've just implemented DUID-UUID for dhcpcd. > Patch here: > https://roy.marples.name/git/dhcpcd.git/commit/?id=71981cab0e41ea2833489bc51307611727276aff > > Tested on NetBSD, OpenBSD, FreeBSD and Linux. > Unsure how to get system-uuid for Solaris or QNX at this time, which are the > only other platforms dhcpcd works on (but isn't as well supported). I finally managed to test this in my testing setup - it works perfectly fine! Could you let me know once it's integrated upstream? I plan to open issues for dhclient, systemd-networkd etc. then and could reference that RFC6355 is already handled fine in a very portable way on a wide range of OS by dhcpcd. In a later step, I'll then ping the debian-installer and kickstart developers, since they should also adopt this (I think they use dhclient, but I may be wrong). It's nice to see that dhcpcd is first on this :-). All the best and many thanks, Oliver > > Roy > > ___ > 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] DHCPv6 with dnsmasq for automated deployments
> > Alternatively: > Does somebody know of a clean way to administratively expire a lease handed > out by dnsmasq? > Then deployment tooling could forcefully expire an old lease when > reinstalling a node, and after the final reboot in the installed OS. > > Right now, I only know one could: > - Stop dnsmasq. > - Purge the lease from the leases-file. > - Restart dnsmasq. > > Is there a more convenient way? > There's a method in the DBus API to delete a DHCP lease. See dbus/DBus-interface for details. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
On 04/06/2018 11:49, Roy Marples wrote: These problems are very nicely solved with RFC 6355 which adds DUID-UUID where UUID is taken from the hosts firmware. The UUID can then be displayed on the node alongside the MAC address for provisioning. https://tools.ietf.org/html/rfc6355 The downside is that no client I know of supports this and I keep meaning to add support to dhcpcd for it. The other downside is that not all hosts have a retrievable UUID as it depends on both the OS and host itself - for example some OS's present a UUID based on the CPUID. Of course this only works if all OS's generate the same UUID from the base data. I've just implemented DUID-UUID for dhcpcd. Patch here: https://roy.marples.name/git/dhcpcd.git/commit/?id=71981cab0e41ea2833489bc51307611727276aff Tested on NetBSD, OpenBSD, FreeBSD and Linux. Unsure how to get system-uuid for Solaris or QNX at this time, which are the only other platforms dhcpcd works on (but isn't as well supported). Roy ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
Am 04.06.2018 um 23:27 schrieb Roy Marples: > On 25/05/2018 13:07, Oliver Freyermuth wrote: >> I fear the following is a design issue of DHCPv6, but I wonder if there's a >> way to overcome it with dnsmasq... >> >> When automatically deploying machines via PXE / network installer, there's >> usually first a DHCPv6 client running in the installer, >> and afterwards (when the machine is installed) the "real" DHCPv6 client >> running on the machine. >> Naturally, both will usually have different client DUIDs... > > The partial solution to this, without any dnsmasq hackery OR DHCPv6 client > fixes, would be to seed the installed image with the duid from the installer. > The only issue is if you re-run the installer it will create a new duid - > unless it performs a disk scan, finds the installation and then uses it. This > is an issue because there could be more than one installed target found, and > which to use? > > NetBSD installer has been doing this with great success for some time now, no > reason why others cannot. That's indeed a good point. It seems at least the Debian Installer is not doing that, I'm not 100% sure about RedHats kickstart, since I never had it in my test setup. But I know that some Linux installers, e.g. autoyast (openSUSE) also scrape existing installations for SSH host keys, to deploy them to the new installation. So the concept is certainly not new also for Linux, but apparently it has not made its way to the end just yet. I should probably go ahead at some point and open a bug report against Debian-Installer, and check out how Kickstart behaves. Of course, something which would fail in any case would be the approach to boot e.g. a temporary "bare-metal discovery" image to detect hardware, then the installer, and only then provision the machine. That's commonly done (see e.g. Foreman's discovery image). We're not doing that yet, but are planning to. The only solution for that would be RFC 6355, or using a type-3 DUID in the discovery image, since that's really volatile by design. Once we start to use the Foreman discovery image, I'll have a look what it does. Cheers, Oliver > > Roy ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
On 25/05/2018 13:07, Oliver Freyermuth wrote: I fear the following is a design issue of DHCPv6, but I wonder if there's a way to overcome it with dnsmasq... When automatically deploying machines via PXE / network installer, there's usually first a DHCPv6 client running in the installer, and afterwards (when the machine is installed) the "real" DHCPv6 client running on the machine. Naturally, both will usually have different client DUIDs... The partial solution to this, without any dnsmasq hackery OR DHCPv6 client fixes, would be to seed the installed image with the duid from the installer. The only issue is if you re-run the installer it will create a new duid - unless it performs a disk scan, finds the installation and then uses it. This is an issue because there could be more than one installed target found, and which to use? NetBSD installer has been doing this with great success for some time now, no reason why others cannot. Roy ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
Am 04.06.2018 um 18:46 schrieb wkitt...@gmail.com: > On 06/04/2018 07:36 AM, Oliver Freyermuth wrote: >> Right now, I only know one could: >> - Stop dnsmasq. >> - Purge the lease from the leases-file. >> - Restart dnsmasq. > > > i think the process is: > > rewrite the leases file as needed > HUP dnsmasq > > but i'm not positive... if not HUB, maybe one of the other signals... if none > of them, then something with DBUS... I think this works for some separate files specified explicitly, e.g. dhcp-hostsfile, but the lease file is not reloaded on SIGHUP, but kept in memory and flushed from time to time... That's also what the manpage suggests in the "NOTES" section. I'm not sure if leases are destroyed when the corresponding entry in dhcp-hostsfile is removed and SIGHUP is sent. This might be a possibility, but I would not expect that this destroys a still-valid lease. But indeed I find "RemoveDhcpLease" in: https://github.com/imp/dnsmasq/blob/master/dbus/DBus-interface This would certainly be a possibility :-). Cheers, Oliver ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
On 06/04/2018 07:36 AM, Oliver Freyermuth wrote: Right now, I only know one could: - Stop dnsmasq. - Purge the lease from the leases-file. - Restart dnsmasq. i think the process is: rewrite the leases file as needed HUP dnsmasq but i'm not positive... if not HUB, maybe one of the other signals... if none of them, then something with DBUS... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
Am 04.06.2018 um 12:49 schrieb Roy Marples: > On 03/06/2018 22:20, Simon Kelley wrote: >> I agree that this is an annoying problem. In DHCPv6 even determining the >> MAC address of a client is a slightly dodgy operation - there are >> circumstances where it's not possible. That notwithstanding, dnsmasq >> does it's best, and allows you to configure an address to allocated by >> MAC address. >> >> The problem here is that the client changes DUID - the desired address >> gets allocated by MAC address once, but when the DUID changes, the >> address is already in use by a first DUID/IAID combination, so it can't >> be allocated, even if the MAC address is the same. > > The problem is how the DUID is generated, not the DUID itself. > DUID-LL is not the default (and shouldn't be either). > DUID-LLT is a good default, but comes with the aforementioned problems. > > These problems are very nicely solved with RFC 6355 which adds DUID-UUID > where UUID is taken from the hosts firmware. The UUID can then be displayed > on the node alongside the MAC address for provisioning. > https://tools.ietf.org/html/rfc6355 > > The downside is that no client I know of supports this and I keep meaning to > add support to dhcpcd for it. This sounds like a really nice solution - it would be cool if this was added to dhclient and dhcpcd and systemd-networkd, and would be the default. This should then also fix the problem with automated deployments. Still, even if support for that is added, it will likely take some years until all components are fixed... > The other downside is that not all hosts have a retrievable UUID as it > depends on both the OS and host itself - for example some OS's present a UUID > based on the CPUID. Of course this only works if all OS's generate the same > UUID from the base data. > > TL;DR - this isn't a dnsmasq issue and I agree with Simon that it should not > allow nor encourage RFC violations. I fully agree it's not a dnsmasq issue (I already mentioned that in my first mail). I was mainly unaware of RFC6355 (which should indeed be *the* solution), and am convinced that a workaround on the DHCP server end is significantly easier to deploy for a full network than to get rid of all clients not yet using RFC6355, so I keep wondering whether an optional feature to violate the "old" RFCs would be feasible until all clients are fixed, which will surely take half a century or longer. Alternatively: Does somebody know of a clean way to administratively expire a lease handed out by dnsmasq? Then deployment tooling could forcefully expire an old lease when reinstalling a node, and after the final reboot in the installed OS. Right now, I only know one could: - Stop dnsmasq. - Purge the lease from the leases-file. - Restart dnsmasq. Is there a more convenient way? Cheers, Oliver > > Roy > > ___ > 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] DHCPv6 with dnsmasq for automated deployments
On 03/06/2018 22:20, Simon Kelley wrote: I agree that this is an annoying problem. In DHCPv6 even determining the MAC address of a client is a slightly dodgy operation - there are circumstances where it's not possible. That notwithstanding, dnsmasq does it's best, and allows you to configure an address to allocated by MAC address. The problem here is that the client changes DUID - the desired address gets allocated by MAC address once, but when the DUID changes, the address is already in use by a first DUID/IAID combination, so it can't be allocated, even if the MAC address is the same. The problem is how the DUID is generated, not the DUID itself. DUID-LL is not the default (and shouldn't be either). DUID-LLT is a good default, but comes with the aforementioned problems. These problems are very nicely solved with RFC 6355 which adds DUID-UUID where UUID is taken from the hosts firmware. The UUID can then be displayed on the node alongside the MAC address for provisioning. https://tools.ietf.org/html/rfc6355 The downside is that no client I know of supports this and I keep meaning to add support to dhcpcd for it. The other downside is that not all hosts have a retrievable UUID as it depends on both the OS and host itself - for example some OS's present a UUID based on the CPUID. Of course this only works if all OS's generate the same UUID from the base data. TL;DR - this isn't a dnsmasq issue and I agree with Simon that it should not allow nor encourage RFC violations. Roy ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
Am 03.06.2018 um 23:20 schrieb Simon Kelley: > I agree that this is an annoying problem. In DHCPv6 even determining the > MAC address of a client is a slightly dodgy operation - there are > circumstances where it's not possible. That notwithstanding, dnsmasq > does it's best, and allows you to configure an address to allocated by > MAC address. > > The problem here is that the client changes DUID - the desired address > gets allocated by MAC address once, but when the DUID changes, the > address is already in use by a first DUID/IAID combination, so it can't > be allocated, even if the MAC address is the same. > > The obvious solution is to prioritise MAC address over DUID/IAID and > allocate anyway, but there are at least two reasons why I'm not happy > with that. > > First, as I mentioned above getting the MAC address is not always > possible/reliable. > > Second, it flat-out violates the relevant RFCs. DHCPv6 is predicated on > clients being identified by DUID/IAID. Allocating the same address to > two different DUID/IAIDs, because of hints from an (unreliable) MAC > address violates the DHCP prime directive: thou shall not give the same > address to two different machines. I fully agree. The problem is that for my case, the RFCs do not offer any solution. My case is: A machine boots via PXE, fetches an address in the installer environment, deploys the operating system, reboots - and gets no address anymore, since the DUID/IAID will necessarily be different between the temporary installer environment and the final runtime environment. In short, DHCPv6 is impossible to use (in accordance with thr RFCs) for any automated deployment via PXE. The only way is to use IPv4 in addition, and trust in the fallbacks, and wait for leases to time out. So the RFCs are broken for this very common usecase - that's why my statement was if dnsmasq is willing to offer a workaround for the RFCs, which don't cover one of the most common usecases, unless I'm missing something. > > Looking at Kevin's logs, the client is flat out buggy. It's using a > type-1 DUID which consists of a time and a MAC address. The reason for > the time is to ensure uniqueness when the DUID is created, but the NAS > seems to be updating it on every reboot. That's just plain wrong. type-1 > DUID are meant for devices which have non volatile storage: they > generate the DUID once and store it. If they can't store it (which seems > unlikely for a NAS, but let's give it the benefit of the doubt), they > should use type-3 DUIDs, without the time field. It's all very clear in > RFC 3315, section 9. The other option would be to modify all automated Linux installers (Kickstart / Anaconda, Preseed / Debian Installer) to use type-3 DUIDs. Since right now they appear to use dhclient / dhcpce without any special configuration, that's not the case... That would be a way out in accordance with the RFCs, but things would still fail if a machine is reinstalled - it can't fetch an address when rebooting via PXE, until the old DUID/IAID lease from the past life is expired, which may take days. TL;DR: The RFCs did not think about automated machine deployment :-(. One needs to violate the RFCs to allow for that in a DHCPv6 environment. Cheers, Oliver > > TLDR; these clients are violating the RFCs. The only feasible way to > make them behave is for dnsmasq to violate the RFC too, in a way which > may well break stuff badly. I'm not prepared to implement that in dnsmasq. > > > Cheers, > > Simon. > > > > On 27/05/18 18:36, Oliver Freyermuth wrote: >> Am 25.05.2018 um 17:23 schrieb P W: >>> On Fri, May 25, 2018 at 03:34:08PM +0200, Oliver Freyermuth wrote: Am 25.05.2018 um 15:30 schrieb Kevin Darbyshire-Bryant: >> On 25 May 2018, at 13:07, Oliver Freyermuth wrote: >> >> Dear dnsmasqers, >> >> I fear the following is a design issue of DHCPv6, but I wonder if >> there's a way to overcome it with dnsmasq... > > > Hi Oliver, > > I???ve a similar/same problem when rebooting some QNAP NAS boxen, > first boot/introduction to dnsmasq and they get both IPv4 & v6 > addresses set to fixed values based on MAC address. On reboot whilst > IPv4 is fine, IPv6 is not reallocated to the original address but > rather a new one. By curious co-incidence I just started looking > into this problem today though it has been bugging me for months :-) > Have tried various combinations of MAC address & DUID. > Dear Kevin, I think it's exactly the same issue. Comparing: > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 > DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba with > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 > DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba it seems the QNAP NAS box is using a fresh client DUID each reboot... >>> >>> >>>
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
There is an extension for DHCPv6 to send client's MAC address as DHCP option 79. And in case there is no DHCPv6 relay and packets comes from ethernet, you can read MAC address directly from ethernet frame which contains that UDP (DHCPv6) packet. In other cases MAC address is really not available, but then it would not work. But I guess that in most cases is dnsmasq on same segment as hosts and ethernet is used for UDP packets. In all other cases DHCPv6 relay can be configured to fill option 79 (RFC 6939). I agree that clients which generates after every boot new DUID are buggy, but this is reality. DHCPv6 was designed in this way and for implementing DHCPv6 clients it was easier to introduce these bugs as doing it properly (via permanent storage for DUID). And I doubt that in future it would be better... There still would be a problem with dual-booting. Linux and Windows DHCPv6 clients would *never* use one common permanent storage for DUID. So I would really propose to thing about it and trying to find a way how to make dnsmasq better on network with these devices. On Sunday 03 June 2018 22:20:17 Simon Kelley wrote: > I agree that this is an annoying problem. In DHCPv6 even determining the > MAC address of a client is a slightly dodgy operation - there are > circumstances where it's not possible. That notwithstanding, dnsmasq > does it's best, and allows you to configure an address to allocated by > MAC address. > > The problem here is that the client changes DUID - the desired address > gets allocated by MAC address once, but when the DUID changes, the > address is already in use by a first DUID/IAID combination, so it can't > be allocated, even if the MAC address is the same. > > The obvious solution is to prioritise MAC address over DUID/IAID and > allocate anyway, but there are at least two reasons why I'm not happy > with that. > > First, as I mentioned above getting the MAC address is not always > possible/reliable. > > Second, it flat-out violates the relevant RFCs. DHCPv6 is predicated on > clients being identified by DUID/IAID. Allocating the same address to > two different DUID/IAIDs, because of hints from an (unreliable) MAC > address violates the DHCP prime directive: thou shall not give the same > address to two different machines. > > Looking at Kevin's logs, the client is flat out buggy. It's using a > type-1 DUID which consists of a time and a MAC address. The reason for > the time is to ensure uniqueness when the DUID is created, but the NAS > seems to be updating it on every reboot. That's just plain wrong. type-1 > DUID are meant for devices which have non volatile storage: they > generate the DUID once and store it. If they can't store it (which seems > unlikely for a NAS, but let's give it the benefit of the doubt), they > should use type-3 DUIDs, without the time field. It's all very clear in > RFC 3315, section 9. > > > TLDR; these clients are violating the RFCs. The only feasible way to > make them behave is for dnsmasq to violate the RFC too, in a way which > may well break stuff badly. I'm not prepared to implement that in dnsmasq. > > > Cheers, > > Simon. > > > > On 27/05/18 18:36, Oliver Freyermuth wrote: > > Am 25.05.2018 um 17:23 schrieb P W: > >> On Fri, May 25, 2018 at 03:34:08PM +0200, Oliver Freyermuth wrote: > >>> Am 25.05.2018 um 15:30 schrieb Kevin Darbyshire-Bryant: > > On 25 May 2018, at 13:07, Oliver Freyermuth wrote: > > > > Dear dnsmasqers, > > > > I fear the following is a design issue of DHCPv6, but I wonder if > > there's a way to overcome it with dnsmasq... > > > Hi Oliver, > > I???ve a similar/same problem when rebooting some QNAP NAS boxen, > first boot/introduction to dnsmasq and they get both IPv4 & v6 > addresses set to fixed values based on MAC address. On reboot whilst > IPv4 is fine, IPv6 is not reallocated to the original address but > rather a new one. By curious co-incidence I just started looking > into this problem today though it has been bugging me for months :-) > Have tried various combinations of MAC address & DUID. > > >>> > >>> Dear Kevin, > >>> > >>> I think it's exactly the same issue. > >>> Comparing: > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 > DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba > >>> with > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 > DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba > >>> it seems the QNAP NAS box is using a fresh client DUID each reboot... > >> > >> > >> Patches Welcome > > > > At the moment, there's sadly too much in my queue to start on another > > OpenSource project - but I'll look into it once this changes, > > which sadly won't be in the very near future. > > If anybody else has time at hand, of course I can offer to test a patch > > (the setup is here). > > > > Cheers, > > Oliver > > >
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
I agree that this is an annoying problem. In DHCPv6 even determining the MAC address of a client is a slightly dodgy operation - there are circumstances where it's not possible. That notwithstanding, dnsmasq does it's best, and allows you to configure an address to allocated by MAC address. The problem here is that the client changes DUID - the desired address gets allocated by MAC address once, but when the DUID changes, the address is already in use by a first DUID/IAID combination, so it can't be allocated, even if the MAC address is the same. The obvious solution is to prioritise MAC address over DUID/IAID and allocate anyway, but there are at least two reasons why I'm not happy with that. First, as I mentioned above getting the MAC address is not always possible/reliable. Second, it flat-out violates the relevant RFCs. DHCPv6 is predicated on clients being identified by DUID/IAID. Allocating the same address to two different DUID/IAIDs, because of hints from an (unreliable) MAC address violates the DHCP prime directive: thou shall not give the same address to two different machines. Looking at Kevin's logs, the client is flat out buggy. It's using a type-1 DUID which consists of a time and a MAC address. The reason for the time is to ensure uniqueness when the DUID is created, but the NAS seems to be updating it on every reboot. That's just plain wrong. type-1 DUID are meant for devices which have non volatile storage: they generate the DUID once and store it. If they can't store it (which seems unlikely for a NAS, but let's give it the benefit of the doubt), they should use type-3 DUIDs, without the time field. It's all very clear in RFC 3315, section 9. TLDR; these clients are violating the RFCs. The only feasible way to make them behave is for dnsmasq to violate the RFC too, in a way which may well break stuff badly. I'm not prepared to implement that in dnsmasq. Cheers, Simon. On 27/05/18 18:36, Oliver Freyermuth wrote: > Am 25.05.2018 um 17:23 schrieb P W: >> On Fri, May 25, 2018 at 03:34:08PM +0200, Oliver Freyermuth wrote: >>> Am 25.05.2018 um 15:30 schrieb Kevin Darbyshire-Bryant: > On 25 May 2018, at 13:07, Oliver Freyermuth wrote: > > Dear dnsmasqers, > > I fear the following is a design issue of DHCPv6, but I wonder if there's > a way to overcome it with dnsmasq... Hi Oliver, I???ve a similar/same problem when rebooting some QNAP NAS boxen, first boot/introduction to dnsmasq and they get both IPv4 & v6 addresses set to fixed values based on MAC address. On reboot whilst IPv4 is fine, IPv6 is not reallocated to the original address but rather a new one. By curious co-incidence I just started looking into this problem today though it has been bugging me for months :-) Have tried various combinations of MAC address & DUID. >>> >>> Dear Kevin, >>> >>> I think it's exactly the same issue. >>> Comparing: Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba >>> with Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba >>> it seems the QNAP NAS box is using a fresh client DUID each reboot... >> >> >> Patches Welcome > > At the moment, there's sadly too much in my queue to start on another > OpenSource project - but I'll look into it once this changes, > which sadly won't be in the very near future. > If anybody else has time at hand, of course I can offer to test a patch (the > setup is here). > > Cheers, > Oliver > >> >> ___ >> 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 > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
Am 25.05.2018 um 17:23 schrieb P W: > On Fri, May 25, 2018 at 03:34:08PM +0200, Oliver Freyermuth wrote: >> Am 25.05.2018 um 15:30 schrieb Kevin Darbyshire-Bryant: On 25 May 2018, at 13:07, Oliver Freyermuth wrote: Dear dnsmasqers, I fear the following is a design issue of DHCPv6, but I wonder if there's a way to overcome it with dnsmasq... >>> >>> >>> Hi Oliver, >>> >>> I???ve a similar/same problem when rebooting some QNAP NAS boxen, >>> first boot/introduction to dnsmasq and they get both IPv4 & v6 >>> addresses set to fixed values based on MAC address. On reboot whilst >>> IPv4 is fine, IPv6 is not reallocated to the original address but >>> rather a new one. By curious co-incidence I just started looking >>> into this problem today though it has been bugging me for months :-) >>> Have tried various combinations of MAC address & DUID. >>> >> >> Dear Kevin, >> >> I think it's exactly the same issue. >> Comparing: >>> Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 >>> DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba >> with >>> Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 >>> DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba >> it seems the QNAP NAS box is using a fresh client DUID each reboot... > > > Patches Welcome At the moment, there's sadly too much in my queue to start on another OpenSource project - but I'll look into it once this changes, which sadly won't be in the very near future. If anybody else has time at hand, of course I can offer to test a patch (the setup is here). Cheers, Oliver > > ___ > 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] DHCPv6 with dnsmasq for automated deployments
On Fri, May 25, 2018 at 03:34:08PM +0200, Oliver Freyermuth wrote: > Am 25.05.2018 um 15:30 schrieb Kevin Darbyshire-Bryant: > >> On 25 May 2018, at 13:07, Oliver Freyermuth wrote: > >> > >> Dear dnsmasqers, > >> > >> I fear the following is a design issue of DHCPv6, but I wonder if there's > >> a way to overcome it with dnsmasq... > > > > > > Hi Oliver, > > > > I???ve a similar/same problem when rebooting some QNAP NAS boxen, > > first boot/introduction to dnsmasq and they get both IPv4 & v6 > > addresses set to fixed values based on MAC address. On reboot whilst > > IPv4 is fine, IPv6 is not reallocated to the original address but > > rather a new one. By curious co-incidence I just started looking > > into this problem today though it has been bugging me for months :-) > > Have tried various combinations of MAC address & DUID. > > > > Dear Kevin, > > I think it's exactly the same issue. > Comparing: > > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 > > DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba > with > > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 > > DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba > it seems the QNAP NAS box is using a fresh client DUID each reboot... Patches Welcome ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
Am 25.05.2018 um 15:30 schrieb Kevin Darbyshire-Bryant: > > >> On 25 May 2018, at 13:07, Oliver Freyermuth >> wrote: >> >> Dear dnsmasqers, >> >> I fear the following is a design issue of DHCPv6, but I wonder if there's a >> way to overcome it with dnsmasq... > > > Hi Oliver, > > I’ve a similar/same problem when rebooting some QNAP NAS boxen, first > boot/introduction to dnsmasq and they get both IPv4 & v6 addresses set to > fixed values based on MAC address. On reboot whilst IPv4 is fine, IPv6 is > not reallocated to the original address but rather a new one. By curious > co-incidence I just started looking into this problem today though it has > been bugging me for months :-) Have tried various combinations of MAC > address & DUID. > > Without meaning to thread hijack! If it’s not effectively the same issue > will gladly start a new thread. Dear Kevin, I think it's exactly the same issue. Comparing: > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 > DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba with > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 > DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba it seems the QNAP NAS box is using a fresh client DUID each reboot... Cheers, Oliver > > > First boot with fresh dnsmasq > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 client MAC > address: 24:5e:be:0c:bc:ba > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 > DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 > DHCPREPLY(br-lan) 2a02:c7f:beef:2000::e > 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba Statler > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 tags: lan, > known, dhcpv6, br-lan > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: > 14 option: 2 server-id 00:01:00:01:21:92:2f:dc:60:e3:27:af:9e:51 > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: > 40 option: 3 ia-na IAID=3132886206 T1=21600 T2=37800 > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 nest size: > 24 option: 5 iaaddr 2a02:c7f:beef:2000::e PL=43200 VL=43200 > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: > 9 option: 13 status 0 success > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: > 1 option: 7 preference 255 > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: > 29 option: 24 domain-search lan.darbyshire-bryant.me.uk > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: > 16 option: 23 dns-server 2a02:c7f:beef:2000::da2b:da2b > Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: > 38 option: 39 FQDN Statler.lan.darbyshire-bryant.me.uk > > > And now a reboot of the client: > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 available > DHCP range: 2a02:c7f:beef:2000::1000 -- 2a02:c7f:beef:2000:: > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 client MAC > address: 24:5e:be:0c:bc:ba > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 > DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 > DHCPADVERTISE(br-lan) 2a02:c7f:beef:2000::9c72 > 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba Statler > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 tags: lan, > known, dhcpv6, br-lan > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: > 14 option: 1 client-id 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: > 14 option: 2 server-id 00:01:00:01:21:92:2f:dc:60:e3:27:af:9e:51 > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: > 40 option: 3 ia-na IAID=3132886206 T1=21600 T2=37800 > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 nest size: > 24 option: 5 iaaddr 2a02:c7f:beef:2000::9c72 PL=43200 VL=43200 > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: > 9 option: 13 status 0 success > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: > 1 option: 7 preference 255 > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: > 29 option: 24 domain-search lan.darbyshire-bryant.me.uk > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: > 16 option: 23 dns-server 2a02:c7f:beef:2000::da2b:da2b > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: > 9 option: 39 FQDN Statler > Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 available > DHCP range: 2a02:c7f:beef:2000::1000 -- 2a02:c7f:beef:2000:: > Fri May 25 12:59:40
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
> On 25 May 2018, at 13:07, Oliver Freyermuth > wrote: > > Dear dnsmasqers, > > I fear the following is a design issue of DHCPv6, but I wonder if there's a > way to overcome it with dnsmasq... Hi Oliver, I’ve a similar/same problem when rebooting some QNAP NAS boxen, first boot/introduction to dnsmasq and they get both IPv4 & v6 addresses set to fixed values based on MAC address. On reboot whilst IPv4 is fine, IPv6 is not reallocated to the original address but rather a new one. By curious co-incidence I just started looking into this problem today though it has been bugging me for months :-) Have tried various combinations of MAC address & DUID. Without meaning to thread hijack! If it’s not effectively the same issue will gladly start a new thread. First boot with fresh dnsmasq Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 client MAC address: 24:5e:be:0c:bc:ba Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 DHCPREPLY(br-lan) 2a02:c7f:beef:2000::e 00:01:00:01:22:9a:b4:43:24:5e:be:0c:bc:ba Statler Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 tags: lan, known, dhcpv6, br-lan Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 14 option: 2 server-id 00:01:00:01:21:92:2f:dc:60:e3:27:af:9e:51 Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 40 option: 3 ia-na IAID=3132886206 T1=21600 T2=37800 Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 nest size: 24 option: 5 iaaddr 2a02:c7f:beef:2000::e PL=43200 VL=43200 Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 9 option: 13 status 0 success Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 1 option: 7 preference 255 Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 29 option: 24 domain-search lan.darbyshire-bryant.me.uk Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 16 option: 23 dns-server 2a02:c7f:beef:2000::da2b:da2b Fri May 25 12:47:13 2018 daemon.info dnsmasq-dhcp[26168]: 5514926 sent size: 38 option: 39 FQDN Statler.lan.darbyshire-bryant.me.uk And now a reboot of the client: Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 available DHCP range: 2a02:c7f:beef:2000::1000 -- 2a02:c7f:beef:2000:: Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 client MAC address: 24:5e:be:0c:bc:ba Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 DHCPSOLICIT(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 DHCPADVERTISE(br-lan) 2a02:c7f:beef:2000::9c72 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba Statler Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 tags: lan, known, dhcpv6, br-lan Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 14 option: 1 client-id 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 14 option: 2 server-id 00:01:00:01:21:92:2f:dc:60:e3:27:af:9e:51 Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 40 option: 3 ia-na IAID=3132886206 T1=21600 T2=37800 Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 nest size: 24 option: 5 iaaddr 2a02:c7f:beef:2000::9c72 PL=43200 VL=43200 Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 9 option: 13 status 0 success Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 1 option: 7 preference 255 Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 29 option: 24 domain-search lan.darbyshire-bryant.me.uk Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 16 option: 23 dns-server 2a02:c7f:beef:2000::da2b:da2b Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 12603117 sent size: 9 option: 39 FQDN Statler Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 available DHCP range: 2a02:c7f:beef:2000::1000 -- 2a02:c7f:beef:2000:: Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 client MAC address: 24:5e:be:0c:bc:ba Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 DHCPREQUEST(br-lan) 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 DHCPREPLY(br-lan) 2a02:c7f:beef:2000::9c72 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba Statler Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 tags: lan, known, dhcpv6, br-lan Fri May 25 12:59:40 2018 daemon.info dnsmasq-dhcp[26168]: 15821508 sent size: 14 option: 1 client-id 00:01:00:01:22:9a:b7:2b:24:5e:be:0c:bc:ba Fri May 25 12:59:4
Re: [Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
On Friday 25 May 2018 14:07:34 Oliver Freyermuth wrote: > Dear dnsmasqers, > > I fear the following is a design issue of DHCPv6, but I wonder if there's a > way to overcome it with dnsmasq... > > When automatically deploying machines via PXE / network installer, there's > usually first a DHCPv6 client running in the installer, > and afterwards (when the machine is installed) the "real" DHCPv6 client > running on the machine. > Naturally, both will usually have different client DUIDs... > > Using dnsmasq's functionality to perform DHCPv6 address assignment based on > MAC address, > this works fine for the first client, but the second DHCPv6 client will not > get an address until the old lease is expired. > > In general, I feel this is the correct behaviour, but it's of course rather > inconvenient when deploying machines automatically - > they will retrieve an IPv6 address with the network installer, and then not > get one after the first reboot. > Also, when reinstalling them, they will not get an address in the installer > if the lease from their "old life" is still valid. > > Does somebody have a good solution for this? > Is there something like "id:*" for IPv4 implemented for the IPv6 world (i.e. > something like "duid:*")? > > Cheers and all the best, > Oliver Hi Oliver! dnsmasq for DHCPv6 stores in lease file IAID, not DUID. But assignment of address is done either by DUID or MAC address. I think you hit some problem affected by the way how is IPv6 address assigned according to DUID, IAID, MAC address and status of lease file. 2 years ago I tried to discuss with Simon about possibility to assign one address to more DHCP requests identified by MAC address and one of needed thing was probably extension of lease file (to include also MAC address and DUID) and handling of requests which already have address assigned in lease file. Apparently until now Simon has not response about it and I gave up trying to ping him again... http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010404.html -- Pali Rohár pali.ro...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] DHCPv6 with dnsmasq for automated deployments
Dear dnsmasqers, I fear the following is a design issue of DHCPv6, but I wonder if there's a way to overcome it with dnsmasq... When automatically deploying machines via PXE / network installer, there's usually first a DHCPv6 client running in the installer, and afterwards (when the machine is installed) the "real" DHCPv6 client running on the machine. Naturally, both will usually have different client DUIDs... Using dnsmasq's functionality to perform DHCPv6 address assignment based on MAC address, this works fine for the first client, but the second DHCPv6 client will not get an address until the old lease is expired. In general, I feel this is the correct behaviour, but it's of course rather inconvenient when deploying machines automatically - they will retrieve an IPv6 address with the network installer, and then not get one after the first reboot. Also, when reinstalling them, they will not get an address in the installer if the lease from their "old life" is still valid. Does somebody have a good solution for this? Is there something like "id:*" for IPv4 implemented for the IPv6 world (i.e. something like "duid:*")? Cheers and all the best, Oliver ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
