Subject: RE: DHCPv6 client identification...

From: Mark Stapp <[email-masked]>
Date: Thu, 07 Sep 2000 17:56:47 -0400

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

At 11:59 AM 9/7/00 -0400, you wrote:
>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: Jim Bound <[email-masked]>
Date: Thu, 07 Sep 2000 20:29:09 -0400

Mark,

>components has to be used in forming the client-id.

I can live with this and prefer it.  My impression was the WG has always
wanted this specified?  

>client has no existing state for the uuid+binding-id tuple.

I second that.

/jim