Subject: NAK on RENEW or REBINDING

From: Kim Kinnear <[email-masked]>
Date: Fri, 11 Dec 1998 16:17:23 -0500 (EST)

I took an action item in the DHC WG meeting in Orlando
last Wednesday to find the places in the draft where NAK's to
RENEW's or REBINDING's are discussed.

I spent a year or so thinking that what to do if a NAK arrived at
a client in response to a renew or rebinding request was
specified only in the state transition diagram on page 35, and
then I distinctly remember finding some text that also described
this.  However, I cannot now find that descriptive text (and I
only mention it in case someone else has stumbled on this in
their travels through the RFC).

-----------------------------

At present I can find two places that discuss the client's
response to DHCPNAK when in the RENEWING or REBINDING
states:

1.  The state transition diagram for the client on page 35
clearly specifies that a client which receives a DHCPNAK when in
RENEWING state should move to INIT state and "halt network".

2.  Page 32, end of paragraph 5, says "The server may choose not
to extend the lease (as a policy decision by the network
administrator), but should return a DHCPACK message regardless.

These are not inconsistent, but certainly the behavior in
the case where the client receives a DHCPNAK in response
to a RENEW or REBINDING request is less than well specified.

-----------------------

I would propose that we could further clarify RFC 2131 if we
added the following text in the following places. Note that
this does not conflict with what is already in the draft,
and it also represents what many clients do today:

Page 32, new paragraphs placed immediately before paragraph
5:

    If the server determines that the client should no longer use
    the lease, it SHOULD send a DHCPNAK.  Upon receipt of a
    DHCPNAK in the RENEWING state, the client MUST move to the
    INIT state and halt network operations.  The server cannot
    assume that the client entered INIT state until it receives a
    DHCPDISCOVER message, and so MUST NOT reuse the client's IP
    address just because it sent a DHCPNAK to the client.  

    It is important to be aware that a client receiving a DHCPNAK
    when in RENEWING state will immediately terminate all network
    operations (in the same way as it will when its lease
    on an IP address expires without renewal), and so a DHCPNAK
    should only be sent to a client in RENEWING state in
    exceptional circumstances.

Page 33, new paragraphs immediately after paragraph 1:

    If the server determines that the client should no longer use
    the lease, it SHOULD send a DHCPNAK.  Upon receipt of a
    DHCPNAK in the REBINDING state, the client MUST move to the
    INIT state and halt network operations.  The server cannot
    assume that the client entered INIT state until it receives a
    DHCPDISCOVER message, and so MUST NOT reuse the client's IP
    address just because it sent a DHCPNAK to the client.  

    It is important to be aware that a client receiving a DHCPNAK
    when in REBINDING state will immediately terminate all
    network operations (in the same way as it will when its
    lease on an IP address expires without renewal), and so a
    DHCPNAK should only be sent to a client in REBINDING state in
    exceptional circumstances.

Page 41, paragraph 5, addition to the first sentence -->:

    If the lease expires before the client receives a DHCPACK 

  --> or if the client receives an explicit DHCPNAK,   
    
    the client moves to INIT state, MUST immediately stop any
    other network processing and requests network initialization
    parameters as if the client were uninitialized.

------------------------

Cheers -- Kim

Kim Kinnear
Cisco Systems
Chelmsford, MA  01824

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Thu, 17 Dec 1998 14:33:19 -0500 (EST)

Hi Kim,
 
> their travels through the RFC).

Right. This text is trying to fix a interoperability problem we found
at connectathon one year. The point of this text was to clarify a
server's behavior in the case where the client still has a valid lease,
and is requesting a lease extension which the server cannot due to 
administrative policy, honor. The server will respond with the remaining
lease in a DHCPACK, until such time as the client's lease is exhausted,
at which time the server would send a NAK.

> to a RENEW or REBINDING request is less than well specified.

I disagree with this final sentence. Both the client and the server
must cooperate in managing the lease. If a client's lease has expired,
the server MUST send a DHCPNAK. It is then free to reassign that IP
address to another client. Since previously assigned IP addresses are
reused in a Least Recently Used (LRU) order, the chances that the DHCP
server would immediately assign this IP address to a different client are
slim. Futuremore, if such a situation occurred, the DHCP server would detect
that the client IP address is being used via an ICMP echo request, and
would select another IP address.

