Subject: RE: DHCPv6 address model proposal...

From: Bernie Volz <[email-masked]>
Date: Thu, 28 Sep 2000 16:05:54 -0400

I'm with Ted on this one ... I think it best to attempt to generate a unqiue
client id by not using the link-local or MAC address. At least, the unique
client id should not just be this with a few prefix bytes.

However, having said that, I have no problem in a client generating (with
some random component) a unique client identifier from the MAC address (or
link-local addresses) it may have and saving that in stable storage such
that it would use that in the future, regardless of whether one or more
interfaces is changed.

- Bernie

-----Original Message-----
From: Jim Bound [mailto:[email-masked]]
Sent: Thursday, September 28, 2000 3:35 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...

>> That means we can still use the link-local address if we want as
>> described in DHCPv6 as potentially part of the IA or at least keep in
>> the discussion.

>The link-local address changes when you swap network cards.  It is
>stable with respect to a piece of peripheral hardware, not with
>respect to an actual client machine.   For this reason, I am not at
>all enthusiastic about the idea of using it as a client identifier.
>If we don't strongly discourage its use, I am afraid that we will run
>into the same old set of problems we had with DHCPv4 with respect to
>client identifiers being tied to hardware.

I hear what your saying.  But I will use an argument you use often I
think?  How many clients of a 1000 node installation will change their
ethernet card within 6 months at Boeing?  Or at MIT?  I would say not
most.  

We are using the link-local address for all kinds of stuff now in IPv6
too.

But how about this strategy.

We clearly are going to change in the packets to having some IA
identifier.  What we can do is permit the link-local address with the
health warning you state above and have other options too.

But here is other idea for the IA to think about.  Organizations can
request a OUI (24bits) and we can then begin to add to that.  I believe
Multicast uses this now.

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 28 Sep 2000 18:13:30 -0400

I am with you and ted too.  

but what I am concerned about is getting a spec solution out by
december too.

not pushing the link-local address but as example.  for the link-local
the dhcp server can trust it is unique on a link and the prefix is
unique on a link.  no chance of duplication because of DAD and address
architecture in IPv6.

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?

Also what is the range that the IA is unique?
 1) link
 2) site
 3) global (I doubt we can figure that out in dhc)

We need to state how far the IA is unique for a dhcp server

In the current spec that is known.

That is why I brought up the OUI to Ted ????

/jim

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 Sep 2000 18:53:35 -0700

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