Subject: [dhcwg] RFC3315 question about Receipt of Reply message

From: Yoshio Uomori <[email-masked]>
Date: Wed, 11 Nov 2009 20:11:47 +0900

Hi all,

Now, I confuse the following description.

   2568 18.1.8. Receipt of Reply Messages
   2662    When the client receives a Reply message in response to a Renew or
   2663    Rebind message, the client examines each IA independently.  For each
   2664    IA in the original Renew or Rebind message, the client:
   2665 
   2666    -  sends a Request message if the IA contained a Status Code option
   2667       with the NoBinding status (and does not send any additional
   2668       Renew/Rebind messages)
   2669 
   2670    -  sends a Renew/Rebind if the IA is not in the Reply message

If the client receives a Reply message without IA in response to a Renew,
the client transmit a Renew message(not Rebind message).
Is it a correct?

In my interpretation,
If the client receives a Reply message in response to a Renew,
the client do not send a Rebind.

   2363 18.1.4. Creation and Transmission of Rebind Messages
   2364 
   2365    At time T2 for an IA (which will only be reached if the server to
   2366    which the Renew message was sent at time T1 has not responded), the
   2367    client initiates a Rebind/Reply message exchange with any available
   2368    server.  The client includes an IA option with all addresses
   2369    currently assigned to the IA in its Rebind message.

If my interpretation is wrong, please correct me.

Best Regards,
Yoshio Uomori

-- 
Yoshio Uomori <[email-masked]>

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 11 Nov 2009 15:44:03 -0800

> the client transmit a Renew message(not Rebind message).

Yes.

The stipulation is that the server is unable to fit subsequent IA's
in the Reply beyond the previously included IA's, so the client
"resumes where the server left off."

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

---

From: Yoshio Uomori <[email-masked]>
Date: Thu, 12 Nov 2009 09:57:13 +0900

Hi David,

Thanks for your comment.

I want to confirm more.

It is about Reply message.
The client interpret the Reply without IA as a valid message?
If it is true, the client does not send a retransmitted Renew message.
The reason is that the client receives a message in response to Renew and the Renew/Reply message exchange is terminated.

Is it correct?

Best Regards,
Yoshio Uomori

On Wed, 11 Nov 2009 15:44:03 -0800

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 11 Nov 2009 21:12:50 -0800

> The client interpret the Reply without IA as a valid message?

I think the perfect behaviour is:

A Reply without -any- IA's at all: it is an error and should be
discarded - the client sends a new Renew message on its next RT timer
expiration as if it never received the packet.  The transaction is not
stopped.

A Reply with some IA's, but not all: the client starts a new Renew
transaction for any missing IA's, with newly initialized RT timer.  It
sends a first Renew in this new transaction immediately.

This is a little more cautious than RFC 3315 requires / describes in
client implementations (it only describes the second case), but it
should be safe because servers are directed that they MUST include the
client's IA's - with assigned resources or a Status Code option.

I think the situation where a Reply message has no IA's is not
discussed in detail in the RFC because it is a degenerate condition -
the server is broken.

Mainly the point is to make sure that timers on IA's are interpreted
individually; extending the Renew time on IA 1 with a successful reply
does not extend the Renew time on IA 2.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 11 Nov 2009 22:08:33 -0800

On Thu, Nov 12, 2009 at 02:24:44PM +0900, Ted Lemon wrote:
> On Nov 12, 2009, at 2:12 PM, David W. Hankins wrote:
> Can't a reply without any IAs happen in order for the server to communicate a status message?

Yes, I think of Status Code processing as separate, and earlier step,
but should have made some mention of it, so let me rectify that now.

If the packet has a Status Code that directs some other behaviour,
that takes precedence.

We're talking about Renew, so this Reply may get UnspecFail or
UseMulticast for example without including any of the client's IA's.

I think for UnspecFail the direction basically boils down to the same
thing as above; continue to retransmit.  UnspecFail seems sort of
informational.

For UseMulticast, you would ignore any of these other issues and
resend the message using multicast.  I believe immediately/resetting
retransmit timers.