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
- [dhcwg] Address withdrawal Guja, ArturX
- Re: [dhcwg] Address withdrawal Jim Bound