Subject: RE: DHCPv6 client identification...

From: Bernie Volz <[email-masked]>
Date: Wed, 6 Sep 2000 16:14:13 -0400

Ted ... OK, I'm in agreement with you regarding the interface identifier.
You give good reasons for this. (The one situation that might be a problem
is where a host has no stable storage or looses this and might come up with
numbering the interfaces differently  and if these are on different physical
networks yet are served by a single server, the server might find a conflict
where the "old" address for the ids isn't valid. But, that just means it has
to place that address into a weird state until the lease would expire.)

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.

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.

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.

- Bernie Volz

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

> Why do you need an interface index? Unless we expect a client to have more
> than one interface connected to a single subnet, do we really need this?
The
> interface identifier is implied by the source of the client's request at
the
> server (giaddr or received interface).

I am trying to get away from the notion that an IP address is uniquely
identified by {client identifier, physical network}.   This causes
lots of obnoxious ambiguity in RFC2131 that I don't think adds any
value - to correctly implement the protocol, I have to allow clients
to have active leases with the same client identifier on different
physical networks at the same time, which means that when a client
moves from physical network to physical network within the same
administrative domain, the server may wind up with active leases for
that client on more than one network when the client is only connected
to one network.   Having one identity association per network
interface avoids this problem - if you are multiply attached, you'll
have multiple identity associations, and if you're singly attached, I
can nuke your old lease when you change networks.

Why have an interface index?   I'm trying to avoid a situation where
you have a client with lots of network interfaces that change around -
e.g., a laptop that has an ethernet card and an 802.11 card that get
swapped in and out - that winds up not being able to keep a static
address, or winds up consuming extra addresses, because the DHCP
client doesn't maintain a consistent identification for each
interface.   Consider the following sequence of events:

(1) laptop is powered on with an ethernet card in pcmcia slot 1.
(2) laptop gets IP address using DHCP for {0, UUID}
(3) application starts, requests the client to get another identity
(4) client gets that identity using {1, UUID}
(5) user inserts 802.11 card, which acquires an identity using {2, UUID}
(6) user power cycles laptop
(7) laptop gets IP address for ethernet card using {0, UUID}
(8) laptop gets IP address for 802.11 card using {1, UUID}
(9) application starts, gets its IP address using {2, UUID}

Note that the IP addresses assigned to {1, UUID} and {2, UUID} will
likely be different the second time through.

You see the problem?   Using the interface index doesn't actually
solve this problem, but it makes it less likely to happen, and it also
raises the issue in the mind of the implementor.   I'm not sure this
matters, but I mention it because I think it's useful to think about.

As for having variable-width prefixes, I think this is not a good
idea, because it invites the possibility of identifier clashes.  The
algorithm for generating a UUID may work pretty well, but it's
probably predicated on the idea that everybody will use a similar
algorithm.  So what happens when you modify this algorithm by allowing
the client to attach arbitrary strings to it?  How do you avoid the
case where {prefix1, UUID1} and {prefix2, UUID2} happen to be the same
quantity?

I can implement an algorithm that avoids this problem by doing a
two-stage hash lookup, but do we want to *require* that all DHCP
server implementors implement this more complicated algorithm?  If you
use a fixed-width prefix that is always present, I think you avoid
having to do this, and I think that's worthwhile.

			       _MelloN_

---

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

> has these three values associated with it, but they are separate items not a

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.

> interface? Sure, it could change the UUID, but we want to get away from

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

> 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: Jim Bound <[email-masked]>
Date: Thu, 07 Sep 2000 02:08:42 -0400

Ted,

Absolutely correct.  As side note I was one of the key principles in
IPv6 that shot variable addresses in the head and had some formiddable
opponents.  I am pretty adamant about this the second case is much less
code all around too.

Also I had suggested in earlier response use 
  16bits for interface
  16bits for instance

thats 32K of interfaces and 32k of instances.  something else in dhcpv6
will break before that does.

regards,
/jim