Subject: RE: Discussion: client identifier

From: Bernie Volz <[email-masked]>
Date: Tue, 10 Oct 2000 12:16:43 -0400

We have discussed this issue on the mailing list and I'm sure Ralph will get
around to publishing the discussion/summary soon. I suspect that there are
still several open issues related to this.

For the summary that Ralph wrote up, saying that we'll be using these two
items is correct. But a further summary of what these two items are is
hopefully coming.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Tuesday, October 10, 2000 12:02 PM
To: DHCPv6 discussion list
Subject: Re: Discussion: client identifier

> Summary: IAs will be identfied by a tuple: (UUID, binding-id).  UUID
> is a unique identifier for a DHCP client.

How are UUIDs assigned? How does a client determine its UUID? I'm
thinking in particular of:

1) machines that are plugged into the network for the first time
2) machines that have no stable storage, and thus can't store
   configuration information across system restarts.

As much as using a MAC has its disadvantages, it does have the
advantage that every interface has one, and its pretty much globally
unique. If one doesn't use the MAC, what will be used instead?

Or is the thinking that the default UUID for a node will be based on
the MAC address? What if that network interface is then taken out of
one machine and put into another? How will conflicts be resolved if
two machines create UUIDs derived from the same MAC address?

Thomas

---

From: Bernie Volz <[email-masked]>
Date: Tue, 10 Oct 2000 14:55:08 -0400

The binding-id was discussed several times to be 8 or 16-bit value. It was
probably in the earlier context of using 3-tuple (client identifier,
interface identifier, and binding identifier) that this size was discussed.

Personally, I like the idea of an opaque value (from 0 to 16 or so bytes)
but that wasn't liked by others because it made hashing and lookups more of
a problem.

Regarding the UUID, there were some discussions about that as well - at
least how to create it. Length again might best be variable (up to some
upper bound). I think the format should be something like a byte or word for
a type of UUID, followed by one or more fields depending on how the UUID was
generated. For example, if a serial number were used, these fields might
consist of a hardware type id followed by the serial number. Now, of course,
it would be best to use some sort of hash over this such that the data is
not meaningful to anyone to pull out these values easily.

But, agreed we need more detailed discussion to resolve both of these issues
- UUID and binding identifier.

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Tuesday, October 10, 2000 2:20 PM
To: DHCPv6 discussion list
Subject: RE: Discussion: client identifier

>still several open issues related to this.

Actually, what I published was what I took to be the resolution of the 
issue as it was developed in the course of the mailing list discussion.  I 
don't intend to summarize the discussion itself.  I mentioned an open 
issue: the size and shape of the UID and binding-id are TBD.  Thomas 
brought up another open issue: what does a client use as its UUID.

>items is correct. But a further summary of what these two items are is

I just reviewed the discussion - as far as I can tell, we decided on the 
two part identifier, (UUID, binding-id), and defined the binding-id as an 
opaque value chosen by the client.  I don't think we answered either of the 
two open issues listed above.  So, we need to resolve the two issues or 
document them as still open in the next rev of the spec...

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 10 Oct 2000 15:12:23 -0400

>interface identifier, and binding identifier) that this size was discussed.

Right - I read the final description as "an opaque value of undetermined 
size" and used that definition in the summary.

>upper bound).

In his original message, Ted mentioned the PXE algorithm, but I can't find 
any subsequent reference to a mechanism for specifying a UUID.  So I view 
that issue as open.  We also discussed variable versus fixed length UID, 
again, as far as I know, without consensus on an answer.

>  I think the format should be something like a byte or word for

Yup...

- Ralph

---

From: Bernie Volz <[email-masked]>
Date: Tue, 10 Oct 2000 17:26:16 -0400

I believe there was one additional clarification, perhaps by Thomas but I
could be wrong ... and that was to use a hash or some other encryption
method on the various techniques of creating the UUID to reduce the
likelyhood that any of the information could be used by someone seeing the
packets. The idea is that the value is unique to a client but should not be
usable to derive anything meaningful about the client.

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Tuesday, October 10, 2000 3:24 PM
To: DHCPv6 discussion list
Subject: Re: Discussion: client identifier

At 11:52 AM 10/10/00 -0700, you wrote:

>Ralph, we have a pretty clear specification for how a UUID is defined
>that Bernie sent to the mailing list.

I discovered the source of my confusion - Bernie's spec appeared in the 
address model thread, not in the client identifier thread.  I wrote up the 
summary with my "thread-blinders" on.

So, here's Bernie's specification:

1) If a client has previously stored a unique identifier in stable storage,
it MUST use this for all its interfaces.
2) If a client has unique identifying information (such as a serial number)
that it can use as a unique identifier, it MUST use this (after storing it
in stable storage if possible).
3) If a client does not have unique identifying information and it has
stable storage, it should generate a unique identifier by combining the
link-layer address of one or more network interfaces, padded with zeros at
the end to a total length of sixteen bytes, with a randomly generated
four-byte quantity, and compute an MD5 (SHA?) hash over this to produce a
unique identifier, and should store this identifier in stable storage.
4) Otherwise, the client must generate a unique identifier in a way that the
same value is likely to be generated each time it boots, such as by using
the link-layer address of one of their network interfaces as the client
identifer, and MUST use the same client identifier for all of their
interfaces.

And Erik's follow up:

 > 2) If a client has unique identifying information (such as a serial
number)
 > that it can use as a unique identifier, it MUST use this (after storing
it
 > in stable storage if possible).

For this to produce unique numbers you need to identify the number space
as part of the I-D. Otherwise two boxes made by two different vendors
might both have serial number 17.