Subject: Address lifetime extension and configuration changes in response to Confirm (Was: RE: A few additional items re: -19 draft)

From: Ralph Droms <[email-masked]>
Date: Thu, 26 Jul 2001 16:33:25 -0400

Bernie, you don't explicitly react to my proposal that the Reply to a 
Confirm should be a simple ACK/NAK.  I infer that since you argue against 
even a simple address lifetime extension, you support the ACK/NAK 
model.  Does my inference correctly reflect your opinion?

- Ralph

At 03:01 PM 7/26/2001 -0500, Bernie Volz (EUD) wrote:

> >There's no need to include a definition in section 14 as well.
>
>Great. Guess I didn't do a throughout enough saerch. Removing redundancy
>(especially when conflicting) is good.
>
> >Perhaps we might allow extension of address lifetimes, as this has been
> >shown to work among multiple servers with DHCPv4 failover...
>
>Hum ...
>
>Failover servers are kind of special since they generally share information.
>
>But consider if you have multiple servers that don't communicate with each
>other (and have the protections of the failover protocol), then you can't
>allow one to extend the lifetimes since the original server never learns of
>the extension and would potentially "reclaim" the addresses.
>
>So, I would say that only the server that gave out the addresses in the
>first place can extend them on a Confirm. Future extensions to DHCPv6 or
>special server-to-server communication protocols could alter this behavior
>in the future.
>
>Also, if you did allow *ANY* server to extend the lifetimes on a Confirm,
>does that mean the client should communicate with that new server when it
>is time to Renew? Or should it go back to "old" server (that gave it the
>addresses on a Request or previously Renewed)?
>
>- Bernie
>
>-----Original Message-----
>From: Ralph Droms [<mailto:[email-masked]>mailto:[email-masked]]
>Sent: Thursday, July 26, 2001 3:31 PM
>To: DHCPv6 discussion list
>Cc: DHCPv6 discussion list
>Subject: Re: A few additional items re: -19 draft
>
>At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote:
>
> >- For the Confirm message, Section 14. states:
> >
> >Confirm Confirm the validity of assigned addresses and other
> >        configuration changes through the server from which the
> >        configuration information was obtained when the client's
> >        assigned addresses may not be valid; for example, when
> >        the client reboots or loses its connection to a link
>
>Turns out you've pointed out redundant and conflicting text in -19.  DHCPv6
>messages are defined in section 7 and each definition includes a short
>description.  There's no need to include a definition in section 14 as well.
>
>Here's the text from section 7:
>
>        CONFIRM (4)          The DHCP Confirm (or Confirm) message is used
>                             by clients to confirm that the addresses
>                             assigned to an IA and the lifetimes for
>                             those addresses, as well as the current
>                             configuration parameters assigned by the
>                             server to the client are still valid.
>
>Perhaps the easiest thing to do would be to constrain the Reply to a
>Confirm to be a binary response: ACK implies everything OK (no changes from
>the server; everything from the client used as currently known to the
>client); NAK implies client does a Request.  Otherwise, we might get
>conflicting responses from multiple, non-coordinating servers, as you point
>out:
>
> >We probably need to clarify the behavior somewhat. For example,
> >if a server that did not give out the addresses responds, can
> >it:
> >- Allocate additional addresses (to the IA)?
> >- Extend the lifetimes of existing addresses?
> >- Change/respond with configuration parameters?
>
>Perhaps we might allow extension of address lifetimes, as this has been
>shown to work among multiple servers with DHCPv4 failover...
>
> >If the client does request (and supply) other options, what
> >happens if the server's reply does not include those options
> >(perhaps because the server doesn't feel it can supply them).
> >
> >I guess what I'm suggesting is that we indicate that allocation
> >of addresses and supplying configuration parameters with a
> >Confirm are problematic. And, that a client MUST NOT assume
> >that the lack of a configuration parameter (option) means
> >that the previous value for that option should be removed.
> >
> >Similar behavior might be required for Rebind - as multiple
> >servers may respond? Though I think there are fewer issues
> >here.
> >
> >Perhaps we should stress that Confirm SHOULD (MUST) only be
> >used to confirm whether addresses are valid and SHOULD NOT
> >(MUST NOT) be used in place of a Renew/Rebind?? Perhaps we
> >should even specifically state that clients MUST NOT apply
> >changes to the lifetimes or addition of new addresses received
> >in a Reply to a Confirm?