Re: [dhcwg] DHCP_DECLINE question

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

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg