Subject: [dhcwg] Re: 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, 08 Feb 2007 10:06:57 -0500

I will try to summarize the outcome of this discussion (which started on dhcwg,
and continued on dhcp-users).  I apologize in advance if my attempt to summarize
leaves out the many valid finer points, or if I have misunderstood anyone.

As the discussion developed, there were three "is this compliant with the RFCs?" issues:

1) May a DHCP client send a DHCPDISCOVER message while in the DHCP BOUND state (and
   remain in the BOUND state)?

   * Irwin Tillman (myself) believes a client that does so is not compliant with
     RFC 2131, based on the client state transition diagram.
   
     (Irwin also believes that if a server treats receipt of a DHCPDISCOVER message as
     indication that the client is in the DHCP INIT state, the server is compliant
     with RFC 2131, but is more restrictive than necessary.)
   
   * David Hankins believes a client that does so is compliant with RFC 2131,
     because this is not specifically disallowed by the RFC, and because the client
     state transition diagram shouldn't be interpreted as "MUST" behavior. He also
     believes the server shouldn't discard an existing lease except as a result of
     receiving a DHCPRELEASE or a DHCPREQUEST message from a client. He believes
     the server shouldn't infer the state of the client based solely upon the
     messages received from the client.
   
     (David also believes that if a server treats receipt of a DHCPDISCOVER message as
     indication that the client is in INIT state, the server is not compliant with RFC 2131.)
   
   * Keith Neufeld believes a client that does so is compliant with RFC 2131.
   
   * Kim Kinnear believes a client that does so is not compliant with RFC 2131,
     based primarily on the client state transition diagram.
   
   * Ted Lemon believes a client that does so is not compliant with RFC 2131.
   
     (Ted also believes that if a server treats receipt of a DHCPDISCOVER message as
     indication that the client is in the DHCP INIT state, the server is compliant
     with RFC 2131, but is more restrictive than necessary.)

2) May a DHCP client that believes it is RENEWING or REBINDING send DHCPREQUEST
   messages where the DHCP 'Server IP Address Option' is 0, the DHCP 'Requested
   IP Address Option' is 0, and the 'ciaddr' field is 0?

   * Irwin Tillman (myself) believes a client that does so is not compliant
     with RFC 2131.
   
   * David Hankins believes a client that does so is not compliant with RFC 2131.

3) May a client implementing DNAv4 send a DHCPDISCOVER message while carrying out 
   the DNAv4 procedure if it has an "operable address"?

   * Irwin Tillman (myself) believes a client that does so is not compliant
     with RFC 4436.
   
   * David Hankins generally believes that the client that does so is not
     compliant with the text of RFC 4436, but believes that this was not the
     intent of RFC 4436. David feels the term "operable address" in that RFC may
     need to be updated.
   
   * Kim Kinnear believe a client that does so is not compliant with RFC 4436.
   
   * Ted Lemon believes a client that does so is not compliant with RFC 2131.

FYI, I'd previously reported these issues to Apple as this is the way Apple 
Mac OS X 10.4.x behaves (at least versions 10.4.2 through 10.4.8). (Apple assigned
this Bug Reporter Problem ID 4904550.) I updated my Apple bug report following our
discussion.

Apple's conclusion was, and remains, that the behavior of their client is correct.
So the discussion, I suppose, is moot (at least as far as getting Mac OS X's behavior
changed) but I thank you all for your valuable guidance and time.

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: Thu, 8 Feb 2007 10:50:00 -0800

Given the responses of my peers, I probably am going to have to
eat some 'unequivocal crow'.

But as I've reflected on this further, we're really pitting two
opposing non-reference behaviours against each other.

"DISCOVER without continuing processing through to BOUND."

It's hard to describe a behaviour that is not in RFC2131 as
'compliant', except that the DISCOVER that is emitted is done
per the spec.  So while I probably wouldn't use the word
compliant, I would probably not use the word non-compliant.

They're doing their own thing, and probably think of it
as "INIT-RECONNECTED" state, or something like that, rather
than anything on RFC2131's diagram.

The DNAv4 variant of this same issue is absolutely non-compliant.

I have reasons for thinking the author intended for 'operable
address' to be different from 'unexpired lease.'  Not the least
of which is the conspicuous choice of words.  'unexpired lease'
being used in RFC2131 (so, already well understood).

More importantly, I believe the author of RFC4436 was optimizing
for time.

Transmitting a DISCOVER instead of a "INIT-REBOOT REQUEST"
saves you the time it takes to receive a NAK and kick off the
next DISCOVER.  In either case, DNAv4 lets the client short
circuit all other messages if the ARP probe succeeds.  It is
only to optimize for the ARP probe failure case that any message
is transmitted: to optimize on time.

At the same time, since DHCP servers do not commit
information to persistent storage on DISCOVER, but do on
REQUEST, it also represents a lighter-weight speculation.

Since that represents what I think is a valid use case, it's
my opinion that we should err on the side of permissiveness.

In which case RFC4436 would clearly need to be updated, which
judging by my peers there may not be consensus for.

"Trimming lease-times on DISCOVER."

This is more of a penumbra.

No matter what the message, anytime a DHCP server elects to
shorten a lease time it is taking a risk.  On REQUEST/ACK, the
response may be lost, and so the client may perfectly reasonably
stay on the lease until the original expiration time.  Of course
we often do so anyway because it's a useful tool for a syadmin
to have, but the risk is the same (the difference is that the
sysadmin is watching, or has a greater risk to manage).

DISCOVER/OFFER is no different.

Again in the DISCOVER processing section of RFC2131, there is
no explicit mention that the server do anything other than that
it SHOULD NOT offer the same lease to a different client.  So
a server that chooses to shorten the lease time is neither
implementing RFC2131 nor are they failing to.

