Subject: RE: DHCPv6 address model proposal...

From: Bernie Volz <[email-masked]>
Date: Wed, 6 Sep 2000 17:41:46 -0400

>> Sure. What I meant was the request the system generates when it comes up,
>> instead of an application or otherwise requested allocation. All systems
are
>> likely to request this whenever DHCP is enabled on an interface, so
rather
>> than having them supply an identifier, make this the no (or null)
>> identifier. That way, a simple client that only supports "one" allocation
>> never has to deal with this identifier.
>
>But there *has* to be an identifier.  Right now it's the local link
>address, but as we discussed last week, this doesn't work well,
>because the local link address can change arbitrarily based on
>swapping hardware.  I think we need this the *most* in the simple
>case, actually.
>
>			       _MelloN_

I think we're discussing different issues? When I was saying identifier, I
meant "application index". Agreed that a UUID and "interface index" needs to
be supplied (using terminology from your original message).

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 06 Sep 2000 14:56:34 -0700

> be supplied (using terminology from your original message).

Okay, we agree on this, sort of.  I actually spent some time thinking
about how to make this work when I composed my other reply to you, but
I finally decided that there was no way to do it that didn't force
significant complexity on the server.  For something like the ISC DHCP
server, which practically revels in (I hope useful!) complexity, this
is not such a problem, but for something like an Apple Airport base
station, I think it would be.

Basically, if you force the server to treat the application ID as an
additional qualifier, you force it to have a two-stage lookup - first
it looks up the UUID, which returns a data structure that contains all
the information about all the identity associations for that UUID, and
then you do a lookup in that.   I think for a trivial embedded DHCP
server, you really want to just take the identity association as a
whole and do a single lookup on it.   I don't think it's right to
require the additional complexity in this protocol specification.

Note that you are forced to do this because if you don't, you run the
risk of the interface index and optional application index combining
with the UUID to produce something that's no longer unique.   So you
could argue that the DHCP server should just mash them all together
and do a lookup on that, but I think that would be a bad idea.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Thu, 07 Sep 2000 02:16:11 -0400

Ted,

Sorry I am catching up.  Just got back from labor day really.

>require the additional complexity in this protocol specification.

I think we need Instance or Application-index or whatever.  But I don't
think its a problem for a server if the field is split or all in one
chunk.

Interface   App-Index-Instance   UUID

or 

UUID == Interface+App-Index-Instance+client ID

In either case I think

16bits+16bits+96bits is required and sufficient.

When I do the hash, link-list, or btree search I will concatenate them
at the server and do the lookup once (unless I don't get hit right).

Either way your search will be the same.

>>and do a lookup on that, but I think that would be a bad idea.

Superb argument.  Thats right we want the uuid to be alone for the
security too.

They should be split up in the eventual message format.

regards,
/jim