Subject: [Dhcpv6bis] Changing default DUID to DUID-LL?

From: Tomek Mrugalski <[email-masked]>
Date: Sat, 21 May 2016 18:58:16 +0200

I recall we did talk about this briefly, but I can't find anything
specific posted to dhcpv6bis.

Once in a while sysadmins keep asking why DHCPv6 is using DUID-LLT as
default, rather than just LL. Here's an example of such question asked
last week:
https://www.facebook.com/groups/2234775539/permalink/10154080188010540/
(if you don't have facebook account, you can still see the discussion by
clicking X comments link).

The details vary, but the general objection is still the same. There's a
large enterprise or similar organization and the sysadmin would like to
know DUIDs of the devices he's about to plug into his network to do host
reservation, access control or provide some options on a per host basis.
He can't do that without powering up every device and letting it
generate its LLT duid.

There are several twists to this. First, some people claim it's
difficult to extract generated DUIDs from many operating systems, so
cases where users themselves are expected to provide their DUID, even if
the device was booted up already, are problematic for users to handle.

Another objection is that most hardware these days have MAC address
printed on it. Vendors can't really print DUIDs as they are not known
during manufacturing phase.

As I understand it, the original rationale for using LLT rather than LL
as default was to avoid cases when switching faulty NIC would make the
client to change its DUID. This is very 1990s. If you disagree with
this, when was the last time you replaced faulty interface card? Also,
the mechanism we have right now - generate the DUID and store it -
effectively solves the concern.

So, what's your opinion on making the DUID-LL the default for regular
devices (i.e. those with clocks and stable storage for generated DUIDs)?

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 21 May 2016 17:32:47 +0000

Best to create a ticket for this issue? Perhaps we should also asking on
WG ML?

I think you are referring to the following text:

   This method of DUID generation is recommended for all general purpose
   computing devices such as desktop computers and laptop computers, and
   also for devices such as printers, routers, and so on, that contain
   some form of writable non-volatile storage.

FYI: Cablelabs already requires use of DUID-LL for Cable Modems (and I
think “eRouter” CPEs use them too, but would have to check).

I wonder whether a middle ground is just to remove this paragraph and
leave it unsaid which to use? There’s already a bunch of text that makes
it clear when one type should not be used (I.e., no stable storage or
time).

- Bernie

On 5/21/16, 12:58 PM, "Dhcpv6bis on behalf of Tomek Mrugalski"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>Dhcpv6bis mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcpv6bis

---

From: Ted Lemon <[email-masked]>
Date: Sat, 21 May 2016 19:43:12 -0400

I don't see the point--DUID-LLT and DUID-LL both contain the link-local
address, so if they want to track that, it's easy to do.   However, the
language has frequently been interpreted as being much more restrictive
than we intended when we originally wrote it, so I agree that this should
be updated.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 22 May 2016 12:33:15 +0200

>  Best to create a ticket for this issue? Perhaps we should also asking on

=> I join you: this is a design question so for the WG ML.

>     some form of writable non-volatile storage.

=> note the "recommended" is lower case so not a RFC 2119 keyword
(same about the equivalent text at the end of 9.4 DUID-LL).

I have a suggestion: change recommended by a equivalent term which
cannot be misinterpreted as a KEYWORD, and make the support of
DUID-LL a SHOULD or a MUST for clients which already support DUID-LLT
(i.e., leave admins the choice to use DUID-LL even with writable
non-volatile storage).

Thanks

[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Sun, 22 May 2016 14:12:12 -0400

Admin choice is inappropriate: DHCP is for automatic configuration. not
manual configuration.   It would not address the problem that we're talking
about, which really just boils down to ease-of-use: by requiring the admin
to set some setting on the client, we would be substantially damaging
ease-of-use.

You are right about "recommended" though--we could say "suggested" and
express the same intention.