Subject: [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: Wed, 24 Jan 2007 09:47:54 -0500

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?

Irwin Tillman / OIT Network Systems / Princeton University

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 24 Jan 2007 10:41:35 -0800

> Any thoughts as to whether RFC 2131 permits this?

It doesn't disallow it, if that's what you're asking.

I think you also want to look at RFC4436 (DNAv4), which I think
describes where and why this can be done and is (reasonably)
safe.  To have a problem you need an environment using RFC1918
addresses AND either (VRPP or HSRP) OR (routers with identical
mac addresses).

I think the solution is not to perform DNAv4 on RFC1918 networks.

The objective of DNAv4 is to reduce the time to get back on an
old lease if interface state changed but the network did not.

In this case if the ARP probe succeeds, then the client knows that
it can 'continue being BOUND' on the old address even though it
speculatively transmitted a DISCOVER.  If the ARP probe fails, it
would need to carry on based on the contents of the OFFER.

So a DISCOVER is sent to net an OFFER speculatively.  The ARP
is speculated to suceed, the DISCOVER is a backup speculating
the ARP will fail.

I probably would have chosen a REQUEST to make it look like an
early REBIND, but this has server side implications (since the
server must update a database in that case - processing a DISCOVER
is much lighter weight).

-- 
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

---

From: Irwin Tillman <[email-masked]>
Date: Wed, 24 Jan 2007 15:35:42 -0500

On 24 Jan 2007 10:41:35 -0800, David W. Hankins wrote:

>safe. 
...
>server must update a database in that case - processing a DISCOVER

Yes, it does look like DNAv4 (or something similar) is going on here.

Looking at RFC 4436 (DNAv4), I see where it permits it can permit a client in
the situation I'm seeing to attempt DHCPv4 in parallel with the reachability
tests. (Section 2.1, seventh paragraph).

That paragraph appears to imply that DHCP attempt is a DHCPREQUEST made from the
INIT-REBOOT state, but the explicit details are in the next section.

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.

So it seems to me that if the DHCP client (in the particular situation I'm
seeing) is doing DNAv4 (and it does seem to be doing something like it), it
should be broadcasting DHCPREQUEST from INIT-REBOOT, not DHCPDISCOVER from INIT.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 24 Jan 2007 13:05:36 -0800

> operable routable IPv4 address.

I'm not sure if 'operable' means that the lease is usable (in which case
I would have expected 'unexpired' which I think RFC2131 uses or maybe
'valid'), or 'in operation' (as in actively configured on the interface,
in use, able to transmit and receive IP packets).

It's my suspicion that 'operable' means 'in operation', but I admit
I didn't take this up with the document authors at the time.  I have
a vague sense that it would be safe in either case from a protocol
standpoint (or at least not the client's fault if something goes
wrong - even though old ISC DHCP server versions would make things
go wrong), so I didn't think nor ask about it.

---

From: Irwin Tillman <[email-masked]>
Date: Wed, 24 Jan 2007 17:17:27 -0500

On 24 Jan 2007 13:05:36 -0800, David W. Hankins wrote:

>in use, able to transmit and receive IP packets).

I believe they're using the specific "operable address" definition from Section 1.3
(final paragraph):

'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.'

In the situation I'm seeing, the DHCP client (Mac OS X 10.4.x)
has an "operable address."

(So the DNAv4 spec says to send DHCPREQUEST in INIT-REBOOT, 
not DHCPDISCOVER in INIT.)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Jan 2007 15:32:50 -0700

> in use, able to transmit and receive IP packets).

It's probably better to think of the entire configuration, rather  
than just the IP address and the lease on it.   So if the device  
holding that configuration can use it to communicate on the network,  
it is operable; if it cannot, it is not.   And this is true even  
though the lease has not yet expired.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 31 Jan 2007 11:47:15 -0800

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.

In your recent message to unisog [1] you said:

| 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. In some

This is not true.  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.

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.

| * More importantly, the client transitions directly from the DHCP
|   INIT state to the BOUND state.  I don't believe that's permitted
|   in DHCP.
| 
| Specifically, Figure 5 in RFC 2131 contains the state transition
| diagram for DHCP clients.  (There have been some changes due to
| later RFCs, but none that are directly relevant to this matter.)
| 
| It makes it clear that a client the only time a DHCP client may send
| a DHCPDISCOVER is when it is in the DHCP INIT state, and that there
| is no way for a client in the DHCP INIT state to get to the DHCP
| BOUND state without the server granting it a lease.

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

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).

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.

[1] [unisog] Mac OS X 10.4.x "DHCP client sometimes remains BOUND
	     after sending DHCPDISCOVER" bug
    January 30, 2007
    by Irwin Tillman
    http://lists.sans.org/pipermail/unisog/2007-January/027056.html

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 31 Jan 2007 11:49:38 -0800

> though the lease has not yet expired.

Irwin has a point that although we understand the term in this
manner, that isn't the text of the rfc's definitions section.

Errata?