Subject: Re: Re: Re: RE: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6.

From: HYUN WOOK CHA <[email-masked]>
Date: Wed, 02 May 2007 00:49:21 +0000 (GMT)

Dear David, 

Thank you for your comments.

I agree with you. 
So, I want to correct my suggestion like this.
Server keeps leases for addreses which are not included in RENEW messages instead of releasing and refreshing, and send REPLY with refreshed addresses and additional addresses whose delivery has not been confirmed. 
I think that Delivery of REPLY to RENEW can be confirmed using RENEW retransmission timeout. 
If a first RENEW is arrived, REPLY confirm timeout is set to RENEW retransmission timeout and send REPLY to the client. REPLY includes refreshed addresses and new assinged addresses, which are marked as DELIVERING. If another RENEW is received within REPLY confirm timeout, the server sends REPLY including refreshed addresses and additional addresses which are newly assigned or in the DELIVERING stage. 
If REPLY message is not within REPLY confirm timeout, the server sends REPLY including refreshed addresses and additional addresses if any. At this time, REPLY does not include any addresses which were in DELIVERING state and not refreshed because delivery of these addresses was already confirmed.
I think that issues you mentioned can be avoided with above suggestion. 

Regards, 

Joseph HyunWook Cha

"For you, O God, tested us; you refined us like silver."

Software Engineer 
Development Part 1. I/Infra  
Network System Division 
Tel 031-279-3804  Mobile 010-3024-3804

------- Original Message -------
Sender : David W. Hankins<[email-masked]> 
Date   : 2007-05-02 04:23
Title  : Re: Re: RE: [dhcwg] A question about processing a RENEW message from a
 clientin DHCPv6.

On Tue, May 01, 2007 at 01:29:58AM +0000, HYUN WOOK CHA wrote:
> According to your opinion, if a client MUST renew all addresses
> which are not released or declined, Must server check that RENEW
> message from client include all addresses associated with the
> IA and discard the RENEW message with missing address option?

It's hard to say that it should.

RFC3315 allows servers to add addresses to the IA as conditions
change, so new addresses show up in Renew-Replies.

So if a new prefix is added to the subnet, and the sysadmin wants
systems to migrate to the new prefix (the old one will be revoked
in the future), an earlier Renew will have given the client this
new address.

But - we cannot tell for certain that the client received the
Reply.  It might have been dropped, and the client is
retransmitting (or in Rebind's case, it might have gotten a Reply
from another server that kept it alive).

So the next Renew might very well not reflect this new address,
and if you treated that like an error you'd lose contact with
the client.

So at very minimum, I think a server has to give out the client's
addresses until it can confirm the client has received its Reply - for
example by receiving a Renew from the client which contains the new
binding.

But considering the amount of time inbetween these events, and that
it's problematic to "remember" what you've seen from a client in
this regard reliably (getting fuzzier every time you consider
out-of-order delivery), this is probably more complex than just
always giving the client the addresses it is assigned, wether they
appear in the Renew or not.

So, I think servers should be encouraged to always provide the
full contextual results, and not treat missing information as
an error.

> When server receives a RENEW message which does not include
> all addresses assigned to the client by it, it considers that the
> client uses only addresses included in the RENEW message, and
> refuses(or ignore) or releases other addresses. Then, server releases
> those address from IA binding immeidately or keep during only their
> lifetimes without refreshing. And REPLY message that server sends
> includes only refreshed addresses and additional new addresses if
> any. 

No, I don't think that's correct.

I do think the DHCPv6 server should do whatever the operator's policy
is.  So if the policy stipulates multiple addresses ("one address
per subnet"), or even specific multiple addresses, it would always
give them out despite the client's input.

Removing bindings in anything other than a Release or Decline is
always tricky business one should think carefully about.  Not
just removing.  Reducing times on bindings is just as perilous
(but a very handy knob for any sysadmin).

Out-of-order problems are one obvious source of angst.  If the
client transmits two Renew packets before receiving a Reply,
the server sent a Reply with a new address, and then received the
second Renew packet - should it remove that binding?  Chances are
good that the client will decide to adopt the first Reply, or at
least will be given a hard decision to make if it records both
Replies from the same server.  So chances are good that the server
and the client's cache are out of synch.

We also get into tricky situations around multiple end-host
operating systems that all have the same DUID/IAID selections.
If host operating system A gets 2 addresses, and shuts down
ungracefully, now booting host operating system B which confirms
its old addresses (which OS A may have extended), then Renews or
Rebinds them according to their timers - then if you remove the
bindings OS A has recorded but OS B did not echo, the server and
OS A's cache are out of sync.

It's tricky business.  It's probably a bad idea.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

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

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 2 May 2007 13:44:01 -0700

> Thank you for your comments.

And thank you for the discussion.

> I think that issues you mentioned can be avoided with above suggestion. 

Hm.  I think I get what you're after (I think there are some typos
here).

How do you know what the next retransmission will be (the previous n
Renews may have been dropped)?  The 'elapsed time' option, you're
thinking?  I wonder about that.  In DHCPv4, the 'secs' field analogue
was wildly inaccurate and inconsistently implemented.  I'm not sure
how this will go.

What if the next retransmitted Renew is lost on its way to the
server?

The retransmit times are very well defined in RFC3315, to
its credit, so we hope to be able to expect good behaviour from
most clients.  But in at least one place to my memory, it
suggests that the reference values might be adjusted through
user configuration...so what if some implementor or user has
determined to use different values than we expect?

What if the client's system clock has a time-warp?

I think that you could do this without the timeout in the
logic - just requiring that the client produce a packet with
the address included at least once, showing that it received
the information.  You might even set t1 lower for one cycle
to get that information quicker.  But I would still discourage
this as it's still fairly complex, and we're likely missing
something.

I don't think the case where a server is going to miss a
Renew or Decline message is that frequent, and where it is,
I don't think the penalty (which is a binding lasting longer
than the client wishes) is great enough to justify complex
ways to detect it.

I appreciate that you're trying to create a conservative server
implementation (one that cleans up well)...but I think you're
trying too hard. :)