Your sentence states that if the DHCP server doesn't recieve a DISCOVER
after the NAK, that IP address can never be reused again (unless that
client comes back up again). I don't think that's the behavior you were
intending. IMHO, I think the protocol already deals adequately with this
situation.
  
>     address just because it sent a DHCPNAK to the client.  

Again, I take exception to the last sentence, for the reasons I
mentioned above.

>     parameters as if the client were uninitialized.

This looks good.

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 17 Dec 1998 17:42:39 -0500 (EST)

Mike,

Thanks thinking about this stuff.  More comments below:

>Hi Kim,
.
.
.
>>  Kim said:

>Mike responded:

Your are quite right, of course. If the lease has expired then
the server can re-use it at will.  If the lease has expired on a renewal
and the server doesn't choose to extend it, it though that
it SHOULD NAK it today. I think you are suggesting we would make that
a MUST NAK?  I could go with that.

My point was that if the lease *hasn't* expired, and the server
NAK's it, the server MUST NOT reuse it until the client issues
a DHCPDISCOVER (indicating that is it in INIT state) or (as
you point out) the lease expires.

Cheers -- Kim

---

From: Steve Gonczi <[email-masked]>
Date: Thu, 17 Dec 1998 18:22:14 -0500 (EST)

I see some difficulties with trying to revoke a lease before its agreed upon
expiration time.  
Once a client has been granted a lease, it is conceivable that the server
can not further communicate with the client ( e.g.: router failure).

Hence:

1) A contractual issue: Once the client was granted a lease, it is entitled
to use it, until it expires,
or hands it back.

2) An unreliable delivery issue: Even if a server NAK-s a lease, while the
contract is still in effect, 
there is no way to know for sure whether the client has received the NAK.

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Thu, 17 Dec 1998 18:22:52 -0500 (EST)

> a MUST NAK?  I could go with that.

A server MUST NAK only when the lease has expired (and local policy has
be set to preclude lease extensions).

> you point out) the lease expires.

In the case where a client's lease has not yet expired, but T1 and/or T2 times
have passed (prompting the client to renew/rebind), a server MUST NOT NAK
the client. Any server that would NAK in this situation is broken IMHO. The
server should just return the remaining lease time in a DHCPACK, until the
lease ultimately expires. Then the client should be sent the NAK, if it keeps
on trying to extend (the client may have experienced clock drift, and think
it still has some time when in fact it does not). Otherwise, the client would
drop back to INIT on its own.

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Thu, 17 Dec 1998 18:23:15 -0500 (EST)

Hi Steve,

> I see some difficulties with trying to revoke a lease before its agreed upon

I don't believe I was proposing such a thing. In fact, I was trying to prevent
exactly that. A DHCP server should always respond with a DHCPACK as long as the
client's lease is still valid. It may not be able to extend that lease due to
site policy, but it must still return the remaining lease in an DHCPACK.

> to use it, until it expires,

Yes.

> there is no way to know for sure whether the client has received the NAK.

That's true. There is no acknowledgement of NAKs. But the duplicate IP address
detection at the server (and most clients) will prevent any problems due to
undelivered NAKs.

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Thu, 17 Dec 1998 19:08:24 -0500 (EST)

[I respond]:

> >In the case where a client's lease has not yet expired, but T1 and/or T2
> times >have passed (prompting the client to renew/rebind), a server MUST NOT
> NAK >the client. Any server that would NAK in this situation is broken IMHO.

[Kim responds]:

> 
> This is where we disagree.  The situation where a server might NAK
> a RENEW is where it has decided that a client SHOULD not be using this 
> address anymore, despite the existance of a valid lease for a longer time.
> The reasons for this are perhaps because the server has found a need
> to renumber a large set of clients, or becaue the "flavor" of lease
> that this client is using has been determined to be not appropriate 
> for that client (using some method of determination outside of the
> scope of the protocol).

We do disagree. The client and server enter into a contract when the lease
assignment is made (and followup lease extensions occur). Both parties agree
to the lease value. The client may give up the lease (RELEASE) before it
expires, but the server should never fail to honor that lease time. Behavior
such as you suggest could result in a loss of user data. At least in the
standard case where the client and server agree on the lease time, the client
would be issuing warnings to it's users that the lease on the IP address will
soon  expire (so that they can save their work, for example).