What's conspicuously missing from RFC2131 here is the text
similar to what is used in REQUEST handling:

     offer.  The server selected in the DHCPREQUEST message commits the
     binding for the client to persistent storage and responds with a
     DHCPACK message containing the configuration parameters for the
     requesting client.  The combination of 'client identifier' or

The conspicuous absence of similar text regarding DISCOVER processing
leads me to believe that no permanent changes must be recorded by
receiving a DISCOVER.

At any rate, thank you Irwin for bringing this to our attention.

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

---

From: Bud Millwood <[email-masked]>
Date: Fri, 9 Feb 2007 11:04:06 +0100

On Thursday 08 February 2007 19:50, David W. Hankins wrote:

> per the spec.

It's done per the syntax of the spec.

> So while I probably wouldn't use the word

It's semantically non-compliant with the spec.

> than anything on RFC2131's diagram.

Which leads us to: Is the syntax of RFC 2131 independent of the semantics? I 
don't believe it is. It tries to be, but without the semantics, isn't the 
syntax moot?

It follows that I believe that implementing RFC 2131 syntactically correctly 
is not enough to make you conformant, regardless of the fact that the RFC 
strives to make the syntax as independent of the semantics as possible.

The protocol is about semantics.

- Bud

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
mailto:[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Feb 2007 13:43:54 -0700

> being used in RFC2131 (so, already well understood).

Be careful here.   One issue is that one has leases on IP  
addresses.   The IP address is not a lease.   So you can't say "use  
the lease."   You have to say "use the IP address."   And I think  
that may account for distinction in the wording.   So IMHO you  
shouldn't take the distinction the way you are taking it - to me it  
seems clear that the wording is referring to an IP address on which  
the DHCP client has a valid lease.

Also, bear in mind that before you can send a DHCPOFFER you have to  
ping-test the IP address.   And the expected state is generally that  
the DHCPREQUEST will be ACKed, not ignored.   So in the common case  
it's *faster* to send a DHCPREQUEST, not slower.   It's only if your  
network attachment has *actually* changed that sending the  
DHCPDISCOVER is faster, and even then it's not very fast - many DHCP  
servers wait an entire second for the ping to come back.

I agree that your reading of the RFC casts suspicion on the idea of  
taking a DHCPDISCOVER to mean that the client is no longer holding  
the lease.   However, on the other side, bear in mind that the RFC  
also prohibits the client from responding to an ICMP echo request at  
DHCPDISCOVER time.   Which means that the client *can't* be using the  
IP address.   So while you can say that the DHCP server in question  
is in a grey area, I have a hard time saying its behavior is  
*wrong*.   There are a lot of holes in the draft - a careful  
implementation probably needs to avoid the described behavior, but I  
don't think it's fair to say that the described behavior is actually  
out of compliance.

But what the client is supposedly doing is still definitely not  
correct, at least according to my reading of the two RFCs.   If you  
really think sending a DHCPDISCOVER is faster, you need to do the  
entire handshake.   I suspect that the author of this DHCP client  
didn't account for the echo request delay, and that's why it's timing  
out before it receives a DHCPOFFER.

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 12 Feb 2007 11:26:39 -0800

> the DHCP client has a valid lease.

Right, an unexpired lease (which in DHCPv4, also has one address).

I don't see any point in pretending there's a difference between
the two things.  All DHCPv4 leases have precisely one IP address.
All DHCPv4'd IP addresses must only be got via leases.

> ping-test the IP address.   And the expected state is generally that  

s/have to/SHOULD/

> servers wait an entire second for the ping to come back.

If you aren't performing an ARP probe, then a DHCPREQUEST/ACK is
faster in the same-network case.

If you are performing an ARP probe, then that will detect
same-network faster than DHCP will (or they wouldn't bother with
it).

So your DHCP-side probe is optimized for the different-network case,
speculating the ARP probe will fail.

If a DHCPREQUEST is NAK'd, then the client must then DISCOVER.

So DISCOVER out of the gate reduces the number of messages by one
exchange.

> DHCPDISCOVER time.

I looked at RFC2131, and could not find the prohibition that DHCPv4
clients MUST NOT respond to an ICMP echo request at any specific
or non-specific time.

I think you mean to say that it's implied since DHCPDISCOVER is
not exampled as something reasonable for use unless the client
has no address (and that servers SHOULD perform an ICMP echo
request is supporting evidence).

I wish it was there.  There has been at least one instance, and I
think actually more than one since, where a client was found to
transmit a DHCPDISCOVER while it was bound to its leased address,
responding to ICMP echo requests.

So a ping-check of a lease that is active is already known to give
false positives.

Given the nature and number of the clients that already behave in
this manner, I think little would be gained by trying to "correct"
the client behaviour.  So the server behaviour should be modified.

My advice is that a server should either elect not to ICMP check
a lease that is already active, or to examine ICMP responses for
source MAC address (obviously made difficult in networks served by
relay agents) and compare it to the lease's active or previous
binding.

> There are a lot of holes in the draft - a careful  

At least we agree on something.  If you recall, I did say I would
use neither the words 'conform' nor 'non-conform' to describe this.

I would advise an implementor heavily against this behaviour,
however.

> out before it receives a DHCPOFFER.

I thought they're just discarding the entire session if the ARP probe
succeeds, going BOUND, and scheduling renewal.

This is the first time anyone's mentioned ICMP echo timeouts.

Completing the handshake has a nice symmetry to it.  I suspect
that the client implementor did not want to transmit a message
that was "server intensive" as often as its link state changed
(which on a wireless network, may be extremely frequent).  Wether
this is done out of the gate or after a DHCPOFFER, it all amounts
to making the server touch disk.