loophole with limiting leases per client

Brian J. Murrell brian_murrell at bctel.net
Mon Oct 18 18:43:50 UTC 1999


from the quill of "HIBBS, BARR (PB)" <RBHIBBS at msg.pacbell.com> on scroll
<21839C593E75D211BF7800805FCCD026EAADE1 at msgsrv03.srv.PacBell.COM>
> 
> 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.

Indeed.  3.0 does the same.

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

Which I disagree with BTW.  When a roaming client moves from subnet A to
subnet B, his lease on subnet A should be released and available for
re-assignment according to the guidelines of assigning the oldest lease
first.  The "one-lease-per-client" feature of version 3 achieves this. 
This is not my problem however.

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

Agreed, if you should want to allow simultaneous leases on many subnets for
roaming clients.  But again, this is not my problem.  :-)

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

Yes.

> and that your host declarations do not contain a fixed-address
> declaration,

Correct.

> as version 2.0 clearly favors fixed host addresses over dynamic
> allocation.

As does version 3.

> I guess I don't see why you think this behavior is incorrect or
> undesirable.

It is undesirable because one client can exhaust a pool of addresses by
simply sending multiple requests with different client identifiers.  This
can happen because the server will prefer to manage leases by client
identifier if it is present in the DISCOVER/REQUEST messages.  A client
that sends two REQUESTS with different client identifiers will be, as far
as the server is concerned two clients.

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

Have you tested a client's ability to have two simultaneous leases on the
same subnet by altering it's client identifier?  How about getting two
leases by first not offering a client identifier, then requesting a second
lease using a client identifier?

b.



--
Brian J. Murrell                                        Brian_Murrell at bctel.net
BCTel Advanced Communications                                      604 454 5279
Vancouver, B.C.


More information about the dhcp-hackers mailing list