For behavior such as renumbering, then the local policy should be to set the
lease time to the lowest comfortable value such that the renumbering can take
place as soon as the lease on the existing IP addresses expire. (since the
lease is short (hours), this will happen in a timely fashion).
> 
> Certainly sending a DHCPNAK when there is time left to run on a
> lease is something that must only be done in the most critical
> circumstances because it will bring down all of the network connections
> on that client.  However, we have found a number of times (typcially
> as part of provisioning cable modems and machines behind cable modems)
> where they aren't really up to any degree anyway and are just
> waiting for a NAK to signal them to go back and get another address.

Yes, loosing data is my concern.
> > The
> >lease ultimately expires. Then the client should be sent the NAK, if it
> keeps >on trying to extend (the client may have experienced clock drift, and
> think >it still has some time when in fact it does not). Otherwise, the
> client would >drop back to INIT on its own.
> >> 
> >> Cheers -- Kim
> >> 
> >>  
> >
> >
> >
> >Mike Carney
> >SNT Internet Engineering
> >Sun Microsystems, Inc.
> > 

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 17 Dec 1998 19:07:40 -0500 (EST)

At 06:04 PM 12/17/98 -0500, Mike Carney - SNT Internet Engineering wrote:
>the client. Any server that would NAK in this situation is broken IMHO.

Cheers -- Kim

---

From: Rob Stevens <[email-masked]>
Date: Fri, 18 Dec 1998 02:47:17 -0500 (EST)

Perhaps I am alone in this but...

1. I really don't see the purpose in server's ACKING a RENEW
   if they aren't extending the lease.
   The client says "will you renew my lease". The server says
   "Yes. Here is the identical lease again".
   This does not seem logical.
   There may be clients out there (we have one) that start complaining
   when they cannot renew their leases, and complain more vigorously
   when they can't rebind (times nearly up).
   I think that ACKing without actually renewing the lease may lead
   to the undesirable behavior that the client is not aware that the
   lease is actaully going to evaporate.
  With a mere seconds to go the server sends a 2 second lease
   and the client thinks: that's great - no need to alert the user
   that his connection is about to be blown.

2. I don't think that servers should NAK for renumbering. It seems
   to me that clients should be allowed to quietly fade away, be
   and be forced to DISCOVER all over again. It systems admins
   have configured leases which are too long to sensibly do this
   then.....get a new system admin.
   As Steve Gonczi has said, NAk is not reliable, so a server
   cannot re-use the address anyway unless the client sends
   a DISCOVER.
   I'd like to ask Microsoft what the behavior of their client is
   in response to a NAK of a renewal.
   Rather than change a zillion clients, I would prefer to change
   a few servers.

3. I also don't think that servers should NAK simply because the
    lease has expired. Sure, an expired binding may have been
    excised on a server database, and the server may NAK in this
   case. But it seems pedantic to have servers NAK merely because
   the client is being naughty and shouldn't be renewing.

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 18 Dec 1998 10:30:53 -0500 (EST)

Carl,

Thanks for responding.  Two points I'd like to make:

1. Nothing in what I've said has anything to do with
expecting a client to be listening the the server
at any arbitrary time.  I'm talking *only* about 
why one might respond to a renewal or rebinding
with a NAK instead of an ACK -- a very different
thing.

2. Nothing in what I've said should require a
change to any existing client -- I'm only proposing
to clarify the RFC.  Any client that was coded
to correspond to the RFC or the previous drafts 
will move into INIT state if it receives a DHCPNAK
in response to a RENEW or REBINDING.  

Cheers -- Kim

At 04:57 PM 12/17/98 -0800, Carl Smith wrote:
>	I'm with Mike.  What you're describing is a broken behavior caused
>by incorrect administration.  I thought we had long ago made peace with the
>notion that we can't expect v4 clients to even be listening to us, much less
>be prepared to do something intelligent if we try to pull a renumbering
>exercise.  We knew about this limitation when DHCP was designed.  It can't
>be changed without doing an unknown amount of harm to already-deployed clients.
>
>			Carl
>

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 18 Dec 1998 10:36:03 -0500 (EST)

>   then.....get a new system admin.

An interesting approach, certainly.

>   cannot re-use the address anyway unless the client sends

I completely agree, and so I wanted to clarify that in the 
language I proposed.

>   Rather than change a zillion clients, I would prefer to change
 
As I responded to Carl, any client that is coded in accordance
with the RFC or the previous drafts MUST move into INIT state
if it receives a DHCPNAK in response to a RENEWAL or REBINDING.

I'm *not* talking about changing clients, existing or otherwise.
I'm only talking about clarifying the RFC.

Cheers -- Kim

---

From: Paul Fox <[email-masked]>
Date: Fri, 18 Dec 1998 10:36:30 -0500 (EST)

> > address anymore, despite the existance of a valid lease for a longer time.
 ...
 > expires, but the server should never fail to honor that lease time. Behavior

only allowing the client to renege on the "contract" before its expiration
really seems impractical, and places an undo burden on administrators
to foresee unforeseen circumstances.

can i suggest a modification to kim's suggested change which might
sit better?

       If the server determines that the client should no longer use
       the lease, it SHOULD allow the lease to expire naturally,
       either by ACKing the client's renewals without extending the
       lease, or by simply not responding to the client.  In cases
       where the server has determined it is necessary for the client
       to stop using the address immediately, the server MAY send a
       DHCPNAK.  Upon receipt of a DHCPNAK in the RENEWING state, the
       client MUST move to the INIT state and halt network operations. 
       The server cannot assume that the client entered INIT state
       until it receives a DHCPDISCOVER message, and so MUST NOT reuse
       the client's IP address just because it sent a DHCPNAK to the
       client. 
       
       Discussion:

=---------------------
       paul fox  [email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 18 Dec 1998 11:30:48 -0500 (EST)

>        the client's IP address just because it sent a DHCPNAK to the

Can you spell out precisely how a server is supposed to associate a
DISCOVER message with a previous lease?  i.e., how does it know that
the entity sending the DISCOVER is actually the one which held the
lease?

What if you run multiple instances of DHCP on a single network
interface because you need multiple addresses for some reason or
another?

If you want to change the DHCP protocol to let it revoke leases at the
server's discretion, perhaps a safer/less radical change would be to
require the client to send a RELEASE after a RENEW/REBIND-state
REQUEST has been NAK'ed

					- Bill

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Fri, 18 Dec 1998 11:30:23 -0500 (EST)

Hi Rob,

>    that his connection is about to be blown.

I disagree. The fundamental purpose of a DHCPNAK is to inform a client that
its IP address is incorrect. When a client inserts the lease time option
in its requests, it is "requesting" a lease extension. Whether or not
this extension is granted is a DHCP server policy switch. Clients commonly
ask for a permanent lease, knowing the server will set them straight.
 What's wrong with asking for the world? ;^)

Suppose the following situation - a client was given a 5 day lease. Since
the t1 time isn't explicitly set, the client's renewal time is 50% of the
lease, or 2.5 days. Further suppose that the server has been instructed not
to extend leases. 2.5 days into the lease, the client tries to renew.

a) If the client is DHCPNAK'ed, boom - all current connections
are nuked and the client drops to INIT state - without warning.

b) If the client is handed the remaining lease (2.5 days), it continues to
function, trying again in 1.25 days.

I prefer #b behavior. However, you do point out an omission in the draft.
Clients are supposed to use an inverse exponential timeout algorithm, such
that renew/rebind requests will happen more and more frequently as the lease
expiration time is approached. If the user warning is to occur, the client
would need to be aware that the lease time it is being assigned is not being
extended, and output a warning message. As the expiration approaches, these
warnings would become more numerous. We should add text suggesting this
warning to the draft.

>    Rather than change a zillion clients, I would prefer to change

I agree.

>    the client is being naughty and shouldn't be renewing.

I think you need to expand on this one alittle. IMHO, a server MUST
NAK if the lease has expired. It is the only way to bring the client
and server back into synchronization (some settings might have changed,
like the IP address, subnet mask, etc - renumbering for example).

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Fri, 18 Dec 1998 11:31:10 -0500 (EST)

Hi Paul,

> to foresee unforeseen circumstances.

