Subject: RE: Discussion: client identifier

From: Ralph Droms <[email-masked]>
Date: Tue, 10 Oct 2000 14:20:02 -0400

At 12:16 PM 10/10/00 -0400, you wrote:
>We have discussed this issue on the mailing list and I'm sure Ralph will get
>around to publishing the discussion/summary soon. I suspect that there are
>still several open issues related to this.

Actually, what I published was what I took to be the resolution of the 
issue as it was developed in the course of the mailing list discussion.  I 
don't intend to summarize the discussion itself.  I mentioned an open 
issue: the size and shape of the UID and binding-id are TBD.  Thomas 
brought up another open issue: what does a client use as its UUID.

>For the summary that Ralph wrote up, saying that we'll be using these two
>items is correct. But a further summary of what these two items are is
>hopefully coming.

I just reviewed the discussion - as far as I can tell, we decided on the 
two part identifier, (UUID, binding-id), and defined the binding-id as an 
opaque value chosen by the client.  I don't think we answered either of the 
two open issues listed above.  So, we need to resolve the two issues or 
document them as still open in the next rev of the spec...

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Oct 2000 11:52:21 -0700

> document them as still open in the next rev of the spec...

Ralph, we have a pretty clear specification for how a UUID is defined
that Bernie sent to the mailing list.   I certainly agree that this is
the right thing to do, and other than one clarification that someone
(Erik Nordmark?) made, I think it works and we should use it.   I
thought that *was* the consensus!   :'}

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Tue, 10 Oct 2000 15:17:35 -0400

>thought that *was* the consensus!   :'}

I'm sorry to be difficult, but I can find neither Bernie's final 
description nor Erik's clarification.  Can you point me at those 
words?  Thanks...

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 10 Oct 2000 15:23:55 -0400

At 11:52 AM 10/10/00 -0700, you wrote:

>that Bernie sent to the mailing list.

I discovered the source of my confusion - Bernie's spec appeared in the 
address model thread, not in the client identifier thread.  I wrote up the 
summary with my "thread-blinders" on.

So, here's Bernie's specification:

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

And Erik's follow up:

 > 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 you need to identify the number space
as part of the I-D. Otherwise two boxes made by two different vendors
might both have serial number 17.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Oct 2000 12:24:41 -0700

> description nor Erik's clarification.  Can you point me at those 

No problem!   :')

				_MelloN_

------- Forwarded Messages

Message-ID: <[email-masked]>
From: Bernie Volz <[email-masked]>
To: DHCPv6 discussion list <[email-masked]>
Cc: [email-masked]
Subject: RE: DHCPv6 address model proposal...
Date: Mon, 2 Oct 2000 11:02:54 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: [email-masked]
Sender: [email-masked]
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I do think the wording below will need some rework. For example: "Clients
that have no stable storage MUST use the link-layer address of one of their
network interfaces as the client identifer, and MUST use the same client
identifier for all of their interfaces."

If a client has other unique identifying information, such as a unique
serial number burned into memory it should use that and not any network
interface information. Therefore the "MUST" MUST be removed or changed to be
conditional.

I believe the rules should be:

- - Bernie

- -----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, September 28, 2000 9:54 PM
To: DHCPv6 discussion list
Cc: [email-masked]
Subject: Re: DHCPv6 address model proposal...

> How do we verify that a clients IA is in fact unique if it don't verify
> that with other clients?
>  a) on the link best case
>  b) with the servers dhcp domain?

The schemes that have been proposed for coming up with UUIDs
(Universally Unique Identifiers) rely more on reducing the chance of
collision to ridiculously low amounts than they do on any mechanical
process of guaranteeing that the identifier is unique.  I am pretty
sure that Windows has a UUID that is generated this way.   Computers
with serial numbers could use a vendor name plus the serial number.

I think the language in the draft should say something like "DHCP
clients SHOULD use a client identifier that will not vary as a result
of changes in network hardware and will be consistent between network
interfaces.  DHCP clients SHOULD NOT use the link-layer address of a
network interface by itself as a client identifier, but SHOULD instead
use some other identifier that is known to be globally unique - for
example, a combination of the CPU's serial number and manufacturer's
registered domain name.   DHCP clients that have no unique identifier
other than the link-layer address SHOULD combine 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.   Clients that have no stable storage MUST use the
link-layer address of one of their network interfaces as the client
identifer, and MUST use the same client identifier for all of their
interfaces."

This is rather convoluted, but I think it covers all the possible
cases where one could get into trouble.   The only case where we could
get into trouble is if two clients connected to the same link use the
HASH (pad16 (link-layer-addr) + random4) and wind up producing the
same hash value.   The reason for using the highly-structured formula
for producing the hash is to make this vanishingly unlikely, but I'm
not a crypto-geek, so I may have gotten it wrong.

We could also require the client to identify which of the algorithms
it is using in the first byte of the identifier, which would avoid
stupid collisions due to differing algorithms.

The language should also probably be made more readable - I'd be happy
to do this if people think this is a good set of methods to use to
generate the client identifier.

BTW, I am just talking about how to generate the common per-client
part of the identifier.  We also talked about the client combining its
per-client identifier with an additional per-instance identifier so as
to uniquely identify an address association, so that the client could
have more than one address association - e.g., for application-
specific situations or for clients supporting more than one interface,
or using DHCP to manage a care-of address as well as a home address.

			       _MelloN_

------- Message 2

Date: Wed, 4 Oct 2000 18:34:53 -0700 (PDT)
From: Erik Nordmark <[email-masked]>
Reply-To: Erik Nordmark <[email-masked]>
Subject: RE: DHCPv6 address model proposal...
To: DHCPv6 discussion list <[email-masked]>
In-Reply-To: "Your message with ID" <[email-masked]>
Message-ID: <Roam.SIMC.2.0.6.970709693.5419.nordmark@jurassic>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [email-masked]
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Bernie,

   Erik

------- End of Forwarded Messages

---

From: Ralph Droms <[email-masked]>
Date: Tue, 10 Oct 2000 16:42:37 -0400

OK, so here's the "client identifier" summary, extended to include the 
details of UUID generation
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 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.

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.

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

---

From: "Barr Hibbs" <[email-masked]>
Date: Tue, 10 Oct 2000 14:33:54 -0700

> might both have serial number 17.

...I'd be reluctant to specify the algorithm too closely:  better to specify
a uniform format (that is, minimum length) and desirable properties (such as
cryptographic strength), but to leave it at that...

One of the problems with the v4 spec is that the suggested method for
generating client identifiers leads to implementation issues when the NIC is
changed, and I'd like to avoid that again.

I doubt it is possible to guarantee that UUIDs don't collide, so a server
implementation would be required to have some process for dealing with
collisions, regardless of how well-specified the algorithm might be.

--Barr

---

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

> changed, and I'd like to avoid that again.

There is also a different issue, one that concerns me somewhat, though
I'm not quite sure how much. If the client identifier is generated
from the MAC on an interface, and that gets saved in stable storage
(and reused from that point on per rule 1), there is an chance of
collisions occuring when the interface get moved to a different
machine, which subsequently generates a client indentifer using the
same algorithm. ONe is relying on the "add a random component" part of
the algorithm to generate good randomness. Maybe we can do that, but I
am somewhat concerned that this will not be robust enough in practice.

We really want the vast majority of client IDs to be generated by the
device maker at manufacture time (i.e, vendor ID plus serial
number). Is this something that we are confident can be done today on
effectively all devices?

> collisions, regardless of how well-specified the algorithm might be.

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.

Thomas

---

From: Jim Bound <[email-masked]>
Date: Tue, 10 Oct 2000 23:32:51 -0400

Thomas,

I think implementors need to pick good binding-ids.  Is as best we will
get.

In the current spec prefix+link-local will work but it has the NIC card
problem.  

