Subject: RE: DHCPv6 address model proposal...

From: "Pouffary, Yanick" <[email-masked]>
Date: Fri, 15 Sep 2000 09:55:02 +0200

Jim I thought you were going to sleep :-)

Yanick

		-----Original Message-----
		From:	Bound, Jim 
		Sent:	Friday, September 15, 2000 09:26
		To:	DHCPv6 discussion list
		Subject:	Re: DHCPv6 address model proposal... 

		>> We don't want the identity assoication expiring before
address
		>> lifetimes that will cause big problems.

		>It's not an expiry time.  It's a renewal time.  This allows
us to
		>renew all addresses in an identity association at the same
time,
		>rather than having each address's renewal come at a
different time.
		>The addresses do not expire until their lifetimes expire.

		Ah then I don't agree with where you headed.  

		>> All but one valid lifetime for one address are 10 hours.
But this one
		>> address is 1 hour.   I don't think the client should have
to send all 4
		>> addreses across the wire to get one either more time or
not more time.

		>Yes, this could result in more bits passing across the wire
in cases
		>where the disparity between renewal times is very large.
But it would
		>result in the same number of packets, so this would matter
only in a
		>context where indivual bits in a packet really count.  And
I think
		>this is actually a very unlikely scenario - can you come up
with a
		>reason why the lifetimes would be so different?

		I was not concerned about the bits but the clients
performance to update
		one address.  

		One address is global, one is site-local, and one is
organizational.
		Each have different thresholds.  Each have different times.
		I would think the global would have less, and site the most
time.

		Also in IPv6 we do not make any assumptions about the times
thus far and
		treat them and their lifetimes as individual datums not as a
group.
		For that reason they can renew or release at any time.

		Why do you think they would all be the same time?

		>Anyway, in this case, 3Xk is greater than 2X, so address B
will expire
		>before the client renews, which probably isn't what you
want - you
		>want to renew address B *before* it expires.  So the
renewal time has
		>to be 2Xk, not 3Xk.

		>> >Installs timeout at 2Xk to send a new DHCP Request.
		>> >Installs timeout at X to delete address A
		>> >Installs timeout at 2X to delete address B
		>> >Installs timeout at 3X to delete address C
		>> 
		>> I don't think 3X should be running during renewal state.
		>> 
		>> I also think X should not have to wait for Request at
renewal state.
		>> But that implies we need more discussion for IA if it
changes.

		>All of the above timeouts are installed at the same time.

		I know that and have implemented stateless this way too.

		>> I don't agree with this.  What if the server is providing
A as the nodes
		>> global address to reach the Intratnet to the Internet and
the others are
		>> site local addresses.  The server wants the client to
check back in for
		>> global addresses not loose them after getting them once.

		>The scenario here is that address A is deprecated, and will
not be
		>renewed.   If address A is not deprecated, then it will be
counted by
		>the server in determining the renewal time, and so the
renewal time
		>will be Xk, not 2Xk.

		Oh so in the reply (and I asked that) you were telling the
client the
		address was deprecated, but they have X time left?

		How will the client know its deprecated?  

		>> Address A
		>>    at 80% Y
		>>    if A will not be RELEASED by Client (mobile node
decision)
		>>                                        (for handoff as
example using
		>>                                         lazy cell
evaluation)
		>>       REQUEST address A again

		>Address A is deprecated, meaning that the server will not
extend it,
		>so a request at this time would be met with a renewal for
20% Y, and
		>then the new renewal time would be 80% of that, and you'd
quickly get
		>down to really short renewal times.

		Ah Ha..we are not using terms the same way I don't think.  I
am using
		and DHCPv6 uses the term deprecated as defined in 2462.

		Deprecated means that the preferred timer has went off but
the valid
		timer is still ticking.  So a telnet connection will
continue in the
		deprecated state until the valid lifetime goes off so before
that
		happens go get more time.

		What I am proposing is something Thomas Narten wanted.

		When the preferred timer is 80% till expiration go request
new times or
		another address from the server.

		>You also say above "mobile node decision."   This implies
that you
		>think the mobile node is going to decide which addresses in
an
		>identity association to renew, and which not to.  I don't
see how that
		>can work.   Can you clarify what you intend here?

		Sure.  The mobile node has an IPv6 address it can use in a
particular
		routing realm as its roaming.  It will know as it roams it
is moving to
		a new routing realm.  The prefix of the routing realm
changes and it
		knows it has to use a new address to communicate in the new
routing
		realm or in wireless terms cell with new Base Station.

		>Finally, in your scenario the client is sending three
seperate
		>renewals per identity association rather than one.   This
will consume
		>more bandwidth in most cases, not less.   There should be a
good
		>reason for splitting things out this way.   I'm not seeing
the reason
		>why this is the right thing to do.

		That was to depict that even though three separate messages
were used
		the same server code works.  The client would only send them
as
		addresses expires or are deprecated.  Depending on the lease
for each
		address these may get sent four hours apart as one example.

		But also under your model the client cannot renew lets say
their global
		address until the renewal timer goes off which is based on
the
		site-local address as 2X as an example.  The client has to
wait 2X
		before it can ask for a new lease or address for global
communications.

		I believe the trade-off to permit the client to update
individual
		address lifetimes if the server permits it is worth it for
the case wher
		the client needs to update the lease even though their
renewal has not
		gone off.

		>> Note I think the IA needs its own message type too to
negotiate a new
		>> IA with the Server as it changes the bindings at the
server and I assume
		>> the security keys.

		>The identity association is something the client declares.
There is
		>no negotiation.  To the server, it is simply a
client-supplied
		>identifier with some structure that lets you compare two
different
		>identifiers to see if they're from the same client.

		How does the server do garbage collection then of IAs that
are defunct
		for some reason?  I don't want them sitting around in my
database or
		however I choose to implement the server config database?

		In the current dhcpv6 model if the client releases the
address the
		binding also can be released by the implementation.  I think
we need
		some means to do that with the IA too.

		The implementation reason is the same reason we balance
binary trees
		every now and then it reduces the search for the client when
it comes to
		the server.

		regards,
		/jim

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Sep 2000 01:07:04 -0700

It's only four in the morning, and Jim's espresso machine still has
beans in it, so the night is young.  :')   However, I should go to bed
and stop keeping Jim awake...

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Fri, 15 Sep 2000 15:19:39 -0400

>and stop keeping Jim awake...

Well I did get about 5 hours in.  And yep had that expresso machine out
again....But seriously its very good to keep this debate going now if
the editors are to get this next rev out per the schedule but I think we
are slipping.

/jim

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Sep 2000 13:21:20 -0700

> the editors are to get this next rev out per the schedule but I think we

Yup.

			       _MelloN_