Hi!

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

On Monday 23 May 2016 22:01:40 Tomek Mrugalski wrote:
> People (in particular those people that run actual networks, but never
> come to IETF) complained about DHCPv6 being difficult to use, because
> DUIDs of new devices are unknown until the device is booted up. This is
> opposed to MAC addresses that are typically printed on the devices. This
> information could be used directly if the clients used DUID-LL rather
> than DUID-LLT by default. See forwarded email below for more details.
> 
> The proposal is tweak existing text in RFC3315bis to explicitly say that
> DUID-LL is the default (existing text suggested that DUID-LLT is the
> default if device has clock and a stable storage and that's how it was
> interpreted by most vendors).

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.

> Recently we discussed this on dhcpv6bis list. The responses were
> favorable, but there's strong agreement that change of this scope
> requires consensus in DHC WG. You can review the previous discussion on
> dhcpv6bis here:
> https://mailarchive.ietf.org/arch/msg/dhcpv6bis/0r50PZd_oGBtkzP3L3wRkBEqNUg
> 
> Two technical points were made:
> 
> 1. Bernie pointed out that Cable labs already requires using DUID-LL for
> cable modems.
> 
> 2. Ted pointed out that DUID-LL does not reveal anything more than
> DUID-LLT already does, so there's no problem from privacy perspective.
> 
> So, what's your opinion on this?

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.

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.

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

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.

So it can be quite easy if you spend a little time thinking about it.

Roy