JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <[EMAIL PROTECTED]> writes:

> Good point...I thought in this context we assume vendors implement
> temporary addresses and users configure temporary addresses by
> default.  Otherwise, the original concern:

>   "The IESG is concerned that if temporary addresses are not enabled by
>   default, they won't see widespread use in practice."

The logic is roughly as follows. The more barriers that exist
w.r.t. the usage of temporary addresses, the less likely we'll see
widespread usage.

Today, they are optional. It's certainly a barrier that they have to be
implemented to be used. :-)

But even if they are implemented (say in typical OSes), but not used
by default, who will actually use them? We would have to wait for
individual appications to enable their use. We seem to have experience
in other spaces that getting lots of applications to implement a
desired capability can take a very long time...

> If, for example, the premise is implementing and configuring temporary
> addresses are both optional, I'll be just okay with the proposed
> change.

Today, implementation is optional. I think the document assumes if you
implemente, you want to enable, but can't find exact words on this
right off. 3041 does say, howoever:

   Finally, this document assumes that when a node initiates outgoing
   communication, temporary addresses can be given preference over
   public addresses.  This can mean that all connections initiated by
   the node use temporary addresses by default, or that applications
   individually indicate whether they prefer to use temporary or public
   addresses.  Giving preference to temporary address is consistent with
   on-going work that addresses the topic of source-address selection in
   the more general case [ADDR_SELECT].  An implementation may make it a
   policy that it does not select a public address in the event that no
   temporary address is available (e.g., if generation of a useable
   temporary address fails).


> Users (or administrators) who dare to configure temporary
> addresses under such an environments should have a strong desire for
> privacy.  So, even if the source address selection prefers public
> address by default, such users will explicitly (try to) reverse the
> logic for every communication.  This makes the default meaningless,
> and thus preferring temporary address should make much sense.
> (though the premise would be meaningless according to the original
> motivation; widespread use of temporary addresses)

The default-addr-select document isn't mandating the use of temporary
addresses. So what is being requested here is that *if* temporary
addresses have been implemented and are being used, *then* give them
preference over public addresses.

Thomas
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to