Subject: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation

From: Ole Troan <[email-masked]>
Date: Tue, 17 Sep 2002 17:46:27 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 18 Sep 2002 20:42:42 -0500

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:[email-masked]]
Sent: Wednesday, September 18, 2002 8:04 PM
To: Bernie Volz (EUD)
Cc: [email-masked]
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