Re: Proposal for addressing an "address leak" problem

[Rajesh Saluja <[e-mail]>]

I think that such a hint from the DHCP server can be very useful. There are
following conditions, in which the selection of an IP address based on this
hint is really required:
1. Mobile users ( as pointed by Lewis ).
2. On the same net, suppose the client released back the IP address to the 
   server, but the server is down. Since for DHCPRELEASE , there is no ACK
   from the DHCP server, the client never knows whether the address has been
   released or not. If next time, the client gets the same IP address (if
   lease not expired), address leak problem can be minimized, otherwise the
   address can be unnecessarily blocked.
3. There may be requirement (for any reason) that for a particular time
   duration, the client should always get the same IP address during bootup.
   We can configure the lease equal to the specified time and get the same Ip
   address each time, if the client has the ability to select the previously
   used address out of the offered addresses.
       In short, for a client, it is always better to use the previously used
   address if the lease is not expired. One option for the client is to 
   remember the previously used address, but it does not seem logical to
   remember when the server anyway remebers the address assigned. Hence the 
   server should always give hint to the client about the previous address
   ( if the lease is not expired ) and the client should select this address.

> 
> The following is a proposal to amend to the DHCP standards document to handle
> an "address leak" problem that can occur at sites with mobile users and 
> multiple DHCP servers handling a subnet.  The problem is a follows:
> 
> Consider a home site with two DHCP servers, a remote site with DHCP
> services, and a mobile client.  The client first connects to the home
> site and receives an address from one of the two serves.  He/she then
> travels to the remote site (without releasing the lease at the home
> site) and attempts to use the acquired address.  It is of course NAK'ed
> and the client receives an address appropriate for the remote site.  The
> client then returns home and tries to use the address from the remote
> site.  It is NAK'ed but now the client broadcasts a DHCPDISCOVER to get
> a address.  Both servers will offer addresses back to the client: he 
> server that holds the previous lease will offer the original address back 
> while the other server will offer a new address.  The client will select 
> one with no guarantee that it will select the one that is currently leased.
> Consequently, it is possible for the client to acquire an address on the 
> other server and therefore have two leases within the site.  If there are
> many mobile clients that operate in this mode, the site could become 
> constrained on available addresses.  
> 
> The administrator has few tools to resolve this situation; he/she would have 
> to be vigilant in examining the allocated address database for duplicates and 
> then PING each of the addresses in hopes that the client is on the network and 
> only one responds.  The adminstrator could, of course, eliminate the second 
> server, but in the case of a site with many mobile clients, the second server 
> provides some fault tolerance should the primary server become incapacitated.
> 
> A DHCP server to server protocol could solve this problem easily but in the 
> absence of such, a simple change can be made to the current specification to 
> provide some stopgap relief.  The change is to define a new flag bit 
> indicating whether the address lease is already valid (in a server database) 
> or not.  A server would set the flag to "1" if the address were already 
> allocated in its database to that MAC address; the flag would be set to "0"
> otherwise.  The client would utilize this information as part of its criteria 
> in selecting a lease; it should favor an address OFFER with the flag bit set 
> over one without.
> 
> The flag bit should only be set/considered on OFFERs.  
> 
> This flag could also be used for manuall assigned addresses as effectively, 
> these leases are already in a server's database.  This would help alleviate 
> the problem of having to assign manual addresses on all servers servicing a 
> subnet to ensure the client get the manually assigned address.
> 
> Using this flag bit would simplify an administrator's job by elminating the 
> potential for a mobile or manually assigned client receiving two different 
> leases from different servers.  I'd be interested in any feedback or 
> alternatives to this proposal.
> 
> Thanks.
> 

-- 
Best Regards
RAJESH SALUJA