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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 26 Jul 2001 16:21:56 -0500

Sorry ...

I do think that a simple ACK / NAK sequence would be best.

By NAK I assume we mean "NoPrefixMatch" type error.

By ACK I assume we mean "the prefixes you're using are valid for the link"
(no indication of whether the addresses themselves are).

I think that's all the Confirm needs to say since I believe all it was
intended to communicate was whether the client was still on the same
link.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 4:33 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Address lifetime extension and configuration changes in
response to Confirm (Was: RE: A few additional items re: -19 draft)

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?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Jul 2001 14:54:02 -0700

> intended to communicate was whether the client was still on the same

This sounds fine, but the present language for this message needs to
be clarified to make this more clear.

			       _MelloN_