[dhcwg] Address withdrawal

"Guja, ArturX" <ArturX.Guja@intel.com> Mon, 24 September 2001 13:02 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 JAA01465; Mon, 24 Sep 2001 09:02:37 -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 IAA19812; Mon, 24 Sep 2001 08:59:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19780 for <dhcwg@optimus.ietf.org>; Mon, 24 Sep 2001 08:59:49 -0400 (EDT)
Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00854 for <dhcwg@ietf.org>; Mon, 24 Sep 2001 08:59:39 -0400 (EDT)
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4, v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id JAA11385 for <dhcwg@ietf.org>; Mon, 24 Sep 2001 09:24:53 GMT
Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001092402242707319 for <dhcwg@ietf.org>; Mon, 24 Sep 2001 02:24:27 -0700
Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsx29.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T2T6Z5WF; Mon, 24 Sep 2001 02:24:57 -0700
Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id <NMB58HF0>; Mon, 24 Sep 2001 11:24:51 +0200
Message-ID: <413FBB0BA5AED1119122000083234B1A0247B447@alpha.igk.intel.com>
From: "Guja, ArturX" <ArturX.Guja@intel.com>
To: "Dhcwg (E-mail)" <dhcwg@ietf.org>
Date: Mon, 24 Sep 2001 11:24:46 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-2"
Subject: [dhcwg] Address withdrawal
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

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