Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt)

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

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id BAA15920; Fri, 27 Aug 2004 01:54:00 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C0ZaD-0007B4-Cy; Fri, 27 Aug 2004 01:47:29 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C0ZZ9-0006rJ-CX for; Fri, 27 Aug 2004 01:46:23 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id BAA15662 for <>; Fri, 27 Aug 2004 01:46:21 -0400 (EDT)
Received: from ([] by with esmtp (Exim 4.33) id 1C0ZaB-0000mT-Mq for; Fri, 27 Aug 2004 01:47:30 -0400
Received: from munnari.OZ.AU (localhost []) by (8.12.9/8.11.6) with ESMTP id i7R5j29O000810; Fri, 27 Aug 2004 12:45:06 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: Bernie Volz <>
Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt)
In-Reply-To: <001501c48a3e$f4246d90$>
References: <001501c48a3e$f4246d90$>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 27 Aug 2004 12:45:02 +0700
Message-ID: <29651.1093585502@munnari.OZ.AU>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc:,,, 'Stig Venaas' <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

    Date:        Tue, 24 Aug 2004 21:00:45 -0400
    From:        "Bernie Volz" <>
    Message-ID:  <001501c48a3e$f4246d90$>

  | I'd vote for "Refresh Time Option". I have no problem renaming this

The name of the option isn't really the point.   Jinmei has a valid point,
but didn't manage to express the real issue perhaps as clearly as should
have been done.

The issue isn't really "what happens when the lifetime expires" (whatever
you call it), the issue is "what happens when the DHCP server doesn't give
us some information that was given to us before" ?

You're mostly all thinking (it seems) of the case where the DHCP server
doesn't reply at all to a later request for information - and so no new
data is provided.

The other case, where the dhcp server does reply, and supplies new information.
We all know what to do in that case.

But those aren't the only two cases - the problem case is what happens when
the (a) DHCP server does reply, but only supplies values for some of the
options that an earlier DHCP response had supplied.

That is, suppose I ask for NTP servers and DNS servers.   When I boot
I get told fe80::99 for NTP, and fe80::7 for DNS.   Then later, I ask
again, and get told 2001:1234:5678::16 for DNS, but get no NTP server
addresses supplied at all.

What is the client expected to do in that case?   It seems reasonably clear
(to me anyway) that the likely cause of this kind of change, is that the
client is a portable device, that has been moved from one location to
another, and is now talking to a different DHCP server than it was before
(though entirely possibly both servers migh just happen to have been
configured at fe80::9 on their respective LANs).

Should the client just keep on using the (probably now bogus) NTP server
address, or should it just give up on NTP, given the local lan most
likely has no available server?   Does it make a difference if the
previous "lifetime" has or has not expired?   Or for that matter, whether
or not there was ever a lifetime option, or whether or not the client
requested it (and knows anything aboutthis new option) ?

Once you work out the right answer to that problem, it is a minor issue to
extend that answer to the case where no answers at all are returned.


ps: notice here I am not suggesting what the answer should be.

dhcwg mailing list