Kai Meitzner
On 14/02/2019 14:35, Tomek Mrugalski wrote:
On 14.02.2019 12:20, ѽ҉ᶬḳ℠ wrote:
Though perhaps a bit off topic, please bear with me, I have been
wondering about DUID in ipv4 since thought that it would be only
applicable to ipv6?
That was the original idea. But then the reality kicked in. The primary
use case for DUIDs in ipv4 is to be able to match requests coming from
dual-stack devices.

To my understanding the DUID would be provided by the dhcp client but I
have not found way to figure the clients's ipv4 DUID, all linux distros,
in order to use it for host reservation. Neither iproute2 nor ifupdown2
seem to provide that information. Is there a way to harvest those ipv4 DUID?
Not sure. If the client supports it, as a last resort you can capture
the traffic and extract its client-id option. That's not exactly a
convenient way, I admit that. I found a discussion about it on systemd
github: https://github.com/systemd/systemd/issues/394. It mentions some
pull requests that apparently were merged. You may want to look around
that area and see if anything comes up.

Tomek


The current dnsmasq ipv4 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?
Suppose such client identifier would be matching client-id in the Kea conf?

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.

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 reservation matching. My network management preference though is ifupdown2.
_______________________________________________
Kea-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users

Reply via email to