Re: [dhcwg] Lifetime option (draft-ietf-dhc-lifetime-00.txt)

Stig Venaas <> Tue, 06 July 2004 14:27 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id KAA18899; Tue, 6 Jul 2004 10:27:19 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1BhqWS-0006KQ-QQ; Tue, 06 Jul 2004 10:02:12 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1BhphV-00088G-0j for; Tue, 06 Jul 2004 09:09:33 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA12388 for <>; Tue, 6 Jul 2004 09:09:26 -0400 (EDT)
Received: from ([] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhphP-0001nT-7Z for; Tue, 06 Jul 2004 09:09:27 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhpgT-0001Tg-00 for; Tue, 06 Jul 2004 09:08:30 -0400
Received: from ([]) by ietf-mx with esmtp (Exim 4.12) id 1Bhpg0-00018p-00 for; Tue, 06 Jul 2004 09:08:00 -0400
Received: from ( [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by (8.12.10/8.12.10) with ESMTP id i66D7MDW007795; Tue, 6 Jul 2004 15:07:22 +0200
Received: (from venaas@localhost) by (8.12.8/8.12.8/Submit) id i66D7HLD009252; Tue, 6 Jul 2004 15:07:17 +0200
X-Authentication-Warning: venaas set sender to using -f
Date: Tue, 6 Jul 2004 15:07:17 +0200
From: Stig Venaas <>
To: Thomas Narten <>
Subject: Re: [dhcwg] Lifetime option (draft-ietf-dhc-lifetime-00.txt)
Message-ID: <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On Fri, Jul 02, 2004 at 10:36:18AM -0400, Thomas Narten wrote:
> Personally, I think that if one is trying to contact a DHC server, and
> none respond, there should be a generic algorithm used for
> retries. I.e., the case for this option should not be any different
> (for say) the case where one first boots, and no DHC server responds,
> or when one fails to renew an address after an address expires.
> I.e., isn't there already a generic retranmission with backoff and
> some upper limit? Why not just do the same? Is there a need for
> multiple different algorithms?

You're right. I've looked more carefully at RFC 3315, and the obvious
thing is to follow the same rules. It specifies how a client should
send messages (including backoff) and we're after all not changing the
DHCP protocol.

I suggest the following text for the next version:

   Before making the request it MUST wait for a random amount of time
   between 0 and INF_MAX_DELAY.  INF_MAX_DELAY is defined in [RFC 3315].

   Then it can make the DHCP request to update the configuration.  The
   message MUST be created and transmitted according to [RFC 3315].  E.g.
   for an Information-request message it must be done according to the
   rules for creation and transmission of Information-request messages in
   section 18.1.5 of [RFC 3315].

Any other comments on the draft are welcome. I'm hoping the next version
may be the final one, I don't think there's much more that can be said
about this simple option...


dhcwg mailing list