I saw this when we restarted this discussion.  What we will do is make
the trade-off.

I am still not convinced that folks change their NIC cards enough to
loose the guranteed uniqueness we have in the current spec.
And it will come back to haunt us the first time servers crash because
of collisions.

Important trade-off decision we have to make.

/jim

---

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 11 Oct 2000 11:29:34 -0700

> -----Original Message-----
> From: Thomas Narten
> Sent: Tuesday, October 10, 2000 6:53 PM
>
[Barr]
> > One of the problems with the v4 spec is that the suggested method
> > for generating client identifiers leads to implementation issues
> > when the NIC is changed, and I'd like to avoid that again.
>
[Thomas]
> There is also a different issue, one that concerns me somewhat,
> though I'm not quite sure how much. If the client identifier is
> generated from the MAC on an interface, and that gets saved in
> stable storage (and reused from that point on per rule 1), there
> is an chance of collisions occuring when the interface get moved
> to a different machine, which subsequently generates a client
> indentifer using the same algorithm. ONe is relying on the "add a
> random component" part of the algorithm to generate good randomness.
> Maybe we can do that, but I am somewhat concerned that this will not
> be robust enough in practice.
>
[Barr]
...to help qualify this, my experience shows that many "low-cost" NICs have
reliability problems, yet many organizations prefer using them because the
cost of dispatching a skilled technician to diagnose network problems,
possibly replacing a faulty NIC after an hour or so of debugging, is MUCH
greater than simply replacing one NIC with another and throwing the old NIC
away!  Thus, in many instances, NICs are changed frequently.  If a certain
NIC fails 0.2% of the time, then   for a population of 100,000 NICs, one can
expect a NIC to fail every 3-4 days, which matches my experience pretty
well.

...this affects mostly legacy clients, as the reliability of NICs has been
steadily increasing, still, NIC failures do occur.

...because of the cost of diagnosing and repairing, or even returning failed
units to the manufacturer for refurbishing, having one NIC float from one
machine to another isn't very common, but what is quite common is for a
manufacturer to create identical configurations for a batch of, say, 3,000
machines, all based on an image with a particular NIC that was in the
manufacturer's lab.  There are a couple of scenarios where introducing such
machines into an environment will have the appearance of a "wandering NIC,"
as Thomas mentions.

[Thomas]
> number). Is this something that we are confident can be done today on
[Barr]
> > I doubt it is possible to guarantee that UUIDs don't collide,
> > so a server implementation would be required to have some process
> > for dealing with collisions, regardless of how well-specified the
> > algorithm might be.
>
[Thomas]
> different nodes asking for information.
[Barr]
...in DHCPv4, there is an explicit and an implicit algorithm for resolving
conflicts, although it definitely could have been better specified:  FIRST,
use the Client Identifier as an index to an IP address lease;  THEN, if the
Client Identifier is not present, use the Client Hardware Address.  [before
anyone starts quoting the RFC to me, I'll admit I'm not quoting it exactly]

...implicitly, the third choice is if the IP address requested has been
assigned or is available for assignment, AND the server *somehow* determines
that the requesting client is entitled to use it.

...what DHCPv4 DOESN'T do is to explain how to resolve conflicts when BOTH a
Client Identifier and Hardware Address are present, but don't indicate the
same IP address lease.  If we were to ever revise the v4 RFC, I'd like this
to be clarified.

...I think it was unfortunate to suggest using the MAC address in the DHCPv4
RFC without regard to also suggesting or specifying how to resolve
conflicts.  Each of us probably has a slightly different take on this,
witness the long discussion last year on the ISC server mailing list about
how to do this in a completely reliable, unambiguous way.

...that brings us to DHCPv6:  do we specify a resolution process, or let
that be an implementor's decision?  I'm pretty happy with the general idea
of using a client-invariant serial number or other identifier, combined with
one or more other elements, randomized cryptographically, as the basis for
the client identifer.  But the question at the beginning of this paragraph
needs to be answered.

...comments?  suggestions?

--Barr Hibbs
  UltraDNS:  "We connect the dots in dot COM!"

---

From: Richard Johnson <[email-masked]>
Date: Wed, 11 Oct 2000 12:56:07 -0700 (PDT)

> number). Is this something that we are confident can be done today on

As far as I understand, the answer is a definite "no".  Projects I
have worked on here at cisco from time to have a searched for a unique 
serial number, etc., which could be used in this way and I've always
been informed there isn't one.  If someone else on this list knows
better, I'm interested.

/raj

---

From: Bernie Volz <[email-masked]>
Date: Thu, 12 Oct 2000 10:48:13 -0400

Ralph:

No complaint from me. While originally I had thought that saving the bytes
in the packet would be nice, I quickly changed my mind (it was Ted in fact
that triggered this change), but then discussions started about not sending
the addresses. I feel it best to send the addresses so I'm glad we've
(hopefully) settled on that.

>1) The address expiration model: does the server expire addresses 
>(effectively make the valid lifetime 0) by explicitly setting the address 
>lifetime to 0 or implicitly by omitting the address from the IA?

I assume that both techniques are valid. Omitting the address from the IA
means that whatever lifetimes that client previously had apply and it is
free to use the address until the lifetimes end. Explicitly setting the
address lifetime to 0 means that the server requests the client stop using
that address immediately.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, October 12, 2000 8:17 AM
To: DHCPv6 discussion list
Subject: RE: DHCPv6 address model proposal...

I just finished writing this note, and see that it is *way* longer than one 
page.  So here's an executive summary:

The requirements of the failover protocol and explicit expiration of 
addresses in server-client messages combine to require that the client send 
its version of the IA - identifier and addresses - with every message to 
the server...

- Ralph

At 01:56 PM 10/11/00 -0400, you wrote:

>2) Ted was arguing NOT to include the list of addresses in client renewals
>(but to include them in REBINDINGS, which need to be explicitly addressed
in
>the DHCPv6 specification). I personally would like to see them included
>always, but we've debated that issue before.

I think there is need for some additional clarity in this debate.  I see 
two issues influencing the inclusion of addresses with IAs in 
client->server communication:

1) The address expiration model: does the server expire addresses 
(effectively make the valid lifetime 0) by explicitly setting the address 
lifetime to 0 or implicitly by omitting the address from the IA?

2) Failover protocol: a client using multicast to extend the assignment 
time of an IA must include the addresses with the IA in case the extension 
request is received by the backup server, which has not received the 
information about the IA from the primary server.  In the case where the 
backup server does not know about the IA, it assumes the IA from the client 
is valid, extracts the information about the IA from the client message and 
commits the IA to its binding database.  Note: I used the terms 
"mutlticast", "extend", "extension" and "assignment time" here to describe 
the situation in the abstract without conflicting with terms like "renew", 
"RENEWING", "REBINDING" and "lease" from DHCPv4.

I'll work backwards: (2) requires that the addresses be included in any 
messages that might be received by the backup in a primary-backup failover 
pair before the backup has received the IA binding from the server.  This 
is the case when the client uses multicast to extend the assignment time of 
an IA, corresponding to a DHCPREQUEST message from a client in REBINDING 
state in DHCPv4.  I've heard WG consensus to require that IA addresses be 
included in these messages from the client.

(1) comes into play in any message in which the client thinks it knows the 
addresses in the IA; the corresponding states in DHCPv4 would be 
INIT-REBOOT and RENEWING.  In both of those cases, the server must know the 
addresses in the IA before it can expire any addresses that are no longer 
usable by the client.  In theory, because the server is authoritative, the 
server knows what addresses are in the IA and need not get the current 
state of the IA from the client.  In practice, if the client and server are 
out of sync, the server may not know all of the addresses in use by the 
client and therefore will not know to expire those addresses.  I think the 
requirement for explicit expiration and recognizing that clients and 
servers may be out of sync requires, as a belt-and-suspenders measure, that 
the client send the addresses with the IA any time it has addresses it 
thinks it can use.

So, it appears to me that the client should always send the entire IA to 
the server.  If the client thinks the IA is "empty" (i.e., a new IA for 
which the client is requesting address assignment), the client sends no 
addresses with the IA; otherwise, the client sends what it thinks is the 
current list of addresses in the IA.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Oct 2000 10:39:02 -0700

> (hopefully) settled on that.

I think we should say that the client SHOULD send its addresses, and
that if it doesn't it may not get clean failover behaviour.   That way
the cell phone people can decide what's more important to them -
completely robust failover or small packets.

			       _MelloN_

---

From: "Ralph E. Droms" <[email-masked]>
Date: Thu, 12 Oct 2000 14:15:51 -0400 (EDT)

> completely robust failover or small packets.

It's not just failover - in the case where the client thinks it knows some
addresses (e.g., the equivalent of DHCPv4 INIT-REBOOT), the server won't
be able to expire any of the client's addresses if it doesn't know the
client's current IA.  For example, if the client has plugged into a new
network segment, served by a different DHCP server than the one from which
the client originally obtained its IA, the server won't be able to expire
the old addresses unless the client sends them to the server.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Oct 2000 11:29:15 -0700

Yes, well, that's why I wanted to specify that the client would throw
out any DHCP-acquired addresses not mentioned in a subsequent DHCP
Reply.  I still think that's the right thing to do - it adds a small
amount of hair to the client, which has to remember that it got some
addresses from DHCP and some from stateless, but I think it's actually
more efficient.   Besides, the client shouldn't be sending addresses
it got from stateless addrconf to the server, should it?   So it
*still* has to remember.

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Thu, 12 Oct 2000 22:01:24 -0400

>it got from stateless addrconf to the server, should it?   So it

Exactly.

- Ralph

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 13 Oct 2000 14:08:44 -0700

[Thomas]
> 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: Jim Bound <[email-masked]>
Date: Sun, 15 Oct 2000 19:02:51 -0400

I suggest if we head down the path to have dhcpv6 clients listen for
UUIDs on the LAN we add extensions to Neighbor Discovery.  Either way to
get this done and with consensus will not be quick.  Do we need to do
this for version 1 of dhcpv6?

Organizational User Identifier (OUI)
Why not state that another approach is to go get an OUI from XXX (I will
have to recall who) and we assume they are unique within an
organization.  Then we can work on future drafts or work to see if we
can and how we build a protocol to listen to each other to figure out UUID
or add extensions to Neighbor Discovery.

Worst case is the link-local + prefix will work for version 1.
And we have nothing to do?

/jim

---

From: Ralph Droms <[email-masked]>
Date: Sun, 15 Oct 2000 15:11:38 -0400

Executive summary:  There are two types of name collisions possible in the 
address model we've been discussing: collisions between IA identifiers and 
collisions between UUIDs.  The two types of collisions may have different 
outcomes.  Collisions between IA identifiers from hosts on different 
subnets may cause duplicate address assignment...

=====

At 02:08 PM 10/13/00 -0700, Bernard Aboba wrote:
>identical UUIDs on the same LAN.

Bernard - your "only" in the sentence prompted me to do a little thinking 
about name collisions...

I think we need to clarify exactly what we mean by a collision - a 
collision between UUIDs will have one kind of impact on client-server 
operations while a collision between IA identifiers will have a different 
kind of impact.

I'm working here from our current working definition of an IA identifier as 
(UUID, binding-id), where UUID is a unique identifier for a host and a 
binding-id is an opaque cookie used to differentiate between IAs associated 
with one host.  In other words, IAs (123, 1), (123, 2) and (456, 1) all 
represent different IAs, and the first two IAs come from the same host.

