Re: [dhcwg] DHCP_DECLINE question

Ted Lemon <Ted.Lemon@nominum.com> Wed, 06 March 2002 23:29 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14910 for <dhcwg-archive@odin.ietf.org>; Wed, 6 Mar 2002 18:29:40 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA27165 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 18:29:44 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27101; Wed, 6 Mar 2002 18:27:11 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27080 for <dhcwg@optimus.ietf.org>; Wed, 6 Mar 2002 18:27:09 -0500 (EST)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14804 for <dhcwg@ietf.org>; Wed, 6 Mar 2002 18:27:04 -0500 (EST)
Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g26NMaX26782; Wed, 6 Mar 2002 15:22:36 -0800 (PST)
Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g26NQxF00428; Wed, 6 Mar 2002 17:26:59 -0600 (CST)
Date: Wed, 06 Mar 2002 17:26:59 -0600
Subject: Re: [dhcwg] DHCP_DECLINE question
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v481)
Cc: dhcwg@ietf.org
To: rbhibbs@pacbell.net
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <JCELKJCFMDGAKJCIGGPNOEOPDKAA.rbhibbs@pacbell.net>
Message-Id: <A828DD9A-3159-11D6-8B5E-00039367340A@nominum.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
Content-Transfer-Encoding: 7bit
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Content-Transfer-Encoding: 7bit

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