IETF Logo Mail Archive

RE: [dhcwg] DHCP_DECLINE question

Richard Barr Hibbs <rbhibbs@pacbell.net> Thu, 07 March 2002 15:35 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 KAA00668 for <dhcwg-archive@odin.ietf.org>; Thu, 7 Mar 2002 10:35:29 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02801 for dhcwg-archive@odin.ietf.org; Thu, 7 Mar 2002 10:35:32 -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 KAA02622; Thu, 7 Mar 2002 10:32:17 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02591 for <dhcwg@optimus.ietf.org>; Thu, 7 Mar 2002 10:32:15 -0500 (EST)
Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00443 for <dhcwg@ietf.org>; Thu, 7 Mar 2002 10:32:10 -0500 (EST)
Received: from BarrH63p601 ([63.193.193.26]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GSM00CYU0HQNK@mta5.snfc21.pbi.net> for dhcwg@ietf.org; Thu, 07 Mar 2002 07:32:14 -0800 (PST)
Date: Thu, 07 Mar 2002 07:31:47 -0800
From: Richard Barr Hibbs <rbhibbs@pacbell.net>
Subject: RE: [dhcwg] DHCP_DECLINE question
In-reply-to: <2E33960095B58E40A4D3345AB9F65EC103C09A39@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
To: dhcwg@ietf.org
Reply-to: rbhibbs@pacbell.net
Message-id: <JCELKJCFMDGAKJCIGGPNIEAKDLAA.rbhibbs@pacbell.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
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

> -----Original Message-----
> From: Thirumalesh Bhat
> Sent: Wednesday, March 06, 2002 22:00
> 

<*Snip!*>

>  
> If the client does a release after getting an ack because it 
> doesnt like some lease parameter and ends up in the init state, 
> the client may loop for ever. As Ted has mentioned, this is a 
> very unlikely real world scenario.
>  

...I disagree:  a network with a single DHCP server is not likely to change option values for a specific lease/client pair, so a client that releases an address because of an issue with one or more option values will simply be offered the same lease, with the same option values, repeatedly.

Having said that, such behavior on the part of the client, if not broken, is at least ill-conceived:  clients should be a bit permissive in the option values they accept, accepting that the network administrator who configured the server has additional or global knowledge that resulted in the option values offered.

--Barr


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

v2.23.0 | Report a Bug | By Email