Subject: DHCPv6 address model proposal...

From: Ted Lemon <[email-masked]>
Date: Wed, 06 Sep 2000 00:29:41 -0700

We talked a bit about the DHCPv6 address model at the end of the
conference call, and I think we sort of all knew what we were talking
about, but it's not entirely clear.  I think there are two aspects to
this: to what form of identification are addresses bound, what sort of
address requests are permissible, and who decides what to do?

I think there are actually only two questions a client ever needs to
ask the server: "please associate an IP address with this identity,"
and "please renew the association for this identity."   In the current
DHCPv6 model, "this identity" is the local link address, although
there are limitations to this model that need to be discussed
seperately.   Anyway, I'm going to call the association between a
client-supplied identity and the client's IP address an "identity
association."

One complication with IPv6 is that globally-routable addresses can
have prefixes that change over time.   DHCPv6 seems to need a
mechanism to support this.   When the DHCP server is asked to renew an
association with a given identity, it may be that there is an old
prefix that is still usable but deprecated, that the DHCP server
should renew for the client just in case the client is still using it,
and there may also be a new prefix that the client should be told to
use for all new connections.   The time when the leases on each of
these addresses expires may be different - the deprecated address may
not be valid for the full duration of the lease on the recommended
address.

It's hard to solve this problem in a way that isn't really hairy.   I
know this from trying to state a solution, and also from having
watched the draft authors and the WG chair wrestle with this issue in
the past.   I don't have a trivially simple model to propose.   What I
will propose is this:

Each identity association can have more than one IP address associated
with it, but except for the deprecated/non-deprecated status of these
IP addresses, all of the IP addresses are semantically equivalent.
Each address, recommended or deprecated, comes with an individual
lease.  The identity association comes with a seperate renewal time.
It's possible for any address in an identity association to expire
before the renewal time on that association, and it's very likely that
a deprecated address would expire before this renewal time, and very
unlikely that a recommended address would.

The server tells the client what addresses it has for an identity
association - the client can't say "I'd like three".  This choice is
based strictly on the network topology - the server is not giving the
client three addresses to do three different things with.

If the client wants to have IP addresses that have different meanings,
it generates more than one identity.  That is, if the client wants to
be able to listen on one IP address and provide service for
www.arf.org, and on another IP address and provide service for
www.blaznorf.edu, it creates two seperate identities, and it maintains
completely seperate state machines for two seperate identity
associations.  The server doesn't need to know that the two identities
are related, although we may want to make it *possible* for the server
to know that they are related.

There is also the question of when the client can ask for addresses.
I think the answer is "anytime".  It should be possible to fork a new
identity association at the request of an application, and to get rid
of it later at the request of the application.   It should be possible
for the DHCP client to generate an identity association for each
network interface at boot time.   I don't think we need to specify
this, other than to say "the client gets to decide when it does this."

As to the question of synchronization between identity associations, I
don't think it's possible, although it's a seductive idea.  I think
the DHCP client should send seperate packets for each identity
association.  We could make it optionally possible to combine requests
on behalf of more than one identity association, but I think this
costs us some complexity and I can't see any way that it helps us,
beyond perhaps the initial packet requesting addresses for each
identity association.   It would be nice if the DHCP server could
present a uniform set of extensions that is consistent across identity
associations, but I don't see any way to specify this that is helpful
- I think this is a topic for future research.

One interesting fallout from having a renewal time on the identity
association rather than on the address is that it means that the
server can respond with zero IP addresses and a renewal time, forcing
the client to wait some period of time without getting an IP address,
and then try again.   I don't know if we care about this - it's just
something that occurred to me.   We have talked about similar
functionality for DHCPv4 in the past, but I don't get the impression
that everybody thinks this is a good idea.

So I have two questions: first, does this presentation make sense, or
have I left out things that are obvious to me but not to the reader.
Second, if it makes sense, is it the right thing to do?   What do we
need to change?

			       _MelloN_

---

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

Ted:

I think you almost have it.

I was thinking more of a model that would have the client/server maintain
lists that have three main entries - the address assignment ID, the address,
and the expiration time.

When a client requests [new] address(es) it sends a request with an address
assignment ID (we may allow it to be absent or "null"). It is assigned any
number of addresses (0 to n). Each of these addresses may expire at
different times.

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.

Bookkeeping is rather simple - when an address expires, that entry is
removed.

A client MAY also renew each address (even if multiple ones use the same
address assignment ID) individually.

I also think that a client should be able to ask for "specific" addresses.
The way it does this is that is supplies the "address" option but provides
an INCOMPLETE address (for IPv6, this is one with a prefix length of less
than 128; for IPv4, this is one with a mask length of less than 32?). Since
these are incomplete addresses, the server knows that this is a "subnet
selection" type request and can supply those addresses (if available to the
client); the server MAY supply any number of other addresses it deems the
client should have.

I also believe that we should have a "magic" address assignment ID such that
a server knows that this is the "basic" set of addresses for the client.
This could be the "null" (or absent) address assignment ID. I think this has
value in that a server may want to know to give out single addresses for
non-"magic" address assignment IDs since these are likely for application
specific purposes and thus a single address likely suffices. I'm not
suggesting that we require this; just that it would be helpful for the
client and server to agree on what is a "basic" address request.

I agree with you that a request should be simple and we should not allow a
request to include multiple address assignment IDs. Otherwise, the
processing at the server becomes rather complex. And, a request should
either renew one or more addresses or request "new" addresses, not both.

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 3:30 AM
To: DHCPv6 discussion list
Subject: DHCPv6 address model proposal...

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Wed, 06 Sep 2000 13:33:11 -0700

> client); the server MAY supply any number of other addresses it deems the

Hm.   Missed this part.   I agree that this makes sense, although I
don't grok IPv6 addressing well enough to understand exactly how this
would work.   Jim asked us to contribute actual verbiage for any
changes we want to the current spec, so I'm expecting to contribute
verbiage for the address model proposal, but I don't feel confident
that I could word this part correctly.   Could you do that?

> client and server to agree on what is a "basic" address request.

I'm afraid I don't know what you mean by a "basic" address request.
Can you expand on this?

> A request should either renew one or more addresses or request "new"
> addresses, not both.

Good point.   However, I'm not sure we actually need to add anything
to support this - really, if you want a "new" address, you're
generating a new identity association.   So the server will have to
allocate it a new address, because it never previously allocated it an
address.   If you have an old identity association, that fact in
itself means you're hoping to get back an old address, doesn't it?
Do we need to make an explicit distinction here between "new" and
"renew"?

			       _MelloN_

---

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

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

> would send it *ALL* of the addresses it wants to allocate for that client's

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: Jim Bound <[email-masked]>
Date: Thu, 07 Sep 2000 01:17:55 -0400

Ted,

>to know that they are related.

It is imperative IMO that we make it so the server can know that a
client "set" of identities applies to a client interface on the link.
The reason is an implementation one.  I want to be able to reduce my
search tree for clients on the same link and interface for admin reasons
too.

Soooo.. I think part of the client identifier should include a set of
bits that identify the interface too.  Right now the identifier is a
link-local address and 128bits.  I am sure we can do this in 64bits but
I don't trust 32bits.  But that is details.  What I would like is to
have a "set" part in the identifier.

I also think this can reduce the state machine complexity at the client
implementation.  A client identity for the same interfaces if known will
make the code base for IPv6 base reqs much easier to be managed and
perform better.

>this, other than to say "the client gets to decide when it does this."

Just a nit.  It don't have to be a fork could be an asynch op or thread.
The input to the client dhcpv6 mod will have to apply to an interface
though as more reason to make a set within the identifier.

>- I think this is a topic for future research.

I think if we add a set section of bits we can head in the right
direction.

>that everybody thinks this is a good idea.

I think its a fine idea as long as the adherence to the reqs for Ipv6
addresses in stateless addrconf applies to dhcpv6 too.  

One of the implementation reqs for dhcpv6 is to not break the if6_net
(new ifnet for IPv6) on an IPv6 implementation.  But I don't think it
matters if we renew valid and preferred lifetimes (this is far different
than dhcpv4 nomenclature too and we have to use it) for the addresses a
client identifier.

I also think with the set bits above we could kill all addresses still
on an interface on a link too.  Net admins will not want to send out 3
messages to 3 different identitity associations to stop address use on a
client that has an interface it want to kill.

>Second, if it makes sense, is it the right thing to do?   What do we

I would like to explore during the design of the identifier the ability
to clump if you will a set of bits in the identifiers that make it known
that its from the same client interface.

But I do like this model.

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 07 Sep 2000 01:55:38 -0400

Ted,

>Do we need to make an explicit distinction here between "new" and

This I think must be an idempotent semantic to the server and how it is
in dhcpv6 since we removed the xid stuff.  The client should not have to
do anything special or understand this with your proposed model.  An
identity association will only ever get x number of addresses for a
specific instance of the UUID with the modifiers:

  Interface           Instance            Identifier
    1                   1                  glok-glok-clump
    1                   2                  glok-glok-clump
    2                   1                  glok-glok-clump

Interface 1 Instance 1 will get x addresses
Interface 1 Instance 2 will get x addresses (client wanted more addresses for
                                 another URL like your example in
                                 your kick-off thread on this topic)

[I don't like zero to represent interfaces or instances also I liked
your three-tuple approach to identification and I think Bernie did to as
his respond had 3-tuple also]

Once the server gives Interface 1 Instance 1 a set of addresses and the 
client comes back its either asking for a renewal or releasing them.

This also I think addresses Ralphs concern about the multiple address
model being different than DHCPv4.  We keep the good implementation
knowledge of a finite set address model from DHCPv4, but permit with the
Interface+Instance+UUID model the ability to do what Charlie wants with
minimal work to the spec and I think a much clearer implementation
model.  As captain kirk stated we would have a win-win scenario and we
can declare victory as a WG and move on.

