Subject: RE: [dhcwg] Options differing in OFFER and ACK

From: "Kostur, Andre" <[email-masked]>
Date: Mon, 2 Feb 2004 19:04:14 -0800

Huh? Not sure how that could happen:

Client DISCOVERs
Server OFFERs IP X
Client REQUESTs w/ RequestedIP == X

If the server isn't willing to assign X to the client, then it will NAK at
this point.  The server _is_ allowed to change its mind between the OFFER
and the REQUEST.  But if it's not willing to assign X, it must NAK.  I don't
have 2131 in front of me, so I can't quote the section it's in.

> -----Original Message-----
> From: Kevin A. Noll [mailto:[email-masked]]
> Sent: Monday, February 02, 2004 5:30 PM
> To: [email-masked]
> Subject: [dhcwg] Options differing in OFFER and ACK
> 
> 
> 
> 
> I'm trying to figure out how a client is expected to react if the
> server returns an IP address in the DHCPACK than what was offered
> in the DHCPOFFER (and requested by the client in the DHCPREQUEST).
> 
> Following the general idea of DISCOVER-OFFER, REQUEST-ACK and the
> behavior implied for INIT-REBOOT, it seems that the most obvious 
> way to handle this would be for the client to use the IP address 
> returned in the DHCPACK, even if it is different than what was 
> requested. However, there does not seem to be any specific resolution 
> to this in RFC2131 or in draft-ietf-dhc-implementation-01.
> 
> Can someone tell me if there is a specific answer to this? Is there
> a requirement that the server grant the IP address being requested
> if it was previously offered?

---

From: "Kevin A. Noll" <[email-masked]>
Date: Mon, 02 Feb 2004 22:26:58 -0500

RE: [dhcwg] Options differing in OFFER and ACK
A bug in the server?

--kan--
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Kostur, Andre
  Sent: Monday, 02 February, 2004 10:04 PM
  To: 'Kevin A. Noll'; [email-masked]
  Subject: RE: [dhcwg] Options differing in OFFER and ACK

  Client DISCOVERs
  Server OFFERs IP X