Subject: Re: [dhcwg] Query Regarding DHCP Lease time, Rebind Time and Renewal Time.

From: Ted Lemon <[email-masked]>
Date: Mon, 1 Nov 2010 03:30:05 -0400

On Nov 1, 2010, at 12:06 AM, Bernie Volz (volz) wrote:
> So, I guess the DHCPv4 client could considers the OFFER (or ACK)
> invalid. Another option would be to ignore the servers T1/T2 and just
> use the default values?

I would expect the client to just go into rebind at T2, or else possibly go into renew at T2 and then immediately into rebind.   IOW, don't do it, because you can't predict what will happen.  :)

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 1 Nov 2010 11:57:44 -0700

On Sun, Oct 31, 2010 at 11:06:05PM -0500, Bernie Volz (volz) wrote:
>    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.
> 

I think Ramesh is specifically asking about client-calculated T1/T2,
where the client has a clock granularity in seconds and is receiving
very low lease times.

Note that 3315 instructs the client to check for 'T1 greater than T2',
not 'greater than or equal.'  This made me wonder if T1 = T2 is legal
in DHCPv6, and implies as Ted suggests to schedule Rebind only.

I have wondered if this language was intentional or not; in other
places the document also uses the language that a client should select
(e.g. a retransmit timer) "between values x and y", and it seemed
strange to me that this wasn't made inclusive.

Anyway - I think in DHCPv6 there is a higher expectation that the
client implement timers in a higher resolution that whole seconds
(several references to centiseconds), but at the same time doesn't
seem to concretely specify that ability as a requirement.  So in
this case in DHCPv6 I would expect the Reply IA_NA/IAADR;

  T1 = T2 = 0
  preferred = valid = 1

To result in T1 = 1/2 second, T2 = 7/8ths, or similar defaults ("at
the client's discretion").

Although I can't imagine anyone doing that on purpose.

-- 
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: Ted Lemon <[email-masked]>
Date: Mon, 1 Nov 2010 15:07:05 -0400

> this case in DHCPv6 I would expect the Reply IA_NA/IAADR;

I don't think you can implement the protocol as described without a clock resolution of at least hundredths of seconds, although I suppose if you wanted to be really literal about it, you could probably claim that the resolution only needed to be as fine as an eighth of a second.

But as you say, it's somewhat immaterial.   The reason we put in the additional resolution was to get quick recovery from transient failures, not to allow for absurdly short leases.

---

From: Ramesh Ganapathi <[email-masked]>
Date: Tue, 2 Nov 2010 01:01:23 +0530

Thank you all for your feedback/comments.

For DHCPv4 Client running in the legacy systems where the clock resolution
is in the order of seconds I think the RFC doesn't prescribe a way to handle
T1 == T2 (As suggested we need to DROP the OFFER). I think in DHCP server
also there is no minimum configurable value for lease time is specified, so
that the value of 0 (zero) is also allowed for configuring lease time (T1
and T2 also become 0)

[I tried with Linux DHCP server and it allows to configure lease time with 0
(zero)].

--Ramesh.G

On Tue, Nov 2, 2010 at 12:37 AM, Ted Lemon <[email-masked]> wrote:

> I don't think you can implement the protocol as described without a clock
> resolution of at least hundredths of seconds, although I suppose if you
> wanted to be really literal about it, you could probably claim that the
> resolution only needed to be as fine as an eighth of a second.
>
> But as you say, it's somewhat immaterial.   The reason we put in the
> additional resolution was to get quick recovery from transient failures, not
> to allow for absurdly short leases.
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Ramesh Ganapathi <[email-masked]>
Date: Tue, 2 Nov 2010 01:12:05 +0530

--Ramesh.G

---

From: Ted Lemon <[email-masked]>
Date: Sun, 7 Nov 2010 17:58:47 -0800

On Nov 2, 2010, at 3:42 AM, Ramesh Ganapathi wrote:
[I tried with Linux DHCP server and it allows to configure lease time with 0 (zero)].

I never bothered to put in a check for that because it seemed obvious that nobody would configure a value of zero intentionally.