If we can also define this UUID beast.

p.s. Also you should re-suggest your clump idea to send these addresses
back and forth at the appropriate time you hinted at in the design team.

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 07 Sep 2000 02:21:50 -0400

Ted,

>implementation of) this negotiation.

Also why would a server give one valid / preferred time to one
address and not the other?  I can see it happening but why?

But then lets suppose an admin says this client gets three addresses for
this Interface+Instance+UUID.  But one of them I want to renew with me
cause the prefix is a "special" thing?  Then we do have the situation
where renewing all of them is a waste of client and server processing.

We need to consider this carefully.

But it is still not like dhcpv6.  The difference is that this model has
finite set of addresses for a specific client UUID not variable.
So it is very managable.

regards,
/jim

---

From: Ralph Droms <[email-masked]>
Date: Thu, 14 Sep 2000 12:52:12 -0400

> >Do we need to make an explicit distinction here between "new" and

Well, suppose the client has just a single request it can make of the 
server: here's an identity association (IA) identifier - tell me the IP 
addresses (and associated lease lengths) associated with this IA.

If the server has no record of the IA (a "new" request), it assigns some 
addresses and returns them to the client.  If the server has previously 
assigned addresses to the IA, it simply returns those addresses, with 
(potentially) new lease lengths.  If the state of the IA has changed - 
e.g., some of the previously assigned addresses are no longer valid - the 
server returns the *current* addresses.

This strategy addresses the idempotency/identification problem with the 
explicit IA identifier, which gives the server a way to differentiate 
between successive requests for the same IA (address) or different IAs.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 14 Sep 2000 13:09:14 -0400

I've finally had a chance to catch up on the DHCPv6 discussion threads.  My 
wife was ill and then in the hospital for a week, so I'm *way* behind on my 
e-mail...

Let me see if I have Ted's model - as amended by Bernie and Jim - right...

The basic unit of address allocation is the "identity association" 
(IA).  An IA has:

* a unique identifier
* one or more associated IP addresses
* a renewal time

Each IA is managed independently by the server and a client.  A client may 
be an OS or an application and there may be multiple DHCP clients within a 
single physical box.

Servers control the IAs.  That is, a server determines the addresses 
associated with an IA, perhaps based on hints from the client.  In 
particular, the client does not get to "ask for three addresses".  I also 
infer that the client does not get to ask for more addresses to be 
associated with an existing IA.

IA identifiers may be structured to express a relationship between 
clients.  E.g., identifiers from clients on the same computer might share a 
common prefix.

A client can make two requests to a server about an IA:

* Associate some IP addresses with this IA
* Renew this IA

The IP addresses associated with an IA have independent leases, which are 
also independent of the IA renewal time.  Renewing an IA is independent of 
extending the leases on the IP addresses associated with an IA.

Jim noted that "leases" may not be appropriate for IPv6 addresses, as an 
IPv6 address is either valid or invalid.  While valid, an address may be 
preferred or deprecated.  From RFC 2462, "IPv6 Stateless Address 
Autoconfiguration":

    IPv6 addresses are leased to an interface for a fixed (possibly
    infinite) length of time. Each address has an associated lifetime
    that indicates how long the address is bound to an interface. When a
    lifetime expires, the binding (and address) become invalid and the
    address may be reassigned to another interface elsewhere in the
    Internet. To handle the expiration of address bindings gracefully, an
    address goes through two distinct phases while assigned to an
    interface. Initially, an address is "preferred", meaning that its use
    in arbitrary communication is unrestricted. Later, an address becomes
    "deprecated" in anticipation that its current interface binding will
    become invalid.

So, RFC 2462 talks both about leasing and so should DHCP...

In any event, does this summary capture the consensus on the address model?

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Sep 2000 11:14:20 -0700

> server returns the *current* addresses.

Right, that's what I had in mind too.   :')

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Sep 2000 11:16:23 -0700

> * Associate some IP addresses with this IA

I thought we figured out that these were both the same request!   :'}
Or is the distinction that the latter case it may include some
addresses as a suggestion to the server, whereas in the former case it
will never do this?

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Thu, 14 Sep 2000 14:45:58 -0400

I took this from your original message:

>and "please renew the association for this identity."

We might have figured out the are both the same request in another message 
- I skimmed through all the messages pretty quickly and may have missed 

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 14 Sep 2000 14:48:27 -0400

>Right, that's what I had in mind too.   :')

Looks like our e-mail is crossing in flight and we're having a time-delayed 
agreement...

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Sep 2000 11:51:02 -0700

> it.  In fact, I made a similar suggestion in another message:

Right, that's where I took the agreement from.  Maybe I hadn't agreed
to this before, though... :'}

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Sep 2000 11:51:33 -0700

> Looks like our e-mail is crossing in flight and we're having a time-delayed 

I think you're right.   :')   I should be slower off the mark, I guess.

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Thu, 14 Sep 2000 15:13:51 -0400

>to this before, though... :'}

Ah - I had just made that as an off-hand observation.  I had no idea 
someone actually agreed with me.

Perhaps it comes from spending so much time one-on-one with my kids over 
the last week or two.  They *never* agree with me...

- Ralph

---

From: Bernie Volz <[email-masked]>
Date: Thu, 14 Sep 2000 15:47:13 -0400

Opps ... I should have read the longer email first. In that message, Ralph
indicates that each address has its own lifetimes.

-----Original Message-----
From: Bernie Volz [mailto:[email-masked]]
Sent: Thursday, September 14, 2000 3:31 PM
To: DHCPv6 discussion list
Subject: RE: DHCPv6 address model proposal...

In agreement with the two basic requests.

The first (Associate some IP addresses with this IA) request is really lease
me some addresses (or lease me what addresses I might have had in the past)
and the second is the renewal request.

We did have some open issues with these requests that were under discussion.

- I believe we all agreed that allowing the client to supply a list of
prefixes for addresses the client wanted is allowed. The server can supply
additional addresses and might not assign addresses for all supplied
prefixes.

- I believe the renewal was a bigger issue because it wasn't clear whether a
client could "renew" an individual address or had to renew all of them. The
issue also required us to resolve whether lifetimes are per address or per
IA, which was never fully resolved. As with router prefix advertisements, I
personnally feel that the lifetimes should be per address, not per IA (ie,
the "lease" each address includes per address lifetimes, rather than a
single lifetime for all addresses).

The way the list of requests below reads ("renew this IA") kind of implies
that one leases IAs and not addresses. Perhaps you've implied to solve the
problem by saying all addresses for an IA have the same lifetimes?

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, September 14, 2000 2:46 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Sep 2000 15:44:56 -0700

> problem by saying all addresses for an IA have the same lifetimes?

I think the solution to the problem is that each address should have
its own lifetime, but that the identity association should have a
renewal time.  If the DHCP server isn't going to renew a deprecated
address, it can set the identity association renewal time to be after
the lifetime of that address expires.  Excluding deprecated addresses,
the DHCP server would then use the shortest lifetime of the remaining
addresses to figure the lease time for the identity association.   The
DHCP client would then always renew at the appropriate percentage of
the identity association renewal time.

So what I'm suggesting is that we seperate out the lifetime concept
from the renewal time concept.  The client tracks lifetimes in the
sense that if an address's lifetime expires, the client drops it.  But
it always renews identity associations, not address lifetimes.  So on
the client side you have a drop dead timer on each lifetime that's
initialized each time an address is installed as a result of the
server assigning it.  The client also has to remember that each of
these addresses is part of an identity association, and drop the
addresses if the server doesn't renew them.  But in terms of asking
for renewals, it renews all the addresses associated with an IA at
once, even if some of them have much longer lifetimes than others.

The implementation looks something like this (I've simplified the
initial DHCP Reply processing - really, both DHCP Replies are
processed as in the description of the second DHCP Reply):

Receives DHCP Reply:
   address A: lifetime = X (deprecated)
   address B: lifetime = 2X
   address C: lifetime = 3X
   renewal time: 2Xk (k = percentage of lease lifetime before renewal)

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

.
.
.

At X:
   Process timeout on address A:
      delete address A from interface
      delete address A from identity association record

At 2Xk:

Sends DHCP Request

Receives DHCP Reply:
   address B: lifetime = X
   address C: lifetime = 3X
   address D: lifetime = 2X

For each address in identity association record:
   deletes timeout for address
   is address in {B, C, D}?
     no: delete address from interface
	 delete address from identity association record
For each address in {B, C, D}:
   add timeout at address lifetime
   is address in identity association record?
     no: install address on interface
         install address in identity association record