No, I don't believe so. In DHCP, clients are active, servers are passive. Thus
it makes perfect sense for a client to announce to the server that it no longer
needs an IP address (via DHCPRELEASE) in order to allow the server to assign
the IP address to another client. Note that this behavior is entirely defined
within the protocol, such that it is within the "contract" between client and
server.

>        the client's IP address just because it sent a DHCPNAK to the

Breaking the lease contract on the passive side (server) is wrong, IMHO,
for the reasons I've stated in my response to Kim's mail. And you're still
asking the server to withhold assignment of an IP address until it receives
a DHCPDISCOVER from that client. This is wrong for the reasons I've mentioned.
DHCP already more than adequately deals with this situation. I don't see the
advantages of changing the current behavior.

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 18 Dec 1998 12:25:42 -0500 (EST)

>the entity sending the DISCOVER is actually the one which held the

	Yes, RFC 2131 spells out on page 26 the way that a DHCP
	server associates a client with an IP address.  In short
	it says (more or less) "use the client-id if one appears,
	else use the MAC address".  This is what servers use today
	such that if a client sends in a DISCOVER with the same
	client-id that they used to previously lease an IP address,
	they get that same address (and not a different one) back
	again -- and not an additional lease on a new address.
>interface because you need multiple addresses for some reason or

	Then you must use multiple client-id's to do so (which is
	perfectly legal and supported) or fudge the MAC address
	in some way (which I don't like, but is done), or both
	(which is also done).

>require the client to send a RELEASE after a RENEW/REBIND-state

	I do *not* want to change the DHCP protocol.  I am trying to
	clarify currently documented behavior in RFC 2131 that
	is implemented in all clients of which I am aware.

       See the state transition diagram on page 35 of RFC 3121, 
	the DHCPNAK state transitions from the RENEWING or REBINDING 
	states.

	Cheers -- Kim

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 18 Dec 1998 12:26:04 -0500 (EST)

>a DHCPDISCOVER from that client. This is wrong for the reasons I've mentioned.

I don't understand these reasons, as I thought I dealt with them -- they
are two:

1. Either the lease expires, and you can reuse it.

2. Or if (prior to expiration) the same client shows up with a DISCOVER, then
you can reuse the lease that it had previously should you choose to.

>advantages of changing the current behavior.

I am in *no* way attempting to alter current behavior, I am only attempting
to clarify something that is already documented on page 35 of the RFC 2131
quite clearly.  

Cheers -- Kim

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Fri, 18 Dec 1998 12:26:24 -0500 (EST)

Hi Kim,
	Sorry; I wasn't inferring that you hadn't dealt with
these reasons. It appeared that Paul was re-proposing your original
change; I was simply trying to reference that discussion.

Yes.

Yes.

> >advantages of changing the current behavior. >
> 

Yes, I understand.

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.

---

From: Paul Fox <[email-masked]>
Date: Fri, 18 Dec 1998 13:04:28 -0500 (EST)

> change; ...

it was a re-proposal, with a significant difference.  kim's SHOULD had
become a MAY, and your (and others') preferred behavior (letting the
client keep the lease as per prior agreement) had become the SHOULD.

paul
=---------------------
       paul fox  [email-masked]

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Fri, 18 Dec 1998 13:06:26 -0500 (EST)

Hi Rob,
	See my later response to Ted Lemon - Where I said I misread your
message! What you're proposing is perfectly valid.

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Fri, 18 Dec 1998 13:05:43 -0500 (EST)

> 
> > The fundamental purpose of a DHCPNAK is to inform a client that its
> > IP address is incorrect.
> 
> Right.  I think what Rob's saying (and certainly this is my opinion)
> is that an IP address can become incorrect for more reasons than just
> that the client has been moved to a different network.

I misread Rob's mail - I thought he was proposing that a server NAK a
client who is seeking a lease extension. What he is proposing (a server
should remain silent) is perfectly valid. The text I wrote after this
misreading is therefore invalid.

> I don't see where you get this.   If the client runs off the end of
> the lease, it automatically reverts to INIT state, just as if it had
> received a DHCPNAK.   So whether or not you send a DHCPNAK in this
> case is immaterial.   Indeed, if the lease has expired, the client
> shouldn't even be sending a DHCPREQUEST - it should be sending a
> DHCPDISCOVER.   I don't see why the server needs to take any explicit
> action to resynchronize with the client here.
> 
> 		
	   
You're assuming the client's clock is valid.

I'm speaking about the case where the clock in the client gets out of sync
for some reason (laptop was suspended, lithium battery on board is dead) such
that the client loses time. It thinks it still has plenty of time, however, the
lease has expired from the servers point of view. The client tries to renew.
Don't you think the server should NAK the client in this case?  For the reason
you mentioned above about a client getting the latest information?

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.

---

From: Rob Stevens <[email-masked]>
Date: Fri, 18 Dec 1998 13:06:04 -0500 (EST)

>warnings would become more numerous. We should add text suggesting this

Mike
I wasn't suggesting that the server NAK if it won't extend the lease -
certainly not!
I was suggesting that it not respond.

I can see one advantage in ACK'ing with the same lease though - it
relieves the client of the necessity to backoff and re-transmit.
It occurs to me that, since the client is going to try several
times to renew before the lease expires, it may not be necessary
to have backoff and re-transmission on renewals.

E.g. on a 4 hour lease the client will (with default T1) try
after 2 hours, then 1 hour, 30 mins. Whoops, this seems
inadequate. I take back the last sentence of the previous paragraph.

---

From: Munil Shah <[email-masked]>
Date: Fri, 18 Dec 1998 13:50:37 -0500 (EST)

First of all let me apologize for not replying to this email thread even
though I was the one who sort of intiated this discussion at IETF.

Let me state what our clients do currently. Bith win9x and winNT clients do
expect to receive NAK from the server even during RENEWING state. This is
consistent with the DHCP client state diagram in the RFC. When they receive
NAK, they go back into INIT state. So if we change the behaviour from what
the DHCP state diagram suggests, our clients will suddenly be non-compliant
with the RFC.

Moreover, i think allowing NAK is the right thing to do. Some people have
expressed two concerns with this.
1) Client has a contract from the server and the server shouldnt break this.
2) Even if the server sends NAK, how does the server guarantee that client
would have released the address.

