RE: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation

["Bernie Volz (EUD)" <[e-mail]>]

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