RE: [dhcwg] DHCP_DECLINE question

"Kostur, Andre" <Andre@incognito.com> Tue, 05 March 2002 17:06 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 MAA09459 for <dhcwg-archive@odin.ietf.org>; Tue, 5 Mar 2002 12:06:30 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17641 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 12:06: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 MAA16961; Tue, 5 Mar 2002 12:00:52 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16921 for <dhcwg@optimus.ietf.org>; Tue, 5 Mar 2002 12:00:50 -0500 (EST)
Received: from portal.incognito.com (HAZARD.INCOGNITO.COM [207.102.214.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09217 for <dhcwg@ietf.org>; Tue, 5 Mar 2002 12:00:45 -0500 (EST)
Received: from homer.incognito.com ([207.102.214.21] helo=homer.incognito.com.) by portal.incognito.com with smtp (Exim 3.33 #1) id 16iI3v-00027Y-00; Tue, 05 Mar 2002 08:45:15 -0800
Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <13HA4987>; Tue, 5 Mar 2002 09:05:26 -0800
Message-ID: <4FB49E60CFBA724E88867317DAA3D19849544D@homer.incognito.com.>
From: "Kostur, Andre" <Andre@incognito.com>
To: 'Ralph Droms' <rdroms@cisco.com>, Burcak Beser <burcak@juniper.net>
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] DHCP_DECLINE question
Date: Tue, 05 Mar 2002 09:05:21 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C467.EF2290A0"
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

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]
> 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
> >
> >
> >_______________________________________________
> >dhcwg mailing list
> >dhcwg@ietf.org
> >https://www1.ietf.org/mailman/listinfo/dhcwg
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>