Subject: RE: Temporary Address Solution

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 6 Mar 2001 21:34:50 -0600

Jim:

I think I responded to Ralph's posting of the temporary address issue (then Thomas responded to that) with some of the questions/issues regarding the need for special processing of temporary addresses.

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

Some of your comments below also potentially introduce problems. For example, you state that a temporary address cannot be renewed. However, why can't a client do a renewal (or rebind) on the address? Seems like a client that thinks it might have changed networks might want to renew the address to make sure it is still usable on the network. I can understand it if you want to prevent temporary addresses from having their lease times extended (ie, if the address is valid for a week, the server never would extend it beyond that week but would allow renewals - granting the remaining time on the lease). But renewals until then should be allowed. [Again, I question the need for any special processing in DHCPv6 for this issue.]

If we really want this, perhaps another option (no pun intended) is simply to have two options - one that requests 'permanent' addresses and another that requests 'temporary' addresses.

Sounds like this might be a good agenda item for the conference call next week?

- Bernie Volz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 06, 2001 10:16 PM
To: DHCPv6 discussion list
Cc: [email-masked]
Subject: Temporary Address Solution

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: [email-masked]
Date: Wed, 7 Mar 2001 10:59:45 -0600

Hi Bernie,
 
By the way we (authors) really appreciate you rolling up your sleeves and
working on the spec its appreciated.

.

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

Agree with you on this point. 

Some of your comments below also potentially introduce problems. For
example, you state that a temporary address cannot be renewed. However, why
can't a client do a renewal (or rebind) on the address? Seems like a client
that thinks it might have changed networks might want to renew the address
to make sure it is still usable on the network. I can understand it if you
want to prevent temporary addresses from having their lease times extended
(ie, if the address is valid for a week, the server never would extend it
beyond that week but would allow renewals - granting the remaining time on
the lease). But renewals until then should be allowed. [Again, I question
the need for any special processing in DHCPv6 for this issue.] 

First I question the need to in general. But Thomas is on the IESG and
raised the issue quite elegantly.  We need to address it.  The reason we
cannot do Renew or Rebind is pretty clear if you read rfc 3041.  The object
is to make sure temporary address tokens or parts cannot be learned on the
network from repeated use.  If we let a client Renew and Rebind a Temporary
address that point is defeated in rfc 3041   There is no reason to Renew if
the lease has not expired and other servers should not be giving out
Temporary addresses in our Rebind state.  The Confirm is fine fyi.

If we really want this, perhaps another option (no pun intended) is simply
to have two options - one that requests 'permanent' addresses and another
that requests 'temporary' addresses. 

I went down that path while eating dinner last night after seeing Thomas's
mail.  But I think setting a bit in the addr status does the same thing.  I
don't care that would be fine with me too. 

Sounds like this might be a good agenda item for the conference call next
week?  

Yes I agree.  I just don't want this or any other issue hold us up wrapping
up this spec to get to last call to the IESG so we can get folks writing
code and for this spec they will not do that until we hit PS because we have
been working on this for some time.  I think fyi this latest specs are
really really good so just trying to keep the ball rolling.

thanks

/jim

---

From: [email-masked]
Date: Thu, 8 Mar 2001 09:40:01 -0600

Bernie

I'll read RFC 3041 again. I did recently, but more skimmed it rather than
studied it carefully. 
 
OK 
 
If we're OK with IPv4 like behavoir with IPv6 when using DHCP, then one
question that I've raised several times comes up again ... what are the
recommendations for HOW a DHCPv6 server is supposed to 'generate' addresses?
If we ignore the multiple addresses per prefix for the moment (ie, IA),
should DHCPv6 servers EVER generate IPv6 addresses based on the client's
[IEEE] hardware identifier? If we say no it should not, than at worst case
you'd have the same lower address bits every time you connected to a
particular network (however you'd have different addresses on different
networks). Hence, you'd only be leaking as much information as IPv4 does.
Your at home lower address bits would not be the same as your at work lower
address bits since different DHCP servers would be used to generate the
address. 
 
I think we do not want to prohibit dhcpv6 from doing the same function as
router prefix advertisements but that case is handled by the client I
believe.  We avoid the problem by simply doing what I suggest and giving
context to addresses that are temporary and its a done deal.  We don't have
to worry about it again.
 
You have not told me anything that is wrong with what I proposed and it
solves the problem completely.  Open to hearing why you don't think it
solves the problem and what I may be missing as always.

Of course, we might want to improve things even more with IPv6 and not
reassign the same address even when you reconnect to the network. This would
be what the temporary address request could be used for. 
 
No. Temporary address has now a context per Thomas' mail.  We need to now
differentiate temporary from public that is the issue.  If we don't do that
then we are not solving the needs of that requirement .
 
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). 
 
That does not solve the problem as Thomas pointed out in his response to
Ralph.   
 
We could still let clients 'renew' the 'temporary' address, but only until
the lease time is up. The server would never extend the lease time (it would
just give the client the time that remains on the original lease). A client
would normally not renew 'temporary' addresses, except if it needed to
confirm for some reason (such as it was disconnected from the network or
rebooted) whether the address was still valid.  
 
Your first sentence is just the confirm request.  We should not allow renew
or rebind.
 
thanks
/jim

---

From: [email-masked]
Date: Thu, 8 Mar 2001 10:20:44 -0600

folks it appears ms mail is hosing me here is my reply to bernie again

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday,March 08,2001 10:40 AM
To: DHCPv6 discussion list
Subject: RE: Temporary Address Solution

Bernie

[JPB] ** OK 

[JPB] *** I think we do not want to prohibit dhcpv6 from doing the same
function as router prefix advertisements but that case is handled by the
client I believe.  We avoid the problem by simply doing what I suggest and
giving context to addresses that are temporary and its a done deal.  We
don't have to worry about it again.
 
[JPB] ** You have not told me anything that is wrong with what I proposed
and it solves the problem completely.  Open to hearing why you don't think
it solves the problem and what I may be missing as always.

[JPB] *** No. Temporary address has now a context per Thomas' mail.  We need
to now differentiate temporary from public that is the issue.  If we don't
do that then we are not solving the needs of that requirement .

T[JPB] ** That does not solve the problem as Thomas pointed out in his
response to Ralph.   

[JPB] ** Your first sentence is just the confirm request.  We should not
allow renew or rebind.
 
thanks
/jim

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 8 Mar 2001 15:00:22 -0600

Jim:
 
I do think we are basically in agreement.
 
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).  
 
[JPB] ** That does not solve the problem as Thomas pointed out in his response to Ralph.   
 
All I was trying to say here is that when a DHCP client requests a temporary address (whatever form that request takes), there are three fundamental differences for the DHCP Server:
- Don't assign the same address(es) that might have been previously assigned for that IA.
- Don't use a fixed identifier (such as the IEEE MAC address) to generate the address(es). [This wasn't explicit in my comment above.]
- Use a potentially different lease time and/or lifetimes for the address. Perhaps stated another way is that the lease time, T1, and T2 times for the IA simply don't apply to "temporary" addresses. Once the client has the address, it simply uses it until the valid lifetime for the address expires. Yet, from the DHCP Servers perspective, it would need to track this address is being in-use until the lifetime expires (or "lease" time expires, it might set the lease time to the lifetime).
 
Are Releases for "temporary" addresses allowed if the client wants to give up the address earlier? I'd say yes.
 
>From what you've said, neither the Renew or Rebind requests would ever include temporary addresses in the IA. A Confirm request is allowed to include it. Now, what happens on the Reply for these (Renew, Rebind, Confirm)? Is the server supposed to reply with the "temporary" addresses for an IA. I would assume you would say NO.
 
One issue to be aware of is what happens if a server has no XID cache (Section 18.4 of the -17 draft says "a server implementation MAY include an in memory transaction-ID cache"). So, if a server has no cache and the client fails to receive the Reply for a Request (the server did assign the temporary addresses)? When the server gets the retransmitted Request, how does it know whether to assign a new set of "temporary" addresses or not? I guess the server should assume that since the remaining preferred lifetime on the previously assigned temporary addresses is still mostly there, to resend those rather than assigning new ones (otherwise you have a nice attack to use up addresses). OR, perhaps we should change the "MAY" to a "SHOULD" when we include "temporary" address support. Or perhaps a server must keep the XID of the Request associated with "temporary" addresses if it has no cache.
 
