Subject: RE: DHCPv6 client identification...

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

Ted:

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 suppose that if we want to be really robust, the interface index is
useful. However, why not just use some opaque identifier such as the
hardware (or link local in IPv6) address. This avoids the problem of
interface number, since the number may not always be fixed (ie, if I add a
new interface to a system, it might change what was interface 1 to interface
2). There is the problem of devices without hardware addresses, but these
could fall back to an index as you indicated. The only problem with using
the hardware address is probably its length. But, then again you already
need to include SOME information for the server to be able to communicate
back to the client, so if this same piece of information were used, you're
all set.

I also suggest we don't limit the application index to any fixed length. We
could certainly specify a limit (such as 16 bytes), but why not let the
client implement pick what it wants. And, as I mentioned in my reply to the
address model proposal, I'd suggest using a null (or absent) application
index to mean the default. That way, we don't argue as to whether it is 0 or
1 or whatever. It's also nice since it reduces the size of the normal
(default case) messages since there is no need to include it.

The exact format of how this information is communicated hasn't been
specifically stated. Let me suggest:
- The unique client identification (only) is sent in an option/extension.
- The application index (or address index or whatever) is also sent as a
SEPARATE option/extension.
- The interface index is based on the whatever link-layer information is
sent by the client to allow the server to communicate with it (in IPv6, the
link local address). This would likely be carried in the packet header since
it will be required.

- Bernie Volz

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

We had a nice discussion about client identifiers during the
conference call.  The issues that I remember us talking about are:

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

For (a), we seem to have pretty much agreed that we need a
universally-unique identifier, similar to what Intel has done in the
PXE specification.

We can solve (b) by having the client come up with more than one
UUID.   However, to solve (c) and (d), it would be better if we
defined a way to have the DHCP client specify a UUID and then specify
a modifier to that UUID, so that the identity association would
actually be made up of {modifier, UUID}.   Authentication would be
done based on {UUID}, not on {modifier, UUID}, and the server could
therefore tell that two identity associations are the same client by
noticing that although the modifier is different, the UUID is the
same.

In order to avoid creating the possibility of namespace clashes, I'd
suggest that we specify the modifier as a 16-bit number, defined by
the client, that's just an index.   So if a DHCP client had two
network interfaces, its two identity associations would probably be
{0, UUID} and {1, UUID}.

There is one problem with this: if the DHCP client is not consistent
about assigning prefixes, it would be possible for it to assign {0,
UUID} to one network interface one time, and {1, UUID} to that network
interface the next time.   This shouldn't be a huge problem for a
typical client, but for fancy clients the client implementor might
want to actually maintain its own mapping between the network hardware
address and the index.

It might also make sense to have the modifier be an 8-bit interface
index and an 8-bit application index, with application index == 0
always being the initial configuration for that interface.   So a
typical client with two network interfaces would have these two
identity associations: {0, 0, UUID} and {1, 0, UUID}.   And if an
application decided to listen with its own address on each interface,
then the client would have four identity associations: {0, 0, UUID},
{0, 1, UUID}, {1, 0, UUID} and {1, 1, UUID}.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Wed, 06 Sep 2000 12:01:17 -0700

> 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: Mark Stapp <[email-masked]>
Date: Thu, 07 Sep 2000 11:06:13 -0400

I think Ted uses a really interesting example. I'd like to suggest that 
client implementations MUST maintain a consistent association between the 
binding-id part of the identification and a physical interface as long as 

>likely be different the second time through.

The client has active bindings for the ethernet and the 802.11 devices, but 
doesn't use the binding-id part of the client-id consistently across 
re-starts. That shouldn't happen: the client should be required to use the 
client-id tuple consistently once it has acquired lease(s) with it. 
Requiring consistent use means that we can just use a single 16- or 32-bit 
binding-id along with the UUID to form the tuple: we don't need to require 
the client to manage 'interface indexes', we just have to require that the 
client use the binding-id consistently during the lifetime of the leases 
associated with it.

The other part of this that's interesting is the 'application-requested' 
address situation. This example raises several very interesting questions. 
What does that application do with the address that it asked for across 
reboots? What do the stack and dhcp client do with the address? When this 
host reboots, its dhcp client and stack find three dhcp client-identities, 
and a set of one or more addresses associated with each of those three. I 
can imagine how the dhcp client handles the two binding sets that are 
associated with the interface cards, and I suppose that it pays attention 
to those leases' expiration times, and renews them pretty much 
indefinitely. Is the stack supposed to know which of the three was 
'application-requested'? Is there some way for the application to determine 
that one of the address sets was allocated by a previous instance of the 
application process? Is the stack supposed to prohibit other processes from 
using the address(es) associated with that application-requested 
allocation? Is the dhcp client supposed to keep renewing those addresses 
indefinitely, even if the application doesn't run before the leases' 
renewal time(s)? What if the application never runs again?

I like the example a lot, but I dislike having to answer all of these 
questions now, in the absence of concrete proposals about the interaction 
between applications and the ipv6 dhcp client. I feel that we're trying to 
imagine a capability from the server-side, a capability that we all seem to 
think will be useful (and possibly inevitable). But the capability is 
fundamentally a client problem, and I don't personally see enough detail to 
know what I would have to do if I were to have to implement a client. We 
should either be extremely restrictive, and require that the dhcp client 
release all application-requested lease bindings upon restart, or we should 
specify that the dhcp client will ignore and not renew any 
application-requested bindings. Either of those choices seems awkward to 
me. Either way, we'd have to require that the dhcp client would distinguish 
application requested bindings from stack- or interface-requested bindings. 
We either need to add a significant work-item to decide how the dhcp client 
should handle this hypothetical application-level capability, or we need to 
decide that we won't chase our tails trying to handle it until it exists.

The client-id mechanism that's been proposed seems flexible enough that it 
can accomodate multiple requests for new bindings from a single host, even 
a host with a single physical interface. That suggests that the protocol 
can handle application-requested bindings whenever they show up, although 
dhcp client behavior will have to be carefully specified.

-- Mark