RE: [dhcwg] behavior on lifetime expiration (Re: commentson draft-ietf-dhc-lifetime-01.txt)

"Bernie Volz" <> Wed, 25 August 2004 02:03 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id WAA03616; Tue, 24 Aug 2004 22:03:35 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1Bzmk9-0007uW-Au; Tue, 24 Aug 2004 21:38:29 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1BzmLJ-00047X-7h for; Tue, 24 Aug 2004 21:12:49 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id VAA29952 for <>; Tue, 24 Aug 2004 21:12:42 -0400 (EDT)
Received: from ([] by with esmtp (Exim 4.33) id 1BzmLr-0005QH-2X for; Tue, 24 Aug 2004 21:13:23 -0400
Received: from ( by with ESMTP; 24 Aug 2004 18:17:09 -0700
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id i7P1C5We022866; Tue, 24 Aug 2004 18:12:06 -0700 (PDT)
Received: from volzw2k ( []) by (MOS 3.4.6-GR) with ESMTP id ALB57532; Tue, 24 Aug 2004 21:12:06 -0400 (EDT)
From: Bernie Volz <>
To: 'JINMEI Tatuya / _-¾'BÆ' <>, 'Ted Lemon' <>
Subject: RE: [dhcwg] behavior on lifetime expiration (Re: commentson draft-ietf-dhc-lifetime-01.txt)
Date: Tue, 24 Aug 2004 21:12:07 -0400
Organization: Cisco
Message-ID: <001601c48a40$8a411e80$>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.5709
In-Reply-To: <>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Content-Transfer-Encoding: quoted-printable
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: quoted-printable


You'd prefer IPv4 based information over IPv6?

And DHCPv4, if Inform was used, doesn't have *ANY* time to expire the
information - so I don't think you'd want to use this information in
preference to DHCPv6 information with a time?

If you can't obtain newer information, you're always free to take whatever
steps you like on the client - ie, start a local recursive server daemon
(e.g., run BIND named on my laptop and specify ::1 in /etc/resolv.conf).

The issue of not receiving some information that was previously received is
a good one and we probably should give some advice in the draft as to
possible options that a client could chose (based on "local" policy). My own
feeling is that I'd discard the old information and use the new, especially
if the source can be trusted (ie, authentication was used). There may be
valid reasons why some options are no longer available; in other cases it
could be a configuration error and in that case it may be good for
administrators to know about it sooner than later. The worst is if it is a
Denial of Service attack, but in that case they can just as easily send you
bogus information.

- Bernie

> -----Original Message-----
> From: [] 
> On Behalf Of JINMEI Tatuya / _–¾’BÆ
> Sent: Tuesday, August 24, 2004 8:12 AM
> To: Ted Lemon
> Cc:
> Subject: Re: [dhcwg] behavior on lifetime expiration (Re: 
> commentson draft-ietf-dhc-lifetime-01.txt)
> >>>>> On Mon, 23 Aug 2004 10:28:12 -0400,
> >>>>> Ted Lemon <> said:
> >> - even if the clients cannot get a response by the expiration, it 
> >> should continue sending Information-requests.  However, it 
> can also 
> >> invalidate the expired information in some way, e.g., by 
> preferring a 
> >> "last resort" default or by using other means of configuration.
> > Can you think of a real-world scenario where this would be 
> the right 
> > thing to do?   I can't come up with one.
> The scenario I thought of is that if the "lifetime" of a DNS
> (recursive) server expires with no update I'd stop using the 
> server and start a local recursive server daemon (e.g., run 
> BIND named on my laptop and specify ::1 in /etc/resolv.conf) 
> as a last resort.  I'm quite sure that this is a "real world" 
> scenario because I, for one, would like to have this feature 
> and I'm living in the real world of the Internet.  I admit 
> this might be a niche demand though.
> I can also think of a scenario where I'll then prefer 
> information from DHCPv4 (over the expired information from 
> DHCPv6).  But I don't know this makes sense in the real world.
> Aside from the scenarios, I'm also concerned about a 
> (possible) pitfall with the "update timer" semantics.
> Assume that we have a reply to Information-request containing 
> a DNS server address X with update timer (or lifetime) T.  T 
> seconds later, the client will restart 
> Information-request/reply exchanges.  If we then get a 
> different DNS server address Y, we'll stop using the old 
> address X and switch to Y.  This should exactly be the 
> "renumbering scenario", and the behavior looks reasonable.  
> But what if the reply does not contain any new DNS server 
> address?  Can we still continue to use address X, or will we 
> then lose any usable DNS server address?
> If the former is the intent, it seems a bit odd to me that 
> the behavior is different based on whether the replied set is 
> empty or not (at least the specification is not very clear on 
> this).  If the latter is the intent, doesn't it almost mean 
> we invalidate the expired information X?
> far, others do not seem to be very happy with the 
> idea of invalidating expired information.  If the above 
> explanation is still not so convincing, I won't stick to the 
> idea.  I can live with the "update timer" semantics as long 
> as the specification is clear enough to implement.
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, 
> Toshiba Corp.
> p.s. I'm afraid I won't be able to be very active on the list 
> this week.  I'd apologize in advance for future delay of my responses.
> _______________________________________________
> dhcwg mailing list

dhcwg mailing list