- Bernie
 
PS: The -17 draft has no description (that I could easily find) of the "addr status" field in the IA. Is this were you and Ralph thought the temporary/public flag would go? Also, the -17 draft references the IA option's "status" field in many places. I think this should be "IA status" in most instances.

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday,March 08,2001 10:40 AM
To: DHCPv6 discussion list
Subject: RE: Temporary Address Solution

Bernie

I'll read RFC 3041 again. I did recently, but more skimmed it rather than studied it carefully. 
 
[JPB] ** OK 
 
If we're OK with IPv4 like behavoir with IPv6 when using DHCP, then one question that I've raised several times comes up again ... what are the recommendations for HOW a DHCPv6 server is supposed to 'generate' addresses? If we ignore the multiple addresses per prefix for the moment (ie, IA), should DHCPv6 servers EVER generate IPv6 addresses based on the client's [IEEE] hardware identifier? If we say no it should not, than at worst case you'd have the same lower address bits every time you connected to a particular network (however you'd have different addresses on different networks). Hence, you'd only be leaking as much information as IPv4 does. Your at home lower address bits would not be the same as your at work lower address bits since different DHCP servers would be used to generate the address. 
 
[JPB] *** I think we do not want to prohibit dhcpv6 from doing the same function as router prefix advertisements but that case is handled by the client I believe.  We avoid the problem by simply doing what I suggest and giving context to addresses that are temporary and its a done deal.  We don't have to worry about it again.
 
[JPB] ** You have not told me anything that is wrong with what I proposed and it solves the problem completely.  Open to hearing why you don't think it solves the problem and what I may be missing as always.

Of course, we might want to improve things even more with IPv6 and not reassign the same address even when you reconnect to the network. This would be what the temporary address request could be used for. 
 
[JPB] *** No. Temporary address has now a context per Thomas' mail.  We need to now differentiate temporary from public that is the issue.  If we don't do that then we are not solving the needs of that requirement .
 
 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). 
 
T[JPB] ** That does not solve the problem as Thomas pointed out in his response to Ralph.   
 
We could still let clients 'renew' the 'temporary' address, but only until the lease time is up. The server would never extend the lease time (it would just give the client the time that remains on the original lease). A client would normally not renew 'temporary' addresses, except if it needed to confirm for some reason (such as it was disconnected from the network or rebooted) whether the address was still valid.  
 
[JPB] ** Your first sentence is just the confirm request.  We should not allow renew or rebind.
 
thanks
/jim

---

From: [email-masked]
Date: Fri, 9 Mar 2001 10:16:50 -0600

Hi Bernie,

[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).  
 
[JPB] ** That does not solve the problem as Thomas pointed out in his
response to Ralph.   
[JPB2]  Well Thomas suggested we not ruleout Renew.  But for this draft I
suggest we do and keep it very simple.  The problem is that we do not want
to permit an eaves dropper to determine anything from a temporary address
bits on the wire.  My response was saying there is more to supplying
temporary addresses than just changing the lease. 
 