So, suppose we have a network like this:

     UUID 123
     +--------+          /----\
     |        |         /      \
     | Host A +-------+ Subnet X +-\
     |        |         \      /    \---\  +-------------+
     +--------+          \----/          \-+             |
                                           | DHCP server |
     +--------+          /----\          /-+             |
     |        |         /      \    /---/  +-------------+
     | Host B +-------+ Subnet Y +-/
     |        |         \      /
     +--------+          \----/
     UUID 123

where hosts A and B have both chosen to use the same UUID.  Now suppose 
hosts A and B ask for IAs (123, 1) and (123,2).  The DHCP server will 
assign some address from subnet X (IP.X) to (123,1) and some address from 
subnet Y (IP.Y) to (123,2).  The server will treat the two IAs as 
independent.  For the purposes of assigning other parameters, the server 
may treat the two IAs as being associated with a dual-homed host.  So, in 
this scenario I see that the DHCP server won't make any incorrect IP 
address assignments, but may make some errors in assigning other parameters 
because the server has reason to believe the two IAs are from the same host.

Now, suppose hosts A and B both contact the DHCP server for addresses for 
the same IA, (123, 1) and A goes first.  The DHCP server will assign IP.X 
to the IA and return that IA to A.  Later, when B contacts the DHCP server, 
the server will assign IP.Y to the IA and, presumably, release IP.X from 
the IA (more about this later!).  When A contacts the server to extend the 
assignment for (123,1), the server will assign an address from subnet X 
(perhaps IP.X again).  The net effect is that A and B each get an 
appropriate address, while the DHCP server bounces the IA back and forth 
between IP.X and IP.Y.  No specific problems, yet, but it sure doesn't feel 
right to have the IA out of sync with some of the address assignments.

Well, perhaps there is a potential problem.  In this diagram:

     UUID 123
     +--------+          /----\
     |        |         /      \
     | Host A +-------+ Subnet X +-\
     |        |         \      /    \---\  +-------------+
     +--------+          \----/          \-+             |
                                           | DHCP server |
     +--------+          /----\          /-+             |
     |        |         /      \    /---/  +-------------+
     | Host B +-------+ Subnet Y +-/
     |        |      ---\      //
     +--------+     /    \----/
     UUID 123      /
                  /
     +--------+  /
     |        | /
     | Host C +/
     |        |
     +--------+
     UUID 456

suppose hosts A and B, sharing IA (123, 1) have been assigned IP.X and 
IP.y.  Now, host C contacts the DHCP server for an address for IA (456, 
1).  If the DHCP server has IP.X assigned to (123, 1), presumably IP.Y is 
free and may be assigned to host C.  Of course, host B is still using IP.Y, 
so there's a duplicate assignment of IP.Y to both B and C (more about this 
later, as well).

So, let's come back to the earlier scenario, where nodes A and B are 
sharing IA (123, 1).  We need to define the server behavior in the case 
where and IA moves from one subnet to another.  This is an area of some 
unclarity in DHCPv4.  If we make an assumption that all UUIDs or IA 
identifiers are unique, do we want to specify that a DHCP server MUST, 
SHOULD or MAY release any previously assigned addresses when an IA moves to 
a new subnet?  Perhaps there's another alternative - the server adds some 
more addresses to the IA (leaving the old [presumably now unusable] 
addresses in the IA)?

At the end of the second example of shared IAs, I noted the case in which 
IP.Y might be assigned to both nodes B and C.  Will the DHCP server 
(through ping or some other remote DAD mechanism) or the nodes themselves 
(doing DAD) notice the problem?  Given that the server or the nodes have 
noticed the problem, is there anything the server or the nodes or an 
administrator can do about it?

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Mon, 16 Oct 2000 00:12:43 -0400

Ralph,

prefix + link-local won't work now regardless of the nic issue. 
The reason is the security benefits from UUIDs.  So I forget that.

OUI - I just checked the IEEE page and that won't work cause you have to
buy it and order it and whatever and that is not good as we want nodes
to be able to have multiple IAs if they desire, and this will put just
to much administrative complexity on the end user site.

But we do need to nail down the UUID.  Maybe Barr's idea will work for
version 1? 

