RE: [dhcwg] DHCP_DECLINE question

I am not sure what you mean by "changes the contents of the options".

The RFC only speaks of the client declining the ACK because of
an address conflict.

Conceptually I see no problem with the client declining for some other
reason.  E.g.: the client examined the option list
it received, and did not like one/some of them.

The RFC says:

"5. The client receives the DHCPACK message with configuration
     parameters.  The client SHOULD perform a final check on the
     parameters (e.g., ARP for allocated network address)"

Advocating such parameter check implies that the check could possibly
fail, and could fail for some reason other than an addres conflict.

PS.
There is a remote possibility, that some server implementation
takes the DECLINE to mean that there IS an address conflict,
and blacklists the address.

/sG

-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Burcak
Beser
Sent: Wednesday, February 27, 2002 6:05 PM
To: dhcwg@ietf.org
Cc: rdroms@cisco.com
Subject: [dhcwg] DHCP_DECLINE question

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

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