Subject: Re: Discussion: client identifier

From: Ralph Droms <[email-masked]>
Date: Thu, 19 Oct 2000 13:49:10 -0400

And here's my latest definition of the DHCPv6 client identifier.  this 
version is essentially unchanged from the previous version - I only edited 
it for brevity.  There are two TBD issues at the end of the definition.

Please review this doc and post any comments.  If we have any unresolved 
issues I'll add them to the draft for discussion at our next design team 
phone call.

- Ralph

=====
Issue: Definition of "client identifier" for DHCPv6.

Summary: IAs will be identified by a tuple: (UUID, binding-id).  UUID
is a unique identifier for a DHCP client.  All IAs from one DHCP
client share the same UUID.  A binding-id is an opaque value uniquely
identifying an IA within a client.  The client is responsible for
managing binding-ids and the protocol makes no statement about the way
in which binding-ids are formed.

The rules for selecting a UUID are:

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).  For this to
    produce unique numbers the spec must identify the number
    space. Otherwise two boxes made by two different vendors might both
    have serial number 17.

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 identifier, and MUST use the same client
    identifier for all of their interfaces.

Using a unique, permanent UUID allows a DHCP client to be positively
identified regardless of its network connections.  Identifying IAs
by (UUID, binding-id) allows a DHCP server to determine which IAs are
associated with the same DHCP client; for example, a DHCP server can
differentiate between a client that has moved to a new physical
network and a multi-homed client.  All authentication for a client is
based on the UUID, so transactions for all of a client's IAs can be
authenticated with a single key.

Changes: This summary was rewritten for brevity without changing the
   definition of the IA identifier.

TBD:
* Size and shape (number of bits, fixed or variable length) of UUID
   and binding-id.

   We have one suggestion for the format of a UUID: 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.

* How to detect and respond to UUID collisions.  In the event that two
   DHCP clients choose the same UUID, and given that we don't want to
   include the network prefix as part of the IA identifier, the server
   may assign the same internet address to two different clients.

---

From: Jim Bound <[email-masked]>
Date: Fri, 20 Oct 2000 07:23:15 -0400

On client identifier I posted mail why the network prefix should
be used with the client identifier and have seen no response.
this is the architecture in the present spec.  Can we have discussion
and debate on this per my mail.  As removing that feature from
dhcpv6 wil be a big negative for this solution.

regards,
/jim

---

From: "Ralph E. Droms" <[email-masked]>
Date: Fri, 20 Oct 2000 08:39:24 -0400 (EDT)

> dhcpv6 wil be a big negative for this solution.

I think that adding the prefix to the UUID leaves us with the same problem
we have in DHCPv4 today - we can't differentiate between a host that moves
from one link to another and a multi-homed host.

Suppose a DHCP server receives a request for IA (P1, UUID0, binding-id0)
and then for IA (P2, UUID, binding-id1).  (I believe that we have
already decided we can't guarantee a client will always use the same
binding-id  for an interface.)  Are these requests for two different
interfaces from multi-homed client UUID0 or has client UUID0 moved from
link P1 to link P2?

Perhaps, if we could guarantee that a client would ALWAYS use the same
binding-id for an interface we could use the network prefix to dismbiguate
UUID collisions...

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Sun, 22 Oct 2000 22:42:11 -0400

>from one link to another and a multi-homed host.

True.  But for stationary hosts it works fine.  We could use the Mobile
IPv6 Binding Update option to notify a move in prefix too?  I don't
think we should sacrafice stationary hosts management for mobile host
management at all as a design center.  Also if the client releases their
addresses when they leave a link the prefix still works or will just
time out.

I also have no faith we will define a UUID that will work across a site
let alone the Internet any better than we did in IPv6 for 5 years.

>interfaces from multi-homed client UUID0 or has client UUID0 moved from

