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

[Irwin Tillman]

David W. Hankins wrote:

> As it turns out there is a reference, RFC4436, which describes
> that a client might do this if it doesn't have an operable address. 
>
> I presume Apple is implementing this RFC.

Yes, that's what I think too.

> The wording of 'operable address' in that RFC seems to be the only
> remaining point of contention.  I don't think the author really meant
> "any unexpired address", but rather meant "does not have an address
> configured on its interface."  Which might be a prudent thing not
> to do if you have re-acquired a network and don't know for certain
> you are still attached to the same one.  In rfc1918 addressed
> networks, you might conflict with someone else's address.

The case I'm seeing is a client that obtained an IP address
via DHCPv4, the client's not sent a DHCPRELEASE message, and
the lease hasn't yet expired.

And the definition (RFC 4436 section 1.3) of "operable address" is
(apologies for quoting the RFC):

   In this specification, the term "operable address" refers either
   to a static IPv4 address, or an address assigned via DHCPv4 that
   has not been returned to the DHCP server via a DHCP RELEASE
   message, and whose lease has not yet expired.

So it seems to me that the IP address is indeed exactly
that DNAv4 calls an "operable address".

If that's not what the RFC authors' meant, then of course it can
be updated in another RFC....but as it is, I believe the client's behavior
(sending DHCPDISCOVER instead of DHCPREQUEST in this situation) is violating this RFC.

> ...

> The only things a client transmits to relinquish a lease is
> DHCPRELEASE, or a DHCPREQUEST for a different address. 


> > > 3) Before the lease is due to expire, the client broadcasts a DHCPDISCOVER packet.
> > >
> > >    Since the client is still attached to the same network, and is still
> > >    using the same DHCP Client Identifier, this implies the client has entered the
> > >    DHCP INIT state, implicitly relinquishing the old lease.


> Well, that's a server bug then.
> 
> Servers that process DISCOVER and make any long-term changes to the
> leases they OFFER are in for a big surprise.
> 
> If the client REQUESTed a different lease, sure, then you could
> do this.
>
> I'd like to know why his server is doing any extra processing of
> DISCOVER packets outside of just finding an OFFER.  I bet it's
> some scheme to give out random ip addresses to discourage server
> hosting. 

It's because this server implementation uses a single store for
leases and offers.  Offers 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 fails to 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.


Irwin Tillman / OIT Network Systems / Princeton University