Subject: RE: DHCPv6 client identification...

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

Well, there's also:

+-------------+-----+----------+-------------+---------------+--------------
----+-
| option code | len | UUID-len | UUID ...    | interface-len | interface-id
... |
+-------------+-----+----------+-------------+---------------+--------------
----+-

     ---------+--------------------+
      app-len | application-id ... |
     ---------+--------------------+

where the interface-len and app-len are from 0 to <n>, inclusive.

Regarding the application-id, the example of www.xyz.com was bad. And,
perhaps the concept is bad. I was thinking of this as more of a
"kind-of-service" that the DHCP server could use to select a specific
"range" of addresses. I guess this is probably not a good use of this
(especially for IPv6 addresses). [And DHCPv6 will likely have other means of
doing this - like user class, etc.]

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 5:22 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 client identification...

> The only item I still don't fully agree with is the fixed vs
variable-length
> issue. I wasn't saying that I was using a PREFIX. I feel the interface id
> and application id should be SEPARATE from the UUID. Each address
allocation
> has these three values associated with it, but they are separate items not
a
> single byte-string.

I think that they will be sent seperately.   The question is, do we
want to force the server to deal with them seperately.   Also, think
about how options are formed.   Do we want:

+-------------+-----+--------+-------------+-----+------+
| option code | len | prefix | option code | len | UUID |
+-------------+-----+--------+-------------+-----+------+

or:

+-------------+-----+--------+------+
| option code | len | prefix | UUID |
+-------------+-----+--------+------+

I think the second option is pretty desirable, so we should have a
good reason for not doing it.

> There is no disagreement that fixed is easier to deal with. But, I just
hate
> limiting ourselves today for no good reason. Are you certain that no
system
> (such as a server) might not want more than 256 addresses at a time for an
> interface? Sure, it could change the UUID, but we want to get away from
> that.

We could make the application prefix 16 bytes instead of 8...   I
agree that limiting things this way sounds a bit lame.

> Also, if applications are going to be requesting addresses (we're all
> assuming this, aren't we?), might it not be useful for the server to
> potentially be configured to provide a specific address (from a pool) for
a
> particular application? And having that be something like "www.xyz.com" is
> far more useful than having it be 1.

Hm.   Yes, but...   Supporting a fixed association like this cleanly
opens a huge can of worms.   What if you want to move the application
to a different client?   Is there a way to tell the server that {0,
www.xyz.com, UUID1} and {0, www.xyz.com, UUID2} are the same?   How
far do you want to carry this?   I think as an academic point, you're
right, but as a pragmatic point, I don't think we're answering a
common case here, and I think that figuring out how to do this right
is a much harder problem than we should be considering, and not
something that this protocol really needs to address.   The ability to
get more than one IP address?   Sure.   The ability to do fancy
associations?   Not sure.   I think exporting this problem to the
server is too much - if the client wants consistency, it should be
responsible for maintaining it.

			       _MelloN_

---

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

> And DHCPv6 will likely have other means of doing this - like user
> class, etc.

Right, this sounds good.

			       _MelloN_