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

Joe Quanaim <> Fri, 27 August 2004 13:46 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA29395; Fri, 27 Aug 2004 09:46:07 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1C0gy1-0001MB-Ot; Fri, 27 Aug 2004 09:40:33 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1C0gok-0008O7-0c for; Fri, 27 Aug 2004 09:30:58 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA28406 for <>; Fri, 27 Aug 2004 09:30:55 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1C0gpq-0001Hw-8y for; Fri, 27 Aug 2004 09:32:09 -0400
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id i7RDUIEG002450; Fri, 27 Aug 2004 08:30:19 -0500 (CDT)
Received: from by (8.11.7+Sun/EMS-1.5 sol2) id i7RDUIY16252; Fri, 27 Aug 2004 09:30:18 -0400 (EDT)
From: Joe Quanaim <>
To: Robert Elz <kre@munnari.OZ.AU>, Stig Venaas <>
Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments ondraft-ietf-dhc-lifetime-01.txt)
Date: Fri, 27 Aug 2004 09:29:46 -0400
User-Agent: KMail/1.5.4
References: <> <29651.1093585502@munnari.OZ.AU> <77.1093589569@munnari.OZ.AU>
In-Reply-To: <77.1093589569@munnari.OZ.AU>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit

Robert Elz wrote:
>     Date:        Fri, 27 Aug 2004 08:23:21 +0200
>     From:        Stig Venaas <>
>     Message-ID:  <>
>   | 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.
> Yes, it is a much bigger issue than just providing a mechanism for
> specifying when a new info request should be attempted.
> But it is when we specify that that the problem becomes obvious, and
> we need to have a solution - until now (including in IPv4) we mostly
> just pretended that none of this ever happened, and once learned, all
> of this information was static forever (hence, DNS "servers" (back end
> resolvers really) go in /etc/resolv.conf - that gets updated when the
> info changes, but applications know nothing of that, and simply keep on
> using the old information forever).
> All this is something of a quagmire - but is something that needs to be
> addressed, and ought to be addressed along with this new option (if not
> necessarily in the same document).

I agree that this is an issue, but I don't think it's something this document 
should address.  It's a larger part of the dhcp specification, and the 
example you gave could happen in stateful configuration as well.

For the example involving dns and this option, I read the draft as such: when 
the option expires, don't dismiss the configured dns data.  Request new 
information.  When new information is received, replace the existing data 
with the newly obtained.  This prevents the client from being left without 
dns while making an attempt to be current.  Also, if a server returns an 
empty set of dns servers, that is what the client should use.  It doesn't 
make much sense, but misconfigured dhcp servers aren't something a client 
should be programmed to handle.

Generalizing this issue is not simple.  How does a dhcp client update the ntp 
configuration?  And why does it?  The ntp configuration could be pointing to 
a server reachable from multiple networks.  This seems like local policy.

Joe Quanaim.

dhcwg mailing list