Then I thought in your diagram below:

     UUID 123
     +--------+          /----\
     |        |         /      \

Host A and Host B and C are on different subnets.  In IPv6 you cannot
duplicate prefixes across links.  

So it would be valid to have subnet prefixes:

4ffe (A's subnet) Subnet X
3ffe (B's subnet) Subnet Y
3ffe (C's subnet) Subnet Y

It would not be valid to have:

4ffe (A's subnet)
3ffe (B's subnet) 
4ffe (C's subnet)

So IPv6 rules out 4ffe from being on subnet Y.

If we extend the IA model as follows:

  (Prefix, UUID, binding-id)

Host A IA would be:  (4ffe, 123, ?)
Host B IA would be:  (3ffe, 123, ?)
Host C IA would be:  (3ffe, 256, ?)

We can use DAD today (I need to check the code for sure) to take the
prefix+UUID and do DAD.  So we can prevent duplicate UUIDs on a Link
(subnet in IPv4 terms).  When prefixes change though thru router
advertisements the UUID would have to be reverified.  We would have to
write all this up in DHCPv6 to if we wanted to use DAD in IPv6.  Also if
their are not routers on the link and ONLY a DHCPv6 server we need to
know that (the IPv6 Dentist Office Scenario).  Other parts need to be
checked if we think this is a good idea.  This would I think answer
Bernard's question to discover if the UUID was duplicated on a link. The
IPv6 implementations already have this code running so not hard to

>so there's a duplicate assignment of IP.Y to both B and C (more about this 

Now the server would differetiate A and B by the different prefixes when
C asks for an address because it would know:

Server Database:
4ffe 123 ? := IP.X
     aaa ? := IP.X+1  (other UUIDs on 4ffe)
     bbb ? := IP.X+2    "      "       "
3ffe 123 ? := IP.Y
     ccc ? := IP.Y+1  (other UUIDs on 3ffe)

In this case the server would not IP.Y has been given out and would give
Host C IP.Y+2.

>more addresses to the IA (leaving the old [presumably now unusable] 

I think the answer is yes and it should be a SHOULD.  Not all clients
that move may be able to do the release, hence, not a MUST.  But if the
client did not release the addresses to the server it MUST stop using
them when it roams to another subnet, because the addresses may not be 
reachable at the next location.

But lets say the client C moves to subnet Z now which has prefix 5ffe.
The client builds a new IA but keeps its UUID for security:

5ffe 456 ? := IP.Z

The old:

3ffe 456 ? �? := IP.Y+2 would time out.

>administrator can do about it?

With the prefix in the IA B and C could never be assigned the same
address so it cannot happen.  Nor the same UUID on the link because of 
DAD in IPv6.

The scenario above would work with all existing IPv6 implementations
quickly for deployment and not much new code would have to be
reinvented.

The security advantage of the UUID would still be applicable even when
the node roams.

regards,
/jim

---

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

> From: Jim Bound
> Sent: Sunday, October 15, 2000 9:13 PM
>
>
> Ralph,
>

...wow!  this is all very interesting, but seems to have strayed from my
original point, which was meant to cover the following case:

  +------------+     +-----+
  |   Host A   |     |     |
  | Client ID: +-----+  N  |
  |    1023    |     |  E  |     +========+
  +------------+     |  T  |     |  DHCP  |
                     |  W  +-----+ Server |
  +------------+     |  O  |     |        |
  |   Host B   |     |  R  |     +========+
  | Client ID: +-----+  K  |
  |    1023    |     |     |
  +------------+     +-----+

Thus my two questions:
(1) can we reliably detect that Client ID 1023 has been chosen by DIFFERENT
hosts?
(2) can we SUGGEST ways to resolve this collision that don't create other
problems?

(1) arises because I'm not convinced that it is possible to guarantee
uniqueness of any identifier, so, better to be prepared to deal with its
occurrence

(2) arises because of similar problems with the DHCPv4 client identifier

--Barr Hibbs

---

From: Jim Bound <[email-masked]>
Date: Mon, 16 Oct 2000 13:35:56 -0400

I sent mail last night can you respond to that where yes we can verify
this on a link using DAD but not across several links.  Links in IPv6
are subnets in IPv4 basically.

>(2) can we SUGGEST ways to resolve this collision that don't create other

Yes in same mail above I suggest using the IPv6 Prefix which is unique
to each link in a site.  Can you respond to that mail.  I think it
solves the problem.

>uniqueness of any identifier, so, better to be prepared to deal with its

Yes that is why the prefix must be part of the IA in DHCPv6.

>(2) arises because of similar problems with the DHCPv4 client identifier

Yes I can see that DHCPv4 has same problem.  The tightened up rule set
for IPv6 can help for DHCPv6 with the prefix allocations.

regards,
/jim

---

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

Here's my latest summary of the DHCPv6 address model.  I've included a 
summary of changes from the previous model and  a list of 3 TBD issues at 
the end of the summary.

Please review this summary 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: DHCPv6 address model.  Here's my summary of the discussion:

DHCP clients and servers will use Identity Associations (IAs) to
manage IPv6 addresses.  Each IA will have:

* a unique identifier
* a set of IPv6 addresses
* a renewal time

Clients and servers use the unique identifier to identify the IAs in
protocol messages.

Each IPv6 address has an associated preferred and valid lifetime.  The
lifetimes are determined by the server and handed to the client.
There are no restrictions on the scopes or number of IPv6 addresses in
an IA; an IA might contain just one IPv6 address or it might contain a
collection of global- and  site-local addresses.

The renewal time defines the time at which the client must contact the
server to get the current state of the IA (call this "renewing" the
IA).  The renewal time is independent of the address lifetimes of any
of the lifetimes of the IPv6 addresses in the IA.  It makes most sense
for the renewal time to be less than the preferred lifetimes of all of the
IPv6 addresses in the IA, and the renewal time must be less than the
valid lifetimes or the client will lose the use of some expired
addresses.

When the client renews an IA, the server tells the client about the
current set of IPv6 addresses in the IA.  The server may change the
set of addresses or the lifetimes of existing addresses during this
renewal.  For example, setting a longer lifetime on an address already
in the IA is the equivalent of extending the lease on a DHCPv4-managed
address.  Setting the valid lifetime to zero marks an address
immediately as no longer valid for the client.  Adding a new address
to the IA can be used for renumbering.  If the client has an address
assocaited with an IA that is not explicitly mentioned in a message
from the server, the client leaves the address in the IA and may
continue to use the address until the lifetime for the address
expires. In any event, the server is authoritative about the set of
addresses and lifetimes in the IA.

The client must send all of the addresses associated with an IA when
renewing the IA.  The server examines this list of addresses and may
extend the lifetime or set the lifetime to zero of any addresses in
the IA.  The server may also add new addresses to the IA.  The server
returns the new IA to the client.

In all other transactions, the client sends the IA identifier and the
server returns IA identifier along with the list of addresses in the
IA.  The server is authoritative and the client simply records the IA
and configures the associated addresses.

Changes from previous summary:

* (3rd para) DHCP server does not hand out link-local addresses (input
   from Jim Bound)

* (5th para) If the server does not include an address in the IA, the
   client is allowed to continue using the address until its valid
   lifetime expires (input from Bernie Volz)

TBD:

* During the address model discussion, we noted that the current
   spec leaves the details of the renewal process to the DHCPv6 client
   implementor.  I heard consensus that we should define the renewal
   process and include it in the spec.

* We have not yet reached consensus on when the client sends the
   addresses in an IA - with every messages or only when trying to
   locate a new DHCP server (as in DHCPv4 REBINDING state)?  And, is
   the wording for sending the addresses SHOULD or MUST?

* There is still a minority position that the contents of the IA from
   the server should be authoritative, and any addresses not explicitly
   included in the IA from the server should be discarded immediately
   by the client.