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

[David W. Hankins]

On Wed, Jan 31, 2007 at 07:05:24AM -0600, Keith Neufeld wrote:
> > Since September 2005 (yes, 2005) I've been seeing a DHCP client  
> > issue from
> > Mac OS 10.4.x systems at Princeton University, where I maintain DHCP
> > service.
> >
> > I reported it to Apple (Apple Bug Reporter Problem ID 4904550);
> > Apple's examined it and confirmed that Mac OS X does indeed behave
> > this way, and that they believe this behavior is correct (is  
> > consistent
> > with RFC 2131).   I believe the behavior violates RFC 2131.
> 
> I don't buy it.  I mean, I don't buy it as a violation.

I think this guy sent mail to dhcwg at ietf.org too.

I think he has confused "a client sent a DHCPDISCOVER" with "the
client is in INIT state."

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.

So it's not reference behaviour, but it's not exactly "a protocol
violation" either.

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.

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 only thing that is unsafe here is if the client can be
ICMP echo'd at the address the server is about to OFFER.  If it
can, then it may confuse duplicate address detection.  If it
can't, then it all just wrks.

> > Some time after obtaining a DHCP lease (entering the DHCP BOUND  
> > state), the
> > client sends one or more DHCPDISCOVER packet. This implies the  
> > client has
> > returned to the DHCP INIT state, relinquishing the old DHCP lease.

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.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins