Subject: Re: Issue from San Diego IETF - temporary addresses

From: Thomas Narten <[email-masked]>
Date: Tue, 06 Mar 2001 16:54:09 -0500

> Narten also raised issue of interaction between DHCP and temporary
> addresses. DHCP server can provide temporary addresses by assigning
> addresses with short lifetimes. However, there will be an API
> through which an application can request a temporary address. How
> can the DHCP server indicate to the client which addresses are to be
> "temporary" and which are "permanent"? Narten thinks IESG will
> bounce anything that doesn't deal with temporary addresses. He will
> develop requirements doc so WG can develop solution.

Let me try to summarize the issues. The IPv6 architecture now support
the notion of temporary addresses. Temporary addresses are normal
addresses, i.e., they can be used just like other IPv6
addresses. However, they are designed to be used in cases where the
TCP connection doesn't last forever, i.e., is "short" where short can
mean a few seconds to minutes to hours. It does not mean for weeks or
months. I.e., RFC 3041 suggests that a temporary address be
'preferred' for one day, and become invalid after a week. So its
really intended for connections that don't last very long. Also,
temporary addresses are intended to be uses by applications/devices
that don't want to expose their (permanent) interface identifier to
remote sites.

There is a need for an API so that applications can indicate if they
want to use a temporary vs. a "public" address, i.e., one that that
doesn't change (or at least, doesn't change until there is a
renumbering event, etc.). That is still a TBD item in IPNG and is not
something this WG needs to worry about too much.

For nodes using stateless autoconfiguration, RFC 3041 describes how
temporary addresses are created, when they expire, etc. DHCPv6,
because it can also be used to assign addresses to nodes, needs to
have a story on temporary addresses. That is, a node should be able to
use temporary addresses regardless of whether stateless or stateful
address autoconfiguration is needed. Thus, the DHCPv6 spec needs to
say how temporary addresses are created and/or assigned when DHCPv6 is
used.

Note that RFC 3041 makes it clear which addresses are "temporary" and
which are not, and the address selection document
draft-ietf-ipngwg-default-addr-select-02.txt makes recommendations on
what to do with temporary addresses. I.e., it is a property of the
address whether it is temporary or not, and that property is exploited
in other parts of the IPv6 architecture.  So I believe what DHCPv6
needs to do is define the mechanics for how temporary addresses are
assigned to nodes.

> Shouldn't this say "How can the DHCP client indicate to the server
> which addreses are to be "temporary" and which are "permanent"? It
> is after all the client that might have an understanding of how long
> the address is desired.

I would turn it around. One possible way of providing temporary
address support in DHCP is to allow (require?) that the client request
(via DHCP) that it wants temporary address(es) in addition to regular
addresses. Note I am not saying the client says how many or anything
other than "it does want temporary addresses". The DHCP server then
*could* return a set of addresses, with the temporary addresses
flagged with a special indication so that the client knows they are
temporary (this is needed for the address selection rules mentioned
earlier).

> As the client will send an "Identity Association Option" to request
> address(es), couldn't this simply be communicated via a lease
> request time? Though there probably is no good field to store this
> in.

I don't think you want to overload lease time for this
purpose. Temporary addresses are semantically different than addresses
with a short lease. 

> And, then we should perhaps ask WHY DOES THE SERVER CARE? If the
> client wants a short lease, the server simply grants it the
> address(es) for however long the server policy dictates. If the
> client doesn't want to use the address after a period of time, it is
> ALWAYS able to RELEASE it whenever it is done. Even if it doesn't
> release it but instead simply lets it expire, what's the harm? There
> should be plenty of addresses available in IPv6.

The client doesn't just want a short lease. It wants a temporary
address (in addition to a public address). When its current temporary
address expires, it will want to get a new one that is  different than
the one it had before. If the client just requested a new address with
shorter lease, it might just get back the one it just had, which
defeats the reason for having temporary addresses.

> Of course, the requirements document might help answer why Thomas
> feels there is a need to have a mechanism to explicitly request
> these temporary addresses. Perhaps the reason for the 'temporary'
> addresses is that they are supposed to be 'random' instead of based
> on the EUI-64 identifier of the client; but as a previous message
> pointed out nothing has been said as to how a DHCP server will
> assign addresses.

Not random, but changing over time and not to be reused in a
predictable way.

Thomas

---

From: [email-masked]
Date: Tue, 6 Mar 2001 18:23:43 -0600

Thomas,

I went and checked 3041 and src addr select 02.  More response.

