Subject: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer values in IA_NA option

From: "M A, Aleem Chisti" <[email-masked]>
Date: Tue, 17 May 2011 10:07:57 +0000

Hi,

Sec 22.4 of RFC 3315 describes the following on T1, T2 timer values:

  "If a client receives an IA_NA with T1 greater than T2, and both T1

   and T2 are greater than 0, the client discards the IA_NA option and

   processes the remainder of the message as though the server had not

   included the invalid IA_NA option."

However, this RFC doesn't mention about, what should be the client behavior when T1 is equal to T2.

How should the client deal in such a scenario ?

Thanks

Aleem

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 May 2011 09:15:10 -0400

On May 17, 2011, at 6:07 AM, M A, Aleem Chisti wrote:
> However, this RFC doesn’t mention about, what should be the client behavior when T1 is equal to T2.

As far as I can see, it's not a problem for T1 to be equal to T2.   Are you aware of a concern?

---

From: "M A, Aleem Chisti" <[email-masked]>
Date: Thu, 19 May 2011 06:43:30 +0000

If T1 is equal to T2 and upon the timer expiry, what message should the client send; RENEW or REBIND ?

1. What if it sends a RENEW message and if the server which initially sent a REPLY is no longer present in the network ? How do decide on the number of retransmissions of RENEW before sending a REBIND ?

2. Upon timer expiry, if it sends a REBIND message, what if the server which initially sent a REPLY is still present in the network ?

From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, May 18, 2011 6:45 PM
To: M A, Aleem Chisti
Cc: [email-masked]
Subject: Re: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer values in IA_NA option

---

From: Andre Kostur <[email-masked]>
Date: Thu, 19 May 2011 08:38:15 -0700

I'd say that the device would be expected to transition into the Rebinding
state.  So #1 isn't an issue, the device immediately starts REBINDing.  For
#2, if the issuing server is still present, it will REPLY, and the client is
happy.

On Wed, May 18, 2011 at 23:43, M A, Aleem Chisti <[email-masked]>wrote:

> 1. What if it sends a RENEW message and if the server which initially sent
> a REPLY is no longer present in the network ? How do decide on the number of
> retransmissions of RENEW before sending a REBIND ?
>
>
>
> 2. Upon timer expiry, if it sends a REBIND message, what if the server
> which initially sent a REPLY is still present in the network ?
>
>
>
>
>
> *From:* Ted Lemon [mailto:[email-masked]]
> *Sent:* Wednesday, May 18, 2011 6:45 PM
> *To:* M A, Aleem Chisti
> *Cc:* [email-masked]
> *Subject:* Re: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer
> values in IA_NA option
>
>
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>

-- 
Andre Kostur
Senior Software Design Engineer
P: 604-678-2864  SIP: [email-masked]
<http://www.incognito.com/uc>

---

From: "Sampath, Rangaprasad (HP Networking)" <[email-masked]>
Date: Fri, 20 May 2011 16:47:16 +0000

Could we also treat T1==T2 as an invalid case and follow the behavior outlined for the T1>T2 case? That would mean that for T1>=T2, the client would discard the IA_NA option and process the remainder of the message as though the server had not included the IA_NA option.

Regards,
Ranga..

From: [email-masked] [mailto:[email-masked]] On Behalf Of M A, Aleem Chisti
Sent: Wednesday, May 18, 2011 11:44 PM
To: Ted Lemon
Cc: [email-masked]
Subject: Re: [dhcwg] DHCPv6 RFC 3315 Clarification - T1 and T2 timer values in IA_NA option

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 May 2011 19:32:50 -0400

> Could we also treat T1==T2 as an invalid case and follow the behavior outlined for the T1>T2 case? That would mean that for T1>=T2, the client would discard the IA_NA option and process the remaind…

I think this is a bad idea.   Someone reading the spec could easily conclude that something meaningful would happen if T1==T2.   It makes sense to rebind at T1/T2 in that case.   Your proposal is very clearly out of spec; it's possible that some implementor might decide to violate the spec in the way you propose also, but it's more likely implementors will go straight to REBIND in this case.   If you violate that spec, your client is probably going to be the only one that fails to acquire an IP address.   Generally speaking, this is a result you're better off avoiding.

---

From: Stephen Jacob <[email-masked]>
Date: Fri, 20 May 2011 18:16:41 -0700

On Fri, May 20, 2011 at 07:32:50PM -0400, Ted Lemon wrote:
> > Could we also treat T1==T2 as an invalid case and follow the
> > behavior outlined for the T1>T2 case? That would mean that for
> > T1>=T2, the client would discard the IA_NA option and process the
> > remainder of the message as though the server had not included the
> > IA_NA option.
> 
> I think this is a bad idea.   Someone reading the spec could easily
> conclude that something meaningful would happen if T1==T2.   It makes
> sense to rebind at T1/T2 in that case.   Your proposal is very clearly
> out of spec; it's possible that some implementor might decide to
> violate the spec in the way you propose also, but it's more likely
> implementors will go straight to REBIND in this case.   If you violate
> that spec, your client is probably going to be the only one that fails
> to acquire an IP address.   Generally speaking, this is a result
> you're better off avoiding.

I agree with Ted.

I think the obvious result of T1==T2 should be that you go stright
to Rebinding.

Whether that is via going to Renewing and immediately on to
Rebinding or directly is an implementation detail but I fail to see
how any other course of action follows the rules or intention of the
specification for either DHCPv4 or DHCPv6.

Regards,
Stephen
-- 
 Stephen Jacob | [email-masked] | +1 650 381 6051
 Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000