This sounds kind of complicated, but I think it's significantly
simpler to implement than trying to come up with a mechanism for
renewing portions of the set of addresses in an identity association
seperately from other portions of that set.  And I don't think there's
any significant additional overhead - if you have to send a renewal
packet, you might as well renew all the addresses in the identity
association.   We'd have to think about this for the mobile phone
case (don't want a big packet), but I think it still works.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Thu, 14 Sep 2000 23:38:57 -0400

Ralph,

>be an OS or an application and there may be multiple DHCP clients within a 

I think we need some discussion on what multiple DHCP clients mean.

IPv6 Stateless will permit a DHCP Client to start.  

Can that Client spawn additional Clients or Client Processes or one
process each having its own client identifier?

For example if a node has 3 interfaces on the same link it will hear the
M bit three times from IPv6 stateless.  Each interface will be permitted
to request configuration parameters and addresses.

My first thought is I would like the freedom as implementor to have one
parent DHCP client and then spawn child clients or threaded clients each
with their own identifier hence IA's for each interface or two IA's for
one interface as Ted suggested in the con call.  This permits both #1
and #2 of Charlies model to DHCPv6 and IPng list too.

If that is what this can mean I support it if not we should clear it up.

>associated with an existing IA.

So the server must know if the cliient is multihomed?

>clients.  E.g., identifiers from clients on the same computer might share a 

But per Mark's mail we are not specifying this is my view?

>* Associate some IP addresses with this IA

Yes.

>extending the leases on the IP addresses associated with an IA.

Well we need some verbage if the client's Renewal IA expires before the
valid lifetime (the lease specifically) the client can still use the
address for existing connections, OR make it prohibitive in the spec
that renew of IAs cannot be less than the lease.

>preferred or deprecated.  From RFC 2462, "IPv6 Stateless Address 

I did not mean to imply the word lease is inappropriate.  What I stated
is that DHCPv6 must pass the client both a valid and preferred lifetime.
If we want to define that combination as a lease that is fine.

>In any event, does this summary capture the consensus on the address model?

Except for my questions above for me they do.

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 15 Sep 2000 01:59:32 -0400

>the identity association renewal time.

I think this would work for first spec attempt...

Don't you mean the "DHCP sever would then use the "longest" lifetime...?

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

>once, even if some of them have much longer lifetimes than others.

I think this is causing extra packets on a network.

Lets suppose a client has 4 128bit IPv6 address and thats also 8 32bit
lifetimes.

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.

>   address A: lifetime = X (deprecated)

What is the notation (deprecated) mean?

>   renewal time: 2Xk (k = percentage of lease lifetime before renewal)

In DHCPv6 two lifetimes are sent as a note.  Valid and Preferred.
So in your model I assume the times are the Valid Lifetimes.

Why not make renewal time: 3Xk (I am assuming X is some constant right)

>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.

.
.
.

>   address D: lifetime = 2X

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.  

>case (don't want a big packet), but I think it still works.

I don't agree. Francis has implemented the model to permit a client to
renew a specific address and we have just done it for our Infiniband
work in Compaq using solicit, request, and reply.  So I now declare that
is another implementation in addition to Francis's. 

Also I am thinking we should not tie the REQUEST to the renewal time for
the IA.  The IA is the binding for the client with some other cruft we
need to figure out as implementors.  If that changes lots changes and
including the reason we are using the IA for security keys.

Here is my implementation:

address A valid lifetime == X preferred lifetime == Y
address B valid lifetime == 2X preferred lifetime == 2Y
address C valid lifetime == 3X preferred lifetime == 3Y
renewal IA lifetime == >3Xk (same k constant as yours)

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 B 
   at 80% 2Y 
   if B will not be RELEASED by Client (mobile node decision)
                                       (for handoff as example using
                                        lazy cell evaluation)
     REQUEST address B again

ditto for C

Renewal Timer for IA goes off:
     REQUEST (no addresses supplied just like the client is
              in start state after advertise message)

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.

We want to permit clients to continue use if they want an address
before the deprecated state which is when the preferred timers goes off
per IPv6 addr conf.

At server

Recv REQUEST 
Locate Clients IA+cruft BINDING
 if addresses in REQUEST
  renew lifetimes on address or address set provided for which the
     server previously supplied the client
 else
  provide client all addresses it is permitted to have at this point
     in time (note "time" is key here as the server can change that)
  
The above is completely idempotent (and reentrant) as long as any
changes to the IA are not done at this state.  That should be another
state I don't think we started discussing yet.

The above depicts the advantage of Ted's IA over the current DHCPv6
model.  We still permit the server to maintain tight control over a
finite set of addresses and the client can request no more than the 
server provided.  This is what Ralph wanted I think.

But if the client wants to request more addresses for an interface or a
link or even an NBMA PVC connection they can set up a new IA and then
send REQUEST to the server and the implementation above still works and
can be its own module and thread on the server for all cases.  This
supports what Charlie wanted.

We get both models in our spec.

regards,
/jim

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Sep 2000 23:39:08 -0700

> 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.

> 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?

> So in your model I assume the times are the Valid Lifetimes.

That's an interesting topic for discussion.   I can see good reasons
for using either one.

> Why not make renewal time: 3Xk (I am assuming X is some constant right)

X is a constant in the sense of a convenience constant in algebra, not
something predefined by the server.   I could have said "10, 20 and
30".   The point is just to establish a size relationship between the
lifetimes of the leases.   I would expect X to be some number of
hours, and k to be .8.   I should have been more explicit here - sorry
about that.   But you used "idempotent" in your message, so you don't
get to complain!   :')

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.

> But that implies we need more discussion for IA if it changes.

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

> 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.

>                                        (for handoff as example using

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.

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?

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.

> IA with the Server as it changes the bindings at the server and I assume

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.

> supports what Charlie wanted.

Right.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Fri, 15 Sep 2000 03:26:12 -0400

>The addresses do not expire until their lifetimes expire.

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

>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?

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

I know that and have implemented stateless this way too.

>the server in determining the renewal time, and so the renewal time

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?  

>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.

>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.

>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.

>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:03:59 -0700

> I would think the global would have less, and site the most time.

Why would one identity association have all three of these?   Wouldn't
it either be asking for a global address or not?   How does the server
decide when the client can have a global address and when it can't?
If the client has a global address, why does it need a non-global one?

I think that if the client sometimes has a global address and
sometimes not, it's probably got two identity associations going - one
for the program that needs to have a global address, and one for the
programs that don't.

I may just be dense here, but the scenario you're describing where a
client has all three kinds of addresses at once sounds extremely
exotic to me.   In my own personal use, I am going to always request a
global address for my network interface, and if I get one, I'm not
going to have any interest in any other addresses.   Are you
envisioning a scenario where you have a global address starvation
problem or something?

Or is this a mobile IP scenario, where you have one global address
that you want to keep around, and then you have a site-local address
that changes a lot?  In this case, I think you have two identity
associations - the addresses are being used for completely different
purposes, so it doesn't make sense to treat them as part of the same
network identity.

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

I don't see any reason why one address would have a different lifetime
from another.  I can imagine that they might have different lifetimes
by happenstance, but why would they have *different* times?  It's more
work for the network administrator to specify that addresses in this
class have lifetimes of ten hours, but addresses in this class have
lifetimes of twenty.  The only case where I think addresses are likely
to have significantly different lifetimes is when you are renumbering,
and one of the addresses the server has that the client is using has a
time when the *server* isn't supposed to give it out anymore.  So yes,
lifetimes are individual data, but I think it makes sense to treat the
lifetimes of addresses in an identity association collectively anyway.

> How will the client know its deprecated?  

Probably deprecated addresses have a different extension number but
share the IP Address Extension format.

> happens go get more time.

This is complicated because there are really two sets of lifetimes on
addresses.   There's the lifetime the server knows, and the lifetime
the client knows.   The server may have address pools for which it
knows of no time when it can no longer give out the address, in which
case the lifetime it gives to the client is going to be basically a
lease time.   Setting the preferred time to 80% of the valid time
sounds reasonable, but the choice of valid time is going to be
basically what the server administrator configures in.

When I talk about deprecated addresses, I'm talking about renumbering.
The address A in the scenario I was describing has been renumbered,
and so the server isn't going to renew it.  The server has a drop dead
time on the pool from which that address came, and no matter how often
the client tries to renew that address, it's always going to be told
that address becomes invalid at the same actual time.

The way you (IPv6) are using deprecated is unfortunate, because it
leaves me without a word to describe a lease that will never be
extended, which seems like it's also an important IPv6 concept.   But
be that as it may, using the IPv6 meaning of deprecated, we want the
renewal time on the identity association to be the minimum of all the
preferred lifetimes of all the addresses in that identity association.

> realm or in wireless terms cell with new Base Station.

So the client is going to tell the server "I only want addresses with
this prefix?"

> before it can ask for a new lease or address for global communications.

No, that's not right.   The renewal time is the minimum preferred
lifetime for all the addresses in the identity association.  So the
client *has* to renew the global address just as it becomes
v6deprecated.

> the client needs to update the lease even though their renewal has not

The client is also free to renew anytime it wants prior to the lease
expiry, just like in DHCPv4.   So this doesn't seem like a problem.

> however I choose to implement the server config database?

As soon as there are no valid addresses associated with an IA, you
can gc the IA.

> every now and then it reduces the search for the client when it comes to

This makes sense.   In a high turnover environment, you'd want to be
smart about harvesting stale IAs.   However, in an environment with
a more consistent set of clients, which is the typical DHCPv4
scenario, this isn't a real problem.   And in either case, I don't
think there's any need for a special negotiation.

			       _MelloN_

---

From: Thomas Narten <[email-masked]>
Date: Fri, 15 Sep 2000 10:39:37 -0400

Hi Ted.

Your note seems to indicate a very different thinking between how you
see DHCP being used for addresses (and how addresses are used) and the
predominant view within the IPv6 community (or at least, my read of
the IPng view).  I think it would be good to fully understand the
differences and implications here.

> If the client has a global address, why does it need a non-global

In general, addresses are just used. You don't really care which
address (or addresses) you have, so long as you have one(s) that work.

So, whenever someone suggests a view that a client asks for (say) a
global address, or perhaps a different type of address, this implies a
model in which the client (or application or whatever entity will use
the address(es)) needs to have a fair amount of knowledge about what
addresses are available, and how an address will be used. This model
is very different than the one assumed when stateless address
autoconfiguration is used. In that model, the system admin has says
(via configuration): the following addresses are the ones you will
need, assign them to your interfaces and use them.

Thus, the dhcpv6 counterpart to that model would be for a client (or
application or whatever) to say "I need some addresses", and the dhcp
server would return a *set* of addresses, corresponding to what is
appropriate *for the local network configuration* (as opposed to what
is appropriate for the specific usage enivisioned by the client).

> for the program that needs to have a global address, and one for the

Again, here you are implying a lot of client knowledge about the world
around it. How does the client know what addresses are available? How
does it know which ones would be appropriate to use? In general, I
would assume that the sys admin decides this, and when a client asks
for an address, it should be asking for an "address set", not a
specific address. The server then always returns the appropriate set
of addresses. This eliminates the need for clients to know what
addresses might be available and which ones of those it should ask
for.

> envisioning a scenario where you have a global address starvation

The case where a client three kinds of addresses will likely be the
norm in IPv6. Or at least very common. Specific examples:

1) a site may have a global prefix (and hence global addresses for all
   hosts) plus a site-local prefix/address. The site-local address is
   nice because it will always work for intra-site communication, even
   of global  prefixes stop working, for example, as a result of
   switching ISPs and renumbering.

2) When a site is in the process  of renumbering, there will likely be
   a transition period where two global prefixes will be in use. The
   "old" one that is being phased out, and the new one being phased
   in. The transition period may well last weeks, in order to make
   sure that all traffic has switched to the  new addresses *before*
   disabling the old addresses.

Note that in scenario 2) above, a client most likely won't know a
renumbering event is going on, so it won't really know what kind of
address to ask for (does it ask for the old one? the new one?
both?). These are the types of questions that I believe complicate the
issues surrounding address allocation. Doing everything in terms of
"address sets", where the client always asks for a set, and the server
always returns a set, simplifies a lot of the potential corner cases
we would need to think about.

> purposes, so it doesn't make sense to treat them as part of the same

In the mobile IP scenario, you will likely have *two* global
addresses. One for your home address, and a temporary care of
address. Both will need to be global in order for arbitrary sites to
send packets to them. Note, however, that in this case the client will
be interacting with two different DHCP servers in two different
contexts. The care-of address comes from the local site that is being
visited, the home address comes from the home site. So it's not clear
you need to identity associations separately here (though you might
want to), since two servers are involved and that is enough to
distinguish which addresses one is talking about (i.e., care-of
vs. home).

> lifetimes of addresses in an identity association collectively

I'm not sure whether you are agreeing or disagreeing above. On the one
hand you say, lifetimes should be the same, then you point out that
they won't be during renumbering events. If it can happen, then we
have to assume it will as a design point.

Another example of where lifetimes may be significantly different is
site-local vs. global. Since one probably never expects to renumber
site-local prefixes, they may have lifetimes of weeks/months, whereas
a global address may have a lifetime of only a week or so. In any
case, I don't think we should be making assumptions that lifetimes
will be the same. That is probably too restrictive.

> share the IP Address Extension format.

Any addresses returned by a the DHCP server will need to have
explicit Valid Lifetime and Preferred Lifetimes. Just as DHCPv4
addresses have a lifetime associated with the address, IPv6 addresses
have two lifetimes associated with them. This is a property of IPv6
addresses, not something that results from DHCP.

> addresses.

Yes, but that is a feature of IPv6 addresses. We just have to accept
this.

> There's the lifetime the server knows, and the lifetime
> the client knows.

How is this different than DHCPv4? Conceptually, there is the lease
time the server told the client, and there is the lifetime the server
has. The server could be extending the  lease in real time (e.g, it
always thinks of it  being (say) 2 days, but from the client's
perspective, it varies between 2 days and whatever the time is when it
renews the lease. (Or am I misunderstanding your point?)

> The server may have address pools for which it

Yes. The sys admin will need to specify the Preferred Lifetime of all
addresses. (It can do this by saying that all addresses on subnet X
have the same value though.)

> and so the server isn't going to renew it.

A deprecated address is still a valid address and the DHCP server
should hand them out. If it doesn't a client that attempts to renew an
address with 5 day valid lifetime on it may find the server is telling
it it can't have the address anymore. But this may break the smooth
renumbering goals of IPv6.

But I think you bring up a good point. In DHCPv6, the client should
renew an address *before* it becomes deprecated. But if the server
isn't going to extend the preferred lifetime (while allowing the
client to continue using an addresss -- so it does need to return the
address), the client needs to learn that in a definitive
way. Otherwise, it may continue to ask to extend the lease, not fully
understanding that the server is saying "no".

So, using the term "extend the lease" is not very good
terminology. Because it doesn't fully capture the two lifetimes of an
address.

> The server has a drop dead

> preferred lifetimes of all the addresses in that identity

Agree we have a terminology problem, so maybe we should invent a new
term to describe things.

I also think you are basically right on the renewal point, but I think
there may be subtleties here that we haven't thought through
completely (as I allude to above with regards to knowing when the
preferred time is not going to be extended).

> So the client is going to tell the server "I only want addresses with

I hope not. If a client moves to a new link/subnet, it should just
request that the DHCP server "give me the set of addresses that I'm
supposed to have on the new link I just joined".

> client *has* to renew the global address just as it becomes

I wonder if we should have an explicit renewal time defined by DHCP
that tells the client when to renew, rather than have it derive the
info off the address lifetimes.

Thomas

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Sep 2000 11:22:50 -0700

> differences and implications here.

On the contrary - I am trying to understand why I am being told that
the client would have all these different kinds of addresses.  Why
would the server administrator say "give the client a global address,
*and* a site-local address?"  Why wouldn't it provide one or the
other?  I understand how during renumbering you might give a client
two addresses, but under what other circumstances does this make
sense?

I completely agree with you that it doesn't make sense for the client
to be making these kinds of decisions.

>    disabling the old addresses.

Okay, this explains why the client would get a site-local and a global
address.   I already understood the bit about the two global addresses
during renumbering - that's why I proposed the scheme I did.

> Doing everything in terms of "address sets", where the client always
> asks for a set, and the server always returns a set, simplifies a
> lot of the potential corner cases we would need to think about.

Right.   That's what I've been trying to argue in favor of - each
identity association has an address set.   The entire set of addresses
in an identity association is renewed at once.   The server tells the
client what's in the address set, and when to renew, and also what the
lifetimes of the individual addresses are.