> that don't want to expose their (permanent) interface identifier to

Also 3041 states the main goal is to remove the use of a constant identifier
in IPv6 such as the EUI and was the intention of the IPv6 WG supporting this
work.  3041 even says:2.1.  Extended Use of the Same Identifier

   The use of a non-changing interface identifier to form addresses is a
   specific instance of the more general case where a constant
   identifier is reused over an extended period of time and in multiple
   independent activities.  Anytime the same identifier is used in
   multiple contexts, it becomes possible for that identifier to be used
   to correlate seemingly unrelated activity.  For example, a network
   sniffer placed strategically on a link across which all traffic
   to/from a particular host crosses could keep track of which
   destinations a node communicated with and at what times.  Such
   information can in some cases be used to infer things, such as what
   hours an employee was active, when someone is at home, etc. 

AND  

   The use of a constant identifier within an address is of special
   concern because addresses are a fundamental requirement of
   communication and cannot easily be hidden from eavesdroppers and
   other parties.  Even when higher layers encrypt their payloads,
   addresses in packet headers appear in the clear.  Consequently, if a
   mobile host (e.g., laptop) accessed the network from several
   different locations, an eavesdropper might be able to track the
   movement of that mobile host from place to place, even if the upper
   layer payloads were encrypted [SERIALNUM].

So the core issue is eavesdroppers of constants within an address.

Then 3041 states:

2.4.  Possible Approaches

   One way to avoid some of the problems discussed above is to use DHCP
   for obtaining addresses.  With DHCP, the DHCP server could arrange to
   hand out addresses that change over time.

This we can do.  But read on.

> something this WG needs to worry about too much.

This is just a knob an API is not needed.  We have these all over IPv6
implementations today.

> say how temporary addresses are created and/or assigned when DHCPv6 is

This is not entirely correct.  3041 does not tell how to create them but
only how select that an address has a temporary context based on the
lifetimes used for the addresses.  By the way what is unclear in 3041 is
whether the router or the host alters the lifetimes.  That needs to be
fixed.  My assumption is that its the host and not the router.

Also none of this is mandatory for IPv6 or it would never have gotten thru
IPng or me. Recall our conversation about this at last call?  And as is
pointed out in 3041:

   Use of the extensions defined in this document may complicate
   debugging and other operational troubleshooting activities.
   Consequently, it may be site policy that temporary addresses should
   not be used.  Implementations may provide a method for a trusted
   administrator to override the use of temporary addresses.

> which are not, and the address selection document

No they do not.  What they do is give an algorithm to set the lifetimes as
follows using these constants:

TEMP_VALID_LIFETIME -- Default value: 1 week.  Users should be able
          to override the default value.
TEMP_PREFERRED_LIFETIME -- Default value: 1 day.  Users should be
          able to override the default value.
REGEN_ADVANCE -- 5 seconds
MAX_DESYNC_FACTOR -- 10 minutes.  Upper bound on DESYNC_FACTOR.
DESYNC_FACTOR -- A random value within the range 0 - MAX_DESYNC_FACTOR.
          It is computed once at system start (rather than each time
          it is used) and must never be greater than
          (TEMP_VALID_LIFETIME - REGEN_ADVANCE).

As one who has written the code and shipped in the market stateless addr
conf one could set a bit or switch that once the algorithm in 3041 is
executed set a bit that this address has undergone the processes to become
temporary.

But to state that an IPv6 address can be identified for example from tcpdump
output by looking at the address as literal, hex, or binary format is not
true.  

An address being temporary is a state and context in an implementation.  

> needs to do is define the mechanics for how temporary addresses are

I don't agree with you but will make a proposal for the design meeting the
week before the IETF.  Also this part of src addr select has no consensus
yet.  I for one will object to perferring temporary over public as default.
But that is an IPng issue.

But the main point here is that there is nothing to identify an address as
temporary or public anywhere in IPv6 and we should not do that in IPv6.

> addresses.

Thats silly Thomas.  It is a question of the lease which you deny below.

> Note I am not saying the client says how many or anything
> earlier)

What.. There is nothing in IPv6 to identify an IPv6 address as temporary in
stateless and should not be in DHCPv6.  

Your pushing something into DHCPv6 that does not exist elsewhere and thru
sophistry rhetoric using src addr select saying it exists elsewhere and it
does not.

> purpose. Temporary addresses are semantically different than addresses

NO THEY ARE NOT.  Defend this or I suggest this is NOT TRUE.

> defeats the reason for having temporary addresses.

