RE: [dhcwg] dhcpv6-24: movement detection and Confirm message

"Bound, Jim" <Jim.Bound@hp.com> Mon, 13 May 2002 02:24 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 WAA11005 for <dhcwg-archive@odin.ietf.org>; Sun, 12 May 2002 22:24:03 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA22512 for dhcwg-archive@odin.ietf.org; Sun, 12 May 2002 22:24:15 -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 WAA22400; Sun, 12 May 2002 22:22:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22375 for <dhcwg@optimus.ietf.org>; Sun, 12 May 2002 22:22:33 -0400 (EDT)
Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10889 for <dhcwg@ietf.org>; Sun, 12 May 2002 22:22:17 -0400 (EDT)
Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id B6B712514; Sun, 12 May 2002 22:22:27 -0400 (EDT)
Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 22:22:27 -0400
x-mimeole: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message
Date: Sun, 12 May 2002 22:22:26 -0400
Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B85B3@tayexc13.americas.cpqcorp.net>
Thread-Topic: [dhcwg] dhcpv6-24: movement detection and Confirm message
Thread-Index: AcH5vCnBk6OXEXITQJuxW8RIWRUsQQAaAm4w
From: "Bound, Jim" <Jim.Bound@hp.com>
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>, Thomas Narten <narten@us.ibm.com>
Cc: dhcwg@ietf.org
X-OriginalArrivalTime: 13 May 2002 02:22:27.0590 (UTC) FILETIME=[06AE3A60:01C1FA25]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA22378
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
Content-Transfer-Encoding: 8bit

Bernie,

********************************
But a Renew is only directed to the one server and it is down or not on the network, the client gets no response. What should it do?
********************************

Go look for another server and use the addresses as long as it can.  Confirm should not have been used to detect movement as Thomas stated.  What I am saying is Renew could be a hint.  If a response comes back all is golden.  But putting into the protocol that this works for that case is not ideal.

**********************************
If it gets a Reply, it does know it is on the same network as before.
***************************

Or the server was smart enough to give it a new prefix was where I was going and then the node could have gone to a different link.  This requires no change to the spec.

******************************
If it gets no Reply, it knows only that it may not be on the same network OR that the original server is down. 
****************************

I see no advantage here over Renew and in fact disadvantage per Renew giving the client new addresses with new prefixes for that link.

regards,
/jim

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