RE: [dhcwg] DHCP_DECLINE question

Barr - comments in line...

At 10:09 AM 3/5/2002 -0800, Richard Barr Hibbs wrote:

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

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

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

Agreed...

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

Bute, if the client doesn't like the OFFER, it won't send the REQUEST and 
won't get the ACK.  I think of this case as the lease never being created, 
as opposed to a lease being created and then terminated in the case the 
client doesn't like what's in the ACK.

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?

- Ralph

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

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