Subject: RE: renewal time

From: Bernie Volz <[email-masked]>
Date: Thu, 21 Sep 2000 22:08:45 -0400

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_