Subject: DHCPv6 client identification...

From: Ted Lemon <[email-masked]>
Date: Wed, 06 Sep 2000 00:44:39 -0700

We had a nice discussion about client identifiers during the
conference call.  The issues that I remember us talking about are:

	(a) Giving a DHCP client a unique identification that does
	    not change when network hardware changes
	(b) Providing a way to identify more than one instance of
	    usage (I called these identity associations in my message
	    about the DHCPv6 address model) within an individual client.
	(c) Providing a way for the server to tell that two identity
	    associations actually represent one client.
	(d) Providing a way to have a single authentication
	    key work with all of a client's identity associations.

For (a), we seem to have pretty much agreed that we need a
universally-unique identifier, similar to what Intel has done in the
PXE specification.

We can solve (b) by having the client come up with more than one
UUID.   However, to solve (c) and (d), it would be better if we
defined a way to have the DHCP client specify a UUID and then specify
a modifier to that UUID, so that the identity association would
actually be made up of {modifier, UUID}.   Authentication would be
done based on {UUID}, not on {modifier, UUID}, and the server could
therefore tell that two identity associations are the same client by
noticing that although the modifier is different, the UUID is the
same.

In order to avoid creating the possibility of namespace clashes, I'd
suggest that we specify the modifier as a 16-bit number, defined by
the client, that's just an index.   So if a DHCP client had two
network interfaces, its two identity associations would probably be
{0, UUID} and {1, UUID}.

There is one problem with this: if the DHCP client is not consistent
about assigning prefixes, it would be possible for it to assign {0,
UUID} to one network interface one time, and {1, UUID} to that network
interface the next time.   This shouldn't be a huge problem for a
typical client, but for fancy clients the client implementor might
want to actually maintain its own mapping between the network hardware
address and the index.

It might also make sense to have the modifier be an 8-bit interface
index and an 8-bit application index, with application index == 0
always being the initial configuration for that interface.   So a
typical client with two network interfaces would have these two
identity associations: {0, 0, UUID} and {1, 0, UUID}.   And if an
application decided to listen with its own address on each interface,
then the client would have four identity associations: {0, 0, UUID},
{0, 1, UUID}, {1, 0, UUID} and {1, 1, UUID}.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Thu, 07 Sep 2000 01:33:57 -0400

Ted,

>	    associations actually represent one client.

I would add and an interface on the client.

>	    key work with all of a client's identity associations.

I think this is mandatory.

>universally-unique identifier, similar to what Intel has done in the

I would also look at what infiniband has done for the GUID.
I also think we cannot be stingy with the bits here.
If we need 128bits so be it if we can use less fine.

>noticing that although the modifier is different, the UUID is the

This will work I think.

>network interfaces, its two identity associations would probably be

I would like to see the UUID be recognizable if its the same client for
the same interface.  So I guess I want to discuss what we do with the
UUID?  This may be where the infiniband GUID helps.

>want to actually maintain its own mapping between the network hardware

Do you mean "prefixes" above for the UUID?

>{0, 1, UUID}, {1, 0, UUID} and {1, 1, UUID}.

I would use more than 8 bits for each.  I would use 16 for each and 96
for the UUID.

The success or failure of this is how we do the UUID or whatever it ends
up to be.  

I think that needs its own mail thread discussion to get some ideas.

regards,
/jim

---

From: Ralph Droms <[email-masked]>
Date: Thu, 14 Sep 2000 14:24:15 -0400

Ted - I like your statement of the identification problem.

>             key work with all of a client's identity associations.

(a) is important - I'd like the DHCP server to be able to know that my 
laptop is the same device whether it is plugged in to its docking station 
or connected through its PC card NIC.  (b) and (c) are related, I think - 
we'd like the server to differentiate IAs but be able to determine that two 
IAs come from the same DHCP client (physical computer?)  (d) simplifies the 
key management problem.

Not trying to be diffcult here - but what, exactly, is a "client"?  A 
physical device, a protocol stack, (potentially?) an application?  My 
understanding of (a)-(d) might change depending on the answer.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Sep 2000 11:47:14 -0700

> understanding of (a)-(d) might change depending on the answer.

That's a good question.  I think the answer is "that collection of
programs running on a single computer that interact on the DHCP
protocol port and respond to DHCP requests."  I think in order to
implement this you probably either have to have all of the identity
association state machines either running as part of the same program,
or you have to have an API on your computer that acts as a rendezvous
point for seperate programs each of which is running one or more of
the identity associations.

I don't think we talked about this, but this has implications for the
DHCP Reconfigure message.   The Reconfigure message has to tell the
client which identity association to renew (or to renew all of them, I
guess).

			       _MelloN_