Subject: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt

From: Thomas Narten <[email-masked]>
Date: Tue, 11 Jun 2002 12:19:16 -0400

The IESG has a number of comments on this document. Most of them are
of an editorial nature, and I'll let Rich summarize those in a
separate note.

One issue was substantive and requires WG feedback. The -06 document
specifies that public addresses are to be preferred over temporary by
default. My recollection is that the WG originally had temporary
addresses being preferred, but more recently switched this under
concerns that there were cases where the use of temporary addresses
might harm an application. Thus, the conservative thing to do would be
to prefer public addresses but allow the application (via an API) to
reverse this preference.

The IESG is concerned that if temporary addresses are not enabled by
default, they won't see widespread use in practice. This would
significantly decrease the overall impact that RFC 3041 will have on
reducing the threat it attempts to address.  What the IESG would
prefer seeing is that temporary addresses be given preference by
default, but also include more guidance text in the document to make
it clear that there are cases where the use of temporary addresses by
default may not be appropriate.

The following text has been proposed to address this issue:

Proposed new wording:

   Rule 7: Prefer public addresses.
   
   If SA is a temporary address and SB is a public address, then prefer 
   SA. Similarly, if SB is a temporary address and SA is a public 
   address, then prefer SB. 
   An implementation MUST support a per-connection configuration 
   mechanism (for example, an API extension) to reverse the sense of 
   this preference and prefer public addresses over public 
   addresses. 

   In order for temporary addresses to have their desired effect, they
   must become widely used in practice. The above rule is designed to
   ensure widespread usage and enablement of temporary addresses. It
   is believed that in many cases, temporary addresses can be used in
   place of public addresses without problems. However, there are some
   classes of applications that may fail due to the relatively short
   lifetime of temporary addresses (compared with public addresses) or
   due to the possibility of the reverse lookup of a temporary address
   either failing or returning a randomized name.  Implementations in
   which it is believed that such applications exist MAY reverse the
   sense of this rule and by default prefer public addresses over
   temporary addresses.

   It should also be noted that a simple "prefer" or "don't prefer"
   configuration switch with regards to the default selection of
   temporary addresses is not sufficiently flexible in many cases. In
   practice, it is expected that both client and server applications
   will run on the same devices simultaneously. Client applications
   will generally be able to use temporary addresses, while servers
   will generally need to use public addresses. One possible heuristic
   for distinguishing these cases is to assume that an application
   that invokes a passive open (as its first network usage) is a
   server, while an application that first invokes an active open be
   assumed to be a client.

(Note also, that the above text changes a "may" to MUST with regards
the need to provide a way for individual applications to change the
default via, e.g, a socket option)

Is the above a reasonable way forward? (Individual responses, even if
they are along the lines of "fine with me" would be appreciated, as
this document is needed soon to meet a 3GPP deadline).

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-masked]
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Jun 2002 13:04:52 -0400

I believe that temporary addresses should be available, but they
should NOT be enabled by default.  Many applications will fail in
odd ways if assigned a temporary address.  Temporary addresses are
best viewed as a tool which may enhance privacy but are not applicable
to all situations.  The best default for the API is to assign a 
stable address, and let those apps which can benefit from temporary
addresses request them specifically.

I respect the desire for temporary addresses (and AFAIK I was one of 
the first people to raise concerns about embedding tracable information
in an IPv6 address) but I don't think it's a good idea to effectively
change the API in a way that would break apps at this late date.

Keith

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 11 Jun 2002 13:49:27 -0400

This comment is only on the heuristic:

   One possible heuristic for distinguishing these cases is to assume
   that an application that invokes a passive open (as its first
   network usage) is a server, while an application that first invokes
   an active open be assumed to be a client.

My first reaction is that this heuristic is significantly flawed.

The mapping between "application" and OS-visible objects
(process/program) may not be 1:1; in particular, consider inetd on
most unix systems -- common infrastructure code does the passive open,
and the application isn't started until after the connection is
established.

Even in the case of single-process applications, the server may invoke
some library routine during initialization might do an
under-the-covers active open (e.g., getpwuid() or gethostbyaddr() to
get a character string user or host name for a log entry).

What's more, in the case of TCP, it's largely pointless -- TCP passive
opens do not require source address selection at all.  The networking
API's I'm familiar with typically allow an application to open a port
with wildcarded local address, or to specify the local address in
addition to the port.  In the former case, the peer picks the local
address and it "sticks" for the life of the connection.

In the case of datagram sockets (where there isn't a passive/active
distinction), it might make sense to prefer permanent addresses if the
first activity was the receipt of a packet.

						- Bill

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Jun 2002 22:20:48 +0300 (EEST)

