[dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation

Ole Troan <ot@cisco.com> Tue, 17 September 2002 16:55 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21624 for <dhcwg-archive@odin.ietf.org>; Tue, 17 Sep 2002 12:55:30 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8HGuoP26679 for dhcwg-archive@odin.ietf.org; Tue, 17 Sep 2002 12:56:50 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HGuov26676 for <dhcwg-web-archive@optimus.ietf.org>; Tue, 17 Sep 2002 12:56:50 -0400
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21603 for <dhcwg-web-archive@ietf.org>; Tue, 17 Sep 2002 12:54:59 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HGmkv26334; Tue, 17 Sep 2002 12:48:47 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HGl2v26042 for <dhcwg@optimus.ietf.org>; Tue, 17 Sep 2002 12:47:02 -0400
Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21273 for <dhcwg@ietf.org>; Tue, 17 Sep 2002 12:45:11 -0400 (EDT)
Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA27561; Tue, 17 Sep 2002 17:46:27 +0100 (BST)
X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f
To: dhcwg@ietf.org
From: Ole Troan <ot@cisco.com>
Date: Tue, 17 Sep 2002 17:46:27 +0100
Message-ID: <7t5fzw8k1i4.fsf@mrwint.cisco.com>
Lines: 51
User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (sparc-sun-solaris2.8)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation
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: 8bit
Content-Transfer-Encoding: 8bit

I'm working on the next draft of DHCPv6 Prefix Delegation. I'm trying
to avoid having to specify client/server behaviour for each type of
message exchange in the PD document. Unfortunately the base DHCPv6
specification is very IA centric with regards to all statefull message
exchanges. It would been a lot easier to add new "statefull" options
if the base spec specified the message exchange in a generic way, and
specified the IA option only in the options section. well, well, I
guess it is a bit late now.

a question on Confirm behaviour.

draft-ietf-dhc-dhcpv6-26.txt says:
«18.2.2. Receipt of Confirm messages

   When the server receives a Confirm message, the server determines
   if the addresses in the Confirm message are appropriate to the
   link to which the client is attached.  The server ignores the T1
   and T2 fields in the IA options and the preferred-lifetime and
   valid-lifetime fields in the IA Address options.

   If all of the addresses in the Confirm message pass this test, the
   server returns a status of Success.  If any of the addresses do not
   pass this test, the server returns a status of NotOnLink.

   If the server does not find any addresses that are not appropriate to
   the link to which the client is connected, but cannot determine if
   some of the addresses are appropriate to the link or not appropriate
   to the link, the server MUST NOT send a reply to the client.  For
   example, if the server does not have information about prefixes on
   the link to which the client is connected, the server does not reply.»



from my understanding of the above, a server is allowed to reply to a
confirm even if it does not have a binding for the client.
what is the reason for not requiring that only the server with the
binding can reply to the Confirm message?

in the case of Prefix Delegation, I'm not sure it makes sense to have
servers without the binding replying. if a client has a binding
including both IA and PD options. there are two DHCP servers, one
which doesn't support PD. how should the client behave when sending a
Confirm, as it could get a reply from the non-PD server. as far as I
can tell there is no way for the client to identify which options the
server has confirmed(?). the client can ignore all replies from
servers which do not match the server-ID of course.

I would really like to avoid different behaviour for the basic message
exchanges, dependent on IA or PD.

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