Here's my answer to this. Consider a situation where your network is
renumbered over the weekend. Let's look at both the issues in this scenario.
1) How does it matter whether or not we are breaking the client's contract.
Client has a bogus address on the network. It's no good anyways.
2) There is no need to guarantee because server does not even have the
original subnet configured anymore. The server doesnt care whether or not
client received the NAK and processed it.

In most cases when server decides to send NAK to the client, it is because
the current address the client has is no useful. It is better to tell the
client as early as possible. 
Regarding what happens if the NAK gets dropped: well there is no problem
because either the server doesn't care about that bogus address OR if the
server is configured to do the conflict detection, there is no chance of
reusing that address for some other client.

So i think NAKing does allow some useful things to happen. And i dont think
it causes any serious side effects.

What do you think?
Thanks,
-Munil

---

From: "Hibbs, R BARR (PB-rbhibbs)" <[email-masked]>
Date: Fri, 18 Dec 1998 15:33:03 -0500 (EST)

Boy!  Turn your back on e-mail for even a few hours and look what happens!

I apologize for jumping in with no prior comments, but I want to first ask
the question, "Are there *any* cases for which early termination of a lease
by the server is *acceptable*, *desirable*, or *necessary*?"

I can enumerate a few cases where I believe that a NAK is proper behavior,
but each of these cases applies when the renewal or rebind request is for a
different lease or client.

So, for rigor, I would like to assert that "early termination" applies
specifically to the case where a client and server had negotiated a lease,
and in the renewal or rebinding attempt the client has *not* modified the
"terms" of the lease (i.e., hardware address, IP address, or client
identifier).

Rob Stevens' point about the utility of a server renewing a lease when the
server has no intention of extending the lease beyond its originally
negotiated duration is, I believe, a completely valid observation.  Since
the client is permitted to continue using the lease for the entire duration
of the lease period (and then to relinquish it), why should a server blindly
ACK in this case?

Rob's third point about NAK'ing leases once the original duration has
expired is also, I believe, the correct behavior.  Why not just ignore the
renewal or rebind request and expect that the client will "do the right
thing" and relinquish it?

If I interpret Mike Carney's and Ted Lemon's positions correctly, they both
favor a more liberal use of NAK in order to enforce "polite" behavior on the
client.  True, failing to relinquish a leased address is pretty rude, but I
would want the language in the RFC to be very explicit about the specific
circumstances when a server could (should?  must?) NAK the request.  Paul
Fox's suggested wording is pretty close to what I imagine the final
resolution may be.

I think, after reading all of the flurry of notes on the subject, that we
still haven't settled on (what I believe are) the two principal cases:

1.	for some administration or operational purpose, the server's ability
to instruct clients to relinquish their leases (regardless of time
remaining) might be a valuable feature;  and,
2.	the server (possibly) needs some way to gain control over a rogue
client.

The first of these almost certainly would require a change to the protocol,
the second might, or it could be a local configuration or implementation
matter.

--Barr

---

From: [email-masked] (by way of Ralph Droms)
Date: Fri, 18 Dec 1998 16:19:01 -0500 (EST)

message sent to [email-masked] by [email-masked] follows.
-----------------------------------------------------------------------
>times

			Carl

---

From: [email-masked] (by way of Ralph Droms)
Date: Fri, 18 Dec 1998 16:19:33 -0500 (EST)

message sent to [email-masked] by [email-masked] follows.
------------------------------------------------------------------------

>    then.....get a new system admin.

I think that servers should NAK freely if they know the client should
reconfigure itself, because the sooner it does so, presumably the
sooner it can function correctly.   That is to say, if the information
the client has will not allow it to operate correctly, it should get
new information ASAP.   This will not interrupt network connections
because presumably network connections aren't working.   Whether or
not the server should NAK in this situation should probably just be
tunable, because the sysadmin is probably going to be most qualified
to judge whether NAKing is appropriate.   I tend to agree that
continuously ACKing is the wrong thing to do.

Unfortunately, as Mike says, the server is going to have to continue
to reserve the lease after NAKing until it has some evidence that the
client has stopped using it, or until it has expired.

			       _MelloN_

---

From: [email-masked] (by way of Ralph Droms)
Date: Fri, 18 Dec 1998 16:21:28 -0500 (EST)

> Clients commonly ask for a permanent lease, knowing the server will
> set them straight.  What's wrong with asking for the world? ;^)

Nothing.   But what's wrong with giving the client correct information
as soon as it is possible to do so?

> to extend leases. 2.5 days into the lease, the client tries to renew.

I don't think this is the situation we're talking about.   I don't
think the server should NAK in this situation - it's granted a five
day lease, so either it should extend it or keep mum.   I don't
actually know how you configure a server to "not extend leases", so I
don't see how this particular scenario would come up.

> >    in response to a NAK of a renewal.

I am not speaking for Microsoft here, but my experience in dealing
with ISC DHCP users is that the Microsoft clients do immediately go
into INIT state when they receive a NAK, regardless of what state they
were in when they sent the DHCPREQUEST.   The ISC clients also do
this.   This is, in fact, what the RFC says the client should do -
the only ambiguous language is in the description of what the server
should do.

			       _MelloN_

---

From: [email-masked] (by way of Ralph Droms)
Date: Fri, 18 Dec 1998 16:21:50 -0500 (EST)

> the entity sending the DISCOVER is actually the one which held the

The client identifier or MAC address is guaranteed to be unique.   If
you use it to refer to two different entities, you lose.

> interface because you need multiple addresses for some reason or

In that case, you must use more than one client identifier.

> require the client to send a RELEASE after a RENEW/REBIND-state

This isn't necessary - the RFC already says what the client must do
when it receives a NAK.

			       _MelloN_

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 18 Dec 1998 17:23:49 -0500 (EST)

At 03:33 PM 12/18/98 -0500, Hibbs, R BARR (PB-rbhibbs) wrote:
.
.
.

>The first of these almost certainly would require a change to the protocol,

	If we wished a server to force a client to relinquish its lease 
	at an arbitrary time, that would require a change to the protocol.  	
	I have *certainly* not advocated that, and I don't know of anyone 
	who has as part of this email thread.

	I'm advocating making the words in RFC 2131 (which I claim are less
	than completely clear) match the state transition diagram on page
	35 of RFC 2131 (which I claim is completely clear).  That diagram
	indicates that if a server sends a client a DHCPNAK while the
	client is in RENEWING or REBINDING state, that it must stop
	network operations and go immediately into INIT state.

	I'm also advocating adding words to RFC 2131 that indicate the
	situations in which a server can, having sent a DHCPNAK, reuse
	the lease (which are two -- either it expires or the same client
	subsequently sends in a DHCPDISCOVER).

	Cheers - Kim

