Subject: Client ID and DUID and variable within fixed bound

From: [email-masked]
Date: Fri, 16 Mar 2001 12:48:30 -0600

Folks,

On the design team there was some statements that the client-id + DUID would
be variable.  I have issues with variable after writing code for many years
unless it is absolutely necessary.  It complicates everything but I too have
used it when it really made sense.  Rather than bring this up at the meeting
on Wednesday I thought I would try to get some discussion where people are
coming from.

Also variable within a bounded fixed-length as OSI NSAP address was in that
protocol is at least a minimum requirement without serious justification. I
would also state my gut feeling is that 128bits is more than enough for that
fixed-length field based on old IPng and EID and to some degree NIMROD
discussions days ago in the IETF for many years.

Also for this we really need to think "mobile" wireless and its affect.  And
variable unbounded length fields cause optimizations and much variance in
database and protocol datastructures.  Anyway here is my belief of where we
are with this IA DUID:

6 bytes - Hardware Address or possibly serial number
2 bytes - unique interface identifier the node keeps for each interface at
          the upper layer as it numbers them so it don't change
4 byte  - timestamp
4 byte  - TBD

I am beginning to think the entire set of bytes is the DUID and the IA
identifier?

Can anyone state why we need more than 128bits?

Discussion?

thanks
/jim

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Fri, 16 Mar 2001 15:07:22 -0600

Jim:

I don't have a problem with using a fixed identifer. Though, I
don't see it being variable is such a big deal (especially if
we set a reasonable upper limit).

I think the DUID should just be the CLIENT IDENTIFIER. So, I
would use something like:
- 2 bytes - Type field (how the DUID is constructed, such as
  using the EUI-64 has a different value than if a serial number
  is used to prevent collisions)
- 8 bytes - Hardware Address (EUI-64) or possibly serial number
- 4 byte  - timestamp

The point is that a client thas ONE of this values and uses it
for all DHCP requests (regardless of which interface or how many
requests it is making).

In many ways, having this be a 128-bit quantity is kind of nice.
So, perhaps to increase the randomness of this, we use:
- 2 bytes - Typ field
- 8 bytes - Hardware Address (EUI-64) or possibly serial number
- 4 byte  - timestamp
- 2 byte  - random number
Or, just specify the last 6 bytes as timestamp or other random
number.

What about running this through some short of hashing algorithm
(such as what's proposed for the DHCID RR?) to allow the hardware
address/serial number to be concealed (privacy concerns).

We put this DUID into the packets - I think it should go into the
header. But it could also be an option.

For the Identity Association, we use an IdentityID value that is
32 or 64 bits. This value is contructed by client and is opaque.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 16, 2001 1:49 PM
To: DHCPv6 discussion list
Subject: Client ID and DUID and variable within fixed bound

Folks,

Discussion?

thanks
/jim

---

From: [email-masked]
Date: Fri, 16 Mar 2001 15:40:55 -0600

Bernie,
 
I said I can live with variable as long as there is upper limit (thats what
OSI NSAP did).
I am less clear right now if identity id should be different than client-id.
I have no issue with your proposed fields at first glance.
 
/jim

-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Friday,March 16,2001 4:07 PM
To: DHCPv6 discussion list
Subject: RE: Client ID and DUID and variable within fixed bound

Jim: 

- Bernie 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Friday, March 16, 2001 1:49 PM 
To: DHCPv6 discussion list 
Subject: Client ID and DUID and variable within fixed bound 

Folks, 

Discussion? 

thanks 
/jim

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Fri, 16 Mar 2001 15:51:57 -0600

Great.
 
Regarding identity id, are you referring to what goes into the Identity Association option?
That should be different. The client id needs to go into the ALL requests even if the client
isn't asking for addresses.
 
Reason is we need some way to identify the client that is making a request - such that a
server can:
a) Track what a client has. Since there are applications where you might want to restrict
that.
b) You have some useful and meaningful value by which to track who had an address when.
Just having a value that can constantly change doesn't buy you anything. Sure, you could
record the client link-local address but that is unique only to a link (prefix).
c) We need some id that we can use in the DHCID RR so that a single client is allowed to
register multiple addresses under one name. If the client always registers the forward (A6)
entry, then it could use some other identifier. However, if the server is doing it it needs
some way to know that the existing belongs to the same client.
d) If you want to do client specific reservations (either specific addresses or number of
addresses) OR want to give a specific client some set of configuration parameters
(perhaps other than addresses), you need something by which to identify that client.
 
Do you need more reasons?
 
- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 16, 2001 4:41 PM
To: DHCPv6 discussion list
Subject: RE: Client ID and DUID and variable within fixed bound

Bernie,
 
I said I can live with variable as long as there is upper limit (thats what OSI NSAP did).
I am less clear right now if identity id should be different than client-id.
I have no issue with your proposed fields at first glance.
 
/jim

-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Friday,March 16,2001 4:07 PM
To: DHCPv6 discussion list
Subject: RE: Client ID and DUID and variable within fixed bound

Jim: 

- Bernie 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, March 16, 2001 1:49 PM 
To: DHCPv6 discussion list 
Subject: Client ID and DUID and variable within fixed bound 

Folks, 

Discussion? 

thanks 
/jim

---

From: [email-masked]
Date: Fri, 16 Mar 2001 22:39:16 -0600

understand the reason why we need to identify a client never did have issue
with that.
still not sure we need IA and Client ID.  If a node can have multiple client
IDs.  the only reason a server needs to know about a client is because of
addresses.  everything else is "inform".
 
to say we need it because we "believe it" is weak.  if we follow that logic
then all the folks who wanted the client to request addresses provided much
strong arguments and we told them no.
 
/jim

-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Friday,March 16,2001 4:52 PM
To: DHCPv6 discussion list
Subject: RE: Client ID and DUID and variable within fixed bound

Great.
 
Regarding identity id, are you referring to what goes into the Identity
Association option?
That should be different. The client id needs to go into the ALL requests
even if the client
isn't asking for addresses.
 
Reason is we need some way to identify the client that is making a request -
such that a
server can:
a) Track what a client has. Since there are applications where you might
want to restrict
that.
b) You have some useful and meaningful value by which to track who had an
address when.
Just having a value that can constantly change doesn't buy you anything.
Sure, you could
record the client link-local address but that is unique only to a link
(prefix).
c) We need some id that we can use in the DHCID RR so that a single client
is allowed to
register multiple addresses under one name. If the client always registers
the forward (A6)
entry, then it could use some other identifier. However, if the server is
doing it it needs
some way to know that the existing belongs to the same client.
d) If you want to do client specific reservations (either specific addresses
or number of
addresses) OR want to give a specific client some set of configuration
parameters
(perhaps other than addresses), you need something by which to identify that
client.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 16, 2001 4:41 PM
To: DHCPv6 discussion list
Subject: RE: Client ID and DUID and variable within fixed bound

Bernie,

/jim

-----Original Message-----
From: ext Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Friday,March 16,2001 4:07 PM
To: DHCPv6 discussion list
Subject: RE: Client ID and DUID and variable within fixed bound

Jim: 

- Bernie 

-----Original Message----- 

Folks, 

Discussion? 

thanks 
/jim