> distinguish which addresses one is talking about (i.e., care-of

Right.   So you have two identity associations.

> have to assume it will as a design point.

Yes, and the design I've proposed here addresses this problem very
neatly.  If you put renewal times (note that I am _not_ talking about
lifetimes here!) on addresses, not identity associations, then you
have these problems:

  (1) even if the addresses all have very similar lifetimes, you
      probably send a seperate renewal packet for each address.
  (2) If an address is deprecated, and will not be renewed once its
      lifetime expires, then as its life comes to an end, the client's
      renewal rate increases exponentially 
  (3) It's hard for the server to cause you to change your address
      set, because you're never having a conversation about an address
      set, but only about an address.   So you have to have a lot of
      additional goo in the protocol to make it possible for the
      server to give you a new address set.

If you renew the identity association, you have these advantages:

  (1) You always renew all addresses in the same request, which
      happens at the time you would have had to do the first renewal
      anyway.   This reduces complexity in the client, and reduces
      traffic on the network, although there is a marginal increase in
      packet size.
  (2) If a global address has been renumbered and is not renewable, the
      server doesn't count it in the renewal time, so you don't get an
      exponential curve in the client renewal rate as the address
      expires - the client simply deletes the address from its
      interface when it's no longer valid, completely seperate from
      the renewal process.
  (3) If for some reason you need a different set of addresses, the
      server will tell you all of them when you renew - no muss, no
      fuss.

> addresses, not something that results from DHCP.

I understand this.  Maybe I should use the term "non-renewable" here -
saying the address is deprecated is causing confusion.  There's no
actual need for the client to know that the address is non-renewable -
I only suggest that it be told because it's less likely that an
implementor will make a mistake if non-renewable addresses are
explicitly treated differently.

> Yes, but that is a feature of IPv6 addresses. We just have to accept

I'm not saying we don't have to accept it.  I'm describing how to
handle it.  I get the feeling in your message that you're getting the
impression that I don't know what I'm talking about.  Please don't
read my messages this way - I actually do have a pretty good sense of
what I'm talking about.  I'm just having trouble with the terminology.
I don't remember all the IPv6 terms because I don't read the drafts
every day, and IPv6 uses a fair amount of specialized terminology,
some of which has overlapping uses.  This statement was made to
clarify a place where two meanings for the same set of words overlap,
not to say that we should only have one meaning for that set of
words.

> renumbering goals of IPv6.

There are addresses that, to the client, are (in IPv6 terminology)
deprecated, but that the server will renew, at which time from the
client's perspective, the address will no longer be deprecated.  Then
there are addresses that are deprecated from the server's perspective
- that is, after a certain time (the valid time), the server should no
longer renew them, and after a different, earlier time (the preferred
time), the server shouldn't do new allocations with them.  I'm now
calling these addresses "non-renewable."

If the client requests a renewal prior to the end of the server's idea
of the valid time for one of these addresses, the server should renew
it, but not extend it.  The client's renewal time can't be based on
the valid time or preferred time that the client gives to the server,
because the server will not extend the valid or preferred time on this
address.  So if the client tries to renew based on the relative times
it gets for this address, you get into the exponential upward renewal
rate.

The only usual case where the server should have to tell the client
again about this address after it's become non-renewable is if the
client is renewing some *other* address, or if the client reboots.
And yes, then the server should give the address to the client again,
with the same absolute valid lifetime and absolute preferred lifetime
as before.

> supposed to have on the new link I just joined".

This sounds like the client is making a different request depending on
it's perception of the status of the link.  Is there any particular
reason why the client can't just say "please renew this IA" and have
the server say "okay, because you're on a new link, here are your new
addresses?"  I.e., the client asks the same question, rather than
having to be clever and decide which question to ask?   The client
might be stimulated to ask for an early renewal because it noticed
that the router advertisements it was seeing had changed, but I don't
think it needs to explicitly tell the server "hey, I'm on a new
subnet."

The reason I say this is that the server has to decide what address is
appropriate for the client *anyway* - the client may have lost its
cookies.   So if we have to implement this on the server side, why
bother putting it in the client?   One of our stated goals was to keep
the client simple, after all.

> info off the address lifetimes.

I presume you mean explicitly stated by the server, not explicitly
stated in the protocol.  If you mean the former thing, that's exactly
what I've been proposing!

I think we're actually not very far apart here - it just seems like
we're farther apart because we're using terminology in different ways.
I'm sorry for not grokking the IPv6 terminology better - I've got too
many things on my plate right now to really be up on this, but by
clarifying it as you have done, you've at least helped me with the
particular mistakes I made in this most recent set of message.  :'}

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Fri, 15 Sep 2000 16:10:34 -0400

>If the client has a global address, why does it need a non-global one?

These are good questions I hope folks will read my response it is an
important data point we discuss this and what is driving my assumptions.

But to answer the above it is server admin policy which we don't define
in DHCPv6 or DHCPv4 and we should not for DHCPng thinking of tomorrow.

>for the program that needs to have a global address, and one for the

That makes things more complex IMO than what we have now in DHCPv6.

If we went down this path then we would want a way for the client to let
the server know what it wants and I don't think we should do that and
then we are heading back to the existing spec which I don't think is
wrong but appears to be complex to get implementors excited.  But the
real issue is why I want this and why it is innate to IPv6 Stateless
Addrconf for which I think the DHCPv6 model should support.

>envisioning a scenario where you have a global address starvation

Its not exotic at all.  Here is why in IPv6 we have as you know multiple
address scopes and right now the IPng WG and IPv6 implementors are
working on what is called the Source Address Selection algorithm.  The
bottom line is that if a node does getaddrfino() to find host foo and
gets back a site-local address the source address selection rule set in
an IPv6 implementation will attempt to find the best match address to
use for that destination scope.  So a site-local address will be used
for the source address not the global address.   But if the same node
wants to ftp to a global ftp Internet site then it will want to use a
global source address.  When you want to access your organization server
for something DNS may return an orgganizational scope address and then
the best match for the source address is organization.  The work also
addresses disimilar scopes and if apps hard code the address of course.

But the point is that IPv6 endorses and assumes IPv6 nodes for one
interface may want to have many many addresses of different scopes as I
depict above and the IP6 architecture permits the behavior.  I believe
DHCPv6 must all support that behavior and in fact DHCPv6 would be in
error if it did not.

This is not my (Jim's) architecture but what the authors do have the
intention of supporting the IPv6 architecture and be in synch to some
degree with rfc2461 and rfc2462 (Neighbor Discovery and Stateless
Addrconf).

>purposes, so it doesn't make sense to treat them as part of the same

Mobility is another example.  I can see your model above but I can see
the need for mine too.   I think it easier and less name space pollution
of the IA's if we permit the behavior I am supporting (not my idea OK
but I think its a good idea).

>lifetimes of addresses in an identity association collectively anyway.

I gave you example above.  The global may have less time significantly
than the site-local which I presume would have the most time.

>share the IP Address Extension format.

Hmm I need to think about that if this is what we do at the end of the
day.

>that address becomes invalid at the same actual time.

OK in that scenario which I did not know obviously from your mail
In the scenario I am supporting the Server would respond with valid
lifetime of 2 minutes which will end the address and cause deletion of
that address for the IA.

Note in IPv6 Addrconf Stateless you cannot send a valid lifetime of zero.

>leaves me without a word to describe a lease that will never be

Its not the way "I" am using deprecated its the way IPv6 uses the word
deprecated.  I think for communications and my intent and debate I want
all to know I am advocating use model in IPv6 Stateless Addrconf and
Neighbor Discovery when possible and if we don't there must be a
compelling reason.  Thank You.  So if you don't like this you don't like
what IPv6 has done.

>preferred lifetimes of all the addresses in that identity association.

That is fine if we use that model.  I am not clear now after this
discussion if that is a good model now.

>So the client is going to tell the server "I only want addresses with

Well basically but I would word it that the client mobile node tells the
server I am moving into this routing realm roaming and this is the
prefix of that realm.

>client *has* to renew the global address just as it becomes

But how does it do that in that model.  From your mail the REQUEST could
not happen on the client until the rnewal timer went off as I read the
mail?

>expiry, just like in DHCPv4.   So this doesn't seem like a problem.

If the client can renew anytime whats the point of the renewal timer?

>As soon as there are no valid addresses associated with an IA, you

There is for the server database:

IA1
  config parameters provided and addresses
IA2
  config parameter provided and addresses 
IAn......

Today the only releaseable resources we have are addresses and once
those expire I can delete the IAx binding, if we can assume that any
future releaseable resources will have timers then that will work.  

>think there's any need for a special negotiation.

Possibly not I agree now.

regards,
/jim

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Sep 2000 14:22:37 -0700

> Addrconf for which I think the DHCPv6 model should support.

I don't want this either - I proposed it because it sounded like you
wanted it.   I'm happy with the model Thomas described where the
server administrator determines what kind of addresses get given out,
and the client just has to deal with what it gets.

> DHCPv6 must all support that behavior and in fact DHCPv6 would be in

We are in resounding agreement here.

> So if you don't like this you don't like what IPv6 has done.

I just don't like the way the word is being used in IPv6.  I think the
concept to which it refers is the right thing - indeed, there are
cases right now where customers of mine would like this functionality
in IPv4.

So please don't mistake what I'm saying for griping about the protocol
- I'm just griping about the linguistic difficulties I'm running into
because words are being used in specialized ways and I'm too
specialized in a different direction to be aware of all the different
usages.  I basically just stepped in it in a big way using
"deprecated" the way I did initially.  Sigh.  :'}

> not happen on the client until the rnewal timer went off as I read the

Right, and the renewal timer is on the identity association, not the
address, and it's the correct time to do a renewal given the addresses
in the identity association.   So by definition it is going to cause
the right thing to happen.

> If the client can renew anytime whats the point of the renewal timer?

It is possible for the client to renew anytime - e.g., on reboot.  The
point of the renewal timer is to tell the client when it *must*
renew if it wants to keep its addresses.

> future releaseable resources will have timers then that will work.  

Right.   If a releasable resource doesn't have a timeout, I think
you're stuck remembering the association anyway, at least until you
get a release event or the operator intervenes (shudder).   This
argues strongly in favour of never having releasable resources without
timeouts...  :'}

---

From: Jim Bound <[email-masked]>
Date: Fri, 15 Sep 2000 20:57:45 -0400

>the right thing to happen.

Yes as you stated if the renewal timer is less than a preferred timer
mean that would work I agree.  And if the client don't see the address
then it knows the server has potentially released it then don't own it
anymore.  That would work.  This is progress.

>renew if it wants to keep its addresses.

OK but why is that different than the valid lifetime?  In IPv6 if the
valid timer goes off the connection gets broken.

I just want to be sure we have not maybe solved this timer problem with
the valid lifetime for an address.

But then we could say the renewal time is for the address set in total?

I can live with the client sending back all addresses when it wants to
renew the global address and that will work with the existing IPv6
Address Extension.  It does add extra bytes to the message and I think
we need to at least acknowledge that to a mobile node until we see 156kb
pedestrian throughput for mobile roaming there is a point where we do
need to reduce the bytes we won't see those speeds as I read the Tea
Leaves for Wireless till 2003 as a note.

I think it fair to ask the WG how they feel about this?

Do we try to save bytes for mobile nodes in DHCPv6?  I think we should
if its not too complex to implement which is the engineering trade-off.

Ted and others ????

>argues strongly in favour of never having releasable resources without

Yep thats where I was headed but I am sure somone on the list would tell
me that is too severe a limitation to state in DHCPv6 at this point and
we can always add that later.  But I think its a good statement about
releaseable resources.

regards,
/jim

---

From: Ted Lemon <[email-masked]>
Date: Sat, 16 Sep 2000 00:10:22 -0700

> valid timer goes off the connection gets broken.

The identity association's renewal time is a construct, based on a
process of aggregating all the preferred times (probably) for all the
addresses in an identity association.  It exists so that you don't
have to renew addresses seperately, and secondarily so that you don't
send pointless renewal messages for non-renewable addresses.

> the valid lifetime for an address.

I don't think so - the valid timer serves the purpose of making sure
that an address stops being used once it becomes invalid, and the
renewal timer causes renewal packets to be generated - two different,
albeit related, purposes.

> But then we could say the renewal time is for the address set in total?

Precisamento!   :')

> if its not too complex to implement which is the engineering trade-off.

I think if you do the math it's not the clear cut, *particularly* for
a mobile node.  Let's say for simplicity (so we have to only talk
about one identity association) that you have a mobile node that's not
doing mobile IP - it's just changing its address from time to time as
it moves around, and doing short-lived transactions on the network.
And right now you're sitting in your office with it.   Let's say you
get a global address and a site-local address, and the server is
giving the global address a renewal time of 24 hours, but the site-
local address has a renewal time of a week.   So if you renew
addresses together, over a week period, you get this:

