RE: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard

"Bernie Volz" <volz@metrocast.net> Sat, 15 November 2003 17:49 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14062 for <dhcwg-archive@odin.ietf.org>; Sat, 15 Nov 2003 12:49:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL4Xo-0003HJ-WD for dhcwg-archive@odin.ietf.org; Sat, 15 Nov 2003 12:49:13 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAFHnCkn012602 for dhcwg-archive@odin.ietf.org; Sat, 15 Nov 2003 12:49:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL4Xo-0003HB-Ra for dhcwg-web-archive@optimus.ietf.org; Sat, 15 Nov 2003 12:49:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14029 for <dhcwg-web-archive@ietf.org>; Sat, 15 Nov 2003 12:48:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AL4Xl-0002pS-00 for dhcwg-web-archive@ietf.org; Sat, 15 Nov 2003 12:49:09 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AL4Xk-0002pO-00 for dhcwg-web-archive@ietf.org; Sat, 15 Nov 2003 12:49:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL4Xd-0003Ft-RE; Sat, 15 Nov 2003 12:49:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL4XF-0003FP-EN for dhcwg@optimus.ietf.org; Sat, 15 Nov 2003 12:48:37 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14015; Sat, 15 Nov 2003 12:48:21 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AL4XB-0002ow-00; Sat, 15 Nov 2003 12:48:33 -0500
Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AL4XA-0002ot-00; Sat, 15 Nov 2003 12:48:32 -0500
Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id hAFHmLGn043955; Sat, 15 Nov 2003 12:48:31 -0500 (EST) (envelope-from volz@metrocast.net)
From: Bernie Volz <volz@metrocast.net>
To: 'Tim Chown' <tjc@ecs.soton.ac.uk>, dhcwg@ietf.org, iesg@ietf.org
Subject: RE: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard
Date: Sat, 15 Nov 2003 12:48:23 -0500
Message-ID: <000001c3aba0$ade83820$6401a8c0@BVolz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <20031114160645.GE19013@login.ecs.soton.ac.uk>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: quoted-printable
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

DHCPv6 is no different from what we have with DHCPv4. DHCPINFORM in DHCPv4
has no "lease time" or "lifetime" for the parameters obtained. The implied
behavior for DHCPv4, as it should be for DHCPv6, is that when the address is
reassigned (through some other means), the client should naturally assume
that its current configuration parameters are suspect and hence send a new
DHCPINFORM (or DHCPv6 Information-Request).

There is no prohibition against a client issuing (DHCPv6)
Information-Request messages (or DHCPv4 DHCPINFORM) whenever it believes the
previously obtained configuration information may be out of date. Note also
that DHCPv6 servers may send Reconfigure messages as well (though
draft-ietf-dhc-dhcpv6-stateless-01.txt is silent as to whether stateless
clients support this).

When a client detects that it may be on a different network, whether that is
because it has detected a link state change (such as because the network
cable was reconnected), been powered on (such as from a standby state), or
has its address(es) reconfigured through some non-DHCP mechanism (perhaps
via router advertisements), it should take steps to validate its
configuration information.

We probably should have added to RFC 3315 a similar section for
Information-Request as exists for the stateful case (see section 18.1.2,
Creation and Transmission of Confirm Messages).

- Bernie

-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Tim
Chown
Sent: Friday, November 14, 2003 11:07 AM
To: dhcwg@ietf.org; iesg@ietf.org
Subject: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6
Service' to Proposed Standard

On Thu, Oct 30, 2003 at 05:57:10PM -0500, The IESG wrote:
> The IESG has received a request from the Dynamic Host Configuration WG to 
> consider the following document:
> 
> - 'A Guide to Implementing Stateless DHCPv6 Service'
>    <draft-ietf-dhc-dhcpv6-stateless-01.txt> as a Proposed Standard

Wrt recent exchanges on the dhcwg list, are we concerned that there is
no mechanism in stateless DHCPv6 for the DHCPv6 server to inform DHCPv6
clients of renumbering events to DNS or NTP servers (for example) where
the clients are using stateless autocinfiguration (RFC2462) for address
assignment and DHCPv6 (stateless) for options (DNS, NTP, ...).

If the clients use DHCPv6 for address assignment, the DHCPv6 server could
use its IP lease information to unicast the Reconfigure message, but in
a stateless-only DHCPv6 server this client information would presumably
not be available.

The current solution seems to be that clients must poll for changes, which
is not ideal, but which may suffice in some cases.

Tim

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




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