RE: [dhcwg] Clarification necessary

"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Mon, 17 September 2001 22:11 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 SAA22765; Mon, 17 Sep 2001 18:11:36 -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 SAA17724; Mon, 17 Sep 2001 18:06:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17701 for <dhcwg@optimus.ietf.org>; Mon, 17 Sep 2001 18:06:30 -0400 (EDT)
Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22684 for <dhcwg@ietf.org>; Mon, 17 Sep 2001 18:06:29 -0400 (EDT)
Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f8HM5HQ18451 for <dhcwg@ietf.org>; Mon, 17 Sep 2001 17:05:17 -0500 (CDT)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f8HM5Hl03840 for <dhcwg@ietf.org>; Mon, 17 Sep 2001 17:05:17 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Mon Sep 17 17:05:17 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <P4M0NAND>; Mon, 17 Sep 2001 17:05:16 -0500
Message-ID: <66F66129A77AD411B76200508B65AC697B35E3@eambunt705.ena-east.ericsson.se>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: "'Erik Nordmark'" <Erik.Nordmark@eng.sun.com>
Cc: "'Artur Guja'" <skybird@3miasto.net>, dhcwg@ietf.org
Subject: RE: [dhcwg] Clarification necessary
Date: Mon, 17 Sep 2001 17:05:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13FC4.D398C930"
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

Hi:

As Artur already mentioned, when a node restarts it would likely assume it is perhaps no longer connected to the same link and take steps to "confirm" its addresses by multicasting the Confirm message. Server(s) will respond to this with an indication that the addresses are unacceptable (likely based on the prefixes) or acceptable (again based on the prefixes or because the server assigned those addresses). There may be several different levels of indications in each case - since a server that didn't assign the address might only be able to base its response on the prefixes and not the actual addresses.

A server that receives the Confirm and has a (perhaps "timed-out") Reconfigure-Init needed flag for that client (based on DUID) SHOULD then take steps to initiate the Reconfigure-Init.

My own personal view is that Confirm should not be used to assign new addresses or adjust lifetimes (or even T1/T2 renewal times). It should simply be used to confirm the validity of the addresses on that link. But I'm not sure that is WG consensus.

- Bernie Volz

-----Original Message-----
From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]
Sent: Monday, September 17, 2001 3:20 PM
To: Bernie Volz (EUD)
Cc: 'Artur Guja'; dhcwg@ietf.org
Subject: RE: [dhcwg] Clarification necessary



> 2) Should the client save its leases to a file or do they just go to
> the memory? IOW, are they lost upon reboot?
> 
> BV> A client SHOULD save them such that they survive reboots. This
> BV> is what many DHCPv4 clients already do so it really shouldn't be
> BV> such a big deal. Some of the revised text we're working on will
> BV> provide more clarification around this in cases where a client
> BV> has no permanent storage capabilities. Basically, an ADVERTISE
> BV> will be able to include other IAs for the client that the server
> BV> knows about and it is recommended that these types of clients
> BV> always use the same IA ID (such as 0).

Hmm, has there been any discussion what impact this will have on reconfigure
to do renumbering? I guess the same issue appears with DHCPv4 and its
new ability to do reconfigure.

At a minimum it might make sense to document that reconfigure might not
be able to reach nodes that are turned off but that those nodes
might retain the leases in stable storage.

  Erik