loophole with limiting leases per client

[HIBBS, BARR (PB)]

Brian--

I can't really comment about the 3.0 version, which I haven't yet fully
dissected, but the 2.0 version definitely records a hash table entry for any
client receiving a dynamic lease that is "indexed" by BOTH client hardware
address and client identifier.

This behavior permits a "roaming" client (i.e., one who moves from one
subnet to another -- imagine a laptop computer with an embedded NIC) to be
offered a lease for multiple subnets (more or less simultaneously, depending
on the remaining lease duration) which is the behavior suggested by RFC2131.

Because the most prevalent clients (Microsoft Windows-based) create a client
identifier from the hardware type octet and the client hardware address, one
of these hash table entries is mostly redundant.  But for clients where the
client identifier is not based on the hardware address (think something like
"brians_pc") then this distinction is essential for differentiating
instances of a roaming client.

When you say that one of your clients with a host entry receives a dynamic
address, I assume that you are excluding unknown hosts from receiving
offers, and that your host declarations do not contain a fixed-address
declaration, as version 2.0 clearly favors fixed host addresses over dynamic
allocation.

I guess I don't see why you think this behavior is incorrect or undesirable.
We have extensively tested combinations of stationary and roaming clients,
fixed host address declarations, dynamic address assignment, and clients
with multiple NICs or laptops with embedded NICs in docking stations as well
as PCMCIA NICs, and have always found the behavior to be consistent with our
understanding of how addresses should be allocated.

--Barr



> From: 	Brian J. Murrell[SMTP:brian_murrell at ssd.bctel.net]
> Subject: 	loophole with limiting leases per client
> 
> If a given machine has a host entry, it successfully gets a routed
> address, albeit a dynamic address out of a pool.  The problem arises
> depending on whether the address is bound to a client identifier
> (hereafter referred to as UID) or a hardware address.  If a UID is present
> in the discover/request, the address is bound to that.  If it is absent,
> it is bound to the hardware address.  The latter case is just fine and
> does what we want.  However, if the client sends a UID the address gets
> bound to that.  If the client sends another request with a new UID, a new
> address is allocated and the new UID is bound to the new address.  The
> problem in the case of this client is that we are permitting him addresses
> based on his hardware address being "known" but assigning addresses based
> on his UID, giving him as many addresses as he wishes to ask for using
> different UIDs.
> 
>