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

Stig Venaas <Stig.Venaas@uninett.no> Wed, 01 September 2004 16:27 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 MAA05169; Wed, 1 Sep 2004 12:27:17 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XMS-0005cG-Rk; Wed, 01 Sep 2004 11:49:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VFi-00046A-9h for dhcwg@megatron.ietf.org; Wed, 01 Sep 2004 09:34:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06191 for <dhcwg@ietf.org>; Wed, 1 Sep 2004 09:34:13 -0400 (EDT)
Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2UJ2-0001JM-6O for dhcwg@ietf.org; Wed, 01 Sep 2004 08:33:41 -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 i81CUXOK000613; Wed, 1 Sep 2004 14:30:33 +0200
Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i81CUThF015683; Wed, 1 Sep 2004 14:30:29 +0200
X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f
Date: Wed, 01 Sep 2004 14:30:29 +0200
From: Stig Venaas <Stig.Venaas@uninett.no>
To: "JINMEI Tatuya / ?$B?@L@C#:H" <jinmei@isl.rdc.toshiba.co.jp>
Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt)
Message-ID: <20040901123029.GI15000@sverresborg.uninett.no>
References: <y7vhdrl56ol.wl@ocean.jinmei.org> <20040803033357.GA20506@sverresborg.uninett.no> <y7veklyqkbx.wl@ocean.jinmei.org> <A9C62C40-F510-11D8-AE27-000A95D9C74C@nominum.com> <y7vfz6cenvy.wl@ocean.jinmei.org> <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> <y7vy8jv70uo.wl@ocean.jinmei.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <y7vy8jv70uo.wl@ocean.jinmei.org>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: dhcwg@ietf.org, Ted Lemon <Ted.Lemon@nominum.com>
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

On Wed, Sep 01, 2004 at 01:01:51AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> >>>>> On Tue, 24 Aug 2004 11:08:14 -0400, 
> >>>>> Ted Lemon <Ted.Lemon@nominum.com> said:
> 
> > However, let's consider your scenario a little more closely.   You 
> > acquire some information from the DHCP server.   Subsequently, for some 
> > reason, it becomes impossible for the server to respond to the client.
> 
> > I have a couple of observations about this.   First, the time at which 
> > it becomes impossible for the server to respond is not the same as the 
> > time at which the client attempts to refresh its configuration 
> > information.   The two events are unrelated.
> 
> Okay, I concur on this.  I also see that the scenario might differ
> based on whether the client moves to a new link or it stays in the
> same link.

What you write sounds reasonable, but I'm still not sure we should go
into the details. The reason is that we don't know in general what
the behaviour should be, and it's a generic issue. It's obviously a
related issue though. We could as Ted suggests, specify this later
when we have more information. That could either be as an update to
the lifetime RFC, or IMO perhaps better, add some text if an update
to RFC 3315 is done. There seems to be other reasons to update RFC
3315 too (draft-jinmei-dhc-dhcpv6-clarify-auth-00?).

In general I agree with your distinction between still and moving
clients. What worries me though, is that it might not be possible for
a client to distinguish between movement and renumbering. The fact
that a new prefix is announced in RAs is not sufficient.

Stig

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