Subject: RE: [dhcwg] DHCP_DECLINE question

From: Ralph Droms <[email-masked]>
Date: Tue, 05 Mar 2002 12:26:42 -0500

Good point re. potential for looping.  This behavior should only occur when 
the parameters change between the DHCPOFFER and the DHCPACK.  Presumably, 
on the retry after the RELEASE, the OFFER and the ACK will match and the 
client will accept the parameters in the ACK.

The client will only send the REQUEST if the parameters in the OFFER are 
acceptable, so an infinite loop will only happen if the OFFER and ACK 
continue to "flap".

This answer begs the question of how the client behaves if the client 
doesn't receive an acceptable OFFER; for example, the second OFFER matches 
the first ACK (which the client rejected).  The behavior of the client when 
it receives no acceptable OFFERs is left to the implementation...

- Ralph

At 09:05 AM 3/5/2002 -0800, Kostur, Andre wrote:

>Drawback on the RELEASE/DISCOVER method:  wouldn't this just simply send 
>the client into an infinite loop of DISCOVER/REQUEST/RELEASE sequence?  If 
>the stuff sent by the server is unacceptable the first time around, why 
>would the second time be any different?
>
>And, using DECLINE doesn't make it much better (actually has the potential 
>to make it worse!).  If a client DECLINES an unsuitable ACK because it 
>doesn't like one of the DHCP options, the server would likely mark that IP 
>as used.  Then when that client came back, it will likely DECLINE the next 
>IP that it's given, the DHCP server marks that IP as used too, and so on, 
>and so on, until that one client has effectively consumed your entire IP space!
>
> > -----Original Message-----
> > From: Ralph Droms [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Tuesday, March 5, 2002 5:33 AM
> > To: Burcak Beser
> > Cc: [email-masked]
> > Subject: Re: [dhcwg] DHCP_DECLINE question
> >
> >
> > I agree with Kim and Ted - DHCPDECLINE is defined in RFC2131
> > to be used in
> > the case of an address conflict, and many DHCP servers will mark the
> > address in a DHCPDECLINE so that it is not offered again in
> > the future.
> >
> > If the client decides that the address or other parameters in
> > a DHCPACK are
> > not acceptable, the client should respond with a DHCPRELEASE and then
> > restart the address assignment process with a DHCPDISCOVER.
> >
> > - Ralph
> >
> > At 12:26 PM 2/28/2002 -0500, Kim Kinnear wrote:
> > >At 06:04 PM 2/27/2002, Burcak Beser wrote:
> > > >I have a question regarding the use of DHCP_DECLINE
> > message. If the
> > > client is choosing a valid DHCP_OFFER using contents of the
> > returned
> > > options, and the DHCP SERVER changes the contents of the
> > options while
> > > sending the DHCP_ACK message, is it acceptable for client to use
> > > DHCP_DECLINE? (The RFC 2131 states that DHCP_DECLINE is
> > issued when the
> > > IP address in use.)
> > >
> > >         No, it is not. See below.
> > >
> > >
> > > >In other words when a DHCP_DECLINE is received by the DHCP
> > SERVER does
> > > this mean that the client detected that the IP address is
> > already used by
> > > another entity?
> > >
> > >         Yes, and the implication (as well as the explicit
> > >         direction) is that the DHCP server should not offer this
> > >         IP address to this client or any other client for at
> > >         least some time since it has been shown to be "unusable"
> > >         for DHCP client allocation (because some client (or
> > >         machine, maybe not a DHCP client) appears to be using it).
> > >
> > >         From RFC2131.txt:
> > >
> > >4.3.3 DHCPDECLINE message
> > >
> > >    If the server receives a DHCPDECLINE message, the client has
> > >    discovered through some other means that the suggested network
> > >    address is already in use.  The server MUST mark the
> > network address
> > >    as not available and SHOULD notify the local system
> > administrator of
> > >    a possible configuration problem.
> > >
> > >
> > >         If you don't like the IP address, you could use a
> > >         DHCPRELEASE to give it back.  Of course, you may in that
> > >         case be offered it next time, but you don't need to take
> > >         the offer.
> > >
> > >         If you just want to give it back, use DHCPRELEASE.
> > >
> > >         If you want to give it back and be offered a different IP
> > >         address from this server, that's a harder question, since
> > >         the DHCPDECLINE implies that the address isn't usable.
> > >
> > >         Cheers -- Kim
> > >
> > >
> > >
> > >
> > >
> > > >-burcak
> > > >
> > > >_______________________________________________
> > > >dhcwg mailing list
> > > >[email-masked]
> > > ><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/m 
> ailman/listinfo/dhcwg
> > >
> > >
> > >_______________________________________________
> > >dhcwg mailing list
> > >[email-masked]
> > ><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mai 
> lman/listinfo/dhcwg
> >
> >
> > _______________________________________________
> > dhcwg mailing list
> > [email-masked]
> > 
> <https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailman/listinfo/dhcwg 
>
> >

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

---

From: Richard Barr Hibbs <[email-masked]>
Date: Tue, 05 Mar 2002 10:09:19 -0800

> From: Ralph Droms
> Sent: Tuesday, March 05, 2002 09:27
>
> Good point re. potential for looping.  This behavior should only
> occur when the parameters change between the DHCPOFFER and the
> DHCPACK.  Presumably, on the retry after the RELEASE, the OFFER
> and the ACK will match and the client will accept the parameters
> in the ACK.
>
...while the parameters would likely match, it might be that the client
still doesn't like the values and that takes us back to the initial question
about the meaning of DHCPDECLINE.

If the client is receiving offers from multiple servers, the client could
simply ignore the offer it doesn't like (assuming that the parameters are
actually different between the two offers, and not merely the IP address)
which is our de facto standard for clients dealing with offers they do not
like.

It doesn't even have to be a mismatch between offer and ack that would cause
a client to decide against using the lease, but as I think about it, it
doesn't appear that v4 has a mechanism for rejecting the lease after the
client sends a request -- only if there is an address conflict, not the more
general case.

> The client will only send the REQUEST if the parameters in the
> OFFER are acceptable, so an infinite loop will only happen if
> the OFFER and ACK continue to "flap".
>
...exactly

> This answer begs the question of how the client behaves if the
> client doesn't receive an acceptable OFFER; for example, the
> second OFFER matches the first ACK (which the client rejected).
> The behavior of the client when it receives no acceptable OFFERs
> is left to the implementation...
>
...*IF* we were revisiting the details of the v4 protocol, it might well be
worth providing a mechanism for the client to reject a lease after receiving
the DHCPACK message, but short of that, we'll just have to live with
implementation-specific solutions to this "problem."

--Barr

---

From: Ralph Droms <[email-masked]>
Date: Tue, 05 Mar 2002 14:35:54 -0500

Barr - comments in line...

>about the meaning of DHCPDECLINE.

Barr - I'm with you here up to the last few words.  What do you mean by 
"...the initial question about the meaning of DHCPDECLINE"?

>which is our de facto standard for clients dealing with offers they do not

Agreed...

>client sends a request -- only if there is an address conflict, not the more

Bute, if the client doesn't like the OFFER, it won't send the REQUEST and 
won't get the ACK.  I think of this case as the lease never being created, 
as opposed to a lease being created and then terminated in the case the 
client doesn't like what's in the ACK.

I agree that there is no explicit mechanism for rejecting a lease (as 
opposed to releasing it) once the server sends the REQUEST.  Is there much 
of a difference between the two cases?

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Mar 2002 17:26:59 -0600

I don't see what kind of traction you'd expect to get by telling a DHCP 
server that gave you unacceptable parameters on a DHCPACK that you no 
longer want the IP address.   The only way I can see this happening is if 
the DHCP server is broken - it sent a DHCPOFFER with different information 
than was contained in the DHCPACK.   If it sent the same information in the 
DHCPACK, the client has no business declining the offer - if it didn't like 
it, it should never have sent a DHCPREQUEST.

So if the server is broken and sends different information in the DHCPACK 
than in the DHCPOFFER, the client can either accept what the server sent, 
or write the server off as broken.   Sending a DHCPRELEASE and then 
reconfiguring isn't going to work, and neither is sending a DHCPDECLINE - 
the server is broken, and no protocol action is going to fix it.

---

From: Richard Barr Hibbs <[email-masked]>
Date: Wed, 06 Mar 2002 15:31:47 -0800

I'll try to clarify the points.....

--Barr

> Sent: Tuesday, March 05, 2002 11:36
>
...assuming I understood the question properly, it could be restated as "Can
a client use DHCPDECLINE to reject an offered IP address after sending
DHCPREQUEST?"  Implied in that is what recourse is there for a client that
doesn't like some or all of a server's offer?

<*Snip!*>

> of a difference between the two cases?
...only that if a client releases the lease it is likely to get the same
lease the next time it starts the cycle....  I don't think we should be
making a change to the protocol at this point lacking sufficient evidedence
of harm caused by the current behavior, but it does seem a bit of an
oversight....

--Barr

---

From: Richard Barr Hibbs <[email-masked]>
Date: Wed, 06 Mar 2002 10:42:39 -0800

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2002 15:27
>
> longer want the IP address.
>
...I agree that a client should not arbitrarily change it's mind about a
lease, just observing that we don't seem to have fully specified all of the
cases, and trying to shine a little daylight on one or two....

<Snip!*>

