Subject: Temporary Address Solution

From: [email-masked]
Date: Tue, 6 Mar 2001 21:16:17 -0600

Folks,

Here is the taxonomy of the solution I can write up fully.  Thomas please
respond especially (thanks).

We should nail this one down on the list and at the design conference before
the meeting if possible and present the status.

This solution addresses I think Thomas's input and actually gives all the
context and end result he requests.
The address is identified as temporary and the lease reflects the ruleset in
RFC 3041.  The other result is that on a client when it gets an address from
a server that address can be identified as temporary or public for such
things as source address selection etc (not that I personally support such
forceful standards in the IETF).  

Each IA address component in dhcpv6 draft-17 has an 'addr status'.

We need to use a bit in the 'addr status' of an address to be defined as
follows:

TEMP_PUBLIC_STATUS 
 Set (equiv to 1) == Address is Temporary
 NoTset (equiv to 0) == Address is Public
 [could make BOOLEAN TYPE too I don't care]

Client Requesting a Temporary Address:
A client may request a temporary address by setting the TEMP_PUBLIC_STATUS
in the addr status field for the address in a Request Message.

A client cannot Renew or Rebind Temporary Addresses (they will be rejected
by the server).  This would defeat the concerns in RFC 3041 otherwise.bv

Server Providing Temporary Addresses:
Server MUST return to the client a Temporary Address who requested one in a
valid Request Message.
The Server MAY also give Clients Temporary Addresses who did not ask for
them.
Server sets the addr status bit TEMP_PUBLIC_STATUS for any addresses which
are Temporary.

Server Processing of leases for a Temporary Address SHOULD use the ruleset
based on current administrative policy for preferred and valid lifetimes for
IPv6 addresses as specified in RFC 3031.

Servers providing only Prefixes:
In a situation where a server only provides a prefix to the clients
link-local address then the above can still take place as discussed.  Except
the responsibility and ownership of randomizing the link-local address IPv6
EUI resides with the Client as stated for Stateless Addrconf in RFC 3041.
The dhcp lease provided to the client for Temporary addresses will still be
done by the server as stated in Server Providing Temporary Addresses above.

regards,
/jim

---

From: Thomas Narten <[email-masked]>
Date: Fri, 09 Mar 2001 09:09:45 -0500

Again, summarizing on a number of postings...

> respond especially (thanks).

This looks basically fine to me. Good work.

> by the server).  This would defeat the concerns in RFC 3041
> otherwise.

I'm not sure we need to be totally absolute here. The idea behind
temporary addresses is that in most cases, a connection won't last
very long so a given temporary address shouldn't be valid for more
than a few hours/days. However, if an application is using the
address, what is the harm in continuing to use that address *by*
*that* *one* *application*?  I.e., it would be enough to deprecate the
address but not invalidate it. Other applications opening connections
would use a different temporary address. So it might make sense to
allow the client extend a lease (and in particular to keep an address
that is in active use from becoming invalid, which would result in
termination of the connection), under the assumption that it knows
what it is doing. Having said that, in practice, I'm not sure this
will really be much of an issue. But do we want to shut the door?

> done by the server as stated in Server Providing Temporary Addresses

This might be the simplest to do, but I wonder if folks that deploy
DHCP will like this model. I.e., clients will be using addresses that
the server doesn't know about. If you are using DHCP to assign
addresses, one reason might be so that the administrator knows exactly
what addresses are being used and by whom.

"Bernie Volz (EUD)" <[email-masked]> writes:

>From my understanding, I still don't see the need for handling these
>addresses specially. It really is a client issue (how it wants to
>treat the address). Recall also that by specifying a different IA, a
>client can request any number of addresses - since each IA represents
>a new request. If a client wants a new address, it can simply
>generate a new IA and request an address for that IA. If the IA space
>(per client) is large enough, then if you want a new temporary
>address every week, go for it (by simply requesting a new address via
>a new IA). If the client wants to limit the time it uses an address,
>it is always free to release it or let it expire (by not renewing
>it).

I'm not sure you want the client to have to use a different IA to
request a new set of temporary addresses. One disadvantage is that
when a client reboots, how does it indicate to the server that all the
previous IAs it used are no longer needed and the server can release
thos allocations? Earlier versions of DHCPv6 had a 'c' bit to handle
this. It would be nice to avoid having that again. (more on this
below.)

"Bernie Volz (EUD)" <[email-masked]> writes:

> Though I don't understand your response to my comment:
>  
> [BV] A 'temporary' address request to the DHCPv6 server would mean
> don't give me the same address for this IA that you might have given
> me in the past and 'lease' the address for the temporary lease time
> (not the full permanent address lease time).

Is there any reason not to treat temporary address very similiar to
the public (i.e., regular) addresses from the server perspective?
I.e., the client can renew if it wants, etc. The *main* difference
would be that the server should deprecate/invalidate the address
(normally) after 1 day/1 week (using the 3041 suggested values). To
get a new temporary address, the server treats it like a
renumbering. Give both the old temporary address (which is perhaps
deprecated) but also the new one (which is still valid). This is
similiar to 3041 in that there is typically one temporary address in
the preferred state, but a bunch of older ones in a deprecated state.
  
> Are Releases for "temporary" addresses allowed if the client wants
>  to give up the address earlier? I'd say yes.

I can't see a reason why not to allow this, and it might be
useful. One example: A client reboots, requests temporary addresses,
and gets a bunch of deprecated ones. The client (since it has
rebooted) knows it has no connections using those addresses, so just
releases them.
  
Thomas