RE: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation

Ole:

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.

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).

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.

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

- Bernie

-----Original Message-----
From: Ole Troan [mailto:ot@cisco.com]
Sent: Tuesday, September 17, 2002 12:46 PM
To: dhcwg@ietf.org
Subject: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation

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