[Dibbler] Content of duid
thomson at klub.com.pl
Tue Jun 26 19:38:57 CEST 2012
On 26.06.2012 18:05, Simon Hobson wrote:
> There was a 'fairly heated' discussion over on the ISC DHCP Users List
> not too long ago about DUIDs. As I recall, opinion seemed to be divided
> into those who believe that the use of MAC addresses is evil and we
> should all be using DUIDs - and those who think that in the real world
> the MAC address is no worse (and potentially better, less volatile,
> commonly available before a system is connected and turned on) than most
> DUIDs, and necessary for anyone trying to track equipment.
Yes, and there was a similar discussion on dhcwg list in IETF that
mostly replayed the arguments. The vague suggestion was to revert the
recommendation "prefer DUID-LLT over anything else" in RFC3315 into
"prefer DUID-LL" in RFC3315bis. There is another thing that could be
mentioned in that contest - a hardware option defined in
draft-halwasia-dhc-dhcpv6-hardware-addr-opt. Actually, there is a call
for adoption in dhcwg list announced for it today. A side note: If you
think that is a good idea (I do), please say so on dhcwg.
> If you read the relevant RFCs, it is expressly forbidden to look into
> the DUID even though it's format is defined. Eg, if the client is using
> DUID-LL or DUID-LLT then it's forbidden to extract the MAC from that. I
> believe that most clients don't use DUID-LL or DUID-LLT anyway.
Yes. And Dibbler follows that rule. In every place where client is
referred, you can specify client's DUID, not its MAC address. There is a
work in progress to support reservations based on link-local addresses.
In some cases that will be equivalent to MAC, but not in all (I think it
will fail if client uses privacy extensions).
> For the OP, the RFC is very clear - you cannot under any circumstances
> use the DUID (of any type) for anything but a straight match. In
> practical terms, that means you'll need to power up and connect the
> client, see what DUID it comes up with, and then you can copy/paste that
> to match against. You can only match against the whole thing (ie
> <something> == <something else>) and not look inside it (ie
> substring<something>,... == <something else>).
That is very unfortunate. My understanding is that it is a primary
driving force for hardware-addr-opt draft.
> Bear in mind that the RFCs specify that DUID-LLT and DUID-LL should only
> be used by the client where there is no persistent storage (and for LL,
> no clock either). For many devices, if the user were to reset it or
> re-install the OS etc, then the DUID may well change. On many devices,
> the user may well be able to easily change it - more easily than
> changing the MAC.
The DUID-LLT has other side effects that are problematic. If you have a
server that supports remote management with dual-boot, your preboot
environment will generate one DUID, your Windows will use second and
Linux will use third. So you may end up with one box that uses 3
different DUIDs. From that perspective DUID-LLT is not good.
I have implemented support for various DUID types in dibbler-client,
mostly because I think it is sometimes convenient to use something else
than DUID-LLT. Obviously, DUID-LLT is the default, so unless (a
concious, hopefully) user switches to something else, consequences are
There's another DUID type, called DUID-UUID. I don't know how to read
UUID (and do it in a portable way). If someone is willing to help me
with this or even better, donate some code, I will implement DUID-UUID
support as well.
More information about the Dibbler