RE: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation

"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Thu, 19 September 2002 01:50 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 VAA06940 for <dhcwg-archive@odin.ietf.org>; Wed, 18 Sep 2002 21:50:06 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8J1pUF25135 for dhcwg-archive@odin.ietf.org; Wed, 18 Sep 2002 21:51:30 -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 g8J1pUv25132 for <dhcwg-web-archive@optimus.ietf.org>; Wed, 18 Sep 2002 21:51:30 -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 VAA06931 for <dhcwg-web-archive@ietf.org>; Wed, 18 Sep 2002 21:49:35 -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 g8J1jMv24940; Wed, 18 Sep 2002 21:45: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 g8J1gqv24863 for <dhcwg@optimus.ietf.org>; Wed, 18 Sep 2002 21:42:52 -0400
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06733 for <dhcwg@ietf.org>; Wed, 18 Sep 2002 21:40:58 -0400 (EDT)
Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g8J1gij04236; Wed, 18 Sep 2002 20:42:44 -0500 (CDT)
Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g8J1ghK29240; Wed, 18 Sep 2002 20:42:44 -0500 (CDT)
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id <RZ9GJN3J>; Wed, 18 Sep 2002 20:42:43 -0500
Message-ID: <F9211EC7A7FED4119FD9005004A6C8700A474CE4@eamrcnt723.exu.ericsson.se>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: "'Ole Troan'" <ot@cisco.com>
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation
Date: Wed, 18 Sep 2002 20:42:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25F7D.D855EEBA"
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>

Ole:

CONFIRM is to confirm that the link is valid (or more clearly that the client is very
likely still connected (or not connected) to the same link it was on when it obtained
the address). Not that the entire configuration is valid. The assumption though is that
the configuration is valid as the client is still located where it was and the previous
lifetimes and renewal times can thus still apply.

Why do you need this to do more? If the addresses in the CONFIRM are valid, why would the
prefixes not be? We're not validating the lifetimes - just the prefixes for the addresses.

If prefix delegations are included (and the server supports prefixes), it may be able to
determine that these prefixes are valid "down the link" from which the CONFIRM came.
Probably more importantly, it can confirm if those are NOT valid. I assume that CONFIRMs
would always come from downstream routers? If a server receives the Confirm that doesn't
understand the prefix delegations, than it should only respond if it can Confirm the
prefixes for the addresses.

I do think we should add something to the CONFIRM text that says that if the server has no
options on which to base the confirmation, it must NOT reply. This case would handle the
situation where a server receives a CONFIRM but there are no options on which it can base
the decision. I think the existing text already accommodates this:
   If the server is unable to perform this test
   (for example, the server does not have information about prefixes on
   the link to which the client is connected), the server MUST NOT send
   a reply to the client.
However, it would be better to explain this just in case. Perhaps by replacing the above
text with:
   If the server is unable to perform this test
   (for example, the server does not have information about prefixes on
   the link to which the client is connected or there are no options in
   the CONFIRM for the server to test), the server MUST NOT send
   a reply to the client.

We've discussed what CONFIRM is for many times and I'd hate to reopen that discussion. By
adding the options, I fear that it will quickly be used to confirm more than whether the
client is on the correct link or not. For example, if the client sent a Domain Name option
but the Reply doesn't list that option, should the client consider the Confirm to have failed
to fully confirm its configuration. That is NOT what we wanted CONFIRM to do!

- Bernie

-----Original Message-----
From: Ole Troan [mailto:ot@cisco.com]
Sent: Wednesday, September 18, 2002 8:04 PM
To: Bernie Volz (EUD)
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation


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