Re: [dhcwg] 3315bis question: Changing default DUID to DUID-LL?

[Ted Lemon <[e-mail]>]

On Mon, May 23, 2016 at 4:50 PM, Roy Marples <[e-mail]> wrote:

> First post here, so let me introduce myself.
> My name is Roy Marples and I've maintained dhcpcd for over 10 years.
>

Glad to have you here, Roy!


> This problem was also recently brought to my attention (dhcpcd uses
> DUID-LLT
> by default) by some people integrating NetBSD (where dhcpcd is the default
> client) into SmartOS as a VM.
> SmartOS filters DHCPv4 requests to ensure that the ClientID matches
> predictable
> values, and DUID-LLT is not this.
> I don't know off hand if they filter DHCPv6 in the same way.
>

Of course, the idea that there are "predictable values" for the DHCP client
identifier based on the link-layer address is totally mistaken, and in
violation of the specification.


> In the same way that DUID-LLT is not predictable or known before booting
> the
> host, neither is DUID-LL.
> Consider the host with virtual or hot plugged interfaces. Some hosts also
> randomise their MAC address each boot. Depending on when the client starts
> in
> the boot order a different DUID-LL (especially for parallel booting
> systems)
> could be used each time unless persistently stored. To make it predicable
> and
> known, the DUID-LL would be to be different per interface which I think
> defaults the original goal of determining host (DUID) and interface (IAID).
>
> I think that changing the default to DUID-LL just makes it worse for multi-
> homed users.
>

Exactly.


>
> Also, consider this text from RFC3315 Section 9.
>
>    Clients and servers MUST treat DUIDs as opaque values and MUST only
>    compare DUIDs for equality.  Clients and servers MUST NOT in any
>    other way interpret DUIDs.
>
> Given the use of MUST, I see no reason to change to DUID-LL use to save an
> admin time from booting a device to see the DUID being used or even
> bothering
> to parse it as a MAC address as that goes against the RFC.
> Instead, maybe encourage device makers to pre-assign DUID-LLT by
> performing an
> initial bootstrap of the client before shipping and printing this
> alongside,
> or even replacing, the MAC address.
>

Of course, that's the text I was talking about clarifying.   The point of
that text was to make sure that the entire DUID was used as a client
identifier, not a subset of it.   But it's totally fine to look in the DUID
to see what the link-layer address is, as long as you don't use _just the
link-layer address_ as a DUID.


> I'll note at this point that deriving the DUID of the host is hard - I
> don't
> know where it's stored on windows and some clients store a binary file
> with no
> easy means of viewing. For the dhcpcd case:
> $ cat /etc/dhcpcd.duid
> 00:01:00:01:1e:b9:6d:46:42:33:df:0b:4c:04
>

Is there really any need for that, though?   Once you're on the network,
the DHCP server knows the link between your IP address an DUID, so
registering the device is a simple matter of querying the DHCP server for
the DUID and matching that to the source IP address of the HTTP login (or
whatever).


> It could also be edited for big orgs to use a Vendor-assigned unique ID
> based
> on Enterprise Number, which I'm pretty sure satisfied the provisioning
> case.
>

I've never actually heard of anyone doing this, although I agree that you
are correct in theory.   :)