T+0d00h: DHCPsolicit+DHCPadvertise+DHCPrequest+DHCPreply
T+0d12h: DHCPrequest+DHCPreply
T+1d00h: DHCPrequest+DHCPreply
T+1d12h: DHCPrequest+DHCPreply
T+2d00h: DHCPrequest+DHCPreply
T+2d12h: DHCPrequest+DHCPreply
T+3d00h: DHCPrequest+DHCPreply
T+3d12h: DHCPrequest+DHCPreply
T+4d00h: DHCPrequest+DHCPreply
T+4d12h: DHCPrequest+DHCPreply
T+5d00h: DHCPrequest+DHCPreply
T+5d12h: DHCPrequest+DHCPreply
T+6d00h: DHCPrequest+DHCPreply
T+6d12h: DHCPrequest+DHCPreply
T+7d00h: DHCPrequest+DHCPreply

So you have 1 DHCPsolicit, 1 DHCPadvertise, 15 DHCPrequests and 15
DHCPreplies.  So using the current IP Address extension, each
DHCPreply contains 64 octets of address extensions, plus a minimal
IPv6 header of what, maybe 40 octets, 8 octets of UDP header, and
maybe 16 octets of framing, plus maybe another 64 octets of other
extensions, plus a 16-octet signature, for a total of 208 octets.  The
DHCPrequests, I'm not so sure about, but I'm not convinced that it is
going to be usual in a situation like this for them to contain
explicit address requests, so let's say they're more like 64 octets of
header, 16 octets of extensions and 16 octets of signature, for a
total of 96 octets.  The DHCPsolicit is probably roughly the same size
as the DHCPrequest - 96 octets.  The DHCPadvertise might be as large
as the DHCPreply - 208 octets.  So you have 16 208-octet packets and
16 96-octet packets.  So the total traffic size in this scenario is
4864 bytes.

Now consider your scenario - we have:

T+0d00h: DHCPsolicit+DHCPadvertise+DHCPrequest+DHCPreply for both addresses
T+0d12h: DHCPrequest+DHCPreply for global
T+1d00h: DHCPrequest+DHCPreply for global
T+1d12h: DHCPrequest+DHCPreply for global
T+2d00h: DHCPrequest+DHCPreply for global
T+2d12h: DHCPrequest+DHCPreply for global
T+3d00h: DHCPrequest+DHCPreply for global
T+3d12h: DHCPrequest+DHCPreply for global
T+4d00h: DHCPrequest+DHCPreply for global
T+4d12h: DHCPrequest+DHCPreply for global
T+5d00h: DHCPrequest+DHCPreply for global
T+5d12h: DHCPrequest+DHCPreply for global
T+6d00h: DHCPrequest+DHCPreply for global
T+6d12h: DHCPrequest+DHCPreply for global
T+7d00h: DHCPrequest+DHCPreply for global and site-local

So here you have one DHCPsolicit, one DHCPadvertise, 15 DHCPrequests
and two DHCPreplies that are the same size as in the previous
scenario, for 16x96+3x208.   Plus, you have 13 DHCPreplies that are
174 bytes, so this adds up to a total of 4422 bytes.

So the actual difference in traffic here is 442 bytes - about 10%.
And this is the *worst case scenario*, which you will almost never see
in the context of a roaming device in the real world.   It has a
site-local and global address with very different lifetimes, which is
unlikely in a mobile phone context in the first place.   It didn't
move around, so you didn't have to renew because of cell transitions.
If we'd been renewing on cell transitions, there's a good chance we
would have seen the same number of bytes in both cases, because the
renewals would have happened before either lifetime expired.

So I think in the real world, with a mobile device like a cell phone,
you are going to see no difference in bandwidth consumption.
Furthermore, the worst-case scenario I described is susceptible to
compression, and we might well want to specify a compression mechanism
for low-bandwidth mobile devices anyway.  This would probably burn
that 10% down to 1% - an "I didn't move" renewal is going to have a
tiny payload in both directions.

So I really think that the bandwidth argument isn't a good argument
against this scheme.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Sun, 17 Sep 2000 21:52:40 -0400

>So I really think that the bandwidth argument isn't a good argument

Nice work on that.  I agree.  Also another datapoint is that stateful
addrconf for IPv6 hopefully is not happening as often say using the web
via wap or something.

I am fine with the renewal time strategy.

thanks
/jim

---

From: Bernie Volz <[email-masked]>
Date: Mon, 18 Sep 2000 12:35:06 -0400

Jim:

Can you clarify what you mean? Are you proposing to base the renewal time on
an address lifetime? Or, are you referring to the T1/T2 times like in
DHCPv4?

I'd vote to pass a "lease time" in the packets. The renewal times (if we use
T1/T2 values as in DHCPv4) can be set in the spec (with options/extensions
to override defaults if a site needs it).

- Bernie

-----Original Message-----
From: Jim Bound [mailto:[email-masked]]
Sent: Monday, September 18, 2000 12:05 PM
To: DHCPv6 discussion list
Subject: renewal time

for the renewal time?  should we pass this in the packets or just use
algorithm to determine the time in the spec.  mike and I are beginning
to edit the specs.

personally I don't care but if we can save bytes in the packet and keep
msgs shorter that would be good and one of things we were told people
wanted from dhcpv6.

thanks
/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 18 Sep 2000 14:54:08 -0400

>an address lifetime? Or, are you referring to the T1/T2 times like in

It was the Ted/Jim discussion thread.  I view the renewal time like the
T1/T2 times in DCHPv4.

>to override defaults if a site needs it).

This would be my suggestion too.  The lease time (preferred and valid
times) have to be in the packet like we have in the existing address
extension.  

What Ted is proposing is the client only can send a REQUEST when the
renewal timer goes off or that is how will work as it is based on the
least value of preferred timers.  This will work.  So in that sense its
like the T1 and T2 but adds to DHCPv6 when the client will REQUEST new
addresses.  If we do this I think we can do it with a defined algorithm
for the client in the spec.  Mike and I can make first pass at it to
get a spec out per the deadline.  Is what I was asking.

But I should ask? 

Do other folks not agree with the renewal time strategy so far we have
really only heard from Ralph, Ted, and me?  That's hardly consensus, and
not trying to force this but trying to get a spec for us to discuss by
early october or sept 30th.

Bernie what do you think?
Francis what do you think?
others.....what do you think?

thanks
/jim

---

From: Mark Stapp <[email-masked]>
Date: Mon, 18 Sep 2000 15:23:06 -0400

I agree that there should be renewal time defaults in the protocol itself, 
but that the server should be able to send extension data which overrides 
those defaults. That's how I read the messages from Bernie and Ted. But 

>get a spec out per the deadline.  Is what I was asking.

Jim - when you say "when the client will REQUEST new addresses", do you 
really mean _new_ addresses, as in _additional_ addresses? I think you mean 
something like "will REQUEST that the server extend the lease-times 
associated with a client-id": is that correct, or do you really mean "new 
addresses"?

-- Mark

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Sep 2000 12:55:49 -0700

> associated with a client-id": is that correct, or do you really mean "new 

I think the right phrase here is something like "request the renewal
of the addresses in the identity association."

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Sep 2000 12:55:11 -0700

> this paragraph of Jim's confused me a bit:

Actually, what I'm saying is that the server should always send this,
not that it should be permitted to.   Otherwise the client has to be
prepared to compute the renewal time.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Mon, 18 Sep 2000 21:14:04 -0400

>associated with a client-id": is that correct, or do you really mean "new 

Correct new lease-times or the Server could not give the client an
address back meaning its expired too.  But no new addresses.

regards,
/jim

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Sep 2000 22:42:23 -0700

> address back meaning its expired too.  But no new addresses.

Well, but if we're renumbering, the server might well give back a "new
address", right?  I think the point is that that client isn't asking
the server to do this - it's asking the server to renew.

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Tue, 19 Sep 2000 06:07:49 -0700

I've been thinking of the action associated with renewal as the client 
asking the server "Tell me what addresses are in this IA now and how long I 
can use them".  If the preferred/valid times have changed, it's like a 
lease extension.  If a renumbering event is in progress, the server can 
assign new addresses.  In any event, the server - based on all the 
information the server has about the client - is informing the client of 
the addresses currently in the IA

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 19 Sep 2000 06:39:34 -0700

Let me see if I can successfully summarize the address model we've been 
discussing:

DHCP clients and servers will use Identity Associations (IAs) to manage 
IPv6 addresses.  Each IA will have:

* a unique identifier
* a set of IPv6 addresses
* a renewal time

Clients and servers use the unique identifier to identify the IAs in 
protocol messages.

Each IPv6 has an associated preferred and valid lifetime.  The lifetimes 
are determined by the server and handed to the client.  There are no 
restrictions on the scopes or number of IPv6 addresses in an IA; an IA 
might contain just one IPv6 address or it might contain a collection of 
global-, site- and link-local addresses.

The renewal time defines the time at which the client must contact the 
server to get the current state of the IA (call this "renewing" the 
IA).  The renewal time is independent of the address lifetimes of any of 
the lifetimes of the IPv6 addresses in the IA.  It makes most sense for the 
renewal time to be less than the valid lifetimes of all of the IPv6 
addresses in the IA.

When the client renews an IA, the server tells the client about the current 
set of IPv6 addresses in the IA.  The server may change the set of 
addresses or the lifetimes of existing addresses during this renewal.  For 
example, setting a longer lifetime on an address already in the IA is the 
equivalent of extending the lease on a DHCPv4-managed address.  Leaving an 
address out of an IA marks it immediately as no longer valid for the 
client.  Adding a new address to the IA can be used for renumbering.  In 
any event, the server is authoritative about the set of addresses and 
lifetimes in the IA.

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Tue, 19 Sep 2000 11:46:04 -0400

>renewal time to be less than the valid lifetimes of all of the IPv6 

SHould be less than the preferred times.

>any event, the server is authoritative about the set of addresses and 

Have to watch for DOS attacks as in IPv6 Stateless where router sends
zero valid lifetimes with Router Advertisement.  Also if a server does
not return an address which may have valid lifetime left and telnet
running the connection will be broken as a note.

