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

From: Irwin Tillman <[email-masked]>
Date: Thu, 01 Feb 2007 17:24:07 -0500

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 [email-masked].)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 01 Feb 2007 17:55:01 -0500

At 09:47 AM 1/24/2007, Irwin Tillman wrote:
>My reading of RFC 2131 (especially Figure 5) is that a DHCPv4 client cannot
>transition directly from the INIT state to the BOUND state without passing
>through the SELECTING state.
>
>Under some circumstances, Apple Mac OS X 10.4.x will do just that.
>
>That is, the client was BOUND. The client chooses in some circumstances (e.g.
>following certain sleep/wake or link change events) to transition to the INIT state
>(rather than INIT-REBOOT).  It broadcasts one or more DHCPDISCOVERs. Under some
>circumstances, after broadcasting the DHCPDISCOVER(s) the client then returns to the
>BOUND state, continuing to use the IP address from the old lease.
>Assuming it remains online long enough, it later tries to renew the old lease;
>as far as the client is concerned, it's BOUND again.
>
>My reading of the client state transition diagram (RFC2131 Figure 5) is that
>this isn't right. The only state in which a client may send a DHCPDISCOVER message is
>INIT.  A client in the INIT state can't transition to the BOUND state without
>some additional steps that take it through the SELECTING state (e.g. receive
>DHCPDISCOVER(s), send a DHCPREQUEST, receive a DHCPACK).
>
>(I realize that RFC 4039 adds another path from INIT to BOUND using the 
>DHCP Rapid Commit option, but that's not what's happening here.)
>
>I've reported this to Apple as a bug (Apple Bug Reporter Problem ID 4904550);
>Apple has confirmed that the Mac OS X 10.4.x client behaves this way, but they
>believe RFC 2131 permits this behavior.
>
>Any thoughts as to whether RFC 2131 permits this?

        I was out of the office last week, and so am just getting
        updated on this exchange.  I have read the thread up to
        the present, but it was getting so long that I thought
        I'd reply to this initial message instead of to the
        replies to the replies ...

        I have several points to make:

        1.  I do not believe that RFC2131 permits a client to
        send a DHCPDISCOVER and continue to use any existing
        lease.  I see the client state transition diagram as part
        of RFC 2131, and this explicitly indicates that the
        client is not BOUND if it is in INIT state.  In addition
        to the diagram, I see the following text from section
        4.4.5 to be significant (but not, by itself, enough
        proof):

  If the lease expires before the client receives a DHCPACK, the client
  moves to INIT state, MUST immediately stop any other network
  processing and requests network initialization parameters as if the
  client were uninitialized.  If the client then receives a DHCPACK
  allocating that client its previous network address, the client
  SHOULD continue network processing.  If the client is given a new
  network address, it MUST NOT continue using the previous network
  address and SHOULD notify the local users of the problem.
        
        The implication here is that in INIT state you must stop
        using any lease.  Of course I see how you might assume
        that was only the case if the lease expired, but I think
        the state transition diagram indicates that is not the
        only way you can get to INIT state.

        Another approach to considering this is that a DHCP
        client generally puts any IP address it has leased in the
        ciaddr (see Table 5, RFC 2131).

        2.  Regarding the usage of DHCPDISCOVER and
        DHCPREQUEST/INIT-REBOOT to probe the existence of an
        existing lease.  Irwin paraphrases the DNAv4 RFC
        (RFC4436) as follows:

In section 2.2 (paragraph 1), it makes this explicit in the case where the
client has an "operable routable IPv4" address (which is the case we're dealing
with here). It says that the DHCP attempt is to be a broadcast DHCPREQUEST sent
from the INIT-REBOOT state.

Paragraph 2 says to use broadcast DHCPDISCOVER from the INIT state if the client
doesn't have an operable routable IPv4 address on any network, but that's not
the case here. In the situation I'm seeing, the DHCP client (Mac OS X 10.4.x)
has an unexpired DHCP lease for a globally routable IPv4 address. So it's an
operable routable IPv4 address.

        This to me seems precisely correct -- if you don't have
        an IP address, you use DHCPDISCOVER to get one, and if
        you *do* have an IP address, you use
        DHCPREQUEST/INIT-REBOOT to see if it is still usable.
        This also follows the ciaddr "rule" I mentioned above.

        ---------------------------

        Bottom line:  If you send in a DHCPDISCOVER to a DHCP
        server, I believe that you have declared yourself in INIT
        state, and therefore relinquished any existing lease.

        Maybe Irwin and I are the only two folks who believe
        that, but Irwin is certainly not alone.

        Cheers - Kim

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Feb 2007 15:58:55 -0700

> wants to accept the offer, it MUST send a DHCPREQUEST, then await (and

This is exactly right.   And in case there is any question in  
anyone's mind about whether the behavior ascribed to the DHCP client  
in this case is in conformance with RFC2131 or RFC4436, I would say  
that it clearly is not.   Why not?   Mr. Tillman has already  
explained why it's not in conformance with RFC2131 - I see no need to  
expand on that.

RFC4436 very clearly says that if you have an Operable Address, which  
is defined to be an address for which the client has a valid lease,  
then you should test that address by going into INIT-REBOOT.   It  
does not say you should go into INIT and test it with a  
DHCPDISCOVER.   Indeed, it says you should go into INIT if you do not  
have an operable address.   And that's clearly not the case in the  
situation Mr. Tillman is describing.

So while the DHCP server Mr. Tillman is using is being more  
restrictive in its handling of DHCPDISCOVERs than most, its behavior  
is not out of spec.   It is the client that's out of spec, and  
conformance with RFC4436 doesn't change that, because it isn't  
conforming to RFC4436.

I apologize for being so formal and precise here, but I've been  
seeing a lot of doubt going by about whether there's a problem  
here.   If there's a client that's behaving in the manner Mr. Tillman  
describes, it is in fact out of spec, and needs to be fixed.