All I was trying to say here is that when a DHCP client requests a temporary
address (whatever form that request takes), there are three fundamental
differences for the DHCP Server:
- Don't assign the same address(es) that might have been previously assigned
for that IA.
- Don't use a fixed identifier (such as the IEEE MAC address) to generate
the address(es). [This wasn't explicit in my comment above.]
- Use a potentially different lease time and/or lifetimes for the address.
Perhaps stated another way is that the lease time, T1, and T2 times for the
IA simply don't apply to "temporary" addresses. Once the client has the
address, it simply uses it until the valid lifetime for the address expires.
Yet, from the DHCP Servers perspective, it would need to track this address
is being in-use until the lifetime expires (or "lease" time expires, it
might set the lease time to the lifetime).
[JPB2]  This is a good point about T1 and T2.  We need to discuss. 
 
Are Releases for "temporary" addresses allowed if the client wants to give
up the address earlier? I'd say yes.
[JPB2] I would say yes too. 
 
>From what you've said, neither the Renew or Rebind requests would ever
include temporary addresses in the IA. A Confirm request is allowed to
include it. Now, what happens on the Reply for these (Renew, Rebind,
Confirm)? Is the server supposed to reply with the "temporary" addresses for
an IA. I would assume you would say NO.
[JPB2] I believe a server MUST always respond to a client even if just error
status. 
 
One issue to be aware of is what happens if a server has no XID cache
(Section 18.4 of the -17 draft says "a server implementation MAY include an
in memory transaction-ID cache"). So, if a server has no cache and the
client fails to receive the Reply for a Request (the server did assign the
temporary addresses)? When the server gets the retransmitted Request, how
does it know whether to assign a new set of "temporary" addresses or not? I
guess the server should assume that since the remaining preferred lifetime
on the previously assigned temporary addresses is still mostly there, to
resend those rather than assigning new ones (otherwise you have a nice
attack to use up addresses). OR, perhaps we should change the "MAY" to a
"SHOULD" when we include "temporary" address support. Or perhaps a server
must keep the XID of the Request associated with "temporary" addresses if it
has no cache.
[JPB2] XID cached is an implementation option not required by dhcpv6.  If
the server gets a Request for Temporary address it reassigns them if no XID
cache.  I am pretty sure we have a good idempotent operation in the protocol
for the Request message regardless of temp or public. 
 
PS: The -17 draft has no description (that I could easily find) of the "addr
status" field in the IA. Is this were you and Ralph thought the
temporary/public flag would go? Also, the -17 draft references the IA
option's "status" field in many places. I think this should be "IA status"
in most instances.
[JPB2] We added it to the IA format see page 41.
 
thanks
/jim

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sun, 11 Mar 2001 22:41:17 -0600

Jim:

[BV2] Yes, but all it says is "addr status  Status of this address." So, is this an error value (from section 7.4) or is this a flag bits (that type of status), such as this address is a temporary address (which is I think what you wanted to use it for). Perhaps one could have it both ways (success & public address = 00 and success & temporary address = 01), but I suspect we'll find that will get us into trouble. Or, are you thinking of adding another field to the addresses in an IA Option to use for this purpose? Or did I misunderstand you?
 
- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 09, 2001 11:17 AM
To: DHCPv6 discussion list
Subject: RE: Temporary Address Solution

Hi Bernie,

 
[JPB] ** That does not solve the problem as Thomas pointed out in his response to Ralph.   
[JPB2]  Well Thomas suggested we not ruleout Renew.  But for this draft I suggest we do and keep it very simple.  The problem is that we do not want to permit an eaves dropper to determine anything from a temporary address bits on the wire.  My response was saying there is more to supplying temporary addresses than just changing the lease. 

 
>From what you've said, neither the Renew or Rebind requests would ever include temporary addresses in the IA. A Confirm request is allowed to include it. Now, what happens on the Reply for these (Re…
[JPB2] I believe a server MUST always respond to a client even if just error status. 
 
One issue to be aware of is what happens if a server has no XID cache (Section 18.4 of the -17 draft says "a server implementation MAY include an in memory transaction-ID cache"). So, if a server has no cache and the client fails to receive the Reply for a Request (the server did assign the temporary addresses)? When the server gets the retransmitted Request, how does it know whether to assign a new set of "temporary" addresses or not? I guess the server should assume that since the remaining preferred lifetime on the previously assigned temporary addresses is still mostly there, to resend those rather than assigning new ones (otherwise you have a nice attack to use up addresses). OR, perhaps we should change the "MAY" to a "SHOULD" when we include "temporary" address support. Or perhaps a server must keep the XID of the Request associated with "temporary" addresses if it has no cache.
[JPB2] XID cached is an implementation option not required by dhcpv6.  If the server gets a Request for Temporary address it reassigns them if no XID cache.  I am pretty sure we have a good idempotent operation in the protocol for the Request message regardless of temp or public. 

thanks
/jim