regards,
/jim

---

From: Ralph Droms <[email-masked]>
Date: Tue, 19 Sep 2000 18:32:41 -0700

At 11:46 AM 9/19/00 -0400, Jim Bound wrote:
>It makes most sense for the

Agreed...

> >In
>zero valid lifetimes with Router Advertisement.

This DOS attack would come from a malicious server?

>Also if a server does

Yes.

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Wed, 20 Sep 2000 12:40:47 -0400

>This DOS attack would come from a malicious server?

I think thats the catch.  But then again my reading of a lot of
discussion is that the IETF community trusts servers more than say other
nodes sending stuff in client server protocol like DHCP.  I just
mentioned it as heads up.  

Thomas you know this stuff pretty well from stateless addrconf can you
comment for us?  thanks (note all I did was implement what thomas
specified in addrconf in this space about only 20 lines of new code).

/jim

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 20 Sep 2000 20:34:38 -0700 (PDT)

Ralph,

> [...]

I think the last sentence is actually too much of a simplification.
First of all, for addresses that are fully in use ("preferred" in RFC 2462
terminology i.e. they are neither "deprecated" or "invalid")
you'd really want the renewal time to be less than the shortest preferred
lifetime. This is to ensure that an address doesn't "accidentally" become
deprecated or invalid before the IA is renewed. Thus there has to be
some fudge to allow for the DHCP message exchange necessary to
renew the IA.

But this is not a hard rule. For instance, I expect there will be cases
when a preferred and/or valid lifetime for an address is forced to
zero as part of a renewal. Clearly in  this case the next renewal time should
not be zero.

> any event, the server is authoritative about the set of addresses and 

Hmm, it isn't obvious that we need another way to invalidate an address
(by leaving it out from the IA). Isn't it sufficient to be explicit about
invalidating an address by including it with a zero valid and preferred
lifetime?

   Erik

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Sep 2000 00:04:55 -0700

> invalidating an address by including it with a zero valid and preferred

This requires the server to remember that the client had that address,
so it's actually not a simplification - it makes additional work for
the server, which now has to track the administrative removal of
non-renewable addresses.

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Thu, 21 Sep 2000 15:59:08 -0400

>invalidating an address by including it with a zero valid and preferred

My thought was that specifying that the server send a complete list of only 
the client's currently valid addresses was actually a simplification - the 
client can simply throw out its old list of addresses and copy down the 
current list from the server.

However, there is a second step - the client has to update the 
configuration of its interfaces with the list of addresses from the 
server.  So, I imagine simply omitting addresses makes the client's job a 
little harder - it has to poke around at each of the interfaces and see if 
any of the addresses on those interfaces were missing from the message and 
must therefore be un-configured.

But, as Ted points out, requiring the server to specifically invalidate 
addresses may make the server implementation more complex - the server will 
have to remember each client's previous list of assigned addresses as well 
as any newly assigned addresses until the client has renewed its IA.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 21 Sep 2000 16:03:32 -0400

At 08:34 PM 9/20/00 -0700, Erik Nordmark wrote:
>lifetime.

Yes, making the renewal time shorter than the shortest preferred lifetime 
would likely be more desirable in most cases.  Without getting overly 
complex or prescriptive, perhaps the text in the spec could say that the 
renewal time MUST be "less than the valid lifetimes of all of the IPv6 
addresses in the IA" for correctness and MAY be "less than the shortest 
preferred lifetime" to be more conservative.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Sep 2000 13:18:25 -0700

> So, I imagine simply omitting addresses makes the client's job a 

I doubt a client would poke the interfaces to see what addresses they
have; rather, it would probably remember what addresses were in its
address association.   I think it needs to do this either way.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Sep 2000 13:22:40 -0700

> preferred lifetime" to be more conservative.

I think the failover protocol takes advantage of the 50% renewal time
to provide consistent lease times, so it may be good to specify that
the renewal time should be something like half the duration of the
valid lifetime, or 80% of the preferred lifetime, whichever is
shorter.   I'd prefer to just say half the valid lifetime, but
it's possible that the valid lifetime could be more than twice as long
as the preferred lifetime.

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Thu, 21 Sep 2000 17:01:16 -0400

>address association.   I think it needs to do this either way.

Right.  That's what I get for trying to guess about implementation
strategies...

In any event, if I've got it right, we can assume the client can
do the right thing to change its address configuration to match
the configuration from the server, and the server need not take
responsibility for remembering the client's previous configuration.

- Ralph

---

From: Thomas Narten <[email-masked]>
Date: Fri, 22 Sep 2000 08:07:35 -0400

Ted,

Sorry to be so long in following up, but it sounds like we're
basically in sync, except that terminology threw things off. Cool.

One thing in your posting though has me thinking.

> think it needs to explicitly tell the server "hey, I'm on a new

My assumption has been that when a node moves to a new link, it would
ask for addresses using the *same* IA. I.e., the client doesn't want
to know that it is on a new link and therefore needs to use a
different IA when asking for new addresses (but that might be in
conflict with your first point above). However, thinking about it, a
mobile client *will* need to know its on a new link, as all sorts of
things change for it if it moves to a new link (i.e, it needs a new
first-hop router). So having it send a different IA when moving
probably probably isn't a big deal either. But is it really necessary
or desirable?

Thoughts?

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 22 Sep 2000 08:16:42 -0400

Ralph,

> any event, the server is authoritative about the set of addresses and 

I think that the only way to force a client to "invalidate" or "stop
using" an address is to explicitely tell it that it now has a zero
valid lifetime. Or, one can be silent (omit an address), but that
*does* *not* invalidate the address and cause the client to stop using
it per se. Rather, the client stops using an address when the
addresses' valid lifetime goes to zero. This happens when it times out
through normal expiration (only), but that can be hastened by having
the server send an update saying "the lifetime has now become 0 (or
some other small value)".

My comparison point is stateless addrconf. One doesn't conclude an
address is no longer valid because routers stop advertising it, one
stops using an address when its lifetime expires. If an address is
omitted from an RA, the client probably doesn't even notice this and
doesn't do anything special.  This would seem to simplify a lot of
things.

Note also, that a DHCP server probably *does* want to include all
addresses, including those that will become invalid *very* soon,
because other nodes may be trying to send traffic to those
addresses. If a client has just restarted, it probably won't remember
that it was using an address in the past, but you want it to configure
all of its addresses. If it doesn't, you could run into an odd
situation where a node might have an address (which could be in a
deprecated state), the client reboots, but after reboot, it no longer
has that address configured. But if it hadn't rebooted, it would. This
would seem to be an undesirable situation. And again, it causes no
problem for a client to assign a valid, but deprecated address to its
interfaces. It won't use that address for new communication it
*initiates*, but it will still accept traffic sent to that. This might
happen if the deprecated address was still in the DNS.

Thomas

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Sep 2000 10:38:25 -0700

> However, thinking about it, a mobile client *will* need to know its
> on a new link, as all sorts of things change for it if it moves to a
> new link (i.e, it needs a new first-hop router). So having it send a
> different IA when moving probably probably isn't a big deal
> either. But is it really necessary or desirable?

Yes, the highly-mobile client has to notice the link transition.   No,
it doesn't need to use a different IA on each link - indeed, it should
not.   The IA that notices link state changes is for its care-of
address.   The second IA is for its home address, if it's using DHCP
to allocate that.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Sep 2000 10:43:24 -0700

> Or, one can be silent (omit an address), but that *does* *not*
> invalidate the address and cause the client to stop using it per
> se. Rather, the client stops using an address when the addresses'
> valid lifetime goes to zero.

The way we have talked about this, the client remembers all its
addresses, and the absence of one of these addresses in the response
for an IA indicates that the client should stop using the address
immediately.   We can change to your semantics, but I'm not sure I see
why this would be valuable - in particular, it seems to complicate
things, not make them simpler.   Can you be more explicit in saying
why this is a simplification?   The similarity to stateless addrconf
is a simplification from a protocol perspective, but I'm talking about
implementation here.

> all of its addresses.

I think the way we talked about doing this solves this problem - the
client will never receive a DHCPreply that does not list all the valid
addresses for a particular IA.   The absence of an address in the
DHCPreply means that it is no longer valid.   So a client that's
restarted _will_ get all its addresses.

> If it doesn't, you could run into an odd situation where a node
> might have an address (which could be in a deprecated state), the
> client reboots, but after reboot, it no longer has that address
> configured.

So this can't happen.

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Fri, 22 Sep 2000 15:57:55 -0400

At 08:16 AM 9/22/00 -0400, Thomas Narten wrote:

>addresses' valid lifetime goes to zero.

Can't we define explicitly define those semantics within DHCP?  That
is, can't we define a model in which the client and server agree that
the server will send exactly the current state of the IA - the
current list of addresses associated with the IA.  With such a model,
the server would resend every address that continues to be in the IA
and drops those that are no longer in the IA.

>>My comparison point is stateless addrconf. One doesn't
>>conclude an address is no longer valid because routers
>>stop advertising it, one stops using an address when
>>its lifetime expires.

I can understand the desire to be compatible with stateless
autoconf.  But DHCP allows for host-specific configuration
information, rather than information multicast to
many hosts.  So the problem space is a little different,
I think.  I don't see where omitting some of the addresses
sent from a host to a client simplifies anything - that
list of addresses is just the current state for the
client - while explicitly invalidating some addresses
complicates the server logic by requiring that the server
keep track of the client's previous state.

In fact, specifically invalidating addresses complicates
the protocol logic because, as Kim Kinnear pointed out
to me earlier today, DHCP really manages a database of
configuration information that's distributed among the server
and the clients.