What Ralph stated is 100% correct based on rfc 3041.  Your loosing me
totally.

> Not random, but changing over time and not to be reused in a

The predictability per 3041 is possible to alter.  I would argue that we do
not even have the same problem unless we use the link-local address from
clients as the low order 64bits to hand out an address.  And in that case we
can use the same algorithm.

As in the past your input again is very very very late.  We asked you to
respond over a month ago.  Or do you get special priviledges as an IESG
member?

/jim

---

From: [email-masked]
Date: Fri, 9 Mar 2001 09:26:30 -0600

Thomas,

I think we are in synch now so lets solve the problem.

thanks
/jim

> -----Original Message-----
> From: ext Thomas Narten [mailto:[email-masked]]
> Sent: Friday,March 09,2001 9:09 AM
> To: DHCPv6 discussion list
> Subject: Re: Issue from San Diego IETF - temporary addresses 
> 
> 
> Catching up on a number of postings..
> 
> [email-masked] writes:
> 
> > There is no way to differentiate a temp addr from other addr
> > semantically.  Please give us an example I don't see this in src
> > addr select at all.  In fact there are no bits in IPv6 addr arch
> > anywhere to support this.
> 
> I agree that there is no way to distinguish temporary addresses from
> other ones by looking at them (i.e., syntactically). But there are
> times when an implementation needs to know whether an address is
> temporary or not. Hence, if DHCP is to be used to send temporary
> addresses from the server to the client, there will need to be a way
> to flag this. E.g., a bit in the extention.
> 
> Note: the addr-select document in the ID directory is old. Per a note
> to the IPNg list:
> 
> "Richard Draves" <[email-masked]> writes:
> 
> > I submitted these twelve hours before the deadline, but somehow they
> > didn't get there in time:
> 
> > 
> ftp://ftp.research.microsoft.com/users/richdr/draft-ietf-ipngw
> g-default-addr-select-03.txt
> > 
> ftp://ftp.research.microsoft.com/users/richdr/draft-draves-ipn
> gwg-router-selection-01.txt
> 
> Temporary addresses are described in the default-addr-select document.
> 
> > Putting on my IPv6 hat I got to say that your statement that
> > temporary addresses are part of the IPv6 address architecture is NOT
> > TRUE.  Its an appeasement for paranoids.
> 
> I suspect we're having a disagreement over terminology more than
> substance. Temporary addresses exist, they are part of the overall
> IPv6 picture. Not everyone needs to implement them. But because they
> are part of the overall picture, and they fit in with the existing
> IPv6 architecture, I say they are part of the architecture.
> 
> > > 
> We're in agreement, just differing on terminology. I'm assuming "new
> API" means extensions to the existing ones (i.e., the basic API).
> 
> Note also that if an application can indicate (through the API) that
> it does (or does not) want temporary addresses used, that is another
> reason why such addresses must be distinguishable within an
> implementation. I.e, source address selection indicates how to choose
> temporary vs. public addresses when the application doesn't care, the
> API is needed so that applications can override the defaults.
> 
> > > 
> The host does the lifetimes.
> 
> We are miscommunicating, as I have never stated that one can identify
> temporary addresses via tcpdump.
> 
> I agree. But *if* DHCP supports temporary addresses by having the
> server send them to the client, there would seem to need to be a way
> for those addresses to be flagged as temporary. Stateless addrconf
> doesn't have this issue because its all internal to the implementation
> (e.g., not on the wire).
> 
> Also, I'm not saying that DHCP has to support temporary addresses this
> way. Another approach would be for the the DHCP server to send the
> client the routing prefix and then have the host do everything else,
> ala 3041. I wonder though if this is the "right" model in an
> enviroment where DHCP is being used. I.e., presumably a site using
> DHCP wants to know  *ALL* the addresses that are in use and by whom,
> and having the client generate them would not support this. This is
> something the WG needs to work through.
> 
> Note: I'm not responding to some of your other points because I think
> they all result from a more basic disagreement that is addresses
> earlier in this note. Those may need to be revisited if this note
> isn't clarifying things.
> 
> Thomas
>

---

From: [email-masked]
Date: Fri, 9 Mar 2001 11:30:46 -0600

Thomas,

> Temporary addresses are described in the default-addr-select document

Not guy.  No change in wording. Just points to rfc 3041.  We have just done
more in the dhcpv6 to support I think what someone wants than anywhere else
in the ietf. 

Next mail is to IPng where I will vehemently object to temporary addresses
being preferred over public addresses.

/jim