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

Ted Lemon <> Tue, 24 May 2016 13:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F6CC12D70E for <>; Tue, 24 May 2016 06:28:19 -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 gkIGoMffYxYw for <>; Tue, 24 May 2016 06:28:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92E0C12D75A for <>; Tue, 24 May 2016 06:23:44 -0700 (PDT)
Received: by with SMTP id e126so6144452lfg.2 for <>; Tue, 24 May 2016 06:23:44 -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=Fspc+Sss/E9OhOoHIpeJk08bsJIJ2jknavG1cZ39amk=; b=RBt5lqtmo9KqcpYLJqTKs4mgcWdVtqs6mhWLvDaCxAgF10l95DKqGQmTq4GU3KBGr2 yrLsiyhPUBT5jEUyHsTEofjfU3qI5NcBFtCPQHjZAdyYzoWP/wuolcitaPp432Bl/g4J RzoVkMDKtjcyIgl53n6sSEQGGTIyaDac8u3q/mYuoWXUFVeQ89QbvjfKmRMGCvgzoOh3 NT2ttaBy4WXJXQkBFVFRgUkspubp9x3GbN3EhK8BR+ZN+y09fVfNotQr1t296p4j5OXh z3NsHmPXeBlWhMf9PMdsWKYg0YSzAGW4E72dyHI4dQvtjidJYR3QRuPxxdEaKCKebWqZ sLiA==
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=Fspc+Sss/E9OhOoHIpeJk08bsJIJ2jknavG1cZ39amk=; b=j2jhAZyDLI4i/QNVbRkELvtfiV1fI17PJgXyP7MmzCMifuWIXvHn6fHO4mxJHjygo/ JpfrbQuh1KL+UxCQXmRWKKu2jZrhu2WP2YVpj+E6/MC8Bds0Vt8rmHJpOd2BF9HGEI61 QPkF7quw9+v1knaduLwm+5cT/sI4GxWlGyaCK5zOsmYxdQa55Y2aBFJCf8eOKe4AwLBN HpFv2cHmYTX3R4L0GfVrIyw/1AmLgl2CA9QyggLicdpDA5l7clU6KK6e4OGYwca9P89C hkMcw1oVfT8wBOS8BAU5VY1kft/wZAW1i5926uYi9xYPpRcaxfsyzDWDKIJNxD3xB4ds 7O8w==
X-Gm-Message-State: ALyK8tLZtVdCviZDpzoBF308MWaPUsbQsAnO8tFFGBtBTHEDblEQaaCnpCuXiPpGeHQDM+BpNiK6X8OH/11AVA==
X-Received: by with SMTP id p134mr145152lfb.181.1464096222781; Tue, 24 May 2016 06:23:42 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 24 May 2016 06:23:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Ted Lemon <>
Date: Tue, 24 May 2016 09:23:02 -0400
Message-ID: <>
To: Simon Hobson <>
Content-Type: multipart/alternative; boundary=001a11400b4246c8a6053396773c
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: Tue, 24 May 2016 13:28:19 -0000

DUID-LL is specifically recommended for cases where the client has no
stable storage.   We are not proposing to change that.

Your printer example is a really good one, though.   I think the answer is
to do what most printers now do, which is to use mDNS to register the
printer, and do the authorization part from an already-authorized devices.

And yes, captive portals absolutely suck.   The O.S. should not tell
clients that the network is available before there is connectivity.   We
have better signaling mechanisms for captive portals now, but unfortunately
they are very new and nobody (AFAIK) implements them yet.

On Tue, May 24, 2016 at 5:48 AM, Simon Hobson <>

> Ted Lemon <> wrote:
> >> 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.
> But meanwhile, in the real world, many many people have workflows that
> require them to be able to identify equipment before it's plugged in. In
> this sense, it can be argued that the specification is in violation of real
> world needs.
> Though in this case, I'd agree that the implementation is wrong.
> >> 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.
> IMO, a device which has no persistent storage, and which uses a random MAC
> is not manageable by any system that relies on being able to identify a
> client - without using device class specific tools (like all those devices
> that can only be managed by the vendor's proprietary, and usually Windows
> only, programs) !
> Virtual devices are another class - but do you have any example of such a
> device that has no persistent storage ?
> Are we in danger of sacrificing functionality for many in pursuit of
> unattainable perfection ? There will always be corner cases, but the
> requirement for a "single homed device, with known MAC address, and a
> workflow already setup to capture that MAC address" is (going by the
> discussions here) very real - and would be serviced by using DUID-LL as
> default.
> >> I think that changing the default to DUID-LL just makes it worse for
> multi-
> >> homed users.
> Does it ? Assuming the device has persistent storage then once it's
> generated a DUID it'll keep that. So there is really no change in terms of
> functionality - only a very very very small chance of a clash if MAC
> addresses aren't unique.
> I strongly suspect that devices using virtual NICs (eg virtual hosts)
> aren't using DUID-LL[T] and so the change would not affect them.
> > 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.
> > 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 don't think clarifying is the right word. I cannot see any *reasonable*
> interpretation of that text other than "this is an opaque blob and you can
> only use it as an exact match to some other opaque blob". As a DUID-LL (and
> more so, DUID-LLT) is not the same thing as a MAC address, this text very
> clearly and explicitly prohibits matching the MAC address with the contents
> of the DUID.
> For "clarify", I think you mean "significantly change" :-)
> > 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).
> While that may work for some classes of device - eg a "computer" with a
> browser where the user lands in a captive portal until they've registered
> their device* - I don't think that's a valid statement for the general
> case. I strongly suspect the use case driving this is something like :
> User/department/whoever gets a new printer. When it gets added to the
> network, network services need to ensure it goes to a sensible IP address
> and that relevant systems know about it so it can be used.
> In the IPv4 world, as long as it's MAC is known (usually printed on the
> box, or at least on the device), that can be configured into DHCP to give
> it a known address, and from there it can be configured etc.
> If it uses a predictable DUID (eg DUID-LL and the MAC address is known)
> then much the same process applies for IPv6 - and not much change to long
> established workflows are needed to support IPv6. If the DUID is not
> predictable then "some other means" is needed to find the device - using
> systems (DHCP server) that by design do not capture any known attribute of
> the device.
> So the problem is easily stated. In a system where you have no knowledge
> of the IP address, and no knowledge of the DHCP identifier, how do you find
> and configure the new device ?
> I suspect the answer comes back to : find out it's MAC address (the
> workflow captured it for the IPv4 config), then query a local device on the
> network for it's neighbour cache, and find the IP address from that, and
> only then can we query the DHCP server to find out it's DUID. That's a
> massive change to the workflow.
> BTW - I have first hand experience of the problem in assuming that devices
> can be "registered" by using a portal or similar. A few years ago we (at
> work) were involved in something or other (I vaguely recall is was some
> sort of "design and build" project day for local schools) hosted at a local
> hotel. I wasn't involved in any pre-event stuff, but someone else had been
> told by the hotel that "yes we have wireless internet available".
> Only problem was that access to it was by tickets and registering the
> device in a captive portal. This meant that we couldn't connect a printer
> to the network, and all printing ended up being by sneakernet. In hindsight
> there were probably other issues, but the key thing is that the system was
> designed on the assumption that every device needing to use the network was
> of a certain class - and that meant it didn't work for other classes of
> equipment.
> * These are also really really annoying in that there's a gap between my
> laptop having "a connection" and getting past the captive portal. During
> this period, various bits of software (eg email clients) start spewing out
> security warnings as secure connections fail due to being redirected to the
> portal which (of course) lacks the right security certificates.
> _______________________________________________
> dhcwg mailing list