> change the API in a way that would break apps at this late date.

The idea behind temporary addresses is IMO flawed (see
draft-dupont-ipv6-rfc3041harmful-00.txt, there are some other issues too).  

They provide extra privacy in some cases, but are not a magic bullet.  On
the other hand, they make the others' life quite conflict.

Therefore, I'm strongly against preferring temporary addresses.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Jun 2002 00:29:14 +0200 (CEST)

> change the API in a way that would break apps at this late date.

The proposed text is trying to say that temporary addresses are preferable
but that there might be issues (such as applications having problems)
which consistitute a good enough reason to not follow the default.
Thus there is significant freedom for implementors to use their best
judgement based on their knowledge about the applications.

Do you see a problem with this approach?

   Erik

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Jun 2002 19:20:35 -0400

> Do you see a problem with this approach?

absolutely.  it encourages the API to deviate from one vendor to another,
and from one installation to another.  application coders thus can't
count on predictable behavior from one platform to another - if they
care at all what kind of address they want, they always have to do
explicit binds of both source and destination addresses.  worse, it
introduces subtle failure modes where an application that works fine
in one environment will fail in a different but apparently similar 
environment, even though the network seems to be working find otherwise.

The idea that hosts, or administrators, can make reasonable address 
selections without input from the application is just wrong.  The 
application, no the host,  knows what kinds of addresses it needs - 
for some, temporary addresses will do just fine, but others needs stable,
public, globally-scoped addresses.  If this is not communicated 
explicitly then every application will have to do its own address
selection in order to work reliably.  Being able to alter the policy
on a per-host basis is not a good solution, because it makes the 
platform less predictable (see above), and because multiple applications
needing different policies will often run on the same host.
   
I'd far rather see an approach like the following:

1. the API default is to use stable addresses
2. to request a temporary address, do it this way
3. applicatons that don't need stable addresses SHOULD request 
   temporary addresses

I've got some other problems with the document  also - specifically
the idea that link-local addresses are preferable to global addresses.
Global addresses are always preferable because all applications
can tolerate them.  At most, LL addresses should be used only
when there is no other alternative, because some applications 
need to treat them specially (this isn't as bad in v6 as in v4)
But LL addresses should probably be used only when they are 
explicitly specified.

Keith

---

From: Alain Durand <[email-masked]>
Date: Tue, 11 Jun 2002 16:28:11 -0700

>   this preference and prefer public addresses over public

This proposed text means that all the existing clients that
talks to server that uses reverse DNS lookup will need to be
modified to use this new API extension to re-establish an
existing behavior that would otherwise be broken.

Until such an API is standardized and implemented, this seems
to me an hazardous path. Also, this is asking exiting application
who do not care about privacy to pay for the benefits of the new
ones who desire privacy. I would be convinced this is worth
doing if the number of applications that need to change is
limited, and I'm afraid it is not. Does the IESG have data about this?

And, last but not least, is having most of the traffic sent by client
using this privacy extension such a good thing? Although I understand the
desire from some applications for privacy, I'm afraid it would
create network management nightmares when doing traffic analysis.
Can you imagine a large site trying to do snoop/tcpdump
when most of the traffic is RFC3041?

	- Alain.

---

From: Alain Durand <[email-masked]>
Date: Tue, 11 Jun 2002 16:38:07 -0700

> But LL addresses should probably be used only when they are

I would agree there. If an application stores the IP address of its peer 
for future use,
on a multi-interface node, if link-local addresses are used and the 
application
did not kept track of the incoming interface, there would be some issues 
when
it would like to reconnect to its peer.

	- Alain.

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Jun 2002 19:50:49 -0400

> for future use, on a multi-interface node, if link-local addresses are 
> used and the application did not kept track of the incoming interface, 
> there would be some issues when it would like to reconnect to its peer.

that, and any kind of limited-scope addresses are a pain for apps for 
which any of the components of that app are not in the same scope as all
of the others.

Keith

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 12 Jun 2002 17:39:54 +0900

>>>>> On Tue, 11 Jun 2002 19:20:35 -0400, 
>>>>> Keith Moore <[email-masked]> said:

> the idea that link-local addresses are preferable to global addresses.

Please let me confirm: are you referring to Rule 2 of source address
selection?

   Rule 2: Prefer appropriate scope. 
   If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB 
   and otherwise prefer SA. 
   Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then 
   prefer SA and otherwise prefer SB. 

According to this rule, a link-local source address will be preferred
to a global source address for a link-local destination.  I think the
rule is quite reasonable.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 12 Jun 2002 17:57:06 +0900

>>>>> On Tue, 11 Jun 2002 16:38:07 -0700, 
>>>>> Alain Durand <[email-masked]> said:

> on a multi-interface node, if link-local addresses are used and the 

(in theory, the "multi-interface node" should be "multi-link node".
but anyway)

> it would like to reconnect to its peer.

That's true, but IMO this is a bit different issue from address
selection, particularly the issue of source address selection.  Even
if an application avoids using link-local addresses as source address,
it cannot assume the source address of an incoming packet is always a
non-link-local address.  And, if such an application needs to keep the
peer's address of an incoming packet, it will definitely need to keep
the corresponding scope zone.  This is irrelevant to how the
application chooses the source address for outgoing packets.

I agree that scoped addresses introduce additional costs to
application in general, though.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 12 Jun 2002 21:30:37 +0900

>>>>> On Tue, 11 Jun 2002 12:19:16 -0400, 
>>>>> Thomas Narten <[email-masked]> said:

> this document is needed soon to meet a 3GPP deadline).

I'm personally okay with the change, but my honest impression is that
preferring temporary addresses is overkill.

Some detailed, random thoughts:

It may be true that there are people who are concerned about privacy
leakage due to fixed interface IDs.  But is the group really large
that can affect all other's behavior?  I implemented RFC 3041 on the
KAME stack over a year ago and FreeBSD 4.4 shipped with the
implementation last summar, but I've never heard of a user who is
actually using it for daily use.

Of course, the fact I've never seen such a user does not necessarily
mean there is actually no user.  But I'm quite confident there are
only few real requirements for the privacy extension at this moment.
So, we do not have to be in a hurry to prefer the temporary address by
default.

As for the impacts on the applications' behavior, I don't worry so
much.  I've configured my laptop to prefer temporary addresses over a
year (for experiences - I'm not a privacy-conscious guy), and I've
never seen a trouble with the environment.  I admit I'm only using a
limited type of applications (and we cannot be sure about future
applications), but I believe it covers a certain amount of today's
major applications, including pop client, smtp client, www client, ftp
client, ssh client, and DNS resolver.  In particular, I don't worry
about the "relatively short lifetime" through the experience.  The
lack of reverse lookups may be a bit more serious, but, IMO, this
issue is not necessarily specific to the temporary vs public issue and
should be discussed in a wider framework.

BTW: even if we go with the change, I think the following part should
be revised.

>    One possible heuristic

As some other guy pointed out, real world examples are not that
simple.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 12 Jun 2002 21:40:50 +0900

>>>>> On Wed, 12 Jun 2002 17:39:54 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> Please let me confirm: are you referring to Rule 2 of source address

Perhaps you are talking about Rule 8 of destination address selection:

   Rule 8: Prefer smaller scope. 
   If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > 
   Scope(DB), then prefer DB. 

This rule may be sometimes controversial, but I personally think it is
reasonable, because we can (in theory) expect better reachability for
a smaller scope of destinations.  This is especially true for a
link-local destination where we don't need L3 routing.

					JINMEI, Tatuya

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Jun 2002 08:51:02 -0400

> link-local destination where we don't need L3 routing.

Rule #2 is not a problem, rule #8 is.  The problem is that the address
selected for one connection pair may end up getting reused in other
scope.  So if rule 8 results in an LL or SL address being used, there
might be an attempt to reuse that address (perhaps by another application
component) in a different scope.

There really should be a rule to the effect "avoid scoped addresses
if at all possible".

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Jun 2002 09:06:37 -0400

> about the "relatively short lifetime" through the experience.  

I don't think it's reasonable to allow "today's major applications"
to constrain the behavior of all present and future applications.

I work with p2p and distributed systems every day, and trying to 
deal with temporary and scoped addresses really is very difficult 
for them.  If we are not careful we will end up imposing NAT-like
restrictions in IPv6 even if IPv6 does not have NATs.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 12 Jun 2002 22:20:46 +0900

>>>>> On Wed, 12 Jun 2002 09:06:37 -0400, 

> to constrain the behavior of all present and future applications.

Okay, perhaps I was not very good about the wording, but my intention
was to make the discussion more concrete; it seems to me that the
discussion in this thread so far was too abstract (just saying
"applications", "servers" or "clients" are not so meaningful).  I
wanted to provide concrete examples based on real experiences.  I
fully understand that we cannot make a decision just because of
limited and personal experiences at this moment.

					JINMEI, Tatuya

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 12 Jun 2002 10:38:24 -0400

Hi All,

>judgement based on their knowledge about the applications.

Is it optional for a vendor to implement temporary addresses?  Is it optional
for a user to configure site-local addresses on a box (or perhaps even for
a vendor to support them)?

One reason that has been put forth for having a fixed set of address selection
rules is that it will be possible for implementations to know what addresses 
will be preferred, and override that behaviour if desired.

I'm not quite sure how this works when it isn't clear that all vendors will
implement all address types (temporary, site-local, etc.), or that all address
types will be configured for a given system.  This particularly becomes 
problematic when optional address types (temporary, perhaps site-local)
are preferred over required address types (link-local and global).

Margaret

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Jun 2002 17:22:49 +0200 (CEST)

> But LL addresses should probably be used only when they are 

Part of the issue here depends on how the application finds out addresses
of scope less than global. Link-local addresses don't make sense in
the DNS (and site-local don't make sense in the DNS except when a site 
is running a  two-faced DNS).
Thus if the application is going to explicitly be configured to use
a less-than global address, or explicitly use some link-local name resolution
protocol, this isn't likely to cause a problem in practise.

And for the applications, such as routing daemons, that communicate using
link-local (multicast) addresses the specification causes the right behavior -
a link-local source address will be used when the destination is link local.

  Erik

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Jun 2002 11:50:18 -0400

> protocol, this isn't likely to cause a problem in practise.

I can sort of accept that if you explicitly configure an app to use a
limited-scope address, they you deserve whatever you get.  however I
somehow doubt that the vast majority of Internet users will understand
the difference and why choosing an LL or SL address might cause their
app to break.

also, there are other ways to discover an address besides DNS and
explicit configuration - for instance, by looking at a source address
of a received message.  

> a link-local source address will be used when the destination is link local.

I'd certainly consider it acceptable for routing daemons and diagnostic
tools to have to explicitly bind to an LL address.  But I don't see that
as a justification for having the default rules employ limited-scope
addresses when a global address is available.

Keith

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 13 Jun 2002 02:40:07 +0900

>>>>> On Wed, 12 Jun 2002 08:51:02 -0400, 

> component) in a different scope.

