Subject: RE: Temporary Address Solution

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 7 Mar 2001 12:25:53 -0600

Jim:
 
I'll read RFC 3041 again. I did recently, but more skimmed it rather than studied it carefully.
 
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.
 
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.
 
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).
 
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. 
 
- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 07, 2001 12:00 PM
To: DHCPv6 discussion list
Subject: RE: Temporary Address Solution

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: Thomas Narten <[email-masked]>
Date: Fri, 09 Mar 2001 09:09:31 -0500

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

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

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

My take would be that the document should explain that how it assigns
addresses is an important topic with interesting implications, and
give suggestions on what a server should do. It might even make sense
to recommend that server support a number of ways of assiging
addresses (e.g., just use EUI-64 for interface ID, use random numbers,
number sequentially starting at 1, etc.), with knobs in a config file
for selecting which policy one wants.

Thomas