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

Stig Venaas <Stig.Venaas@uninett.no> Tue, 29 June 2004 11:23 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11929; Tue, 29 Jun 2004 07:23:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfGeT-00054g-EX; Tue, 29 Jun 2004 07:19:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfGbp-0004g9-Jm for dhcwg@megatron.ietf.org; Tue, 29 Jun 2004 07:17:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11576 for <dhcwg@ietf.org>; Tue, 29 Jun 2004 07:17:05 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfGbp-0005v4-30 for dhcwg@ietf.org; Tue, 29 Jun 2004 07:17:05 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfGao-0005by-00 for dhcwg@ietf.org; Tue, 29 Jun 2004 07:16:03 -0400
Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1BfGZl-00051E-00 for dhcwg@ietf.org; Tue, 29 Jun 2004 07:14:57 -0400
Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i5TBEPDW011487 for <dhcwg@ietf.org>; Tue, 29 Jun 2004 13:14:25 +0200
Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i5TBEP1r014075 for dhcwg@ietf.org; Tue, 29 Jun 2004 13:14:25 +0200
X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f
Date: Tue, 29 Jun 2004 13:14:25 +0200
From: Stig Venaas <Stig.Venaas@uninett.no>
To: dhcwg@ietf.org
Message-ID: <20040629111425.GA14068@sverresborg.uninett.no>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [dhcwg] Lifetime option (draft-ietf-dhc-lifetime-00.txt)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org

I would like to get some feedback from you on the lifetime option in
order to submit a revised draft ASAP.

The main issue, is what should happen when the lifetime expires.
Currently it says:

   When the client detects that the lifetime has expired, it must do as
   follows.

   First it MUST ignore or remove the existing lifetime value.  If it
   does not receive a new value in a later request, it MUST behave as if
   no value was ever provided.

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

   Finally it must make a new DHCP request, updating the current
   configuration.  This request will usually be an Information-request
   Message.  If client fails to receive a valid response from a server,
   it MUST retransmit the message according to the retransmission rules
   specified in [RFC 3315].

   If the update fails, the current configuration must be kept as if no
   lifetime was ever provided.

I think it might be better to retry. The retry interval could be a
function of the lifetime. The reason I didn't in the current version,
is that I was worried what would happen if someone sent a forged reply
with say a lifetime of 1s.

What do you think? Should there be some retry? What should the
function be?

Also, should a lifetime of say 0 or 0xffffffff have any special
meanings, e.g. infinity? Personally I don't see a need for that.
If not, 0 is meaningless, so I could possibly say that the value
must be set to non-zero by server, and that clients should ignore 0.

I would be happy for any other comments you might have.

Stig

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg