Subject: RE: Discussion: client identifier [collisions]

From: Bernie Volz <[email-masked]>
Date: Fri, 13 Oct 2000 17:38:38 -0400

1) Defending only works if the defender is up and running. If it isn't, the
server might think this new client is the old client and assign it the
addresses. Once the original node returns, you might have a mess.

2) I don't think the statement that we need to keep the UUID unique to the
same LAN is true. If we're trying to make UUID unique to a client, that
client could easily be attached to several LANs and there is some potential
benefit if a server could know that when assigning addresses (assuming that
a single server is giving out the addresses for both LANs). This benefit
might also extend to management tools that query various servers (or their
repositories) to find out what addresses a single system has. I think the
UUID should ideally be unique to the DHCP server configuration (not
necessarily a single server, but many whether using failover, etc). Of
course, ideally it is universally unique.

3) The more we talk about this, the more I think this is too big a problem
to resolve in the short time we have to get the DHCPv6 draft out. Unless we
can find some prior art in this area - anyone located any?

4) Perhaps an interim solution is to define the UUID concept and today base
it on the hardware address of the interface. Perhaps the UUID today could be
defined as <UUID-type-code><hardware-type><hardware-address> where
UUID-type-code is something like 1 and hardware-type and hardware-address
are what we know them to be in DHCPv4. We might want to hash them in some
fashion. While sounding simple there are some more complex issues to  deal
with, such as what happens if a client no longer has this hardware-address.
Does it pick a new UUID or keep the old? My recommendation - pick a new UUID
(based on one of the hardware addresses). This dimishes the UUID value for
now, but avoids problems in case a new client were to get the original
hardware-address (since then you'd have two systems). Another issue is what
do systems that don't have very unqiue hardware addresses do?

Later, when systems get unique serial numbers or some such identifier, the
UUID can be derived from them instead (with a new UUID-type-code).

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Friday, October 13, 2000 5:09 PM
To: DHCPv6 discussion list
Subject: RE: Discussion: client identifier [collisions]

[Thomas]
> If there is a collision, what do you propose the server do? Seems to
> me that it has no way of distinguishing between the case where the
> same node is asking for different things (at different times) vs. two
> different nodes asking for information.
>

The UUID space is large, but nevertheless there will be collisions. 
In terms of collision avoidance, there are a few things to think about:

a. How do nodes know when they've collided
b. How do they resolve the collision

In terms of collisions, I think that we only care about hosts with
identical UUIDs on the same LAN. So nodes learn about collisions by
listening to DHCPv6 traffic. Note that unlike neighbor discovery 
or mDNS, such traffic won't be frequent, so that a host choosing 
an already taken UUID isn't likely to have heard the previous 
traffic. So you have a situation with asymetric knowledge, 
where the original UUID owner may become aware of the 
collision, but the subsequent UUID claimers probably 
won't be aware of it. 

One possibility is for the origial UUID owner to "defend" the
claim, forcing the subsequent claimant to choose another UUID. 
I think that this may imply another message type, which probably
should be sent unicast. Note that in this model, there is an
implicit "first claimed first owned" model for resolving the
dispute. 

Another possibility is to have a tie breaker algorith, which
may cause the original owner to choose another UUID. My concern
is that this will cause the original owner to have to change 
addresses when the lease runs out. It is generally less disruptive 
to slightly delay a subsequent claimant in obtaining
an address on boot when they have no connections open as opposed
to forcing the original UUID owner with open connections to 
change their address thereby possibly losing some of them.

---

From: "Barr Hibbs" <[email-masked]>
Date: Fri, 13 Oct 2000 16:12:45 -0700

> 1) Defending only works if the defender is up and running. If it
> isn't, the server might think this new client is the old client
> and assign it the addresses. Once the original node returns, you
> might have a mess.
>
...agreed: "defending" an assignment isn't something that a client should
do, and probably not even a server.  WHile a server might notice that its
leases are being "stolen" by a rogue or misconfigured server, or
misappropriated by a client, I think that human intervention will most often
be requred to resolve, so why include any sort of defense mechanism in the
protocol?

> 2) I don't think the statement that we need to keep the UUID
> unique to the same LAN is true. If we're trying to make UUID
> unique to a client, that client could easily be attached to
> several LANs and there is some potential benefit if a server
> could know that when assigning addresses (assuming that
> a single server is giving out the addresses for both LANs).
> This benefit might also extend to management tools that query
> various servers (or their repositories) to find out what addresses
> a single system has. I think the UUID should ideally be unique
> to the DHCP server configuration (not necessarily a single server,
> but many whether using failover, etc). Of course, ideally it is
> universally unique.
>
...while I think it is relatively difficult to define a universally unique
identifier, I believe we can define something that is relatively close, then
the collision detection mechanism (which I believe is a MUCH easier problem)
can be specified, if not algorithmically, at least by its characteristics

> 3) The more we talk about this, the more I think this is too big
> a problem to resolve in the short time we have to get the DHCPv6
> draft out.  Unless we can find some prior art in this area --
> anyone located any?
>
...I vote for the multi-component proposal, using cryptographically robust
methods to randomize it, as I've said before, then declaring the
characteristics of the collision detection and resolution process:  then we
can let implementors find the "best" way.

--Barr Hibbs,
  UltraDNS Corporation

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 13 Oct 2000 22:54:05 -0700

>can be specified, if not algorithmically, at least by its characteristics

Ultimately, I think we only care about UUID collisions to the extent that
they result in address collisions, right? Assuming that we have a mechanism
to
detect address collisions, does this solve the problem?

> draft out.  Unless we can find some prior art in this area --

I'm not sure I'm ready to give up yet.

---

From: "Barr Hibbs" <[email-masked]>
Date: Mon, 16 Oct 2000 10:06:52 -0700

> From: Bernard Aboba
> Sent: Friday, October 13, 2000 10:54 PM

> detect address collisions, does this solve the problem?
...agreed: all we really care about is detection -- at least in an RFC --
though I maintain it would be very useful to define the characteristics of a
resolution mechanism, mostly to avoid misinterpretations which have plagued
DHCPv4

--Barr Hibbs