Subject: [dhcwg] I-D Action:draft-narten-dhc-duid-uuid-00.txt

From: Ted Lemon <[email-masked]>
Date: Fri, 28 May 2010 13:18:12 -0700

FYI...

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Definition of the UUID-based DHCPv6 Unique Identifier (DUID-UUID)
	Author(s)       : T. Narten, J. Johnson
	Filename        : draft-narten-dhc-duid-uuid-00.txt
	Pages           : 5
	Date            : 2010-05-28

This document defines a new DHCPv6 Unique Identifier (DUID) type,
called DUID-UUID.  DUID-UUIDs are derived from the already
standardized UUID format.  DUID-UUID makes it possible for devices to
use UUIDs to identify themselves to DHC servers and vice versa.
UUIDs are globally unique and readily available on many systems,
making them convenient identifiers to leverage within DHCP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-narten-dhc-duid-uuid-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 May 2010 13:27:09 -0700

Instead of this:

>    Many UUIDs are in use today.  For example, they are used in
>    Microsoft's Component Object Module (COM), and for labeling
>    partitions in filesystems.  In order to identify a system
>    consistently within DHCP, however, it is important to choose a UUID
>    that will remain constant across system reconfigurations and other
>    system changes, and to choose a UUID that different system images and
>    boot stages will have easy access to.  This document recommends
>    selecting a UUID that is part of the system firmware.

May I suggest this?

   Although many UUIDs are in use today, not all UUIDs are consistent with
   the requirements of the DHCP protocol.  For example, UUIDs used in
   Microsoft's Component Object Module (COM), and for labeling
   partitions in filesystems, may not be accessible to firmware boot loaders,
   and can change over time.

   Implementations of this specification MUST use a DUID that is persistent
   across system reconfiguration events, and that is available to all DHCP
   protocol agents that may need to identify themselves.   For instance, a DUID
   that is part of the system firmware, or managed by the system firmware, would
   satisfy this requirement.

I don't know if this is necessarily the right way to say it either--I just want the language to be a bit stronger.   Otherwise people will interpret this as loosely as they wish to.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 28 May 2010 16:34:02 -0400

Hi Ted.

Thanks for your comments.  I agree. The language surrounding which
UUIDs to use is important. Most are not really suitable as you say and
the language needs to strongly encourage the right kind of usage. I
like the thrust of your suggested rewording.

Thomas

---

From: Andre Kostur <[email-masked]>
Date: Fri, 28 May 2010 14:00:44 -0700

Hi Thomas.

I'm not entirely sold on the justifications for the new DUID type.  As part of your justification you mention the use of multi-stage loaders.  Even with the existence of DUID-UUID you could still be left with occasions where different stages of the boot loader may use different DUIDs for each stage, such as currently existing BIOSes using something like DUID-LL for the first stage, and then loading an OS which supports DUID-UUID.  You still have the problem of two different DUIDs for the same device.

Secondarily you discount the use of DUID-EN as being inherently proprietary.  Does it being proprietary matter as long os the DUID is consistent?

On 2010-05-28, at 1:34 PM, Thomas Narten wrote:

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

--
Andre Kostur                      P: 604-678-2864
Senior Product Design Engineer    F: 604-678-2864
[email-masked]             SIP: [email-masked]
http://www.incognito.com

http://www.incognito.com/uc

---

From: Thomas Narten <[email-masked]>
Date: Fri, 28 May 2010 17:21:46 -0400

Andre Kostur <[email-masked]> writes:

> I'm not entirely sold on the justifications for the new DUID type.  As
> part of your justification you mention the use of multi-stage loaders.
> Even with the existence of DUID-UUID you could still be left with
> occasions where different stages of the boot loader may use different
> DUIDs for each stage, such as currently existing BIOSes using
> something like DUID-LL for the first stage, and then loading an OS
> which supports DUID-UUID.  You still have the problem of two different
> DUIDs for the same device.

You are right. Defining a new DUID doesn't (by itself) solve the
problem of multistage loaders using different DUIDs. But as stated in
the document, the two other common types (DUID-LLT and DUID-LL) have
the problem that if the device has multiple interfaces, there is no
way to guarantee predictability in what gets chosen. So there is a
problem here, at least for some deployments.

