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

Stig Venaas <> Fri, 27 August 2004 06:27 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id CAA02060; Fri, 27 Aug 2004 02:27:29 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C0aBH-0005ov-Bb; Fri, 27 Aug 2004 02:25:47 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C0a9T-0004on-Im for; Fri, 27 Aug 2004 02:23:55 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id CAA01754 for <>; Fri, 27 Aug 2004 02:23:53 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C0aAY-0001RI-SV for; Fri, 27 Aug 2004 02:25:03 -0400
Received: from ( [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by (8.12.10/8.12.10) with ESMTP id i7R6NMOK013396; Fri, 27 Aug 2004 08:23:22 +0200
Received: (from venaas@localhost) by (8.12.8/8.12.8/Submit) id i7R6NLh5015094; Fri, 27 Aug 2004 08:23:21 +0200
X-Authentication-Warning: venaas set sender to using -f
Date: Fri, 27 Aug 2004 08:23:21 +0200
From: Stig Venaas <>
To: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt)
Message-ID: <>
References: <001501c48a3e$f4246d90$> <29651.1093585502@munnari.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <29651.1093585502@munnari.OZ.AU>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On Fri, Aug 27, 2004 at 12:45:02PM +0700, Robert Elz wrote:
>     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) ?

Thanks for making this clear. We just had some discussion on this, but
the problem was perhaps not clearly stated. And this is one of the
things I tried to ask. What would you do if this happened without this
option. As you said, this is a more generic problem, and it makes me
wonder whether people already have thought about this.

> 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.

Is there a theoretical possibility that you get a response, but without
any options? That should possibly be treated differently from not
getting any reply at all.

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

If you get a response from a server, and later a new from the same
server but with some options missing, then I believe the administrator
must have removed the it on purpose and the old information is not

However, this is not so clear if you get a reply from a new server.
If you're still in the same site, then I think situation is pretty
much like above. But if the client has moved to a new site, the old
information might be valid, but not necessarily.

E.g. if I learn an NTP server at home, I might wish to keep using it
from a new location, even if the administrator in that new location
doesn't care about NTP and hasn't configured anything. Whether I
should continue using the one at home really depends on policy. The
access to the NTP server might for instance be blocked in a firewall
deployed in/around my home site or the site I'm now visiting.

I'm not sure if the answer to these issues need to be described in
the draft since it's a more generic issue. OTOH this draft might be
the most obvious place we have for now.


dhcwg mailing list