RE: [dhcwg] DHCP_DECLINE question

Richard Barr Hibbs <rbhibbs@pacbell.net> Tue, 05 March 2002 18:15 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 NAA13755 for <dhcwg-archive@odin.ietf.org>; Tue, 5 Mar 2002 13:15:40 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23570 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 13:15:41 -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 NAA23146; Tue, 5 Mar 2002 13:09:50 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23104 for <dhcwg@optimus.ietf.org>; Tue, 5 Mar 2002 13:09:47 -0500 (EST)
Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13425 for <dhcwg@ietf.org>; Tue, 5 Mar 2002 13:09:45 -0500 (EST)
Received: from BarrH63p601 ([63.193.193.26]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GSI00EC4IGAPP@mta6.snfc21.pbi.net> for dhcwg@ietf.org; Tue, 05 Mar 2002 10:09:46 -0800 (PST)
Date: Tue, 05 Mar 2002 10:09:19 -0800
From: Richard Barr Hibbs <rbhibbs@pacbell.net>
Subject: RE: [dhcwg] DHCP_DECLINE question
In-reply-to: <4.3.2.7.2.20020305122006.03831e38@funnel.cisco.com>
To: dhcwg@ietf.org
Reply-to: rbhibbs@pacbell.net
Message-id: <JCELKJCFMDGAKJCIGGPNOEOPDKAA.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="US-ASCII"
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: Ralph Droms
> Sent: Tuesday, March 05, 2002 09:27
>
> Good point re. potential for looping.  This behavior should only
> occur when the parameters change between the DHCPOFFER and the
> DHCPACK.  Presumably, on the retry after the RELEASE, the OFFER
> and the ACK will match and the client will accept the parameters
> in the ACK.
>
...while the parameters would likely match, it might be that the client
still doesn't like the values and that takes us back to the initial question
about the meaning of DHCPDECLINE.

If the client is receiving offers from multiple servers, the client could
simply ignore the offer it doesn't like (assuming that the parameters are
actually different between the two offers, and not merely the IP address)
which is our de facto standard for clients dealing with offers they do not
like.

It doesn't even have to be a mismatch between offer and ack that would cause
a client to decide against using the lease, but as I think about it, it
doesn't appear that v4 has a mechanism for rejecting the lease after the
client sends a request -- only if there is an address conflict, not the more
general case.


> The client will only send the REQUEST if the parameters in the
> OFFER are acceptable, so an infinite loop will only happen if
> the OFFER and ACK continue to "flap".
>
...exactly


> This answer begs the question of how the client behaves if the
> client doesn't receive an acceptable OFFER; for example, the
> second OFFER matches the first ACK (which the client rejected).
> The behavior of the client when it receives no acceptable OFFERs
> is left to the implementation...
>
...*IF* we were revisiting the details of the v4 protocol, it might well be
worth providing a mechanism for the client to reject a lease after receiving
the DHCPACK message, but short of that, we'll just have to live with
implementation-specific solutions to this "problem."

--Barr


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