RE: [dhcwg] DHCP_DECLINE question

[Ralph Droms <[e-mail]>]

At 03:31 PM 3/6/2002 -0800, Richard Barr Hibbs wrote:

>I'll try to clarify the points.....
>
>--Barr
>
>
> > -----Original Message-----
> > From: Ralph Droms
> > Sent: Tuesday, March 05, 2002 11:36
> >
> > Barr - comments in line...
> >
> > At 10:09 AM 3/5/2002 -0800, Richard Barr Hibbs wrote:
> >
> > > > 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.
> >
> > Barr - I'm with you here up to the last few words.  What do you mean by
> > "...the initial question about the meaning of DHCPDECLINE"?
> >
>...assuming I understood the question properly, it could be restated as "Can
>a client use DHCPDECLINE to reject an offered IP address after sending
>DHCPREQUEST?"  Implied in that is what recourse is there for a client that
>doesn't like some or all of a server's offer?

The meaning of DHCPDECLINE is pretty well-defined; from the 5th element in 
the numbered list in section 3.1 of RFC2131:

      If the client detects that the
      address is already in use (e.g., through the use of ARP), the
      client MUST send a DHCPDECLINE message to the server and restarts
      the configuration process.

DHCPDECLINE is intended for use when the assigned address is already in use.

In my opinion, a client is within the spec if it sends a DHCPRELEASE 
immediately after receiving a DHCPACK (for whatever reason).  The 
DHCPRELEASE will terminate the lease and make the address available for 
reassignment without causing the server to mark the address as "not to be 
assigned".

There is still the open question of whether we want to *recommend* this 
behavior...



><*Snip!*>
>
> > I agree that there is no explicit mechanism for rejecting a lease (as
> > opposed to releasing it) once the server sends the REQUEST.  Is
> > there much
> > of a difference between the two cases?
> >
>...only that if a client releases the lease it is likely to get the same
>lease the next time it starts the cycle....  I don't think we should be
>making a change to the protocol at this point lacking sufficient evidedence
>of harm caused by the current behavior, but it does seem a bit of an
>oversight....

But the problem isn't the lease/assigned address so much as the other 
parameters.  If the client gets the same (unacceptable) parameters in the 
subsequent DHCPOFFER, the client will ignore it.


>--Barr

- Ralph



_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg