[unisog] Mac OS X 10.4.x "DHCP client sometimes remains BOUND aftersending DHCPDISCOVER" bug

[Irwin Tillman]

David W. Hankins wrote:

>We can't tell what state a client is in from the outside.  Clients
>use messages to get results from servers to change states, and
>RFC2131 only describes DISCOVER being used in INIT state, but I
>don't think it says that a client in any other state MUST NOT use
>the message.  Nor does it say that you can deduce that a client is
>in INIT state based upon the fact it sent a DISCOVER.

If you accept the reasoning that clients can
send a DHCPDISCOVER outside of the INIT state because nothing
in the RFC explicitly forbids it, then don't you need to accept that
a client in the BOUND state may send a DHCPREQUEST of the INIT-REBOOT flavor?

The RFC doesn't say this is possible, and doesn't show it in the client
state transition diagram, but it contains no language explicitly forbidding it.
So it seems to me that the same reasoning would allow this too.

Now consider the consequences of that:

A BOUND client has a lease on IP address 'a' that still has 24 hours remaining.

The client chooses to send a DHCPREQUEST of the INIT-REBOOT flavor.
(A DHCPREQUEST with no 'Server Identifier' option, that has a non-zero
'Requested IP Address', and ciaddr set to zero.)
We'll assume the 'Client Identifier' is the same as the client has used previously, and
the client is still attached to the same network.

(Why would it do this?  Maybe the user erroneously started a second DHCP client
instance on the same network interface.)

Given the characteristics of the DHCPREQUEST,
the server is expected to identify the client as being in the INIT-REBOOT
state, and behave accordingly. 
(Section 4.3.2, DHCPREQUEST generated during INIT-REBOOT state.)

Since the RFC only allows a client identified by (Client Identifier, Subnet)
to have a single lease at a time, from the server's point of view,
this client is asking for a lease on a different IP address ('b', not 'a').

How should the server respond?

Section 4.3.2 (DHCPREQUEST generated during INIT-REBOOT state)
says "the DHCP server should check to see if the client's notion
of its IP address is correct", and if not, send a DHCPNAK.

What "correct" means is not explicitly defined there.

One reasonable approach would be to look up the client in the database, see it
still has an unexpired lease on 'a', and based on that, to decide that 'b'
is not a "correct" address, and so NAK the client.

But another approach would be to look up 'b' to verify that it's an available IP address
this server is allowed to lease to this client.  Since the client
is in INIT-REBOOT state,  allow the client to have the lease on 'b'.
In that case, the server would send a DHCPACK to the client for requested
IP address 'b'. Let's say the server used that approach.

A single (Client Identifier, Subnet)
is only entitled to a single lease at a time, the server would be
justified in deciding that the old lease on 'a' is no longer valid.

In fact, if the server is implemented in such a way that it only
stores one lease per (Client Identifier, Subnet) -- which is all the RFC
requires of the server -- it might *have* to discard the old lease on 'a'
to make room to store the new lease on 'b'.

Now we have a problem, since the server believes the client has a single
lease on 'b', while the client believes it has both a lease on 'a'
and a lease on 'b'.

Does this every happen?  You bet!  I see it when customers manage to
configure their machines with two DHCP client instances on a single
network interface, both using the same Client Identifier.
The client (the device as a whole, rather than the two indpendent DHCP
client instances) now thinks it has two leases, while the server thinks the client has one lease.

Is the client behaving correctly?  No; I believe it's misbehaving (as the result
of a client misconfiguration).

If we were to say that this is correct client behavior (since the RFC doesn't explicitly
forbid sending a DHCPREQUEST (of the INIT-REBOOT flavor) while the client
remains in BOUND), we end up with this problem.

My view is that the RFC doesn't have to explicitly state "a client
may not send a  a DHCPREQUEST (of the INIT-REBOOT flavor) while the client
remains in BOUND"; the client state transition diagram in the RFC indicates
that this is not a valid thing for a client to do.

And by the same reasoning, the  client state transition diagram in the RFC indicates
that sending a DHCPDISCOVER while remaining in the BOUND state is not
a valid thing for the client to do.


Irwin Tillman / OIT Network Systems / Princeton University