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

From: 차현욱 <[email-masked]>
Date: Mon, 30 Apr 2007 02:10:46 +0000 (GMT)

Dear, Bernie.

Thank you for your comment.
You mean that clinet do not have to include all addresses mapped to IA_NA in RENEW to extend lifetime of IA_NA binding in server. 

According to RFC3315 18.1.3. Creation and Transmission of Renew Messages, 

  "At time T1 for an IA, the client initiates a Renew/Reply message
   exchange to extend the lifetimes on any addresses in the IA.  The
   client includes an IA option with all addresses currently assigned to
   the IA in its Renew message. "

I can not agree with you. 

If client determines to use only one of addresses provided by server or knows that any address is not on-link from RA, it will not send RENEW message including all addresses associated to IA_NA in server. For this case, server should not refresh all addresses in the IA but just addreses in RENEW.

I have only little knowledge about DHCPv6. If I am wrong, please correct me. 

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 : Bernie Volz (volz)<[email-masked]> 
Date   : 2007-04-30 09:58
Title  : RE: [dhcwg] A question about processing a RENEW message from a
 clientin DHCPv6.

How about the server includes the address as if it was in the Renew?

If a client sends just a Renew with anIA option but without any IAADDR options, why wouldn't you just renew all addresses for the binding (IA_* and IAID) and include them in the Reply? (Of course, addresses that can't be renewed would be sent with whatever remaining lifetimes they have.)

- Bernie 

-----Original Message-----
From: 차현욱 [mailto:[email-masked]] 
Sent: Sunday, April 29, 2007 8:46 PM
To: [email-masked]
Subject: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6.

Dear, all.

I am now developing DHCPv6 client and server in our product.
I have a question reading source code of a open source package "Wide DHCPv6".
In this software, it does update update_time of binding assigned to client without checking if all assinged stateful addresses for same IA are included in RENEW message from client. 
If server assigned two addresses to IA requested by client and client send RENEW message for only one address, what is correct behavior of server?
Right before, I checked DHCPv6 conformance testsuit document by the TAHI. But I do not find exact answer. 

In my opinion, several choices are possible. 
- Server rejects RENEW message.
- Server releases lease for omitted address in RENEW message and refreshes update_time of binding including only the address in RENEW message from client. Server may include IA_NA address option for the released address with lifetimes set to zero.
- Server keeps lease for omitted address in RENEW message during its valid life time and refreshes update_time of binding including only the address in RENEW message from client.

Any advicees and comments are welcomed.

Thank you in advance. 

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

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sun, 29 Apr 2007 22:26:18 -0400

Obviously the server sent these addresses to the client previously in a Reply. Otherwise, why it would it have them?

And, the server still has the leases (ie, we assume the valid lifetime has not expired). And if there are no server policies that conflict with them being used and renewed, what's wrong with the server renewing them and sending them to the client?

The worst is that the client will ignore them like it did previously. Or, if the client have previously RELEASED or DECLINED them, it should do so now and perhaps those messages will get to the server (the client is not required to keep retrying RELEASE and DECLINE messages so it could be that the previous attempt failed to reach the server); which is a plus as then the server knows that the client doesn't want to use those leases or can't use them because of conflicts.

Note also that the RFC 3315 langague you quoted does not include a MUST. And, also note the language in 18.1.8. Receipt of Reply Messages which clearly indicates that a server may return additional addresses for a Request, Renew, or Rebind.

- Bernie

-----Original Message-----
From: 차현욱 [mailto:[email-masked]] 
Sent: Sunday, April 29, 2007 10:11 PM
To: Bernie Volz (volz); [email-masked]
Subject: Fwd: RE: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6.

Dear, Bernie.

Regards,

Joseph HyunWook Cha

Software Engineer 

------- Original Message -------

- Bernie 

-----Original Message-----
From: 차현욱 [mailto:[email-masked]] 
Sent: Sunday, April 29, 2007 8:46 PM
To: [email-masked]
Subject: [dhcwg] A question about processing a RENEW message from a clientin DHCPv6.

Dear, all.

Thank you in advance. 

Joseph HyunWook Cha

Software Engineer

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 30 Apr 2007 08:54:53 -0700

On Sun, Apr 29, 2007 at 10:26:18PM -0400, Bernie Volz (volz) wrote:
> The worst is that the client will ignore them like it did previously.

If we get into a situation where the DHCP server is sending addresses
the client is ignoring, then DDNS updates get a lot less reliable.

> Note also that the RFC 3315 langague you quoted does not include a MUST. And, also note the language in 18.1.8. Receipt of Reply Messages which clearly indicates that a server may return additional…

I don't like this answer.  If a client releases an address it
"doesn't want" for whatever reason, then the server will offer
more addresses in the next exchange which it probably "doesn't
want" either.

This quickly looks like an infinite loop.

The real answer I think is that a client has no choice in the matter,
and "MUST" bind and keep all addresses the server gives.

So if you want a client to move off an address, that decision can only
be made at the server.

> From: ������ [mailto:[email-masked]] 
> If client determines to use only one of addresses provided by server or knows that any address is not on-link from RA,

I think it would be a mistake not to use an address that is given
by the server and is not covered by a prefix announcement in any RA.

It's been stipulated that there may exist networks in which there are
no routers, at least no route advertisements, and where link-local
addresses may be insufficient.

If the DHCP server is renewing invalid addresses, then that is a
misconfiguration.

-- 
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: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 30 Apr 2007 23:19:20 -0400

David:

I think we end up being in agreement?

I certainly am not recommending clients ignore addresses or don't follow
the rules in sending all of them when renewing. The question that was
asked though is what should a server do if that does happen. My answer
is that the server should "pretend" that the client sent them all.

>This quickly looks like an infinite loop.

Huh? Only when the client would RENEW or REBIND would it get more.

- Bernie 

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Monday, April 30, 2007 11:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: RE: [dhcwg] A question about processing a RENEW message
from aclientin DHCPv6.

On Sun, Apr 29, 2007 at 10:26:18PM -0400, Bernie Volz (volz) wrote:
> And, the server still has the leases (ie, we assume the valid lifetime
has not expired). And if there are no server policies that conflict with
them being used and renewed, what's wrong with the server renewing them
and sending them to the client?

> Note also that the RFC 3315 langague you quoted does not include a
MUST. And, also note the language in 18.1.8. Receipt of Reply Messages
which clearly indicates that a server may return additional addresses
for a Request, Renew, or Rebind.

> From:        [mailto:[email-masked]] 
> If client determines to use only one of addresses provided by server
or knows that any address is not on-link from RA,