(I'm not sure what "reuse" exactly means here, but) It seems to me
that the issue you raised up is how an application treats
(i.e. disambiguates) scoped addresses, rather than (destination)
address selection.  As long as the application may take a particular
numeric address as the destination and the address may be a scoped
one, the application should deal with the weirdness of scoping.  Just
preferring global addresses (when available) does not help the
application.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 13 Jun 2002 02:25:21 +0900

>>>>> On Wed, 12 Jun 2002 10:38:24 -0400, 
>>>>> Margaret Wasserman <[email-masked]> said:

> a vendor to support them)?

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

would not make sense.

If, for example, the premise is implementing and configuring temporary
addresses are both optional, I'll be just okay with the proposed
change.  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)

					JINMEI, Tatuya

---

From: Thomas Narten <[email-masked]>
Date: Wed, 12 Jun 2002 15:20:54 -0400

Keith,

> to constrain the behavior of all present and future applications.

I don't quite follow the logic here. Having the stack, by default,
give preference to temporary over public addresses only means that
they will be used without applications having explicitely asked for
their use. For existing applications, that might cause
surprise/problems in some cases. 

Future applications, on the other hand, still need to be written, and
one could argue they will need to make intelligent choices about
whether the use of temporary addresses will cause problems, and code
accordingly.

I doesn't strike me that giving preference to temporary adddress
"constrains the behavior of future applications".

> restrictions in IPv6 even if IPv6 does not have NATs.

This would seem to follow only if temporary addresses were the only
addresses available. No one seems to be suggesting that and it
wouldn't make sense anyway.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 12 Jun 2002 15:31:17 -0400

Hi Margaret.

> Is it optional for a vendor to implement temporary addresses?

That is my understanding, and I'm sure the topic will come up in the
context of the general node requirements document.

Note that the cellular requirements document we have been working on
has wording now that says "should".

> Is it optional for a user to configure site-local addresses on a box

I'd say yes. There certainly can be no requirement to use them...

> (or perhaps even for a vendor to support them)?

What does it mean to not implement site-local addresses? Would an
implementation reject any packet with a site-local prefix in it? For a
host, I think you'd be hard pressed to not support them. For a router,
I'd assume one has to implement configuration stuff to enforce
boundaries.

> One reason that has been put forth for having a fixed set of address
> selection rules is that it will be possible for implementations to
> know what addresses will be preferred, and override that behaviour
> if desired.

> I'm not quite sure how this works when it isn't clear that all
> vendors will implement all address types (temporary, site-local,
> etc.), or that all address types will be configured for a given
> system.  This particularly becomes problematic when optional address
> types (temporary, perhaps site-local) are preferred over required
> address types (link-local and global).

