[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
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:2
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
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 :-) >&g
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
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
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
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
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] [PATCH] DHCPv6: Honor assigning IPv6 address based on MAC address
Am 11.05.19 um 19:42 schrieb Kevin Darbyshire-Bryant: > > >> On 6 Apr 2019, at 12:01, Geert Stappers wrote: >> >> On Mon, Apr 01, 2019 at 01:02:20AM +0200, Pali Rohár wrote: >>> On Tuesday 12 February 2019 13:41:43 Geert Stappers wrote: On 06-02-2019 21:29, Pali Rohár wrote: > On Friday 11 January 2019 17:52:43 Pali Rohár wrote: >> On Monday 17 December 2018 18:41:09 Pali Rohár wrote: >>> Currently IPv6 addresses are assigned to tuple (IAID, DUID). When system >>> changes IAID/DUID then old assigned IPv6 address cannot be reused, even >>> when in config file was DHCPv6 assignment based on MAC address (and not >>> on >>> DUID). >> >> ... >> >> Hello, can somebody look at this patch? >> >> I remember that more people asked for ability to assign IPv6 address >> based on MAC address specified in config file, rather then IAID/DUID. >> > PING > Another request for Hey, could this patch get reviewed? >>> Hello, can somebody review this patch? >>> >> >> FWIW >> >> * The (four months old) patch does get applied cleanly. >> * My compiler is happy with it >> * Executable remains running upon start ( no early crash ) >> * I'm unable to test the (new) IPv6 functionality >> >> >> Where in the "patch pipeline" is Pali's patch? >> >> >> Regards >> Geert Stappers > > I’ve been using this patch to tame qnap’s frustrating dhcpv6 assignment > limitations for many months. It’s immensely useful. Same here. In an automated deployment situation, client changes DUID in each phase: - PXE (if done via IPv6) - Installation time (from ramdisk) - Final OS after installation This may improve if newer versions of dhcpcd get packaged in installer ramdisks and OS, and also for systemd-dhcp, but I am still unaware of any implementation of machine-id as base for the client DUID in dhclient and of course the implementations are all not exactly the same. And then there is still the UEFI doing the PXE part, systems with broken machine-id etc And of course, dual booting if not set up with identical cliend-DUID. In general, my belief is that the RFC was made without real life use cases in mind and hence did not think of these. The patch is very helpful to overcome these issues and matches user expectation (when specifying a MAC address in the config file, I want it to be used). Cheers, Oliver > > > Cheers, > > Kevin D-B > > gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A > > ___ > 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: Honor assigning IPv6 address based on MAC address
Am 14.05.19 um 17:52 schrieb Roy Marples: > On 14/05/2019 14:29, Oliver Freyermuth wrote: >> Same here. In an automated deployment situation, client changes DUID in each >> phase: >> - PXE (if done via IPv6) >> - Installation time (from ramdisk) >> - Final OS after installation >> This may improve if newer versions of dhcpcd get packaged in installer >> ramdisks and OS, and also for systemd-dhcp, >> but I am still unaware of any implementation of machine-id as base for the >> client DUID in dhclient and of course the implementations are all not >> exactly the same. >> And then there is still the UEFI doing the PXE part, systems with broken >> machine-id etc And of course, dual booting if not set up with identical >> cliend-DUID. >> >> In general, my belief is that the RFC was made without real life use cases >> in mind and hence did not think of these. >> The patch is very helpful to overcome these issues and matches user >> expectation (when specifying a MAC address in the config file, I want it to >> be used). > > Speaking for dhcpcd (as yay, I am the author) - if the OS presents a stable > UUID dhcpcd will use that for the DUID: > > https://tools.ietf.org/html/rfc6355 > https://roy.marples.name/cgit/dhcpcd.git/tree/src/duid.c#n63 > > So a fully automated deployment using dhcpcd AND a kernel which reports a > stable UUID then all is good. There's also still another step that may cause an issue: If the UEFI also PXE boots via IPv6, it may present even another client DUID. It should certainly use the same UUID dhcpcd is using, but if it does not, you might be screwed (at least if your environment is IPv6 only). > > But not everyone uses dhcpcd>=7.0.6 with the UUID code in, nor a kernel which > reports a stable UUID. > > There is literally no reason to use dhclient anymore - and hasn't been for a > number of years. I fully agree (as a Gentoo user who has the freedom of choice). Somebody should teach those guys still shipping dhclient by default in their distro (e.g. Ubuntus network-manager package pulls in dhclient :-( ) or in their installer. And in our case, we are sadly not fully free in terms of choice of distro to use :-(. Cheers (and thanks again for the implementation in dhcpcd, and of course for dhcpcd itself!), Oliver > > Roy ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] DHCPv6: Honor assigning IPv6 address based on MAC address
Am 26.06.19 um 21:49 schrieb Pali Rohár: > On Saturday 11 May 2019 17:42:54 Kevin Darbyshire-Bryant wrote: >>> On 6 Apr 2019, at 12:01, Geert Stappers wrote: >>> >>> On Mon, Apr 01, 2019 at 01:02:20AM +0200, Pali Rohár wrote: On Tuesday 12 February 2019 13:41:43 Geert Stappers wrote: > On 06-02-2019 21:29, Pali Rohár wrote: >> On Friday 11 January 2019 17:52:43 Pali Rohár wrote: >>> On Monday 17 December 2018 18:41:09 Pali Rohár wrote: Currently IPv6 addresses are assigned to tuple (IAID, DUID). When system changes IAID/DUID then old assigned IPv6 address cannot be reused, even when in config file was DHCPv6 assignment based on MAC address (and not on DUID). >>> >>> ... >>> >>> Hello, can somebody look at this patch? >>> >>> I remember that more people asked for ability to assign IPv6 address >>> based on MAC address specified in config file, rather then IAID/DUID. >>> >> PING >> > Another request for > > Hey, could this patch get reviewed? > > Hello, can somebody review this patch? >>> >>> FWIW >>> >>> * The (four months old) patch does get applied cleanly. >>> * My compiler is happy with it >>> * Executable remains running upon start ( no early crash ) >>> * I'm unable to test the (new) IPv6 functionality >>> >>> >>> Where in the "patch pipeline" is Pali's patch? >>> >>> >>> Regards >>> Geert Stappers >> >> I’ve been using this patch to tame qnap’s frustrating dhcpv6 assignment >> limitations for many months. It’s immensely useful. >> >> >> Cheers, >> >> Kevin D-B > > So, could somebody review and comment my patch? Just to add on this: I'm also using this patch in production since over a month now and it works very well for me (with dnsmasq 2.80). Would really love to see this upstream. Cheers, Oliver > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > signature.asc Description: OpenPGP digital signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Add dhcp-ignore-clid configuration option
Hi together, Am 12.10.19 um 23:20 schrieb Simon Kelley: > On 10/10/2019 16:54, Florent Fourcot wrote: >> Hello Simon, >> >> >>> Of course, it involves enumerating the broken machines, rather than a >>> blanket setting covering everything, but that's probably a good thing. >>> It's what I wanted to provide with the tag extension I suggested, and >>> rather renders that redundant. >>> >>> What do you thin Florent? Is this enough, or would you like the new >>> blanket option as well? >> >> Thank you for the point on this option, I missed it before. However, >> iIterating on hosts is not really a solution for us, since it's customer >> devices (they appear/disappear out of our control, on a lot of sites). >> >> Moreover, in our context, MAC addresses are more relevant than clients >> identifiers, even for hosts with a valid identifier. Our networks have >> some checks on couple IP/MAC addresses consistency, and distributing an >> IP address previously in use with another MAC is probably a bad idea for >> this kind of tools. >> >> So, I'm still in favor of the blanket options. >> > > OK, I'm convinced. The patch is in. > > Many thanks. > > Simon. is this also applicable to IPv6, which suffers from similar issues? This could chime in well withe the patch posted earlier by Pali Rohár on this list. 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] [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
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
[Dnsmasq-discuss] Prefix delegation with DNSmasq
Dear DNSmasqers, I have a setup in mind and wonder whether dnsmasq is the correct tool (since I have not found the necessary functionality in the documentation yet). We have a /56 IPv6 network, and plan to use pure DHCPv6 (no stateless autoconfiguration) in several /64 networks. There are several subnets (currently NATed IPv4), such as — for example — a WireGuard VPN network, or a local isolated subnet. While with IPv4, the answer was the use of private addresses and NAT every time, potentially using a DHCP fowarder, for IPv6, the answer should be to use Global Unicast addresses everywhere (right?). How do I approach this correctly? Three options come to mind to handle such subnets: - Use ULAs and NAT (but that does not feel like IPv6...). - Delegate a prefix from the large network (where we'd use dnsmasq) to the "gateway" machine, which then would be a router. However, I am not aware if dnsmasq can delegate prefixes? - Use ProxyNDP (via npdpd or Linux kernel functionality). But I'm not sure if that scales well to a larger number of machines? - Use static routes on the central machine which send the /64 subnet to the "gateways" and use dnsmasq on the gateways. Am I missing something here, or should that "just work"? Is anybody aware of a best-practice guide here (please RTFM me)? Is dnsmasq the correct tool? Cheers and thanks for any guidance, Oliver ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Prefix delegation with DNSmasq
Am 12.04.20 um 19:01 schrieb Simon Kelley: > The first question is, how static are your global addresses? Making a > network which can survive renumbering is a lot more difficult than one > with known and fixed addresses. Luckily, they are completely static :-). Cheers, Oliver > > > Simon. > > > > On 12/04/2020 17:20, Oliver Freyermuth wrote: >> Dear DNSmasqers, >> >> I have a setup in mind and wonder whether dnsmasq is the correct tool (since >> I have not found the necessary functionality in the documentation yet). >> >> We have a /56 IPv6 network, and plan to use pure DHCPv6 (no stateless >> autoconfiguration) in several /64 networks. >> There are several subnets (currently NATed IPv4), such as — for example — a >> WireGuard VPN network, or a local isolated subnet. >> While with IPv4, the answer was the use of private addresses and NAT every >> time, potentially using a DHCP fowarder, for IPv6, the answer should be to >> use Global Unicast addresses everywhere (right?). >> How do I approach this correctly? >> >> Three options come to mind to handle such subnets: >> - Use ULAs and NAT (but that does not feel like IPv6...). >> - Delegate a prefix from the large network (where we'd use dnsmasq) to the >> "gateway" machine, which then would be a router. >> However, I am not aware if dnsmasq can delegate prefixes? >> - Use ProxyNDP (via npdpd or Linux kernel functionality). But I'm not sure >> if that scales well to a larger number of machines? >> - Use static routes on the central machine which send the /64 subnet to the >> "gateways" and use dnsmasq on the gateways. >> Am I missing something here, or should that "just work"? >> >> Is anybody aware of a best-practice guide here (please RTFM me)? Is dnsmasq >> the correct tool? >> >> Cheers and thanks for any guidance, >> 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] Prefix delegation with DNSmasq
Hi, thanks for the elaborate reply! Am 12.04.20 um 19:33 schrieb Uwe Schindler: > Hi > >> I have a setup in mind and wonder whether dnsmasq is the correct tool (since >> I >> have not found the necessary functionality in the documentation yet). >> >> We have a /56 IPv6 network, and plan to use pure DHCPv6 (no stateless >> autoconfiguration) in several /64 networks. > > That's perfect. Looks much like a standard German DSL account. 😊 In our case, even better, since the prefix is completely fixed and will never change ;-). > >> There are several subnets (currently NATed IPv4), such as — for example — a >> WireGuard VPN network, or a local isolated subnet. >> While with IPv4, the answer was the use of private addresses and NAT every >> time, potentially using a DHCP fowarder, for IPv6, the answer should be to >> use >> Global Unicast addresses everywhere (right?). >> How do I approach this correctly? > > That's very easy because you have a /56 net. > >> Three options come to mind to handle such subnets: >> - Use ULAs and NAT (but that does not feel like IPv6...). > > No no no, bad idea and very stupid for such a large network. That's what I thought :-). > >> - Delegate a prefix from the large network (where we'd use dnsmasq) to the >> "gateway" machine, which then would be a router. >> However, I am not aware if dnsmasq can delegate prefixes? > > This should all be done on the central router. For each subnet you have a > separate dnsmasq. Since we already have gateway nodes for IPv4, we'd rather scale the dnsmasqs out, but that does not seem to interfere with the proposed solution. > >> - Use ProxyNDP (via npdpd or Linux kernel functionality). But I'm not sure if >> that scales well to a larger number of machines? > > No need to do that (see below). ProxyNDP is only needed if you want delegate > some global addresses to devices that are in the same subnet but behind > another machine (MAC address). You don't need this. All can be done with > plain simple routing. I see :-). > >> - Use static routes on the central machine which send the /64 subnet to the >> "gateways" and use dnsmasq on the gateways. > > That's the way to go and it will just work! Explanation: > > The provider delegates a /56 prefix to you. How this is done depends, but for > DSL (dynamic) or also at Hetzner (static) the whole thing works on the link > level addresses. For DSL you have the PPP-Daemon wo gets a link local address > on the end point assigned. For DSL you get a prefix delegated using DHCP-PD > (prefix delegation), for static roulds (e.g., Hetzner) you get all traffic > routed to the link-local address of your router (that's coming from the mac > address of router known to provider). > > On the router you just assign the subnets and their primary address (:1) > to a separate interface or VLAN in portions of /64. The linux kernel will > then just automatically route all incoming packets from the WAN interface > (PPP or Ethernet) to the correct (virtual) network adaptor. On each of those > network adaptors you have a dnsmasq listening. There's a slightly more special case for us: We have one central firewall (which gets the full /56 net on the upstream interface routed to it) and most gateways are separate nodes (i.e. most VLANs are not connected to the central FW). So I believe in that case I just need an ip6tables rule (per /64 subnet) on the central firewall to redirect all traffic to the gateway for the /64 subnet, right? > Just some recommendation: I'd NOT go with DHCPv6, as no Chromebook or Android > device supports it. I'd go for SLAAC. Very easy. As you can setup a separate > /64 subnet (up to 256 of them), you have enough flexibility to handle all of > them in a separate network with full /64 SLAAC address space. Each of those > networks have firewalling on the router box and are delegate to the network > switch .e.g, via VLANs. I know (while I knew about Android, good point about the Chromebooks!). Our main usecase is addressing of Linux servers (i.e. there will only be "DHCP reserved" entries). Indeed, for a general purpose network (one of those /64s), we need to think whether we'll go with DHCPv6 (and lose Android and Chromebooks) or really stay with DHCPv6. For now, I'll plan with DHCPv6 ;-). Cheers and thanks, Oliver > If you are interested how to setup the Prefix Delegation with PPP, just ask. > The usual howtos seen on internet with wide-dhcpd are outdated and not very > modern and relying on a broken tool which should not be used anymore. The > correct way for that is "dhcpcd" client daemon listening on the PPP interface > and waiting for DHCP-PD packets. The dhcpcd config file can then > automatically split the delegated /56 network and assign it to various > real/virtual interfaces each with a /64 subnet, where a separate dnsmasq is > handling everything. No hacks needed, just plain routing on the bx (its > enough to enable
Re: [Dnsmasq-discuss] Prefix delegation with DNSmasq
Am 12.04.20 um 19:25 schrieb Simon Kelley: > I'd split your /56 into as many /64s as you need, and set up routing as > required (either static or using some routing daemon). Run dnsmasq > centrally, and use DHCpv6 relays to proxy DHCPv6 requests from the > router on each /64 network back to the central dnsmasq instance. Thanks! I presume the DHCPv6 relay on the gateway nodes (Linux servers in my case) could also be dnsmasqs with "zero configuration" apart from the dhcp-relay option, and enable-ra to force the local subnet to use DHCPv6, right? Cheers, Oliver > > Simon. > > > On 12/04/2020 18:20, Oliver Freyermuth wrote: >> Am 12.04.20 um 19:01 schrieb Simon Kelley: >>> The first question is, how static are your global addresses? Making a >>> network which can survive renumbering is a lot more difficult than one >>> with known and fixed addresses. >> >> Luckily, they are completely static :-). >> >> Cheers, >> Oliver >> >>> >>> >>> Simon. >>> >>> >>> >>> On 12/04/2020 17:20, Oliver Freyermuth wrote: >>>> Dear DNSmasqers, >>>> >>>> I have a setup in mind and wonder whether dnsmasq is the correct tool >>>> (since I have not found the necessary functionality in the documentation >>>> yet). >>>> >>>> We have a /56 IPv6 network, and plan to use pure DHCPv6 (no stateless >>>> autoconfiguration) in several /64 networks. >>>> There are several subnets (currently NATed IPv4), such as — for example — >>>> a WireGuard VPN network, or a local isolated subnet. >>>> While with IPv4, the answer was the use of private addresses and NAT every >>>> time, potentially using a DHCP fowarder, for IPv6, the answer should be to >>>> use Global Unicast addresses everywhere (right?). >>>> How do I approach this correctly? >>>> >>>> Three options come to mind to handle such subnets: >>>> - Use ULAs and NAT (but that does not feel like IPv6...). >>>> - Delegate a prefix from the large network (where we'd use dnsmasq) to the >>>> "gateway" machine, which then would be a router. >>>> However, I am not aware if dnsmasq can delegate prefixes? >>>> - Use ProxyNDP (via npdpd or Linux kernel functionality). But I'm not sure >>>> if that scales well to a larger number of machines? >>>> - Use static routes on the central machine which send the /64 subnet to >>>> the "gateways" and use dnsmasq on the gateways. >>>> Am I missing something here, or should that "just work"? >>>> >>>> Is anybody aware of a best-practice guide here (please RTFM me)? Is >>>> dnsmasq the correct tool? >>>> >>>> Cheers and thanks for any guidance, >>>>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] Prefix delegation with DNSmasq
Hi, Am 12.04.20 um 20:12 schrieb Uwe Schindler: > Hi, > >> thanks for the elaborate reply! > > No problem! and thanks again :-). > >> There's a slightly more special case for us: We have one central firewall >> (which >> gets the full /56 net on the upstream interface routed to it) and most >> gateways >> are separate nodes >> (i.e. most VLANs are not connected to the central FW). >> So I believe in that case I just need an ip6tables rule (per /64 subnet) on >> the >> central firewall to redirect all traffic to the gateway for the /64 subnet, >> right? > > It's important to don't have the /56 or /64 network assigned to an interface > on the router (otherwise you would need proxyNDP)! Noted. Indeed, that's reasonable, and achieved by design for those VLANs not connected to the central router ;-). > If it's prefix delegation, don't assign the 64 or 54 subnet to any interface > on the main router, just bring interfaces up and assign link-local-addresses > to them! On the central firewall just do routing with link-local addresses > (basically, this subnet goes to this adaptor and this mac address - as link > local addresses are basically MAC addresses). Of course the packet filtering > uses the global addresses, but the routing is done with link-local. > > The router box gets the packets from the provider all delegated to its own > link-local address of the upstream interface (that's what most providers do, > including DSL providers with PPP or servers in data centers like Hetzner). So > all incoming packets are sent to the same fe80: address based on the MAC > known to upstream or negotiated via PPP and the router just forwards them > based on the global address inside of the packets. In our case, they waste a dedicated /64 global address network for the connection network between our firewall and their endpoint... That also works, but it's rather wasteful of course ;-). > In the routing table of the main firewall you just add entries like global > subnetA/64 goes to link-local address fe80: on interface XY, and so on. > If you don't like the automatic assigned link-local-addresses based on the > mac interface you can easily change them. In my office I have the router > assigned fe80::1, you could assign fe80::2, fe80::3 to the secondary > routers's network interfaces and then routing tables look easy: > > 2001:abcd:1234:1::/64 => fe80::2@en1 > 2001:abcd:1234:2::/64 => fe80::3@en1 > 2001:abcd:1234:3::/64 => fe80::4@en1.24 (a VLAN #24 on en1) > 2001:abcd:1234:3::/64 => fe80::4@en2 (other network interface) > > Fe80::2, 3, 4 are the separate boxes which route the traffic and have the > dnsmasq. If you don't want to use fe80 link-local addresses, you can use > ULAs, but for routing purposes the link-local ones with interface name are > the easiest. Thanks, that example clarified it for me. Good thinking in using the link-local addresses here, that's completely sufficient. It really helps to talk about these things to clear up my mind from the IPv4 legacy of thinking. > > Another idea is to use one of the /64 subnets as the "inter-router" > communication, but that's not needed for IPv6, because we have > link-local-addresses for that purpose! > > On the internal routers you only assign the full global 64 subnet to the > client facing network adaptors. The connection to the router uses a > link-local address only (as described before). No additional firewalling is > needed, you just need to setup routing entries like above (the other way > round). Thanks, that cleared up my last question completely. Now I just have to explain my colleagues and we can start implementing that in the next weeks (in slow steps, but it seems much more straightforward than I thought) :-). >>> Just some recommendation: I'd NOT go with DHCPv6, as no Chromebook or >> Android device supports it. I'd go for SLAAC. Very easy. As you can setup a >> separate /64 subnet (up to 256 of them), you have enough flexibility to >> handle >> all of them in a separate network with full /64 SLAAC address space. Each of >> those networks have firewalling on the router box and are delegate to the >> network switch .e.g, via VLANs. >> >> I know (while I knew about Android, good point about the Chromebooks!). Our >> main usecase is addressing of Linux servers (i.e. there will only be "DHCP >> reserved" entries). >> Indeed, for a general purpose network (one of those /64s), we need to think >> whether we'll go with DHCPv6 (and lose Android and Chromebooks) or really >> stay with DHCPv6. For now, I'll plan with DHCPv6 ;-). > > No problem. You can have both, depending on subnet. > > Uwe > Cheers and thanks again, Oliver ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Boot file name not given (DHCP Option: 67 Bootfile name - is set but not used in PXE clients)
Hi, Am 08.03.21 um 00:42 schrieb Christoph Loesch: Hi, with dnsmasq (version 2.80 on current OpenWRT 19.07.7) I noticed following (in my opinion wrong) behaviour: when using the setting "dhcp-boot=/pxelinux.0,servername,192.168.1.123" the DHCP Offer/ACK packets sent do not contain the "Boot file name" in the header but "Option: (67) Bootfile name" is set. it's not "wrong" in my opinion, however, there are still many legacy / broken clients out there which don't conform to the DHCP standard completely, and only check the classic BOOTP headers. A noteworthy quite recent example is Grub2, which only learnt this in 2019: https://github.com/rhboot/grub2/commit/93289dc67c7e213b21df0eb09afea5e3b00ad7df#diff-93cd75cf8712d66c15ae5885f7cac5dae3531aaef211a17ef9885eb443ecdb0b Some DHCP clients, who read Option 67 can work with that, but some clients like PXE do not read that option therefor are failing for first tftp file rrq. As I could not find a git commit regarding a fix for this, I wanted to ask if someone can confirm (and/or possibly fix) this on recent dnsmasq version? I also have such legacy clients in use. The option "dhcp-no-override" forces dnsmasq to use the classic BOOTP headers. Note that in general, using the dedicated options for servername and filename is preferrable, since it allows to reuse the space in the headers for options, but if you have legacy clients (as we also have) you have to set "dhcp-no-override". Does this also solve your issue? Cheers, Oliver Kind regards, Christoph ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
