Subject: Discussion: client identifier

From: Ralph Droms <[email-masked]>
Date: Mon, 09 Oct 2000 15:55:17 -0400

Issue: Definition of "client identifier" for DHCPv6.

Ted initiated
the discussion with the following summary of issues:

	(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.

Ted initially proposed a model in which every "identity association"
(IA) (this term is taken from our conversation about the DHCPv6 address
model; an IA is a set of IPv6 addresses and an associated identifier)
has a unique identifier.  An IA identifier is a tuple consisting of a
unique client identifier (UUID) and a modifier.  The client's UID
remains unchanged "forever", addressing issue (a).  All IAs from a single
DHCP client share the same UUID and have different modifiers.  Using
(UUID, modifier) to identify an IA addresses (b).  Because all
IAs from a single client share the same UUID, servers can identify
different IAs from the same client (c).  Finally, by basing
authentication on just the UUID, all messages about IAs from a single
client can be authenticated using the same key.

The discussion settled on calling the "modifier" a "binding-id", which
is an opaque number uniquely identifying an IA from a DHCP client.
The client will likely manage binding-ids over time so that the
addresses in an IA need not be unnecessarily replaced (that is, on a
specific host, if binding-id 1 identifies an IA from subnet A and
binding-id 2 identifies an IA from subnet B, the client will not
switch binding-id 1 to subnet B and vice versa).  If a client cannot
manage binding-ids, it will indicate to the server that it has no
state about previous binding-ids.

Summary: IAs will be identfied 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.

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

---

From: Thomas Narten <[email-masked]>
Date: Tue, 10 Oct 2000 12:01:40 -0400

> is a unique identifier for a DHCP client.

How are UUIDs assigned? How does a client determine its UUID? I'm
thinking in particular of:

1) machines that are plugged into the network for the first time
2) machines that have no stable storage, and thus can't store
   configuration information across system restarts.

As much as using a MAC has its disadvantages, it does have the
advantage that every interface has one, and its pretty much globally
unique. If one doesn't use the MAC, what will be used instead?

Or is the thinking that the default UUID for a node will be based on
the MAC address? What if that network interface is then taken out of
one machine and put into another? How will conflicts be resolved if
two machines create UUIDs derived from the same MAC address?

Thomas