Subject: RE: DHCPv6 address model proposal...

From: Bernie Volz <[email-masked]>
Date: Mon, 25 Sep 2000 17:38:56 -0400

Ted:

Your analysis I think covers the issue. The REBIND case is really the only
one. We have been taking about clients needing to "renew" the leases so
isn't that a REBIND?

If the client never goes back to the server to "renew" the addresses, then
we don't need to send them. And, agreed that we only need to send them in a
rebind case.

If a client has no addresses, it can't send them; I never expected them to
be sent in a SOLICIT.

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Monday, September 25, 2000 5:05 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...

> And, as DHCPv6 has similar goals and requirements (at
> least in my mind), I can't see how this fundamental issue should be
changed.

When the client is contacting a server with which it has an existing
collection of addresses for an identity association, it should not be
necessary for it to resend its current addresses.  And if it is only
using its current addresses as care-of addresses, likewise I think it
doesn't need to send it.  However, if we can get into something like a
REBINDING state, *then* it needs to send its current set of addresses,
so that the other server in a failover pair has the opportunity to
renew them.

I don't think it needs to send its addresses on startup - in the
DHCPsolicit message - because at that time presumably it does not have
any outstanding connections on addresses in the identity association,
so it has nothing to lose if the secondary gives it a different
address.

So I see only one case where this is important: REBIND.   And the
current draft doesn't do REBIND.   I think it should do REBIND, and
when it does, I think the REBIND request should include a list of
addresses.   Would that satisfy your concern?   If we conclude that we
*don't* need REBIND, do you think there is a case where the client
still needs to send its current address list?

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Sep 2000 15:38:40 -0700

> The REBIND case is really the only one. We have been taking about
> clients needing to "renew" the leases so isn't that a REBIND?

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.

			       _MelloN_

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 28 Sep 2000 17:26:05 -0700 (PDT)

Ted,

> 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:46:52 -0700

>    Nothing special needs to be done to get reliability here.

I think this is a valid summary, and your list of choices is correct.
I think given that the fact of the client receiving an IA that doesn't
contain a still-valid address does not invalidate the address, we have
to do the first of your two choices.   This is why I was arguing
against this.   But I think the reason for doing it this way is
stronger than the reason for doing it the other way, so I'm not
arguing that point anymore.

			       _MelloN_