Re: [dhcwg] RFC 2131: can a DHCPv4 client (Mac OS X) transition directly from BOUND to INIT then back to BOUND?

[Irwin Tillman <irwin at princeton.edu>]

David W. Hankins wrote:

> Irwin, I'm sorry that it seems we didn't help you to your satisfaction
> earlier.  We are a group of volunteers, so we often forget that we have
> 'customers' with time-sensitive needs.

I wasn't dissatisfied. I posted my question to dhcwg, there were replies, and
that's it. (Of course, I would have been happier to get responses that agreed
with what I wrote, but such is life.) I very much appreciate the time that
people (volunteers, no less) have spent to consider what I wrote, and to
respond. I wouldn't want you to think I'm dissatisfied with the assistance I
received, or don't appreciate the time you've spent responding.


> ...  DHCPDISCOVER conveys no information to the server
> except that the client is 'discover'ing the presence (or lack thereof)
> of DHCP servers on the network that it might receive configuration
> parameters from, and what those parameters might be.
> 
> It is absolutely a server's violation of RFC2131 to infer that the
> client transmitting a DISCOVER has relinquished its lease.
> 
> The only situation I'm aware of according to RFC2131 in which a server
> may reasonably understand a client's lease to be relinquished before
> the expiration time has elapsed is when the client transmits a
> DHCPRELEASE message (or similarly, DHCPDECLINE, but that's different).
> 
> However, I am also aware that many servers (including ISC DHCP) have
> also implemented a catch should clients transmit a DHCPREQUEST message
> using the same identity as a previous, unexpired binding, but
> requesting a different binding.  A REQUEST really is a demand for
> a given binding, and therefore the client's indication of its
> acceptance and intent to use.  So this practice has not turned out to
> have many pitfalls.
>
> This is often done in order to free resources the old binding carries
> but can not possibly still be used, such as domain names or lease
> limitation counts.


Yes, I do the same thing (discarding the old lease) in that case, although I do
see this situation cause a problem when the reason is that the client is
simultaneously running two DHCP client instances on a single network interface
(with the same Client Identifier). The server ends up with a single lease for
the client (the new lease), while the client believes it has two leases. My take
is that the client's behavior is wrong (as a result of the client misconfiguration
leading to two DHCP client instances running, not as a result of a problem in the
DHCP client implementation).


> I am not aware of any other reasonable circumstances where the client's
> intent to use a binding it has been given may be inferred.
>
> I am also curious as to why you think it is necessary to expire a
> binding when the client issues a DISCOVER, rather than at the time
> they issue some other message.

(There's going to be some unavoidable duplication below between this and the
parallel discussion in dhcp-users at isc.org.)

It's because this server implementation uses a single store for leases and
offers. Offers (with all their associated parameters) are stored as leases
marked for garbage collection if they aren't claimed in a short time.

Since the spec only requires the server to maintain one lease per 
(Client Identifier, subnet), when a BOUND client sends a DHCPDISCOVER that results in a
new offer, the server replaces the old lease in the store. When the client then does not
SELECT that offer (e.g. it sends nothing), some time later that offer gets garbage 
collected. Now the store has no lease for the client.

> ...
> It is a mistake to think that any action indicated in the state
> diagram is a "MUST".

Hmm, consider the following:

A client is in INIT state. It sends a DHCPDISCOVER. A server responds with a
DHCPOFFER.

The state diagram says that to accept the offer, the client sends a DHCPREQUEST,
then the server sends a DHCPACK.

If the client doesn't really have to follow the state diagram, it could
receive the offer, then decide to jump to BOUND without sending a DHCPREQUEST
and receiving a DHCPACK. To me, the state diagram says that if the client
wants to accept the offer, it MUST send a DHCPREQUEST, then await (and
receive) a DHCPACK.

> 
> It is also a mistake to think you know what state the client is
> operating in based entirely on the message it transmits or the
> contents thereof (despite the fact that we do this in at least one
> place in DHCPREQUEST to sense RENEW vs REBIND).
> 

(As do I.  I see no way around this, as the spec requires the server to respond
differently (in some circumstances) to a DHCPREQUEST based on whether the client
is in the SELECTING, INIT-REBOOT, RENEWING, or REBINDING state.)

> Transmitting a DISCOVER in BOUND state does not make a client fail
> to implement RFC2131.  The behaviour simply is not in the reference
> one way or the other.


> | Once a client identified by a unique (client identifier, subnet)
> | tuple sends a DHCPDISCOVER, any old lease identified by that (client
> | identifier, subnet) tuple is no longer valid.  The client's abandoned
> | any old lease identified by that tuple.
> 
> This is unequivocally false.
> 
> 
> Now, you did point out some client bugs in your message that I hope
> Apple will fix.  But those bugs will only result in servers sending
> DHCPNAKs, which hopefully the client processes correctly.



Thank you for your detailed response.  I appreciate it.


Irwin Tillman / OIT Network Systems / Princeton University


_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg