Subject: Re: Re: [dhcwg] A question on receipt of Reply Messages in a client.

From: HYUN WOOK CHA <[email-masked]>
Date: Sun, 20 May 2007 23:37:26 +0000 (GMT)

Hello, David.

Thank you for your kind reply. 
I am sorry that I omitted important words in the question. I want to correct my question as follows. 
Is it allowed for a server to repond with a IA option with Status Code option (NoBinding) to a REBIND message?
Since REBIND message has no server id option, any other server than the server which assigned address to client can reply with "NoBinding" status code option. This can make client send REQUEST message even if client receives positive REPLY from the expected server r right after.    
IMO, REBIND message should not be replied with "NoBinding" status option.  
If I have missing points, please let me know.

Thank you in advance.

Regards, 

Joseph HyunWook Cha

The truth will set you free !!!

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-19 00:56
Title  : Re: [dhcwg] A question on receipt of Reply Messages in a client.

On Fri, May 18, 2007 at 07:22:46AM +0000, 차현욱 wrote:
> I wonder if a server can repond with a IA option with Status Code option (NoBinding).
> If this is not allowed, the above sentence should be changed. 

Section 18.2.3;

   If the server cannot find a client entry for the IA the server
   returns the IA containing no addresses with a Status Code option set
   to NoBinding in the Reply message.

So, this is an IA_XX containing a Status Code option whose status
is NoBinding.  This is allowed, and might happen for example if
the DHCP server "loses its brains", or is forklift-upgraded.

I really don't like this part of RFC3315 - client behaviour regarding
status codes.  It's really twisty, many behaviours relating to
receiving status codes are optional, and in general client behaviour
is very tersely defined.

Best of luck working through this part of your implementation.  It
nearly drove me mad.

-- 
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, 28 May 2007 23:16:47 -0400

The client has had from the T1 to the T2 time to communicate with the original server which obviously must be "down". And, thus at T2, the client starts REBINDing. If other servers are available and receive the REBIND, they may have no knowledge of the binding ...

So, there are two potential choices we had:
1. Have servers that don't know about the binding drop the REBIND request (without responding).
2. Have servers that don't know about the binding send the IA option with the NoBinding Status Code option.

If we had specified (1), the client would wait until the lease expired before it would restart its DHCP protocol.

We specified (2), because all that says is start with Solicit, etc, but the client can CONTINUE to use the addresses (prefixes) it still has because they have not yet expired (ie, there is still some valid lifetime).

When the client does the Solicit/Advertise/Request/Reply, it may get new addresses but it can transition to them properly.

So, choice 2 (what we specified in 3315) is far better.

Perhaps 3315 could have had some language that a client may wait a short period for responses and take the "best" Reply to a REBIND (ie, perhaps one that does not have any status code options?). But, it seems that this would have little practical benefit for the added complexity.

- Bernie

-----Original Message-----
From: HYUN WOOK CHA [mailto:[email-masked]] 
Sent: Sunday, May 20, 2007 7:37 PM
To: David W. Hankins
Cc: [email-masked]
Subject: Re: Re: [dhcwg] A question on receipt of Reply Messages in a client.

Hello, David.

Thank you in advance.

Regards, 

Joseph HyunWook Cha

Software Engineer 

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

Section 18.2.3;