Re: [dhcwg] Address withdrawal

Jim Bound <seamus@bit-net.com> Mon, 24 September 2001 14:14 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11995; Mon, 24 Sep 2001 10:14:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23614; Mon, 24 Sep 2001 10:14:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23589 for <dhcwg@optimus.ietf.org>; Mon, 24 Sep 2001 10:14:08 -0400 (EDT)
Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11923 for <dhcwg@ietf.org>; Mon, 24 Sep 2001 10:13:59 -0400 (EDT)
Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA26777; Mon, 24 Sep 2001 10:13:57 -0400
Date: Mon, 24 Sep 2001 10:13:57 -0400
From: Jim Bound <seamus@bit-net.com>
To: "Guja, ArturX" <ArturX.Guja@intel.com>
Cc: "Dhcwg (E-mail)" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Address withdrawal
In-Reply-To: <413FBB0BA5AED1119122000083234B1A0247B447@alpha.igk.intel.com>
Message-Id: <Pine.OSF.3.95.1010924100453.23830M-100000@www.bit-net.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

This is real life issue and I point you to the ipv6 stateless code on the
implementation your working on.  This SHOULD not happen till the address
becomes "deprecated".  You need to integrate the dhcpv6 client code with
the nodes stateless code on your implementation.

But there is one issue and that is once an address is truly deprecated the
connection is broken.  This is not a dhcp issue again but an IPv6 rule.
That is why its critical that lifetimes be managed by the server in
accordance with the clients needs.

But here is a hint and all I have time to do till next week as I got to
travel this week shortly to the west coast.

In your ipv6 stateless implementation where the code checks for lifetime
or event manager based on timers (thats how I designed it on our code
base) you now need to add dhcpv6 timers and if-then conditions to that
code base to adjust the times for addresses so at renew for dhcpv6 you
change the timing of the events to kill a connection at deprecation state.
I will bet you have code for ipv6 stateless to do it now you just need to
add dhcpv6 affect to that code.  I would not rewrite or have separate code
for lifetime mgmt for dhcpv6 and stateless but an integrated code base.

hope this helps.


/jim


On Mon, 24 Sep 2001, Guja, ArturX wrote:

> Hello,
> 
> I'd like to ask your opinion on the following (standard) scenario:
> 
> The DHCPv6 client notices, that and address has expired.
> It proceeds to remove the address from the interface.
> At the same time, the address was used in as long TCP
> (or any stream) connection(like a video-conference or file
> transfer). The address gets removed, the connection breaks
> down, the user goes mad :)))
> 
> In the spec, it says that the client should "notify upper layers".
> So, in real world, what do I do? There is no way I can
> reassign open application sockets to new addresses. They will break
> down, won't they?
> 
> How is this handled?
> 
> Artur
> 
> PS: Sorry if this is an idiotic question, but I really have a problem with
> this.
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> http://www1.ietf.org/mailman/listinfo/dhcwg
> 


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