I have been talking to the UEFI folk about this document and hopefully
they will chime in. But one possibility is that the early stage
booting steps would default to DUID-UUID. Later stage booters are
(generally) more under the control of the sys admin, so they may be
able to ensure DUID-UUID gets used as well.

The UEFI folk already have the problem that they need to pick a
particular DUID to use. Life was simpler in DHCv4 when there was only
one identifier...

> Secondarily you discount the use of DUID-EN as being inherently
> proprietary.  Does it being proprietary matter as long os the DUID is
> consistent?

DUID-EN (and anything using an Enterprise Number) is really intended
for stuff that is not of general utility and proprietary in nature.

Given that UUIDs alread exist (and apparently are quite widely used --
google around a bit!), it seems natural to just reuse them.

This is especially true with x86 (and I believe OpenFirmware too, but
I haven't confirmed this) where every system comes with a UUID that is
ready to go, just begging to be used. :-)

Folk may want to go back and reread the thread that outlines some of
the background motivating this draft. There is some good background
info there surrounding the problem space that this document is aiming
to address.  I think DUID-UUID may be a useful tool to add to DHC. It
won't be needed (or used) by everyone, but it seems like a reasonable
option to have on the table.

http://www.ietf.org/mail-archive/web/dhcwg/current/msg10192.html

Thomas

---

From: Jarrod Johnson <[email-masked]>
Date: Fri, 28 May 2010 21:59:31 -0400

On Fri, May 28, 2010 at 5:00 PM, Andre Kostur <[email-masked]> wrote:

> Hi Thomas.
>
> I'm not entirely sold on the justifications for the new DUID type.  As part
> of your justification you mention the use of multi-stage loaders.  Even with
> the existence of DUID-UUID you could still be left with occasions where
> different stages of the boot loader may use different DUIDs for each stage,
> such as currently existing BIOSes using something like DUID-LL for the first
> stage, and then loading an OS which supports DUID-UUID.  You still have the
> problem of two different DUIDs for the same device.
>

For DUID as architected, the possibility is unavoidable with this field, as
each client entity is given free reign to choose as they wish.  The only
'fix' for that would be a secondary field allowed for identity where all
parties involved simply have no choice in the matter (like chaddr in DHCPv4,
which I'm not opposed to, but even if approved, it's non-trivial for
end-users to add to current released DHCPv6 platforms).    The intent in
DUID-UUID would be that firmware has a blessed approach based on a current
ubiquitous standard that the OS vendors can elect to use.  As a bonus,
Windows, dhcp6c, and ISC dhclient all can be trivially 'retrofitted' using
existing tooling by administrators without requiring OS vendors to change
policy, though all of those can make it easier for administrators to select
their preference.  Self-managed entities may prefer DUID-LLT if they
consider their hard drive to be more persistent than the hardware that
contains it), whereas centralized scenarios may want to dictate DUID-UUID
for consistency.  The hope here would be that it is sufficiently within the
administrators control to restore some of the predictability/stability of
DHCPv4 without compromising the goals of DUID.

Incidentally, I have seen coreboot has DHCPv6 and uses a different DUID-LL
for every NIC it would hit, which I took to be a relative no-no in RFC-3315.
 This would be an approach more trivial to do and keep with the 'SHOULD's of
RFC 3315.  Maybe they won't be helped today, but any 'fix' to the problem
would require a firmware update anyway regardless of the solution (short of
dhcp servers/relays capturing the layer 2 header and restoring DHCPv4-like
behavior, but that's a relatively taller order than the job of DHCP servers
today).

> proprietary.  Does it being proprietary matter as long os the DUID is

It's feasible with systems where the same vendor controls everything (AIX on
POWER, OSX on Apple, most any embedded scenario), but difficult in an area
like x86 or Linux on POWER/Itanium/Sparc/whatever.  One permutation might be
IBM written firmware implementing interfaces specified by Intel, with a
bootrom provided by Broadcom handing off to an OS by Microsoft.  DUID-EN
could be made possible if firmware dictated it and started ramping up
standards to share that, but the idea here would be that a firmware
maintained UUID is already good to go as implemented in VMware, BIOS, UEFI,
qemu (including kvm), IPMI, CIM, IBM Bladecenter, Windows, Linux and
probably tons of standards I have idea about.  Consequently, UUID already
must be tracked for many other reasons anyway, implementing DUID tags on top
of that means many management scenarios would required tracking both UUID
and DUID independently, which is just another complexity.

---

From: Jarrod Johnson <[email-masked]>
Date: Fri, 28 May 2010 22:15:20 -0400

> particular DUID to use. Life was simpler in DHCv4 when there was only

There were more, but most of the people struggling with DHCPv6's DUID
largely ignored that and simply keyed off the chaddr inherited from B

> ready to go, just begging to be used. :-)
At least in POWER Blades, the AMM is given a platform UUID by the FSP.
 Whether the FSP generates that for the sake of Bladecenter management or it
is managed by openfirmware I don't know yet (i.e. I haven't found an
openfirmware property containing that same data).  Openfirmware standards
may elect to incorporate it when they implement DHCPv6 to gain the
bootp-like behavior, or they may elect to go a different way if they don't
feel particularly invested in UUID. x86 architecture at least is heavily
invested in UUID, so it simply makes massive sense there.

> http://www.ietf.org/mail-archive/web/dhcwg/current/msg10192.html

There are several like that, without common boot firmware, the lack of
predictability of DUID-LLT is the chief pain, and DUID-UUID may serve as a
path to alleviate that without the more controversial chaddr.   The lack of
consistency between boot firmware and OS will become the next pain as it
stands (you can find a few threads already about DHCPv4  PXE roms 'messing
up' DDNS and lease consumption due to lack of OS and firmware coordination
on client-identifier, a whole new mess of issues will come up without
anything consistent to hold it together for the users that either didn't do
ddns before or used static reservations to sidestep the whole situation when
faced with DHCPv6 where chaddr isn't there to fall back on).

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 May 2010 01:22:36 -0700

On May 28, 2010, at 2:21 PM, Thomas Narten wrote:
> problem here, at least for some deployments

This isn't really accurate.   DUID-LLT is just a way of generating a unique identifier.   If you store it in the boot prom's nvram, it would be as available to everybody as the proposed DUID-UUID.   Since it's intended to be persistent, not to be generated on the fly every time, its value shouldn't vary.

I say this not to say that DUID-UUID is a bad idea, but simply to clarify the intended use of DUID-LLT.

---

From: Jarrod Johnson <[email-masked]>
Date: Mon, 31 May 2010 09:15:15 -0400

On Mon, May 31, 2010 at 4:22 AM, Ted Lemon <[email-masked]> wrote:

> This isn't really accurate.   DUID-LLT is just a way of generating a unique
> identifier.   If you store it in the boot prom's nvram, it would be as
> available to everybody as the proposed DUID-UUID.   Since it's intended to
> be persistent, not to be generated on the fly every time, its value
> shouldn't vary.
>

True, however in practice in x86 world, OS puts DUID-LLT on hard drive for
lack of firmware managed storage available/coordinated with.  Making
firmware manage arbitrary DUID storage would be an approach that is
theoretically a way of getting at the same goal, DUID-UUID is a means to
reuse a particular piece of info already central to many standards (at least
on x86) that happens to exhibit the characteristics that are desired in a
DUID.  It allows a large customer set to 'fix' some differences they
currently experience betwen v4 and v6 (They can manipulate current OSes to
use current firmware-provided data for a DUID) as well as having DHCPv6
require less updates of fewer standards as more firmware embraces it.  I
know you weren't saying it was a bad idea, and maybe I'm rehashing some
stuff in the thread, just wanted to be clear on what I'm hoping to get out
of it.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 May 2010 09:51:05 -0700

On May 31, 2010, at 6:15 AM, Jarrod Johnson wrote:
> Making firmware manage arbitrary DUID storage would be an approach that is theoretically a way of getting at the same goal, DUID-UUID is a means to reuse a particular piece of info already central to many standards (at least on x86) that happens to exhibit the characteristics that are desired in a DUID

Right, that makes sense.

In any case, the main intention of the language on DUIDs in RFC3315 was to make sure that they had certain characteristics: persistence and uniqueness.   Any DUID that has these qualities is perfectly fine from the perspective of RFC3315.   The only reason _not_ to allow a new DUID for which someone has a clear use case is that it doesn't have these qualities.   So this proposal seems reasonable to me.