On 14.02.2019 15:37, ѽ҉ᶬḳ℠ wrote: > The current dnsmasq ipv/4/ leases (still in place) supposedly showing > client identifier, e.g. > ff:a9:13:fb:9b:00:02:00:00:ab:11:f0:18:bd:02:af:a5:19:a1. > Perusing online resources has not cleared up for me whether there is a > correlation between DUID and client identifier, some sources hinting the > client identifier containing the DUID? Client-id MAY contain DUID. Clients (presumably dual stack) that support this optional extension may use DUID with some extra information as client-id. See RFC4361 for details, especially section 6.1. In principle Kea supports that, but I think it was never thoroughly tested.
> Suppose such client identifier would be matching */client-id/* in the > Kea conf? Kea can be told to match client-id (the whole option) or duid (a subset of the client-id option), depending on your configuration. See host-reservation-identifiers and some examples of host reservations. > Since client-id spoofing would appear more difficult than mac spoofing I > would probably prefer client-id. Just have to check whether client-ids > are indeed ephemeral. Depends on what you're using to spoof it. It's a configuration option in dhclient. > Seems a bit a of cumbersome way to run first a dhcp server to gather > client-id/DUID from its linux clients to utilise such for host This complaint that is over 15 years old now. If you're really interested in the bottom of this, here's a bit of DHCP history. The concept of DUID was created back in around 2000. The problem people working on a spec that eventually became RFC3315 wanted to solve was a failure of NIC cards. In the 90s network cards were failing sometimes and when replaced, the host appeared as completely new device. So they thought a new type of identifier is needed that would survive changing a MAC address. DUID can do that. And it's about the only thing is does great... Now, fast forward to more recent times when network card failures is a rare event. On the other hand, we have VMs being cloned (with the same DUID appearing on two clones), we have dual boot devices (which each OS using different DUID) and then there are PXE devices that may use different DUIDs for each stage. Even in the simplest of cases - a laptop being booted for the first time - a vendor can't print DUID on the box the same way they print MACs, simply because the DUID is usually created on the first boot. What's more there are currently 4 different types of DUID defined and in actual use: LLT (MAC address + timestamp of first boot of the device), LL (just MAC address + some fixed, well known duid type), EN (vendor assigned) and UUID. RFC3315 preferred LLT. When IETF was updating DHCPv6 spec, we tried to alleviate the problem and RFC8415 no longer says that LLT is the default choice, but there's no easy solution after 15 years of implementations. Personally, I would say the concept of DUID didn't withstand the trial of time well. > reservation matching. My network management preference though is ifupdown2. As Jason has suggested, please consider simply using MAC addresses. You can tweak Kea DHCPv6 to look at MAC addresses. I admit that those are not directly available in DHCPv6, but there are several modes of extracting them from incoming packet. This has been implemented many years ago and I don't remember anyone complaining about that. For details, see https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#mac-in-dhcpv6 Another aspect you may possible look at to let you make a better DUID vs MAC decision is a mechanism defined in RFC6939. It makes client's MAC addresses available to the DHCPv6 server. It requires relay to support it, but that's easier to do than upgrading your clients. Hope that helps, Tomek _______________________________________________ Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
