Subject: RE: DHCPv6 address model proposal...

From: Bernie Volz <[email-masked]>
Date: Wed, 6 Sep 2000 18:23:43 -0400

>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'm not sure we should comment too heavily on how this is implemented
(internet-drafts usually stay away from forcing implementations).

A simple server could simply use the UUID as a hash and then look through
all the entries matching that UUID for the other two ids. Yes, it means it
can't hash over the entire field.

Or, a simple server could hash on/use the byte stream of:
	uuid-len:uuid:fill1:ifid-len:ifid:fill2:appid-len:appid:fill3
where fill1, fill2, and fill3 are filler bytes (0) up to the maximum length
allowed for each of these fields. That way, you always have a unique value
and never any potential for overlap. Sure, it isn't as compact as it could
be but it also doesn't impose any potentially unrealistic restrictions. The
maximum length for each identifier is likely something that we'd want to
specify anyway.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 5:57 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...

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

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: Ted Lemon <[email-masked]>
Date: Wed, 06 Sep 2000 15:46:36 -0700

> 	uuid-len:uuid:fill1:ifid-len:ifid:fill2:appid-len:appid:fill3

Right, you could have a complicated way of solving the problem.  Of
course, a representation like this would waste a lot of memory.  The
question is, why do you want the complicated solution - what does it
buy us?

			       _MelloN_