Subject: RE: DHCPv6 client identification...

From: Bernie Volz <[email-masked]>
Date: Thu, 7 Sep 2000 11:59:22 -0400

Mark:

The only problem with the consistent ids across reboots is for clients that
either don't have permanent storage or where the permanent storage has
failed. But, in these cases we really should require the client to first
release any resources it might have had. BTW: This is a reason I personally
don't like the interface id just being a number such as 1, 2, 3. A more
descriptive value means that the mac address or other identifier for the
interface can be used and avoid some of the problems. Agreed that you create
others, such as by swapping out a card for a replacement; in that case the
two are really identical and there is no reason for the client to get
different addresses.

Regarding the application issues, I think part of the application/DHCP API
would be for the application to register continued interest in the address.
One simple way to do this is to maintain a reference count on the address in
the DHCP client that is incremented when an application requests the address
and decremented when it releases it (note that this is an explicit release,
not just it has no open connections - process rundown would need to notify
the DHCP client). Once the reference count is 0, the DHCP client could
either then release the address or just not renew it next time it expires.

Across a reboot, the DHCP client would reset the reference count (and
release the address). For a warm reboot, the application is still running
and therefore the client takes the same steps it does for other addresses to
determine if they are still valid or whether the client has moved to a
different network.

- Bernie

-----Original Message-----
From: Mark Stapp [mailto:[email-masked]]
Sent: Thursday, September 07, 2000 11:06 AM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 client identification...

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 
that interface has a DHCP-assigned address. In Ted's example:

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

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

---

From: Bernie Volz <[email-masked]>
Date: Thu, 7 Sep 2000 19:59:57 -0400

Mark:

I agree with you that we can make the binding-id a single opaque value. And,
leave it up to clients as to how they use these for requesting addresses.

Going back to Ted's original message, he had 4 cases:
>	(a) Giving a DHCP client a unique identification that does
>	    not change when network hardware changes

The client could create binding-ids that support this if the client wishes
to implement it. While this is a good goal, I don't think it is a
requirement (for the protocol to specify). Especially in IPv6 as
autoconfigured addresses will change anyway if the 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.

A change in the binding-id could be used to do this. The client is free to
generate any ids it wants. A change in binding-id is used to get a new
address.

>	(c) Providing a way for the server to tell that two identity
>	    associations actually represent one client.

The UUID (not binding-id) accomplishes this.

>	(d) Providing a way to have a single authentication
>	    key work with all of a client's identity associations.

The UUID accomplishes this.

- Bernie

-----Original Message-----
From: Mark Stapp [mailto:[email-masked]]
Sent: Thursday, September 07, 2000 5:57 PM
To: DHCPv6 discussion list
Subject: RE: DHCPv6 client identification...

Bernie,

I hear you, but I still think that there are two kinds of info that are 
useful, and that both are available. As you noted in one of your earlier 
emails, some kind of link address must be available anyway. I think that 
that doesn't _have_ to be part of the binding identification, though some 
server implementations _might_ use that address to make decisions about 
lease bindings. I'm only trying to suggest that, rather than mandating that 
some physical characteristic be used in addition to the uuid, we only 
mandate the opaque binding-id. As you say, that only poses a problem for 
clients who've lost all of their state. The link address information is 
still available to the server, which may use it as part of its 
internal  implementation, but it doesn't _have_ to.

The common workstation client could simply use binding-id '0' (or '1') to 
refer to its single ethernet interface, and that interface could be changed 
without confusing the server or generating new address bindings. The laptop 
client in Ted's example must maintain enough state along with the leases it 
obtains to use the binding-ids consistently. If the laptop loses its state, 
it may inadvertently swap the relationship between the two interfaces and 
the two binding-ids. I guess I don't see more than two possibilities there:

1) the server doesn't care which interface either set of addresses is 
associated with. That is, the server doesn't distinguish between the two 
link-local addresses. For example, it doesn't detect wireless cards or give 
out different addresses to wireless cards. The server either notices that 
the relationship between links and binding-ids has swapped, decides that it 
cares about that, and swaps ip bindings to match, or it doesn't notice or 
doesn't care and it gives out the existing ip bindings that match the 
binding-ids.

2) the server cares which addresses are associated with each link address. 
The server either clears its existing binding info for the uuid+binding-id 
tuples, and creates new bindings, or it has recorded the previous link 
addresses, notices what has happened, and updates its bindings to reflect 
the new binding-id to interface relationship.

That's why I prefer an arbitrary binding-id. It saves the expense of 
describing how to use some semantically meaningful component, and it avoids 
over-specification of implementations' internal data structures. Some 
implementations will use link addresses, host-names, user-class strings, 
vendor-specific strings, etc. to make decisions, but none of those 
components has to be used in forming the client-id.

I absolutely agree that it would be very handy for clients to set a 'no 
state available' bit in their initial message as an indication that the 
client has no existing state for the uuid+binding-id tuple.

-- Mark