If the server must explicitly invalidate
client addresses, it must know what those addresses are.
Easy enough, if the client and server are in sync.  But,
to guarantee correctness in the case that the client
and server are out of sync, the server must know reliably
what addresses the client has in the IA (the server can't
assume that it's version of the IA is the same as the
client's).

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 - changing the lifetimes on some addresses,
explicitly invalidating some addresses and adding new
addresses.  That seems more complicated to me than the
server simply sending the client the current, correct,
complete IA.

Agreed...

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Fri, 22 Sep 2000 23:44:44 -0400

Ralph,

The current dhcpv6 does try to emulate what the router does in stateless
addrconf but with the obvious need to support as you say all the
knowledge the server must now keep by definition which the router does
not try to in neighbor discovery.  The router of course is truly
stateless.  The complexity to do this is to mirror the addrconf paradigm
as close as possible.  Thus a paradigm shift from DHCPv4.

regards,
/jim

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Sep 2000 21:24:04 -0700

> The complexity to do this is to mirror the addrconf paradigm

Mirroring the behaviour of one system designed for one purpose in
another system designed for a different purpose is not a paradigm
shift.  It is just a design decision that you maked based on a
cost/benefit analysis.  We've talked about the issues involved quite a
bit, although not from this particular perspective.  I don't think
trying to artificially impose similarities between stateless and
stateful autoconfig is a good idea.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Sat, 23 Sep 2000 01:02:43 -0400

>stateful autoconfig is a good idea.

The end result if implemented would be a paradigm shift completely.  It is
what would happen after the design decision was executed.  Also it was
not artificial but real by using the parts in IPv6 that made it
possible.  But, regardless we don't agree on your last point and I did
not send this to debate it but rather as additional data for the
conversation of stateful vs stateless.

Also as I listen to Francis's input we should have taken the design a
step further and did a stateful discovery protocol, then stateful address
protocol, and then one for config parameters that are not addresses. 
And completely left the entire DHCP paradigm maybe.

But what we have to do now is I think just permit the server to not
return the address.  

But if the client still has time left to use that address the connection
should not be broken as I believe that stateless addrconf as a spec is
the architecture for that decision not ours.  So if a server wants to
stop a client from using an address that still has time left they should
have to send the address back to the client with a reduced lease to end
the connection and use of that address.  Or just let it time out and it
will not get it back and in this new model it can't request a new
address really but must look for another one that may exist from
previous REPLY.

regards,
/jim

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Sep 2000 22:37:03 -0700

> the connection and use of that address.

It seems like what you are disputing is how the server notifies the
client that an address must be dropped, not whether it can.   Am I
right?   So what does this have to do with stateless address
configuration?

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Sun, 24 Sep 2000 23:24:40 -0400

>right?   So what does this have to do with stateless address

Yes the issue is how.

In the existing IPv6 implementations and deployed IPv6 nodes when a
router provides a node with an address with valid and preferred
lifetimes, and then later sends another router advertisement but not
with prefixes previously sent.

Example Router Advertisement #1 (to be used for autoconfgiguration so
the A bit is set)

Prefix 44fe::/64
   Valid Lifetime 5 days
   Preferred Lifetime 4 days and 1400 hours 

Then Router Advertisement #2 is

Prefix 33fe::/64
   Valid Lifetime 5 hours
   Preferred Lifetime 3 hours 

When the second Router Advertisement #2 happens it has no affect to the
first Router Advertisement.  The only way the Router can stop use of the
44fe prefix is as follows:

Router Advertisement #3

Prefix 4ffe::/64
   Valid Lifetime 2 hours
   Preferred Lifetime 2 hours

IPv6 does not permit a router to send a zero lifetime unless IPsec is
being used with neighbor discovery.

So what I am stating is that if the server sends back a Reply and there
is no address in the packet which the client is still using and received
from DHCPv6 the client cannot break the IPv6 connections using that address 
per the rules defined in stateless addrconf.  The reason is that addrconf
has defined a behavior and we cannot break that with a stateful
protocol.  Basically stateless holds some rule over the architecture for
implementation.

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Sun, 24 Sep 2000 23:56:18 -0400

So the renewal time will always be less than the preferred lifetime for
a single address?

And the renewal time will always be less than the smallest preferred
lifetime for an address set provided by the server?

regards,
/jim

---

From: Thomas Narten <[email-masked]>
Date: Mon, 25 Sep 2000 07:35:28 -0400

> immediately.

One reason why the above semantics are perhaps not ideal concerns when
both stateless addrconf *and* DHCPv6 happen to be sending out
information about the same address. Sure, one can argue that this is a
misconfiguration, but it will happen sometimes, and the protocol needs
to define the correct behavior in that case. The addrconf spec says
that in all cases, whenever a node gets "new" information (either from
stateless addrconf or DHCP) that new information becomes definitive
and supercedes any information about that address received in the
past. Thus, a "new" DHCP update always overrides a previous stateless
addrconf advertisement and vice versa.  This choice was made to keep
things simple, as it removes corner cases having to do when deciding
whether to believe stateless over DHCP or vice versa.

For example, if an address is being advertised by both stateless and
DHCP, what happens if the DHCP server *omits* that address the next
time the client renews an IA? Should the client now assume the address
is no longer valid? But does it then also need to remember that it
learned that address via stateless addrconf, and shouldn't invalidate
it?

To me, it seems cleanest to say all addresses have explicit
lifetimes, and the only way to invalidate an address is:

1) have the lifetime go to zero (something the client does should it
   not receive an updated lifetime via DHCP or stateless addrconf)

2) Use DHCP or stateless addrconf to send an update with new lifetimes
   that force step 1) to happen more quickly in those cases where this
   is the desired outcome.

Here is specific scenario where the invalidate implicitely model may
result in incorrect behavior. Consider a misconfiguration where the
same address is being advertised via stateless and DHCP. Suppose the
sys admin determines the misconfiguration and attempts to correct it
by having address/prefix advertised only via statless. The sys admin
then updates the DHCP config file and on the next DHCP update, the
DHCP server omits the address at question. In this case, you do not
want the client to invalidate the address, as it is also being
advertised by stateless. But the client would have already forgotten
that information, unless it remembered the last router advertisement
(something that it is not required to do). If the DHCP semantics were
that an address becomes invalidated only when the lifetime reaches
zero, having DHCP stop advertising the prefix would not cause the
client (in this case) to improperly stop using and address. On the
other hand, if the DHCP semantics resulted in invalidating an address
through omission of the address, the client would invalidate the
address immediately, and it would not become valid again until it
received a new advertisement via stateless (this can take as long as
30 minutes, BTW).

Thomas

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Sep 2000 13:02:21 -0700 (PDT)

> the server, which now has to track the administrative removal of

Got it. Thanks.

  Erik

---

From: Ralph Droms <[email-masked]>
Date: Mon, 25 Sep 2000 12:14:40 -0400

Tomas - in general I see your point.  In the particular case you cite:

>learned that address via stateless addrconf, and shouldn't invalidate

According to the stateful/stateless interaction rule: "a "new" DHCP update 
always overrides a previous stateless addrconf advertisement and vice 
versa."  I would interpret that rule to say that the DHCP message overrides 
the stateless addrconf and the client should invalidate the address...

The more interesting case might be if a stateless addrconf message 
advertises a prefix unknown to the DHCP server.  In the case of implicit 
invalidation ("invalidation b omission"), what does the client do if the 
DHCP server does not return an address within that prefix in the IA?

Here's another interesting case: what does the client do in the server 
explicitly invalidates an address within a prefix advertised by stateless 
addrconf?

Under what circumstances would a host be using both stateful and stateless 
addrconf?

Of course, I may be confused about the operation of stateless addrconf; 
please feel free to correct me (as gently as possible!)...

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Sep 2000 09:18:47 -0700

> per the rules defined in stateless addrconf.

Yes, I understand that.   But you are talking about an implementation
detail, rather than about a goal.   It seems like the goal is that the
protocol should not cause a client to drop an address when it doesn't
have to.    Right?

I'm very uncomfortable with drawing parallels to stateless address
configuration.   The current draft does things the way stateless
address configuration does them, and because this is a state*ful*
protocol and not a state*less* one, this makes the protocol more
difficult to understand and implement than it needs to be, IMHO.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Sep 2000 09:32:07 -0700

Okay, I think I can agree then that the absence of an address in a
DHCPreply should not cause the client to drop that address.  I prefer
the other way, but don't have a strong reason for preferring it, and
you've given a good reason for preferring this way.   :'}

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Mon, 25 Sep 2000 12:43:38 -0400

>protocol should not cause a client to drop an address when it doesn't

Yes that is right.  But I do think we will get into situations in the
spec where we can either be silent or state what is to happen.  I think
the mail Ralph just sent to Thomas on stateless will open more light to
this issue for discussion.  I will not respond and let Thomas respond.
Having implemented stateless this is very tricky stuff and what I would
hope is we learn from that experience and from all the IPv6
implementors.

But I am in agreement with Bernies comments in this space and issues.
For the protocol specification. 

>difficult to understand and implement than it needs to be, IMHO.

I think we need to just make sure we don't break stateless stuff and why
I think we are groking all this now.  In defense of the current draft we
did add the stateful parts where appropriate.  But we are now trying to
reduce complexity with things like the IA.  So I think we will reach
less complexity from the mail I see.  But we cannot ignore the stateful
effect to implementations of stateless is the key point we must make
sure in our design choices for the next version of dhcpv6.

But Mike will send out some questions we have today on all the threads
so we can write this stuff down.  One will be the entire IA use and
definition and lots of questions and clarification of that.  For now I
am just assuming it will work and treating it as opaque but we need to
have detailed discussion of the IA.

regards,
/jim
			       _MelloN_