Subject: RE: DHCPv6 address model proposal...

From: Bernie Volz <[email-masked]>
Date: Mon, 2 Oct 2000 11:02:54 -0400

I do think the wording below will need some rework. For example: "Clients
that have no stable storage MUST use 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."

If a client has other unique identifying information, such as a unique
serial number burned into memory it should use that and not any network
interface information. Therefore the "MUST" MUST be removed or changed to be
conditional.

I believe the rules should be:

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.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, September 28, 2000 9:54 PM
To: DHCPv6 discussion list
Cc: [email-masked]
Subject: Re: DHCPv6 address model proposal...

> How do we verify that a clients IA is in fact unique if it don't verify
> that with other clients?
>  a) on the link best case
>  b) with the servers dhcp domain?

The schemes that have been proposed for coming up with UUIDs
(Universally Unique Identifiers) rely more on reducing the chance of
collision to ridiculously low amounts than they do on any mechanical
process of guaranteeing that the identifier is unique.  I am pretty
sure that Windows has a UUID that is generated this way.   Computers
with serial numbers could use a vendor name plus the serial number.

I think the language in the draft should say something like "DHCP
clients SHOULD use a client identifier that will not vary as a result
of changes in network hardware and will be consistent between network
interfaces.  DHCP clients SHOULD NOT use the link-layer address of a
network interface by itself as a client identifier, but SHOULD instead
use some other identifier that is known to be globally unique - for
example, a combination of the CPU's serial number and manufacturer's
registered domain name.   DHCP clients that have no unique identifier
other than the link-layer address SHOULD combine 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.   Clients that have no stable storage MUST use 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."

This is rather convoluted, but I think it covers all the possible
cases where one could get into trouble.   The only case where we could
get into trouble is if two clients connected to the same link use the
HASH (pad16 (link-layer-addr) + random4) and wind up producing the
same hash value.   The reason for using the highly-structured formula
for producing the hash is to make this vanishingly unlikely, but I'm
not a crypto-geek, so I may have gotten it wrong.

We could also require the client to identify which of the algorithms
it is using in the first byte of the identifier, which would avoid
stupid collisions due to differing algorithms.

The language should also probably be made more readable - I'd be happy
to do this if people think this is a good set of methods to use to
generate the client identifier.

BTW, I am just talking about how to generate the common per-client
part of the identifier.  We also talked about the client combining its
per-client identifier with an additional per-instance identifier so as
to uniquely identify an address association, so that the client could
have more than one address association - e.g., for application-
specific situations or for clients supporting more than one interface,
or using DHCP to manage a care-of address as well as a home address.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Mon, 02 Oct 2000 12:55:19 -0700

> interface information. Therefore the "MUST" MUST be removed or changed to be

Oh, good point.

> in stable storage if possible).

It should compute SHA over this - we don't want to be using an
unmasked serial number any more than we want to use an unmasked
ethernet address.

> identifer, and MUST use the same client identifier for all of their

This sounds good!

			       _MelloN_

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 4 Oct 2000 18:34:53 -0700 (PDT)

Bernie,

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

   Erik