Subject: RE: DHCPv6 address model proposal...

From: Bernie Volz <[email-masked]>
Date: Wed, 6 Sep 2000 18:31:17 -0400

I think this is just a difference of how you treat the data. I don't see why
allowing individual renewals is such a big deal - the DHCP server can find
the addresses either by looking for the requested addres. For renewals, that
seems most efficient for me.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 6:09 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...

Hm, I know I already replied to this, but I just reread it, so now I
have more opinions to generously share with you... :'}

> When a client needs to renew one or more addresses, it sends the address
> assignment ID and the list of addresses (which may be 1 to n). It need NOT
> renew all of the addresses at once (since they may each expire at
different
> times). Note that a request with the address assignment ID and 0 addresses
> means that the client doesn't know what addresses it has and thus the
server
> would send it *ALL* of the addresses it wants to allocate for that
client's
> address assignment ID.

This is how DHCPv6 works now, and I think it's too complicated.  I
think that all of the addresses in any given identity association
should be renewed at once.  I think it makes sense that the client
should be able to request a particular address (perhaps stripped of
its prefix), but this should just be advisory, and the server should
send back a renewal of all the addresses associated with that identity
association, not just those the client selected.  Otherwise I think
it's too complicated to implement, and it doesn't really add much
value - why is it useful for the client to renew out of sync?  Why
would the client know what it should renew and what it shouldn't?  It
might make sense for the client to drop the deprecated address once
all the connections on that address have been dropped, but since this
address is deprecated, I don't think there's any contention for it, so
it doesn't actually add any value to allow (and therefore require the
implementation of) this negotiation.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Wed, 06 Sep 2000 15:50:46 -0700

> seems most efficient for me.

If you provide a mechanism for allowing the client to renew individual
portions of the set of addresses provided for an identity association,
it complicates both the specification and the implementation.  The
server has to implement the case where it returns all the addresses
for an identity association.  Now you want to have a special case
where it returns some subset of that.  Why?  What does this buy us?
When are you going to have expiry times that vary in this way?

I would expect that the only time you'd give addresses different
expiry times would be when one or more addresses are deprecated -
those might expire early.  But you can't renew them - when they
expire, that's it - you're done with them.  So providing a mechanism
like this doesn't make any sense to me.  Can you come up with a
practical reason why we would want such a mechanism?

			       _MelloN_