Subject: [Dhcpv6bis] Client behavior in Reconfigure case

From: Marcin Siodelski <[email-masked]>
Date: Wed, 16 Mar 2016 22:19:03 +0100

Hi,

I am working on the ticket #142 and I am almost there but I just got
slightly confused with a client behavior in case of a Reconfigure.

Suppose the server sends a Reconfigure message that indicates to the
client that it should send Renew. Since the server is communicating with
the client, the Renew should succeed in a typical case. But if it
doesn't, for any reason, the client retransmits according to the
parameters provided in relevant section for a Renew.

What is not really clear to me from the current text is what happens
when the Renew is not responded?

There is this section, which clarifies a bit:

"19.1.3.  Time Out and Retransmission of Renew, Rebind or Information-
         request Messages

   The client uses the same variables and retransmission algorithm as it
   does with Renew, Rebind, or Information-request messages generated as
   part of a client-initiated configuration exchange.  See
   Section 18.1.4, Section 18.1.5, and Section 18.1.6 for details.  If
   the client does not receive a response from the server by the end of
   the retransmission process, the client ignores and discards the
   Reconfigure message."

but what does it actually mean that "that the client does not receive a
response from the server by the end of the retransmission process":

- MRD elapsed for Renew?
- MRD elapsed but the client tried Rebind but all leases eventually
expired and Rebind failed too?
- something else?

(I'd guess the first option is correct)

And, what does it mean that the Reconfigure is discarded? Assuming that
Reconfigure is discarded after client has made a number of unsuccessful
attempts to Renew and the MRD elapsed. "Discarded" means the client
doesn't do Rebind?

I think all this is underspecified in the current text and it might
warrant additional ticket (if we don't have one already).

Thanks for your input in advance,

Marcin

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Mar 2016 21:30:34 +0000

I think the right interpretation is "MRD elapsed for renew."   If the server wants the client to rebind, it should send reconfigure-rebind.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 16 Mar 2016 22:02:38 +0000

Interesting question.

I guess since Reconfigure was originally designed with just Renew, I would guess Ted's answer (- MRD elapsed for Renew?) and that the client JUST does a Renew. Though of course the MRD here would put the client into the T2 (rebind) time, so it would naturally start sending a Rebind ANYWAY. Thus, I think that was the reason why "Reconfigure for a Renew" stops when T2 is hit - as Rebind would start.

While perhaps it doesn't matter depending on what you've re-worked, but let me also point out we forgot to add Rebind in the text in 20.4.1.  Receipt of Reconfigure Messages:

   DISCUSSION:

      The Reconfigure message acts as a trigger that signals the client
      to complete a successful message exchange.  Once the client has
      received a Reconfigure, the client proceeds with the message
      exchange (retransmitting the Renew or Information-request message
      if necessary); the client ignores any additional Reconfigure
      messages until the exchange is complete.  Subsequent Reconfigure
      messages cause the client to initiate a new exchange.

"retransmitting the Renew[, Rebind,] or Information-request"

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Marcin Siodelski
Sent: Wednesday, March 16, 2016 5:19 PM
To: [email-masked]
Subject: [Dhcpv6bis] Client behavior in Reconfigure case

Hi,

I am working on the ticket #142 and I am almost there but I just got slightly confused with a client behavior in case of a Reconfigure.

Suppose the server sends a Reconfigure message that indicates to the client that it should send Renew. Since the server is communicating with the client, the Renew should succeed in a typical case. But if it doesn't, for any reason, the client retransmits according to the parameters provided in relevant section for a Renew.

What is not really clear to me from the current text is what happens when the Renew is not responded?

but what does it actually mean that "that the client does not receive a response from the server by the end of the retransmission process":

- MRD elapsed for Renew?
- MRD elapsed but the client tried Rebind but all leases eventually expired and Rebind failed too?
- something else?

And, what does it mean that the Reconfigure is discarded? Assuming that Reconfigure is discarded after client has made a number of unsuccessful attempts to Renew and the MRD elapsed. "Discarded" means the client doesn't do Rebind?

I think all this is underspecified in the current text and it might warrant additional ticket (if we don't have one already).

Marcin

_______________________________________________
Dhcpv6bis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcpv6bis

---

From: Marcin Siodelski <[email-masked]>
Date: Thu, 17 Mar 2016 09:21:02 +0100

> I guess since Reconfigure was originally designed with just Renew, I would guess Ted's answer (- MRD elapsed for Renew?) and that the client JUST does a Renew. Though of course the MRD here would p…

ok, so this is my proposed text extending the "Renew creation" section:

<t>The message exchange is terminated when time T2 is reached. If
   the client is responding to a Reconfigure, the client ignores
   and discards the Reconfigure message. In this case, the client
   continues to operate as if Reconfigure message was not received,
   i.e. it uses T1/T2 times associated with the client's leases to
   determine when it should send Renew or Rebind to the server.
   If the terminated Renew exchange was not initiated as a result
   of receiving a Reconfigure message, the client begins a Rebind
   message exchange (see <xref target='RFC3315-18.1.4'/>) when
   the time T2 is reached.</t>

and the following text for the "Rebind":

<t>The message exchange is terminated when the valid lifetimes of all
   leases across all IAs have expired, at which time the client uses
   the Solicit message to locate a new DHCP server and sends a Request
   for the expired IAs to the new server. If the terminated Rebind
   exchange was initiated as a result of receiving a Reconfigure
   message, the client ignores and discards the Reconfigure message.</t>

I also think there is nothing we can add to the Information-request text
because for the Information-request both MRC and MRD are 0, in which
case the retransmissions are carried forever.

Note that, I need to extend the relevant sections, because at the same I
have to remove the following text:

<t>The client uses the same variables and retransmission algorithm
as it does with Renew, Rebind, or Information-request messages generated as
part of a client-initiated configuration exchange. See
<xref target='RFC3315-18.1.3'/>, <xref target='RFC3315-18.1.4'/>, and
<xref target='RFC3315-18.1.5'/>
for details. If the client does not receive a
response from the server by the end of the retransmission process,
the client ignores and discards the Reconfigure message.</t>

> "retransmitting the Renew[, Rebind,] or Information-request"

Yeah, I noticed it and it was weird. I can add it as part of the work I
am doing.