Addresses can only be preferred if they actually are candidates for
use (e.g, were returned by the DNS, are assigned to an interface,
etc.) Individual rules aren't used unless they apply to the addresses
being considered. So I don't see any immediate problem if a particular
address type isn't used or implemented.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 12 Jun 2002 16:13:37 -0400

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

> 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

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Jun 2002 16:33:35 -0400

> one, the application should deal with the weirdness of scoping. 

I agree with that statement.  But we need to arrange things so that
(outside of things like routing protocols, RD/ND, diagnostics etc.) 
having a SL or LL destination is a rare occurance, so that most
apps don't have to deal with them at all.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 12 Jun 2002 17:06:35 -0400

>I'd assume one has to implement configuration stuff to enforce

For a host, not implementing site-local addresses is approximately
equivalent to treating them exactly like global addresses -- what many
of us do now.  So, never mind :-).

>address type isn't used or implemented.

Makes sense.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Jun 2002 17:15:17 -0400

> whether the use of temporary addresses will cause problems, and code

it still strikes me as the wrong default - it's choosing an option
that will cause some apps to fail over one which will not cause
those apps to fail.  I don't think the privacy issues associated
with public addresses are so bad that it's worth the cost of having
apps fail mysteriously.   and I don't think it's a good idea to 
have a 'default' that varies from one platform to another either.

> wouldn't make sense anyway.

here I'm talking about not just temp addresses but the idea that
getting your app to work right might require second-guessing the
default address selection mechanisms.  i.e. the idea that scoped
addresses might be widely used causes us to try to design a
heuristic that guesses which address is the right one in each case -
one that often prevents the app from working rather than helping
it.  and encouraging use of scoped addresses might end up 
imposing restrictions similar to those imposed by NATs.

I'm trying to find time to write up an I-D that explains this better.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Jun 2002 17:56:22 -0400

> preference over public addresses.

and I think it would be better to say

- allow apps that only need temporary addresses to request  them.
- if they're not supported, no harm has been done - the app can make
  do with public addresses.

rather than placing the burden on apps to explicitly request 
public addresses and changing the present behavior.

address selection is just the wrong place to encourage use of
temp addresses - the address selection code doesn't know the 
app's needs and can't reliably guess them from the information 
at hand.

Keith

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Jun 2002 08:56:23 +0300 (EEST)

On Wed, 12 Jun 2002, Thomas Narten wrote:
[...]
> preference over public addresses.

This seems strong statement, if it is put in short terms like here.

From my perspective, it is OK to prefer temporary addresses _but only if_
using them isn't enabled by default.

(I think it should be easy to take temporary addresses to use if the user 
wishes so .. but never arbitrarily.)

---

From: Robert Elz <[email-masked]>
Date: Thu, 13 Jun 2002 17:02:58 +0700

Date:        Wed, 12 Jun 2002 16:13:37 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

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

When and why did we switch from allowing this kind of address (and
specifying how to make it work) - which is all just fine for those
people who desire to use them, into evangelism for their use ?

In any case, surely which should be preferred needs to be a config option
for the host (perhaps even for the application) which I believe the draft
explicitly allows for.

What we're really discussing here is what should be done when the user of
the host doesn't care - and for that I see no reason at all that temporary
addresses should be preferred over more stable ones.   Of course, in the
model we have at the minute, all addresses really are temporary - the only
issue is with just how temporary they're expected to be.

And to Keith - yes, apps need to get a lot smarter (or perhaps a lot dumber)
about their use of addresses.   That's true now with IPv4 - we've been using
temporary use addresses ever since we started using dhcp for address
assignment.   Addresses come with a lease length, after which they might
be renewed, or might not be.   Applications, and application protocols
simply need to deal with that.  Currently we're surviving largely by
blind luck - that is, the applications that most people use need an address
to be valid for (at least) an order of magnitude less time than typical
address validity (perhaps commonly 2 orders).   So, applications are just
ignoring the issue completely.   To be correct, they shouldn't.

kre

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Jun 2002 08:51:02 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Jun 2002 09:06:37 -0400

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Jun 2002 08:47:43 -0400

> using them isn't enabled by default.

I guess it depends on who does the enabling.  If it's the app that does
the enabling, maybe that's okay.  But I don't think it's reasonable to
let the host or site assign private source addresses to apps if those apps
aren't prepared to deal with them.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Jun 2002 09:01:52 -0400

> ignoring the issue completely.   To be correct, they shouldn't.

I've come to the opposite conclusion - that it's completely unreasonable 
to expect apps (or hosts) to assume the burdens of:

- selecting the "right" address from several alternatives without knowledge 
  of their own location in the network topology and that of all of their
  current and future peers, 
- dealing with multiple addressing realms (limited-scope addresses are 
  another form of this), where the components of an app are not all in 
  the same realm, or
- expecting apps to know enough about network topology to explicitly
  tunnel through (or configure) NATs, and
- continuing operation across address changes without either support in 
  lower layer protocols to do this or a reliable means of propagating
  address change information to everyone who has an old address
  (they don't necessarily have an open connection)

and that to the degree that apps were ever expected to do this, the folks
who expected them to do those things were on drugs.

it's not just that the apps are being expected to make decisions in the
absence of adequate information to make those decisions (as in,
which of the following N addresses is the best one to use?),
it's also unreasonable to impose burdens on every app that are better
handled by the network.  (e.g. the routing system is having scaling 
problems, so we'll let hosts or apps do address selection to avoid 
having multihomed sites defeat provider-based addressing - never mind 
that they are even less prepared to do routing than the routing system.)

We're not "surviving" by blind luck at all - we're "surviving" by 
pretending that the only apps that matter are those which only need
addresses for a short time (e.g. "web and email are typical")
and ignoring the apps that fail when this assumption doesn't hold.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Jun 2002 15:45:17 +0200

>   default, they won't see widespread use in practice."

But in fact that isn't a correct assumption. It's only a certain class of
systems (today's pure-client style PCs or their equivalents) for which the
privacy aspect of temporary addresses makes any sense. For them, a SHOULD rule
for preferring temporary addresses makes sense. But many other hosts (servers
and anything that wants to break out of the client/server restriction) won't
use temporary addresses and will use other privacy mechanisms; so for them
it's simply irrelevant. I think that is the answer to my colleague Roy Brabson's
objection to the proposed change - hosts that have the problem he describes
won't be using temporary addresses anyway. And anyone who attempts to run server
style apps on a host using temporary addresses will get all kinds of trouble
anyway.

But it should be a SHOULD.

   Brian

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
Board Chairman, Internet Society http://www.isoc.org
INET 2002, Washington, DC, 18-21 June http://www.inet2002.org   <<=== seats still available!

>                                 X-Mozilla-Status: 0009

---

From: Alain Durand <[email-masked]>
Date: Thu, 13 Jun 2002 09:17:09 -0700

> preference over public addresses.

The problem I have with this is, if I decide to implement temporary 
addresses
to enable something like Netscape to use it, with the IESG suggestion,
I will also have to revisit at the same time rlogin and many other 
applications that rather like to
use permanent addresses.

This would create a serious burden to first identify all those 
applications
and second to modify them all before I can release support for temporary 
addresses
in the OS.

And as I do not control 3rd party applications, this gets even more 
complex.

So, I'm very worried that the IESG suggestion could end up being a reason
for me not to implement temporary addresses at all.

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Jun 2002 19:32:23 +0300 (EEST)

On Thu, 13 Jun 2002, Alain Durand wrote:
> addresses to enable something like Netscape to use it, with the IESG
> suggestion, I will also have to revisit at the same time rlogin and many
> other applications that rather like to use permanent addresses.
[...]

I cannot see anything application-specific at least in the above quote
from Thomas.

I expect using temporary addresses would be a system-level toggle which 
might be fine-tunable via some API.

...

The user can always shoot himself in the foot.  If there are concerns
(most of them valid, I think) with applications not working properly with 
temporary addresses this should result in something equivalent to:

 1) temporary addresses SHOULD(/MUST) be off by default
 2) develop a better mechanism for privacy, temp-addr v2 (v3? :-) or 
describe the issues with applications and how to avoid them
 3) revisit decision 1) when 2) is analyzed and/or implemented

IMO, "temporary addresses" should only be randomized when:

 1) (re)starting the OS, or
 2) when there are no open sockets (basically 1), or
 3) manually requested (users would be dissatisfied if they couldn't shoot 
themselves in the foot)

In consequence, I think in many cases, a sufficient amount of privacy
would be gained in client systems without all that many drawbacks.

---

From: Alain Durand <[email-masked]>
Date: Thu, 13 Jun 2002 09:53:19 -0700

> might be fine-tunable via some API.

Great! I implement a system level switch, a user turn it on to
enable 'privacy' on its browser and all the sudden rlogin & co stop 
working!
Support people are going to be very happy.

So, I _need_ to modify all the apps that operate better with stable 
addresses,
before I release such a switch in the general public.

	- Alain.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 14 Jun 2002 02:35:59 +0900

>>>>> On Thu, 13 Jun 2002 15:45:17 +0200, 
>>>>> Brian E Carpenter <[email-masked]> said:

> style apps on a host using temporary addresses will get all kinds of trouble

(though I'm not making an objection to what you're sayign) let me
clarify the issue (mostly for myself) once more.  We're perhaps mixing
up host issues and application issues.  In my understanding,

1. whether or not privacy is desired is a per-host (or
  per-administrator) issue, not a per-application issue; if the main
  user (likely the administrator) of a host really wants the privacy,
  the user wants the privacy apply to all applications on the host,
  even if some of the applications do not work well due to
  the characteristics of temporary addresses.
2. an application may not work well with temporary addresses.
3. there are only few privacy-conscious users, and there will few too
  in the near future.

So, the specification should be:

- the privacy extension draft should clearly say that it is optional
  to (support and) configure temporary addresses and that the default
  is not configuring temporary addresses.  the draft should also
  describe the troublesome cases with temporary addresses to
  communicate the risk of using them for administrators.
- the address selection draft should say *if temporary addresses are
  configured on the host* the temporary addresses should be preferred.
  It should also note that whether or not configuring temporary
  addresses are optional and the default is not configuring them.
- we'll not necessarily need a per-connection switch to change the
  logic of preferring temporary or public addresses, because if we
  want privacy or not is rather a per-host issue.  we MAY add such a
  knob, but it does not have to be a MUST.

Can this be a compromise for this issue?

					JINMEI, Tatuya

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Jun 2002 13:57:16 -0400

> And anyone who attempts to run server style apps on a host using temporary 
> addresses will get all kinds of trouble anyway.

I don't believe in the client-host vs. server-host distinction.
Yes, I realize that large-scape production "servers" usually need 
dedicated hardware.  But there are lots of things that want to answer 
to unsolicited input that don't run on dedicated hardware.
Most hosts are going to run a mixture of clients, servers, and p2p apps.

A per-host "use temporary addresses by default" bit is just another bit
that needs to be set to false so much of the time that you're far better
off never setting it to true.  The presence of this bit increases the
burden for both applications (which have to work regardless of this
bit setting) and sysadmins (for whom the bit creates one more obscure
failure mode that they need to worry about) without any measurable
benefit.

You'll get far better results by not having this bit, and having
apps that can use temporary addresses ask for them explicitly.   
The apps that can use those addresses only need to add or change
one line of code;  those that can't use them don't have to change 
at all, and sysadmins don't have to do anything.  

OTOH, if you do have this bit, some apps will incorporate their 
own address selection code (because there's no way to get the
system library to do what is needed), others won't, and for the sake 
of those others sysadmins will have to worry about whether that bit 
is set correctly.

This is one of those solutions that creates more problems than it solves.
Life will be simpler and things will work smoother without that bit.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Jun 2002 15:08:31 -0400

>   the characteristics of temporary addresses.

I disagree.  I think the user will want applications to work well
even if that means giving them public addresses, and that it's probably 
safe to assume that for applications that do work with private addresses, 
users won't mind if those apps use them.

> Can this be a compromise for this issue?

completely disagree.  there's every reason to let the app control
whether it gets temporary addresses, and no justification that I can
see for the per-host knob.

Keith

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 12 Jun 2002 21:40:50 +0900

JINMEI, Tatuya

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 12 Jun 2002 10:38:24 -0400

Hi All,

Margaret

---

From: Alain Durand <[email-masked]>
Date: Tue, 11 Jun 2002 16:28:11 -0700

- Alain.

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Jun 2002 19:37:27 -0700

for those who care, or can do anything about it, the mail loop is 
[email-masked]

> Received: from patan.sun.com ([192.18.98.43])
> 	by psg.com with esmtp (Exim 3.36 #1)
> 	id 17IgtV-00065s-00
> 	for [email-masked]; Thu, 13 Jun 2002 19:32:57 -0700
> Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
> 	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA18092;
> 	Thu, 13 Jun 2002 20:34:41 -0600 (MDT)
> Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
> 	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24163;
> 	Thu, 13 Jun 2002 19:32:51 -0700 (PDT)
> Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
> 	by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E2Vbk7004073;
> 	Thu, 13 Jun 2002 19:31:37 -0700 (PDT)
> Received: (from majordomo@localhost)
> 	by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E2Vbrl004072;
> 	Thu, 13 Jun 2002 19:31:37 -0700 (PDT)
> X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to [email-masked] using -f
> Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
> 	by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E2VWk7004065
> 	for <[email-masked]>; Thu, 13 Jun 2002 19:31:33 -0700 (PDT)
> Received: from nwkea-mail-2.sun.com ([192.18.42.14])
> 	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA23787
> 	for <[email-masked]>; Thu, 13 Jun 2002 19:31:38 -0700 (PDT)
-------------------------------------------------------------------------
> Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55])
> 	by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29600
> 	for <[email-masked]>; Thu, 13 Jun 2002 19:31:37 -0700 (PDT)
> Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC;
> 	 Thu, 13 Jun 2002 22:28:29 -0400
> Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail8.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
> 	 Tue, 11 Jun 2002 19:30:44 -0400
> Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
> 	by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BNUja2024332
> 	for <[email-masked]>; Tue, 11 Jun 2002 19:30:45 -0400 (EDT)
-------------------------------------------------------------------------
> Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
> 	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03976;
> 	Tue, 11 Jun 2002 16:29:53 -0700 (PDT)
> Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
> 	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12734;
> 	Tue, 11 Jun 2002 16:29:50 -0700 (PDT)
> Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
> 	by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNSLk7012210;
> 	Tue, 11 Jun 2002 16:28:22 -0700 (PDT)
> Received: (from majordomo@localhost)
> 	by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BNSLQY012209;
> 	Tue, 11 Jun 2002 16:28:21 -0700 (PDT)
> X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to [email-masked] using -f
> Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
> 	by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BNSHk7012202
> 	for <[email-masked]>; Tue, 11 Jun 2002 16:28:17 -0700 (PDT)
> Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34])
> 	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13979
> 	for <[email-masked]>; Tue, 11 Jun 2002 16:28:21 -0700 (PDT)
> Received: from esunmail ([129.147.58.122])
> 	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21177
> 	for <[email-masked]>; Tue, 11 Jun 2002 17:28:21 -0600 (MDT)
> Received: from xpa-fe2 (esunmail-ge0 [129.147.58.121])
>  by edgemail1.Central.Sun.COM
>  (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002))
>  with ESMTP id <[email-masked]> for
>  [email-masked]; Tue, 11 Jun 2002 17:28:20 -0600 (MDT)
> Received: from localhost ([66.93.78.11])
>  by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002))
>  with ESMTPSA id <[email-masked]> for [email-masked];
>  Tue, 11 Jun 2002 17:28:19 -0600 (MDT)
> In-reply-to: <[email-masked]>
> Message-id: <[email-masked]>
> MIME-version: 1.0
> X-Mailer: Apple Mail (2.482)
> Content-type: text/plain; charset=US-ASCII; format=flowed
> Content-transfer-encoding: 7BIT
> Sender: [email-masked]
> Precedence: bulk
> Date: Tue, 11 Jun 2002 16:28:11 -0700
> From: Alain Durand <[email-masked]>
> Subject: Re: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt
> To: Erik Nordmark <[email-masked]>
> Cc: Keith Moore <[email-masked]>, Thomas Narten <[email-masked]>,
>         [email-masked]

---

From: Alain Durand <[email-masked]>
Date: Tue, 11 Jun 2002 16:38:07 -0700

- Alain.

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Jun 2002 16:29:24 +0700

Date:        Thu, 13 Jun 2002 09:01:52 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | I've come to the opposite conclusion - that it's completely unreasonable 
  | to expect apps (or hosts) to assume the burdens of:

Keith, what matters is that unless the burdens (and their underlying
causes) are removed, someone has to do it.

Of course, everyone would prefer that it be someone else, and not "me"
but regardless of that, the burden remains, and has to be dealt with
somehow.

All the points you made about the problems that exist are valid, but
unfortunately we can't simply wish them away.  Like it or not, the nature
of the net has changed in the past 20 years, and "it was better 20
years ago" is not a useful thing to say.

It would be nice to go back in time, or perhaps better stated, to revert
the protocols to all work the way they did then - but the reasons that
things changed haven't gone away.   That's largely that the net got a lot
bigger, and what we had 20 years ago simply didn't scale well.

Now it doesn't actually matter whether it is the apps that deal with this,
or something else lower down the stack - in the API (library routines
or whatever), in the transport stacks, or even in the network layer, though
down that low seems to be too low - there's no enough idea about the needs
of the application down there, so bad choices would be made as often as
good ones.

But something has to deal with temporary addresses, as these days, *all*
(global) addresses are temporary, and trying to pretend otherwise is folly.
The only difference between one kind of temporary address and another is
the expected validity period.

Something has to cope with that, and as long as apps keep looking at addresses
at all, it seems that the apps have to be able to handle this complication.
Having the apps just keep on pretending that the world hasn't changed in the
past 20 years is doing a disservice to everyone.

kre

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Jun 2002 19:50:49 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Jun 2002 19:20:35 -0400

Keith