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

"Bernie Volz" <> Fri, 20 August 2004 18:49 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA05350; Fri, 20 Aug 2004 14:49:44 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1ByDwz-0003wa-GN; Fri, 20 Aug 2004 14:17:17 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1ByCW1-0001fK-U7 for; Fri, 20 Aug 2004 12:45:22 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA25915 for <>; Fri, 20 Aug 2004 12:45:14 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1ByCcd-00030K-5J for; Fri, 20 Aug 2004 12:52:11 -0400
Received: from ( by with ESMTP; 20 Aug 2004 12:55:07 -0400
X-BrightmailFiltered: true
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id i7KGieY3009494; Fri, 20 Aug 2004 12:44:41 -0400 (EDT)
Received: from volzw2k ( []) by (MOS 3.4.6-GR) with ESMTP id AKZ47834; Fri, 20 Aug 2004 12:44:38 -0400 (EDT)
From: Bernie Volz <>
To: 'Stig Venaas' <>, 'Joe Quanaim' <>
Subject: RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
Date: Fri, 20 Aug 2004 12:44:38 -0400
Organization: Cisco
Message-ID: <002e01c486d4$fd93d810$>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.5709
In-Reply-To: <>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
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

While the load on a server for processing Information-Requests should be
relatively small, why use a default that is so short? This means that in a
typical working day (8 or more hours) while you've connected your laptop at
work, it will get the parameters when you first connect and at LEAST once

If we're to believe there will be billions of IPv6 devices and a sizeable
fraction will use stateless, why have all of this DHCP traffic?

The lifetime mechanism MUST NOT be used in place of redundancy - if you're
only going to have one DNS resolving server, you're asking for trouble and
using this lifetime option to work aroud failures is NOT correct.

This information should generally be valid for LONG time periods unless a
site has an explicit need to refresh this information more frequently, in
which case the server should be configured with the desired value.

Personally I would like to see a DEFAULT lifetime of NOT LESS than 12 hours.
(Most operational network use a day to a week for lease times from my

Ask yourself what are typical LEASE times and cut these in half. Or, if you
have data on typical address LIFETIMES for IPv6 addresses, use these values.

And, remember we're specifying the DEFAULT. If a server administrator wants
to reduce this, she is free to do so.

I also believe we should, in order to prevent Denial-of-Service attacks or
"Information-Request" storms, specify a LOWER BOUND of something like 10

And, the lifetime option shouldn't be the only trigger a client uses to
refresh this information. Connecting a network cable to the client,
significant changes in the prefixes active on the link, etc. are all other
considerations that a client SHOULD use to trigger refreshing this
information. The lifetime should only apply to very STATIC situations -
where the client isn't mobile and the network addresses don't change.

- Bernie

> -----Original Message-----
> From: Stig Venaas [] 
> Sent: Friday, August 20, 2004 11:08 AM
> To: Joe Quanaim
> Cc: Bernie Volz; 'JINMEI Tatuya / ?$B?@L@C#:H'; 
> Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
> On Fri, Aug 20, 2004 at 10:55:04AM -0400, Joe Quanaim wrote:
> > Bernie Volz wrote:
> > > 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 
> > >
> > > The server MUST NOT include the Lifetime Option in any 
> message other 
> > 
> > This sounds good to me.
> > 
> > Also, did we reach consensus on a default value?  This 
> seems like the
> > appropriate place to mention it:
> > 
> > If a client requests a Lifetime Option and does not receive 
> one in the 
> > reply,
> > it should use the default value of n hours.
> > 
> > Or something to that effect...
> Yes, I've already written some text to that effect, it's not 
> done. What I have so far is:
>    In some cases a default lifetime LT_DEFAULT is used.
>    The recommended value for LT_DEFAULT is 21600 (6 hours).
> I just took 6 out of the air, input needed.
> and then under client behaviour:
>    A client implementing this option MUST when a reply to an
>    Information-Request message does not contain the option, behave
>    as if the option with value LT_DEFAULT was provided.
>    A client MUST also use the default lifetime LT_DEFAULT if the
>    value of the option is zero.
>    If client has received a lifetime with this option, and contacts
>    server to receive new or update any existing data prior to its
>    expiration, it SHOULD also update data covered by this option.
>    If no new lifetime is received, it MUST use the default lifetime
> I need to work a bit more on the text, but let me know if 
> this is not in line with what you think.
> Stig

dhcwg mailing list