---

From: Nathan Lane <[email-masked]>
Date: Fri, 18 Dec 1998 18:20:54 -0500 (EST)

> -----Original Message-----
> From:	Paul Fox [SMTP:[email-masked]]
> Sent:	Friday, December 18, 1998 9:37 AM
> To:	Multiple recipients of list
> Subject:	Re: NAK on RENEW or REBINDING 
> 
	[Nathan Lane]  Agreed...but the administrator will still have to see
"unforeseen" circumstances at 1/2 the lease time...so what does this really
buy us?  If we really want to make this work, the best thing is something
that is not defined in the protocol: a server side "go tell the client his
lease is no good".  Plus significant work on the client side.

>        the client's IP address just because it sent a DHCPNAK to the
	[Nathan Lane]  The use of the phrase "stop using the lease
immediately" is really a misnomer and implies that the server has more
control than it really does. The client only checks at the end of each
renewal interval so "immediately" is a relative term.  The last sentence we
should define to be "The server cannot assume that the client entered the
INIT state until it receives a DHCPDISCOVER message, and so MUST NOT reuse
the client's IP address until the original lease would have expired."
Albeit this language makes IP reclamation difficult, but eliminates the
necessity for the "grace period" concept that is implemented in some places
already, but is not elsewhere defined.  Let's not make more holes than we
are trying to seal up!

	In conjunction with Diana Lane and Wahid Zaman of our team here at
Wal-Mart.

	-Nathan Lane
	Wal-Mart Stores, Inc.
	(501) 277-5786

---

From: [email-masked] (by way of Ralph Droms)
Date: Sat, 19 Dec 1998 08:28:22 -0500 (EST)

> Agreed...but the administrator will still have to see "unforeseen"
> circumstances at 1/2 the lease time...so what does this really buy
> us?

What it buys us is that if an administrator anticipates that there
might be a turnover in the near future for some reason (which could be
renumbering, client registration, or whatever) he or she can choose to
issue short leases, such that the renewal time will happen frequently
enough to make NAKing at renewal useful, for whatever value of useful
holds true in that particular situation.

			       _MelloN_

---

From: [email-masked] (by way of Ralph Droms)
Date: Mon, 21 Dec 1998 07:53:46 -0500 (EST)

> You're assuming the client's clock is valid.

Yup.   If it's not, I don't think there's much we can do about it.

> I'm speaking about the case where the clock in the client gets out
> of sync for some reason (laptop was suspended, lithium battery on
> board is dead) such that the client loses time. It thinks it still
> has plenty of time, however, the lease has expired from the servers
> point of view. The client tries to renew.  Don't you think the
> server should NAK the client in this case?  For the reason you
> mentioned above about a client getting the latest information?

Well, to illustrate the basis for my thinking, allow me to say that
when my server encounter a late DHCPREQUEST, and the address is
available for the client's use, it sends a DHCPACK, not a DHCPNAK.
When the address is not available, or is incorrect, *then* it sends a
DHCPNAK.   I will not argue that this is the only correct behaviour,
but I think it's as reasonable as NAKing, and is likely to result in
fewer client-side hiccups.

An ACK, btw, will do as good a job of syncing clocks after a late
DHCPREQUEST as an OFFER after a DHCPDISCOVER - the lease time starts
from the arrival of the DHCPACK, not any previous time, so it's going
to be as accurate as the client's clock is for the subsequent duration
of the lease.

			       _MelloN_

---

From: "Hibbs, R BARR (PB-rbhibbs)" <[email-masked]>
Date: Tue, 22 Dec 1998 12:57:41 -0500 (EST)

From:  Kim Kinnear [SMTP:[email-masked]]
Sent:  Friday, December 18, 1998 1:27 PM
To:  [email-masked]
Cc:  Multiple recipients of list; [email-masked]
Subject:  RE: NAK on RENEW or REBINDING 

I completely agree with Kim's stated goal of clarifying the wording of the
RFC so that the text matches the state diagram....

--Barr