Re: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation

Ole Troan <ot@cisco.com> Thu, 19 September 2002 00:13 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 UAA04394 for <dhcwg-archive@odin.ietf.org>; Wed, 18 Sep 2002 20:13:57 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8J0FMm20728 for dhcwg-archive@odin.ietf.org; Wed, 18 Sep 2002 20:15:22 -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 g8J0FMv20725 for <dhcwg-web-archive@optimus.ietf.org>; Wed, 18 Sep 2002 20:15:22 -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 UAA04390 for <dhcwg-web-archive@ietf.org>; Wed, 18 Sep 2002 20:13:27 -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 g8J08Jv20516; Wed, 18 Sep 2002 20:08:19 -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 g8J04Nv19894 for <dhcwg@optimus.ietf.org>; Wed, 18 Sep 2002 20:04:23 -0400
Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04185 for <dhcwg@ietf.org>; Wed, 18 Sep 2002 20:02:28 -0400 (EDT)
Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id BAA18142; Thu, 19 Sep 2002 01:03:44 +0100 (BST)
X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation
References: <F9211EC7A7FED4119FD9005004A6C8700A474CB5@eamrcnt723.exu.ericsson.se>
From: Ole Troan <ot@cisco.com>
Date: Thu, 19 Sep 2002 01:03:43 +0100
In-Reply-To: <F9211EC7A7FED4119FD9005004A6C8700A474CB5@eamrcnt723.exu.ericsson.se> ("Bernie Volz's message of "Tue, 17 Sep 2002 12:59:46 -0500")
Message-ID: <7t57khi3kww.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=us-ascii
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>

Bernie,

> There are actually three "responses" from a server:
> - Respond with a Reply indicating success.
> - Respond with a Reply indicating failure.
> - Don't respond (if the data can not be confirmed).
>
> Now, if a CONFIRM includes options a server does not know about
> (because they are new since the server was implemented), it will
> ignore these new options. And it would then base its action on the
> remaining options.
>
> In the case where there are no remaining IA options that clearly define whether the client is on the correct link, the server should NOT respond.
>
> Otherwise, the server should be able to respond.

will the server include the options it confirms in the REPLY? this is
not clear to me from reading the spec. for both PD and IA to be
confirmed independently it must.

> Please note that the CONFIRM is not "confirm all configuration
> parameters" ... it is confirm that the link is still valid. It is
> there only to help the client figure out if it can continue to use
> the configuration parameters it has (because it is still on the same
> link).

I think CONFIRM is specified in a too restrictive way. I would like it
to be useful for any statefull option.

> Should CONFIRM be used to with prefixes? I guess they could be since
> they define the link. But if only prefixes are present, any server
> that hasn't implemented prefix delegation would not be able to
> respond.

I don't think it can be used as it currently stands. a DHCP server has
no notion of a "onlink" property of a delegated prefix. prefixes are
typically delegated to a site, not to a link.

> BTW, the above description is also why ANY server *can* respond if
> the IA information available is unique enough.

right. if the REPLY to the CONFIRM includes which options are
confirmed, and the client side text also states that the options have
to be parsed in addition to checking the status code, it should
work.

then we can add additional text in the PD document to make the client
retry CONFIRMs until all options are accounted for.

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