Subject: RE: DHCPv6 address model proposal...

From: Bernie Volz <[email-masked]>
Date: Sun, 24 Sep 2000 14:53:35 -0400

>> >So, that synchronization could be accomplished by requiring that
>> >the client send its version of the IA to the server, and the server
>> >could send back the changes
>
>> I believe, though perhaps more complicated, that this will be required.
>
>Why do you believe this?   I don't think this is required at all, and
>it does create a great deal of complexity, as well as making client
>packets a lot fatter.   Can you explain why you believe that this is
>necessary?
>
>			       _MelloN_

Ted:

I explained the need for this a few days ago ... you were the one that
suggested it! It has to do with the renewal time discussion - see the emails
below.

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Bernie Volz 
Sent: Thursday, September 21, 2000 10:09 PM
To: [email-masked]'
Subject: RE: renewal time

Ted:

The multiple server case is an interesting one to consider. I would assume
that the renewals and the like will go to the SAME server and therefore the
client's IA is really specific to that server. But, this does create an
interesting issue for renewals that are multicast (I'm lazy at the moment
and don't recall the exact "renewal" steps in DHCPv6, but I assume we're
allowing multicast at some time if the original server isn't responding).
And, also for any failover protocol (since the servers are different, though
they are cooperating). The failover "lazy update" approach may fail since if
the partner server gets a renewal before the original server updated it with
information, how will the partner know what addresses to give? Urgh!

This really does mean there is a reason for the client to send the list of
addresses on a renewal. This would give "other" servers a hint as to what
the client had and the server can determine "oh, those look like reasonable
addresses to me since they aren't in use (or in use by that client)".

Note also that even if the renewal is sent to the same server, it is always
possible that that server lost stable storage and thus there would be no
information on the server and it would assign new addresses (perhaps not the
same ones) unless the client also sent the addresses with the renewal.

So ... scrap my thought of saving bits and processing. 

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, September 21, 2000 9:34 PM
To: DHCPv6 discussion list
Subject: Re: renewal time

> I think this also means that there is no reason for the client to send the
> server the list of addresses it thinks are in the IA. Why waste the bits
on
> the wire and the server processing time when the server will tell the
client
> "here's the addresses associated with this IA" in the response anyway.

There is a reason: to preserve address stability.   But it's not a
very good reason, and I think that by default the client probably
shouldn't bother to tell the DHCP server what its old address was.
There's only one catch here: we have to be careful that the client
doesn't get its IA whacked around by two non-cooperating DHCP servers
on the same wire.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Sun, 24 Sep 2000 12:24:03 -0700

> suggested it! It has to do with the renewal time discussion - see the emails

No, I said that it might be *useful* on some occasions for the client
to send the address in as a hint to the server.  I do not believe that
it is *generally* useful.   I certainly don't think the protocol
should be based on the client always doing this.

I also brought up the problem that a client might lose all its
addresses because it connected with a different server on the same
wire.   Having the client say what addresses it has doesn't solve this
problem, though.

			       _MelloN_