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... > >>>> <snip> > >>>> > >>>> 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: 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: 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 > >> Dnsmasqemail@example.com > >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > >> > > > > _______________________________________________ > > Dnsmasq-discuss mailing list > > Dnsmasqfirstname.lastname@example.org > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasqemail@example.com > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Pali Rohár pali.ro...@gmail.com
Description: PGP signature
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasqfirstname.lastname@example.org http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss