RE: [dhcwg] DHCP_DECLINE question

Ralph Droms <rdroms@cisco.com> Tue, 05 March 2002 17:36 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 MAA10943 for <dhcwg-archive@odin.ietf.org>; Tue, 5 Mar 2002 12:36:15 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19544 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 12:36:18 -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 MAA18834; Tue, 5 Mar 2002 12:27:21 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18803 for <dhcwg@optimus.ietf.org>; Tue, 5 Mar 2002 12:27:19 -0500 (EST)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10496 for <dhcwg@ietf.org>; Tue, 5 Mar 2002 12:27:15 -0500 (EST)
Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-128.cisco.com [161.44.149.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA25680 for <dhcwg@ietf.org>; Tue, 5 Mar 2002 12:26:48 -0500 (EST)
Message-Id: <4.3.2.7.2.20020305122006.03831e38@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 05 Mar 2002 12:26:42 -0500
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Subject: RE: [dhcwg] DHCP_DECLINE question
In-Reply-To: <4FB49E60CFBA724E88867317DAA3D19849544D@homer.incognito.com .>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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

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.

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

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

- Ralph

At 09:05 AM 3/5/2002 -0800, Kostur, Andre wrote:

>Drawback on the RELEASE/DISCOVER method:  wouldn't this just simply send 
>the client into an infinite loop of DISCOVER/REQUEST/RELEASE sequence?  If 
>the stuff sent by the server is unacceptable the first time around, why 
>would the second time be any different?
>
>And, using DECLINE doesn't make it much better (actually has the potential 
>to make it worse!).  If a client DECLINES an unsuitable ACK because it 
>doesn't like one of the DHCP options, the server would likely mark that IP 
>as used.  Then when that client came back, it will likely DECLINE the next 
>IP that it's given, the DHCP server marks that IP as used too, and so on, 
>and so on, until that one client has effectively consumed your entire IP space!
>
> > -----Original Message-----
> > From: Ralph Droms [<mailto:rdroms@cisco.com>mailto:rdroms@cisco.com]
> > Sent: Tuesday, March 5, 2002 5:33 AM
> > To: Burcak Beser
> > Cc: dhcwg@ietf.org
> > Subject: Re: [dhcwg] DHCP_DECLINE question
> >
> >
> > I agree with Kim and Ted - DHCPDECLINE is defined in RFC2131
> > to be used in
> > the case of an address conflict, and many DHCP servers will mark the
> > address in a DHCPDECLINE so that it is not offered again in
> > the future.
> >
> > If the client decides that the address or other parameters in
> > a DHCPACK are
> > not acceptable, the client should respond with a DHCPRELEASE and then
> > restart the address assignment process with a DHCPDISCOVER.
> >
> > - Ralph
> >
> > At 12:26 PM 2/28/2002 -0500, Kim Kinnear wrote:
> > >At 06:04 PM 2/27/2002, Burcak Beser wrote:
> > > >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.)
> > >
> > >         No, it is not. See below.
> > >
> > >
> > > >In other words when a DHCP_DECLINE is received by the DHCP
> > SERVER does
> > > this mean that the client detected that the IP address is
> > already used by
> > > another entity?
> > >
> > >         Yes, and the implication (as well as the explicit
> > >         direction) is that the DHCP server should not offer this
> > >         IP address to this client or any other client for at
> > >         least some time since it has been shown to be "unusable"
> > >         for DHCP client allocation (because some client (or
> > >         machine, maybe not a DHCP client) appears to be using it).
> > >
> > >         From RFC2131.txt:
> > >
> > >4.3.3 DHCPDECLINE message
> > >
> > >    If the server receives a DHCPDECLINE message, the client has
> > >    discovered through some other means that the suggested network
> > >    address is already in use.  The server MUST mark the
> > network address
> > >    as not available and SHOULD notify the local system
> > administrator of
> > >    a possible configuration problem.
> > >
> > >
> > >         If you don't like the IP address, you could use a
> > >         DHCPRELEASE to give it back.  Of course, you may in that
> > >         case be offered it next time, but you don't need to take
> > >         the offer.
> > >
> > >         If you just want to give it back, use DHCPRELEASE.
> > >
> > >         If you want to give it back and be offered a different IP
> > >         address from this server, that's a harder question, since
> > >         the DHCPDECLINE implies that the address isn't usable.
> > >
> > >         Cheers -- Kim
> > >
> > >
> > >
> > >
> > >
> > > >-burcak
> > > >
> > > >_______________________________________________
> > > >dhcwg mailing list
> > > >dhcwg@ietf.org
> > > ><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/m 
> ailman/listinfo/dhcwg
> > >
> > >
> > >_______________________________________________
> > >dhcwg mailing list
> > >dhcwg@ietf.org
> > ><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mai 
> lman/listinfo/dhcwg
> >
> >
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > 
> <https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailman/listinfo/dhcwg 
>
> >


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