Subject: RE: DHCPv6 address model proposal...

From: Bernie Volz <[email-masked]>
Date: Thu, 28 Sep 2000 21:46:29 -0400

> - the server retains state of all addresses handed to the client
>   and when one address is removed from the set the server
>   hands that back to the client with valid lifetime = 0
>   when the client renews. For reliability the server might need to
>   retain information about the invalidated address for some time
>   since the client might not receive the first reply that has lifetime =
0.

The server need not do this. The server can simply eliminate the address
from the client's set. The client can continue to use that address until the
lifetimes "expire" - just because it isn't in the server's response does not
mean that the address has expired.

Of course, you are correct if the server wants to immediately remove the
address from the client's set.

While I do understand the desire to reduce packet sizes and avoid
unnecessary data in packets, I am a bit uncomfortable with not having the
client supply the addresses. We have discussed this and I agree that in
almost all cases it isn't explicitly necessary. But it is a major shift from
what happens today in DHCPv4 and I just fear it may be a mistake. I also
think it benefits the server since it too can know what the client knows.

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Thursday, September 28, 2000 8:26 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...

Ted,

> No.  REBIND is when the client has already tried to renew the lease by
> contacting the server from which it got the lease using a unicast
> message.  Time is running out, so it decides to see if it can contact
> another server using multicast (broadcast in the DHCPv4 case).
> REBINDING and RENEWING are two distinct states, and REBINDING is
> specifically for cases where the old server can't be contacted.
> 
> I do not think it is necessary for the client to send an address list
> in the RENEWING case - only in the REBINDING case.

I agree for the purposes that has been currently discussed.

But not too long back we discussed whether the omission
of an address from an IAS when renewing was to be interpreted as
"invalidate any other address not returned by the server".
I might be wrong but I think I saw concensus not to treat a "missing"
address as a directive for the client to invalidate it.

Assuming I didn't miss anything, we have two choices dealing
with the server removing addresses/prefixes from use
(apart from explicit reconfigure of course):
 - the server retains state of all addresses handed to the client
   and when one address is removed from the set the server
   hands that back to the client with valid lifetime = 0
   when the client renews. For reliability the server might need to
   retain information about the invalidated address for some time
   since the client might not receive the first reply that has lifetime = 0.

 - require that the client include all addresses when renewing.
   if the server see one address that shouldn't be part of the set
   the reply will include that address with lifetime = 0.
   Nothing special needs to be done to get reliability here.

I might have missed this being discussed in the past.

   Erik

---

From: Ted Lemon <[email-masked]>
Date: Fri, 29 Sep 2000 11:49:42 -0700

> think it benefits the server since it too can know what the client knows.

Only if we make it mandatory that the client send this.   I don't
think we should.   We are saying that the client should send this
information when it's in the (currently nonexistant) REBINDING state.
However, if we only send it in that state we get a substantial space
savings - clients should never *get* into that state normally.   So I
think it's worth it.   I think you should have a strong reason to
argue otherwise.

			       _MelloN_