> the server is broken, and no protocol action is going to fix it.
...I agree, but I've also been trying to think of any cases where a client
might find that an option value sent by a server just doesn't work after
receiving a DHCPACK, and whether or not there is any possible recourse.  The
only one I can think of it DNS server addresses:  if they are wrong, the
client is effectively useless for many purposes, the client is not likely to
learn of a bad DNS address until after it has received a DHCPACK, and there
isn't a heck of a lot that the client (or protocol) could do about that, so
your summary seems to be the end of the discussion.

--Barr

---

From: Ralph Droms <[email-masked]>
Date: Wed, 06 Mar 2002 21:51:31 -0500

Ted - I disagree with your flat statement that a server that returns 
different parameters in the DHCPACK is broken:

 From section 3.1 of RFC2131, in the 4th item in the numbered list:

      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.  [...]
      Any configuration parameters in the DHCPACK message SHOULD NOT
      conflict with those in the earlier DHCPOFFER message to which the
      client is responding.

The cited behavior is in conflict with the SHOULD NOT in the second 
sentence, so the server is not violating this part of the protocol spec.

I can imagine a *transient* situation in which the server's configuration 
changes between transmission of the DHCPOFFER and the DHCPACK, causing a 
difference in the parameters in the two messages *for that one 
transaction*.  In this situation, if the client sends a DHCPRELEASE and 
then tries again, the server will, presumably, either send a DHCPOFFER that 
the client will ignore (if the parameters are still unacceptable) or a 
DHCPOFFER that is followed by a consistent DHCPACK.

So, there's an existence proof that the situation might be fixable through 
the protocol.  Now, whether the possibility is worth trying to fix is open 
for discussion...

- Ralph

At 05:26 PM 3/6/2002 -0600, Ted Lemon wrote:
>than was contained in the DHCPACK.   If it sent the same information in 
>the DHCPACK, the client has no business declining the offer - if it didn't 
>like it, it should never have sent a DHCPREQUEST.
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 06 Mar 2002 21:58:32 -0500

>doesn't like some or all of a server's offer?

The meaning of DHCPDECLINE is pretty well-defined; from the 5th element in 
the numbered list in section 3.1 of RFC2131:

      If the client detects that the
      address is already in use (e.g., through the use of ARP), the
      client MUST send a DHCPDECLINE message to the server and restarts
      the configuration process.

DHCPDECLINE is intended for use when the assigned address is already in use.

In my opinion, a client is within the spec if it sends a DHCPRELEASE 
immediately after receiving a DHCPACK (for whatever reason).  The 
DHCPRELEASE will terminate the lease and make the address available for 
reassignment without causing the server to mark the address as "not to be 
assigned".

There is still the open question of whether we want to *recommend* this 
behavior...

>of harm caused by the current behavior, but it does seem a bit of an

But the problem isn't the lease/assigned address so much as the other 
parameters.  If the client gets the same (unacceptable) parameters in the 
subsequent DHCPOFFER, the client will ignore it.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 06 Mar 2002 21:59:34 -0500

>cases, and trying to shine a little daylight on one or two....

Yup, that's what I'm trying to get out of this conversation, too.

Someone outside the DHC WG asked the question, so it seems worth exploring.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Mar 2002 22:41:01 -0600

> reassignment without causing the server to mark the address as "not to be 

True.

> There is still the open question of whether we want to *recommend* this 

Right.   I'd say we shouldn't, because in all likelihood it's going to 
result in the client looping behavior about which Barr is concerned.    I 
think that we are trying to fix a nonexistant problem here, and the fix 
seems much worse than the problem, particularly since I've never observed 
the problem happening in real life.

---

From: Richard Barr Hibbs <[email-masked]>
Date: Thu, 07 Mar 2002 07:23:34 -0800

> Sent: Wednesday, March 06, 2002 19:00

<*Snip!*>

> >...I agree that a client should not arbitrarily change it's
> >mind about a lease, just observing that we don't seem to have
> >fully specified all of the cases, and trying to shine a little
> >daylight on one or two....
>

...I think that while it is clear about the use of DHCPDECLINE to reject an
address that the client believes is already in use, the wording of the RFC
says nothing at all about other [mis-]uses of DHCPDECLINE, nor about other
conditions that might cause a client to decide very late in the message
exchange that it does not want to continue with the offered [and requested!]
address.

For example, what will happen if a client, happily using an address for a
long time, reaches a renew point and issues a gratuitous ARP after receiving
an ack for its lease:  if an address conflict is detected, it could send a
decline message and be completely within spec, but will all servers handle
the decline message properly at this point in the lease lifetime?  What
about a client that periodically ARP's for its address without a protocol
event to trigger it?  Would a server properly handle a decline then?
Stateless servers probably will have no trouble with such behavior, but will
stateful?

--Barr