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

Ted Lemon <> Mon, 23 May 2016 21:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DFC312DBD4 for <>; Mon, 23 May 2016 14:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V7_XtPGYJ5lV for <>; Mon, 23 May 2016 14:33:59 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 912F112DBF9 for <>; Mon, 23 May 2016 14:33:57 -0700 (PDT)
Received: by with SMTP id e130so42517570lfe.3 for <>; Mon, 23 May 2016 14:33:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KIRTKSXMyUUhWcmJarE/J8wVMDr3nCHMyNTupeSvM58=; b=h2y4nMqgM7U/N6tQKD+MZoT69idCKrZYAVYygB9Ft1yEJh9pORGaSM5lYKRusuag7b K2LjN8MJk9HOHIdTzdMWNv1stCtfN+8QTmNlRUq1tUrOPfCbggqxU/6prKLmGunwnlTA jITrm1MKewhEm3YA+apNXnemxkeeA54ub/OKA1XuW0PM6xnm6JT2qKliQkewIXcDEeEs 1lQAnM2H12z7xgIxeJF0d4/+4FVdkZhUSUKGP4VopDeSAkvjmfnu3hv4FMk2djEWN7kJ ogQ4t1eC77GXmN7pTP1tQdyqoWRzMQ43KX0orKgMmMAi+Emw5ZG0QYDmLFzIiM+3oCiG 35KA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KIRTKSXMyUUhWcmJarE/J8wVMDr3nCHMyNTupeSvM58=; b=JBwhOkrheLV62xdP0GlB0u8i96T401Dn+NVerYrku096+iGWqQC7tv4lJotIsEeA+3 7bGyJ1MIdZGw94tCLrsh2IL4+M1KFTALJeSofkKVNZFGmzCuiiSoc5k/GGSlHAcHOLvB NQPogt0E9s3aCD25aovW9wPnWAruuU0UmFmyjs6jy/VLUWX+gAZ4LQ5b6qegJB0Bxui2 eBJgG5krh+BMoSdImag7sIGbane5+l+iDySwiHr8zQbCnjXxH7Cyinbi510LqnB1LYDY RmYyA9MSFi9QhTmVUdzWRrSEnZoEFkbg718BjmNl1QLDgcIsMBxWsF0oJRfZtn179PPC ORpg==
X-Gm-Message-State: AOPr4FVwPDv0EiG8SuASG9/cBBScOzCjRIYY+2NStcfeHkiodtBuFUxO5uzfwla88rd+ZzhA0HprfFKc14WISw==
X-Received: by with SMTP id t19mr6859308lfd.109.1464039235691; Mon, 23 May 2016 14:33:55 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 23 May 2016 14:33:16 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Ted Lemon <>
Date: Mon, 23 May 2016 17:33:16 -0400
Message-ID: <>
To: Roy Marples <>
Content-Type: multipart/alternative; boundary=001a11401faa94c3ae0533893235
Archived-At: <>
Cc: dhcwg <>
Subject: Re: [dhcwg] 3315bis question: Changing default DUID to DUID-LL?
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 May 2016 21:34:01 -0000

On Mon, May 23, 2016 at 4:50 PM, Roy Marples <> 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
> 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.


> 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

> 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.   :)