Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt

Robert Elz <kre@munnari.OZ.AU> Fri, 27 August 2004 06:20 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id CAA01197; Fri, 27 Aug 2004 02:20:00 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C0ZyN-0007RN-SF; Fri, 27 Aug 2004 02:12:27 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C0ZwD-0006F4-KH for; Fri, 27 Aug 2004 02:10:14 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id CAA26411 for <>; Fri, 27 Aug 2004 02:10:12 -0400 (EDT)
Received: from ([] by with esmtp (Exim 4.33) id 1C0ZxH-00019w-Fw for; Fri, 27 Aug 2004 02:11:21 -0400
Received: from munnari.OZ.AU (localhost []) by (8.12.9/8.11.6) with ESMTP id i7R68W9O011614; Fri, 27 Aug 2004 13:08:33 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: Bernie Volz <>
Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
In-Reply-To: <000e01c486b3$66af02b0$>
References: <000e01c486b3$66af02b0$>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 27 Aug 2004 13:08:32 +0700
Message-ID: <6493.1093586912@munnari.OZ.AU>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc:,, 'Stig Venaas' <>,
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

    Date:        Fri, 20 Aug 2004 08:44:14 -0400
    From:        "Bernie Volz" <>
    Message-ID:  <000e01c486b3$66af02b0$>

  | I'm OK to restricting the Lifetime Option to replies to
  | Information-Request's.
  | The client MUST ignore a Lifetime Option that is in any message other than a
  | REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime
  | Option number in an ORO except when sending an INFORMATION-REQUEST message.
  | The server MUST NOT include the Lifetime Option in any message other than a

I've been reading all of the messages on this topic (catching up) and I
haven't managed to find a reason why anyone would want to add this kind
of restriction, I just don't see the need.

You seem to all be imagining that things have to get much more complex
for the clients if they get two timer values, and they're different.
But that's nonsense.

All of these timers are just upper bounds - a client that wants to be
simple just wants a single timer.   If one option says "the upper bound
is 86400 seconds" and another says "the upper bound is 43200 seconds",
then to the client, it just tries again, for all the info, before the
43200 second timer expires.   This isn't complex, it is trivial.

On the other hand, if the client doesn't need to be quite that simple,
then I see no compelling reason to require it to be so.

In particular, and especially given we're talking about IPv6, I see
no reason why a client shouldn't use very long lease times (well,
comparatively long - in IPv4 I've seen values counted in years - that's
absurd, but values of several weeks for address lifetime should be
reasonable).    If there's no prospect that the prefixes are going to
change anytime soon, there's no reason that an IPv6 node shouldn't be
able to keep using its address for a very long time, even if the DHCP
server is down for an extended period (and that's what the lease timers
are all about really - no-one disputes but that addresses stop being
used when their lifetime expires).

On the other hand, we may want to be able to shift which hosts run various
servers with much time lag, so the "other option lifetime" (or whatever it
ends up being called) might want to be quite a bit smaller (maybe measured
in hours, or a day or so).

A simple client will simply refresh everything when the shorter timer
expires.   A complex one might prefer to just use info requests when the
shorter info timer expires, and only do the full dhcp protocol when the
addresses actually expire - aside from anything else, this allows dhcp-lite
servers to respond, where only a full duchv6 server can handle address 

Why would anyone really want to forbid this?   That's all the proposed
language is doing, nothing really gets any simpler (in a simple client now
instead of just taking the lower timer value, it instead has to know
to ignore this particular option if it happens to occur in that particular
message type - which I think is a rather unusual case).


dhcwg mailing list