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 ; 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 ; 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 ; 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" To: "'Ralph Droms'" , Burcak Beser Cc: dhcwg@ietf.org Subject: RE: [dhcwg] DHCP_DECLINE question Date: Tue, 5 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: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C467.EF2290A0 Content-Type: text/plain; charset="iso-8859-1" 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 > ------_=_NextPart_001_01C1C467.EF2290A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCP_DECLINE question

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?
> >
> >       &n= bsp; 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
>

------_=_NextPart_001_01C1C467.EF2290A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg