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
- [dhcwg] Last Call: 'A Guide to Implementing State… The IESG
- [dhcwg] Re: Last Call: 'A Guide to Implementing S… Pekka Savola
- Re: [dhcwg] Re: Last Call: 'A Guide to Implementi… Ralph Droms
- Re: [dhcwg] Re: Last Call: 'A Guide to Implementi… Pekka Savola
- Re: [dhcwg] Re: Last Call: 'A Guide to Implementi… Ralph Droms
- [dhcwg] Re: Last Call: 'A Guide to Implementing S… Tim Chown
- RE: [dhcwg] Re: Last Call: 'A Guide to Implementi… Bernie Volz
- Re: [dhcwg] Re: Last Call: 'A Guide to Implementi… Tim Chown
- Re: [dhcwg] Re: Last Call: 'A Guide to Implementi… Ralph Droms