Re: [dhcwg] dhc wg last call on dhcpv6-reconfigure-rebind

Shane Kerr <Shane_Kerr@isc.org> Tue, 06 March 2007 16:05 UTC

Return-path: <dhcwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOcAf-00068f-Sg; Tue, 06 Mar 2007 11:05:49 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOcAf-00068a-2r for dhcwg@ietf.org; Tue, 06 Mar 2007 11:05:49 -0500
Received: from mx.isc.org ([2001:4f8:0:2::1c]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOcAG-0003iU-K1 for dhcwg@ietf.org; Tue, 06 Mar 2007 11:05:49 -0500
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 46A7011401F; Tue, 6 Mar 2007 16:05:10 +0000 (UTC) (envelope-from Shane_Kerr@isc.org)
Received: from [199.6.1.234] (unknown [199.6.1.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 6DE34E60D9; Tue, 6 Mar 2007 16:05:09 +0000 (UTC) (envelope-from shane@isc.org)
Message-ID: <45ED9133.1080302@isc.org>
Date: Tue, 06 Mar 2007 17:05:07 +0100
From: Shane Kerr <Shane_Kerr@isc.org>
Organization: ISC
User-Agent: Thunderbird 1.5.0.10 (X11/20070304)
MIME-Version: 1.0
To: "Bernie Volz (volz)" <volz@cisco.com>
Subject: Re: [dhcwg] dhc wg last call on dhcpv6-reconfigure-rebind
References: <8E296595B6471A4689555D5D725EBB21037002AF@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: <8E296595B6471A4689555D5D725EBB21037002AF@xmb-rtp-20a.amer.cisco.com>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: dhcwg <dhcwg@ietf.org>
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: shane_kerr@isc.org
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
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>
Errors-To: dhcwg-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bernie Volz (volz) wrote:
> Since it looks like this draft will need a revision, might we also want
> to address the following issues?
> 
> 1. When should a Client send a Reconfigure Accept (and the server
> respond with Reconfigure Accept). RFC 3315 only mentions this for the
> Solicit/Advertise and Request/Reply exchanges. Not for a Renew or
> Rebind.
> 
> Should this be prohibited on a Renew/Rebind? Is it optional? If allowed,
> what should a client do if the client previously received a Reconfigure
> Accept (Request/Reply) but fails to in the Renew/Reply or Rebind/Reply
> exchange? Should it disable Reconfigure support?

In my mind the Reconfigure Accept is part of the lease. A server may require
clients use Reconfigure Accept or not issue a lease, for instance.

While the server could check the presence of this in Renew or Rebind messages, I
think it would be simpler to always omit the option, and use the value from the
original Reply.

This doesn't match what the table in 3315 says, because the table allows
Reconfigure Accept in Renew or Rebind. But if we allow it, we should make it
clear that the server has to re-evaluate the lease based on a possible change of
the Reconfigure Accept value.

> 2. The text in RFC 3315 isn't clear about when the server sends a
> Reconfigure Accept? In 18.2.1 (Receipt of Request Messages) in RFC 3315,
> is written:
>  
>     The server includes a Reconfigure Accept option if the server wants
>     to require that the client accept Reconfigure messages.
>  
> Does this apply even if the client has not sent a Reconfigure Accept
> option in the Request message? That seems likely to be useless since the
> client probably won't accept Reconfigure Accept (since if it did, it
> would have sent the option in the Request).
> 
> In a brief private exchange with Ralph, he thought that a qualifying
> clause is needed:
> 
>     The server includes a Reconfigure Accept option if the server wants
>     to require that the client accept Reconfigure messages, if the
> client
>     sent a Reconfigure Accept option in the Request.

Makes sense to me.

- --
Shane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF7ZEzMsfZxBO4kbQRAv7ZAKDtgsk79hV0yH83939oTsEEuvOj8QCg1Gp7
AIuB3YNhA8X8vwTb0F/V2r8=
=HzzE
-----END PGP SIGNATURE-----

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