The binding-id will not matter and can even be duplicated (hopefully it
won't be) as long as UUIDs are not permitted to be duplicated on a link?

It does not matter as my example in my mail the database at the server
is basing the entry based on an aggregate of Prefix+UUID+binding-id.
That aggregate will work for a search and for management of the client
parameters.  It won't matter if the node is multihomed or on a different
link and be transparent to the server as long as the binding-ids are not
duplicated in the case where the UUID is two NICs on one link.  In that
case I would argue that either the UUIDs or binding-ids must be
different.

>binding-id for an interface we could use the network prefix to dismbiguate

Thats where I went above too.
Well we need to think about that for sure.  I think that would be wise.
IPv6 had the same architecture reasons for not permitting a client to
use the same link-local address on a link that we should not want a
client to duplicate a UUID or binding-id on the same link. 

regards,
/jim

---

From: Ralph Droms <[email-masked]>
Date: Mon, 23 Oct 2000 14:18:45 -0400

At 10:42 PM 10/22/00 -0400, you wrote:

>management at all as a design center.

I was thinking more of "relatively stationary" hosts - say, a desktop PC 
that happens to move to a new office.  I think Ted has expressed (and I'm 
speaking for him here knowing that he's off-line for a couple of weeks) 
concern about prefix-based identifiers based on his experience with the ISC 
DHCP server:

>From: Ted Lemon <[email-masked]>
>Date: Wed, 06 Sep 2000 12:01:17 -0700
>I am trying to get away from the notion that an IP address is uniquely
>identified by {client identifier, physical network}.   This causes
>lots of obnoxious ambiguity in RFC2131 that I don't think adds any
>value - to correctly implement the protocol, I have to allow clients
>to have active leases with the same client identifier on different
>physical networks at the same time, which means that when a client
>moves from physical network to physical network within the same
>administrative domain, the server may wind up with active leases for
>that client on more than one network when the client is only connected
>to one network.   Having one identity association per network
>interface avoids this problem - if you are multiply attached, you'll
>have multiple identity associations, and if you're singly attached, I
>can nuke your old lease when you change networks.

Ted's observation was the basis for my example:

> >and then for IA (P2, UUID0, binding-id1).  (I believe that we have

If the binding-id is duplicated, and the requests come reasonably close 
together in time, the server *might* be able to deduce that UUID0 is not a 
dual-homed host.  But, if the binding-ids are different, either UUID0 is a 
dual-homed host or it moved to a new subnet and renumbered its interfaces.

>case I would argue that either the UUIDs or binding-ids must be

But, Ted expressed a concern and I've given an example - using a common 
case in which a relatively stationary client moves to a new subnet - where 
including the prefix causes a specific problem.   So, I can't agree with 
your claim that prefix+UID+binding-id is sufficient...

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Mon, 23 Oct 2000 23:24:04 -0400

>concern about prefix-based identifiers based on his experience with the ISC 

OK.  I can follow this and did and when the host (or node) moves off a
link in IPv6 it will have a new prefix, not the same prefix.

>Ted's observation was the basis for my example:

I agree with Ted's observation.  It is not the same scenario as DHCPv6
we changed the model in DHCPv6 for what the server maintains and what
the client-identifier is by definition.  In DHCPv6 the client-identifier
of DCHPv4 is:

     Prefix + Link-Local address

Link-Local is guranteed to be unique in IPv6 on a link.
Prefix is guranteed to be unique in a site (or even the Internet).

So with Ted's IA model.

Node A on Alink with-link-local of 22 with prefix 3ffe (3ffe::A::22)

and 

Node B on Blink with-link-local of 22 with prefix 4ffe (4ffe::B::22)

Node A IA = 3ffe::A::22
Node B IA = 4ffe::A::22

Now lets see what happens when Node B moves to Alink.

It enters the LAN and does DAD on its interface and finds out that 22 is
taken and must use another link-local address.  Node B does this and for
this discussion lets asssume it bumps 22 to 23 and then its
with-link-local on Alink is 23.  Now node B becomes 3ffe::A::23 and a
new client database entry in the server database.  The B client IMO should
release its resources before going to Alink, but if it does not its
entry would time out and eventually be deleted.  Or we could define a
Mobile-DHCPv6-Delete-Old-IA.  

The IA changes when you leave the subnet your on.

This supports Ted's postulate above:

>Having one identity association per network interface avoids this problem - 
>if you are multiply attached, you'll have multiple identity associations, 
>and if you're singly attached, I can nuke your old lease when you change 
>networks.

It would be nice if the client told the server they are leaving is the
discussion we still have to have and how, and what happens when it
can't.

What I describe above also supports Ted's IA model where if you have a
dual homed node on the same link it works to in IPv6.  Because each
interface would be an IA which I think is a good simple model.

Now the other part of Ted's good idea is that we trash using the
link-local address (and other input cause its tied to a NIC).  The
link-local address above is changed to the UUID + binding-ID, so now
we have prefix+UUID+binding-id.

If we state the following and can agree to it:

 1) UUIDs cannot be duplicated by hosts on a link.
 2) binding-ids for interfaces must be different on a node.

Then we can do DAD on UUID+binding-ids in IPv6 to verify they are unique
on a link for an interface. 

The UUID can still be used for security and the node can keep it if it
roams in the site.  If its UUID as it roams collides on a link with
another UUID, one of them must change, and the visiting node would have
to change as IPv6 DAD is specified today.  Then this means the node
needs to reset its security parameters.  So if the UUIDs do not collide
there is no problem and with a good algorithm for UUIDs we can be pretty
sure in a site in DHCPv6 the UUIDs won't collide across links.  But if
they do we have a mechanism to cover it.

Then Node B can move to Alink and work as in my above example.

In the above we integrate Ted's IA and UUID model right into the IPv6
architectural benefits and it will work in the present spec for DHCPv6.
I think a good and expedient solution for us.

>dual-homed host or it moved to a new subnet and renumbered its interfaces.

I think I address this in the model above with Ted's parameters?

>your claim that prefix+UID+binding-id is sufficient...

I think I addressed this further using Ted's parameters?

regards,
/jim

---

From: "Richard Barr Hibbs" <[email-masked]>
Date: Wed, 25 Oct 2000 11:37:06 -0700

> -----Original Message-----
> From:  Jim Bound
> Sent: Monday, October 23, 2000 8:24 PM

*Snip!*

> ... when the host (or node) moves off a
...Jim, I'll accept this assertion without challenge, but this seems to be
key to developing a unique identifier, so we'd better be really, really
ceertain that it is correct....

*Snip!*

> .... In DHCPv6 the client-identifier of DCHPv4 is:
>
...somewhere along the line I missed general acceptance of the idea that
Link-Local address is *the* principal component of the identifier.  I
believe that Ralph summarized the prior discussion as the client is
responsible for generating or using a unique value.  Again, I won't protest
this if it accomplishes what we need -- after all, our DHCPv4 experience
with using the MAC address has been less than wonderful.

*Snip!*

> Then we can do DAD on UUID+binding-ids in IPv6 to verify they are
> unique on a link for an interface.
>
...unfortunately, your point (1) is exactly what has generated all the
discussion.  I deeply believe it is quite difficult, if not impossible, to
assert that (1) is always true -- that's why I think that the draft MUST
specify the characteristics of a collision so that implementors are better
able to detect it, and SHOULD provide our best ideas of how to resolve it,
WITHOUT specifying the method.

...or do I completely miss your point?

--Barr Hibbs
  UltraDNS Corporation

---

From: Jim Bound <[email-masked]>
Date: Wed, 25 Oct 2000 20:19:17 -0400

>ceertain that it is correct....

This is from RFC 2373 

   Currently IPv6 continues the IPv4 model that a subnet prefix is
   associated with one link.  Multiple subnet prefixes may be assigned
   to the same link.

A conversation is in research discussion to let a prefix span
multiple links but then DAD MUST be able to be done across multiple
links is the strategy, so we would have to develop that.  But yes we can
depend on my above statement and how IPv6 is being deployed today.

>with using the MAC address has been less than wonderful.

I agree with you and Ralph.  That part of my mail was to state the
current IPv6 means today.  For DHCPv6 I am convinced from all that we
don't want to use a NIC address for the identifier, but the UUID. So I
think we are talking in dhcpv6 now:

Prefix + UUID 

Or at least that is what I am suggesting.

>WITHOUT specifying the method.

(1) is easy to make true if you make the UUID the link-local address in
the IPv6 DAD algroithm and send it on the link alone or with a prefix of
FE80 (link-local).  This will prevent UUIDs from colliding with other
UUIDs on the link.  Then we don't have the issue.  What I am proposing
is 99.9% accurate and will just work if use what we are doing right now
on all our IPv6 implementations today.

regards,
/jim

--Barr Hibbs
  UltraDNS Corporation

---

From: Ralph Droms <[email-masked]>
Date: Thu, 26 Oct 2000 16:18:28 -0400

Here's another long message on the client identifier issue.  The
executive summary is that it seems to me that including the
prefix in an IA is in conflict with some of the basic uses
of an IA that Ted listed in his initial message...

=====

Jim - after thinking about your proposal and scenarios, I may have come
across a point in which we differ in our thinking about the use of
an IA-identifier.  Here's what I think we need to use the IA-identifier
for:

1 Differentiating between IAs (either IAs from different clients
   or different interfaces on a multi-homed host) at any given
   point in time
2 Uniformly identifying an IA over time
3 Determining that two IAs are from the same client
4 Providing a way to have a single authentication
   key work with all of a client's identity associations

These uses are taken from or edits of the points from Ted's
original kickoff message.

Ted's original proposal for using UUID+binding-id for an IA
can be used for 1-4, based on the assumption we can find
a permanent, unique value for every client to use as the UUID.

Using prefix+UUID+binding-id and DAD
to detect and avoid collisions on a link gives us an
IA that is guaranteed to be unique.  But, I don't think the
prefix+UID+binding-id model - assuming that the UUID may
change when a client changes links - can be used for 2 or 3,
and it can only be used for 4 for singly-homed hosts.

One problem arises from the use of the prefix in the IA.
If the prefix is part of the IA, then the IA for an interface
changes over time, and the server can't match an interface
that moves to a new link with its previous IA on the old
link.  You correctly observed that this problem corrects
itself when the old IA expires, but Ted initially raised
the issue because Ted's experience with DHCPv4 is that
leaving old leases around like that is unacceptable.

Another problem comes from the UUID potentially changing
because of a collision when the client moves to a new
link.  In that case, we also lose the ability to track
an IA over time, as well as the ability to associate
multiple IAs with a single client.

I do like the idea of doing some kind of active error
detection.  Perhaps there is a way in which we can
develop and suggest heuristics that servers can
use to disambiguate and report duplicate UUIDs?

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Thu, 26 Oct 2000 22:57:17 -0400

Hi Ralph,

>a permanent, unique value for every client to use as the UUID.

As a note I am challenging that assumption that we can build a UUID that
is unique for every client and I don't think we or anyone can gurantee
it.  Thats why I made my proposal.

>and it can only be used for 4 for singly-homed hosts.

I believe that it can work for 3 as long as the client can keep its UUID
while moving from one link to another as I outlined in my previous mail.
Once their is a collision on the link then the UUID has to change yes.

I think it would work for 4 two.  The UUID would be the same for both
interfaces but the prefixes would be different if multihomed on two
links.  On one link the binding-id would differentiate the IAs.

The server and client use the UUID for uniformity and security in the
model I proposed and 1-4 works as long as the UUID don't change.

If the UUID collides on the link then yes all bets are off.

But I would propose to the WG that the way I am trying to use Ted's
model will in fact work with a UUID algorithm that is mostly going to
work.  And if it does not then the client must get another UUID.

Also a sub proposal I am making is that no matter what model we use for
this DAD should be performed on the UUID+binding-id in DHCPv6 anyway.  I
don't believe we should permit duplicate UUIDs on two different nodes.

>leaving old leases around like that is unacceptable.

But if the UUID is maintained across prefix changes that can be tracked
pretty easily by the server and can react to that mobile situation.  

Clearly it is a trade-off discussion.

>multiple IAs with a single client.

Yes that can happen.    

>use to disambiguate and report duplicate UUIDs?

I think what I will do is lay out what I see are all the holes with not
using a prefix and the drawbacks and then we can compare the list and
see where this is then too.  I will do this next week.
Then the trade-off discussion has an equal weight for analysis.  

/jim